_ そして今日も走ったのです

って毎日書くことが、自分へのプレッシャーとなっているわけなので、ここに書かなくなったら、そっとやめてしまうような気がします。

_ re:Mint Julep「Webクリエイターになりたい人のWebサイト」

　仕事のことなのであんまり具体的には書きませんが、せめてmeta keywordを使いまくるくらいならば、ヘッダの意味と働きくらい理解して欲しいし、文字コードの指定程度のことはやって欲しいと思うのは我侭ですかね。

たぶん、仕事でwebを作っている関係の人で、にじむさんのような考えを持っている人は、ごくごく少数派でしょう。技術系の知識を持っている人間にとっては当たり前にそうするべきだと思っていることも、世の中一般では受け入れられていません。はっきり言って世の中では、“正しいhtml”なんて概念が存在することすら知られていないでしょうし、存在を知っていたところで実際上は気にする必要がないと考えている人がほとんどでしょう。

というのは、世の中のいわゆるネット視聴率が高いwebページをAnother HTML-lintなりW3C HTML Validation Serviceなりでチェックしてみるとわかります。webのメインストリートでは正しいhtmlなんてものはまったく省みられていませんし、世の中の人はそれが常識だと認識しているわけです。

実際、仕事で（一般向けの）webを作る場合においては正しいhtmlを気にするよりも、「ユーザーの閲覧に支障がないレベルでクライアントの要望を満たす」ということの方が重要です。心ある（とごくごく一部の人には思われる）web制作者ならばさらに「正しいhtmlで書く」という手間を厭わないかもしれませんが、その手間賃を請求することはできないでしょう。そんなことするくらいだったら、もっと安くしろと言われるのが関の山だと思います（というか、そんな見積もりをクライアントに出す気にもなれないだろうけど）。

正しいhtmlというものに慣れている人間にとっては、「正しいhtmlで書く」という手間は大したものではないと思うかもしれませんが、「正しくなくてもたいていのブラウザで表示できるように書く」方が簡単であることは事実です。また、仕事としてのweb作成というのは一般にデザイン性が重視されるため、現在発展途上にある正しいhtml的デザイン手法を守りながらいろいろなパターンのデザインを採用したwebページを作成するのは。非常に難しいこととなっています（過去のブラウザ互換性まで考えたら、業務レベルのまともなデザイン複数パターン＋正しいhtmlという組み合わせは不可能に近い）。

そういう現状において、ごく普通にweb制作を依頼した場合は、「正しくないhtmlだが、たいていのブラウザで普通に見える」ようなものが納品されることでしょう。また、web制作会社においては、web技術には詳しくないデザイナーが既製のツール（主にDreamweaverかGoLiveか）を使ってwebページを制作するというパターンが多く、その場合は制作したデザイナー自身その制作物の内容を知らない（＝ブラウザでどう見えるかだけを知っている）ことがほとんどだと思います。そういう人に「この制作物はhtml技術的に云々」と言ったところで、たぶんまったく話は伝わらないでしょう。

正しいhtmlを好む人は、世の中が基本的にそうなっている現状をふまえた上で、自分の手が届く範囲で正しいhtmlが増えていくように啓蒙活動をするか、あるいはひとまず現状は現状としてあきらめつつ、web系の技術が数世代代替わりする間にもうちょっと正しい技術が主流になることを期待するか、そのあたりの立場で妥協しておいた方が無難なような気がします。

イギリスの正式国称 The United Kingdom of Great Britain and Northern Ireland の Great Britain を 偉大なブリテン だと思っている人がいました。

知らなかったよー。てっきり「大日本帝国」と同じノリだと思っていた。「大○○」「小○○」って表現は日本ではなじまないからな。イギリスものの小説とかだとたまに出てくるけど。

_ 「コードの対戦――MicrosoftがP2Pゲームを用意」

　世界各国のプログラマーが向こう数週間，コード作成の腕前を競い合う――「インターネット経由で拡散し，同種のコードと対戦するソフト」の作成を目的としたイベントの中で。

自分でセルの行動パターンをプログラムできる、P2Pネットワークを舞台にしたライフゲームみたいな感じか。面白そうだな。.NETに手を出すかどうか決めかねていた（っつーか、仕事としてやらなきゃいけなくなるまで手を出さないつもりでいた）んだけど、こういう面白げなイベントをやるんだったら早速手を出してみよう。どうせC#は使ってみたかったし。本当にセキュリティホールがないかどうか、イベントモデルの外部に手を出しては消滅するクリーチャーもいろいろ作ってみよう。って、そんなことをやっている余裕はあるのかな？

_ 「ファイル圧縮技術の応用でテキストの筆者を推定」

辞書と照らし合わせた結果、語彙合致度が高いものは類似するものと見なすことができる、というごくごく当たり前の処理を行うためのツールとして、動的に辞書を生成するタイプの圧縮プログラムを流用することができます、というだけのことだよね。オリジナルの辞書作成＆合致度検索プログラムを組むよりも、利用者が多くて洗練されている汎用の圧縮ソフトを流用した方が、そういう用途での効率が良かったりするんだとしたら、ちょっと間抜けな気もする。

_ 書評リンクの話 2 (20:11)

書評リンクの話の続き。もうちょっと具体的な運用イメージを考えてみる。

リンク参加希望サイト側での参加イメージ。

• Web日記システムを使用している場合
  • Web日記システムを拡張して、汎用フォーマットのデータを出力できるようにしておく
    • オンラインで動的生成するタイプならば、CGIなどでいつでも動的に必要項目を汎用フォーマット化できるようにする
    • オフラインで動的生成するタイプならば、Web日記上の該当項目を汎用フォーマット化したデータも別途オンラインにアップロードしておき、該当項目そばにリンクを置くことによって、誰でもダウンロードできるようにしておく
      • 新規記事の汎用フォーマットURLを集約サイトに通知する
        • 簡単にQueryStringで渡してもいいし、複数記事ぶんをまとめてPOSTしてもいいし
        • 通知タイミングは、新規記事作成タイミングでもいいし、あとで適当にでもいい
        • あらかじめ集約サイト側にメンバー登録しておき、そのサイトのRSS URLを登録しておけば、集約サイト側から新規記事の存在確認をしに来る
  • 汎用フォーマットに対応できない場合は、Web日記システムを使用していない場合と同様
• Web日記システムを使用していない場合
  • 自力で汎用フォーマットデータを作って、それをWeb上にアップロードしておく
  • 集約サイトにいって、必要情報を投稿するフォームに各項目を入力する

集約サイト側の運用イメージ。

• メンバー登録されているサイトに対して、
  • RSSなどから最新の記事一覧を取得。記事一覧中に未取得の書評記事を見つけた場合、その記事に汎用フォーマットデータを取得
  • 各サイトの新規記事の汎用フォーマットURLの通知を受け取る。サーバーからその実体を取りに行く（オンタイムもしくはある程度まとめてから定期的に）
  • 各サイトから直接ポストされた汎用フォーマットデータを受け取る
  • サイト内に用意した投稿フォームからさまざまな形式での投稿を受け付ける

集約サイト側は、書誌データと書評データは分けて管理した方がいいだろうな。書誌データの方はAmazon Webサービスみたいなものが日本でも始まることを期待しつつ、基本的にはみんなで使い回せるイメージで。逆に集約サイトが書評サイトに書誌データを配信できるようにすることも考えた方がよさそう。

そうなると書評データの方は、ISBN＋各サイト独自の部分だけを集約サイト側に渡せばよくなる。書評の内容をどこまで集約サイト側に渡すかは、各サイト運営者の意志によっていろいろだろうな。少しも渡さないパターンもあれば、さわりの部分だけ渡すところもあれば、全文渡しちゃうところもあるだろう。どうせなら、サイトをもたない人が集約サイトにだけ書評を投稿できる仕組みももった方がいいんだろうな。

あと、集約するしたときの面白さのために、書評データには評価ランクみたいなわかりやすい項目もオプションとして用意した方がいいだろう。そうすると、評価ランクの平均とかいろいろ面白い見せ方ができるだろうし。

_ また休み (22:21)

なんかすごい勢いで有給が減っていくな。下の子がようやくうんこが固くなってきたかと思ったら、今度は熱を出したんで一回休み。昨日もオクサンが休んでいるんだけどね。っつーか、先月今月で2人合わせて2週間くらい休んだんじゃないか。

_ アップル直でしか受け付けないのね (22:21)

まだ買って一ヶ月だし、もしかしたら初期不良交換してくれるかなーと、買ったジャスコに持っていったら、アップル製品は交換の場合もすべてアップル直でしか受け付けないと言われた。しょうがないんでWebから申し込み。バッテリーの挙動も怪しいんで、できれば交換になってくれるといいんだけどなー。

_ キャッシュ機能 (22:39)

URL関連のメモについては、本人のみが閲覧できるキャッシュ機能を追加しました。自分のメモを[編集]すると、キャッシュへのリンクが表示されます。

キャッシュはメモを作成した時点の内容になります。また、キャッシュの期限は今のところ30日にしていますが、もっと短くなるかもしれません。この機能に関する仕様はばりばり変更されたり、あるいは機能自体がなくなったりするかもしれません。

_ 徳保さんのはてなXSS関連の認識の間違い

あるいは「ブログサービスの XSS 脆弱性対策はいらない その3」。

徳保さんはセキュリティ関係の知識が足りていないんで、きちんと勉強するまではXSSなどのセキュリティ関係の用語を使わないで語った方がいい。というか誤解を広げめられると迷惑だ。

「d.hatena.ne.jp 以下のコンテンツでスクリプトの悪用はありません、なぜならはてなが特別に許可したスクリプト以外は使用が制限されているからです」という安心感を売り物にしようとしている

はてなはCookieによるユーザー認証を利用しており、ユーザーに自由なJavaScriptを許すと、認証情報の盗難・悪用が可能になるから、ユーザーのJavaScript利用を禁止している。それは「安心感を売り物にしている」というレベルではなく、ユーザー認証を利用したサービスを提供しているサービス提供者の最低限の義務であり、それを行わずに被害がでた場合は、サービス提供者が責任を負わされるだろう。

その提供しているサービス内容に付随する義務としてのセキュリティ対策の話と、認証の仕組みを換えれば（ユーザビリティや根本的なサービスのデザインを換えれば）、ユーザーがJavaScriptを利用できるサービスは実現可能だ、というのような、提供するサービス内容自体を変更可能であるという議論とは次元が違う話である。

私がこのサイトにはてなアカウントにログインしているユーザ向けのトラップを仕掛けることは可能です。みなさんは、ただ私を信じているだけでしょう。

現在はたまたまCSSXSSというIEの致命的なセキュリティの欠陥が修正されないまま放置されており、それによって本来サービス外部からは成功しないはずの攻撃が成功してしまう。しかし、これはCSSXSSという非常にたちの悪い欠陥が放置されていることに原因があり、それがなければサービス外部からCSRFによって攻撃することはできないはずだ。

また、外部に攻撃コードが置かれた場合と、サービス内部に攻撃コードが置かれた場合とでは、サービス提供者にかかる責任の重さは圧倒的に違う。特にサービス内部（認証Cookieが読める場所）に攻撃コードが仕掛けられた場合は、認証情報の盗難というリスクがあり、外部からの攻撃とは攻撃の質がまったく異なる。

利用する楽観的なユーザーが実際に被害に遭う前にどう思うかは関係なく、なんらかの攻撃が成功した場合に、サービス提供者にかかる責任はどのくらい重いのか、が対策するべきかどうかの指標だろう。認証Cookieが読める場所でユーザーのJavaScript利用を許可していた場合、既知の攻撃に対して対策をしていなかったことになり、サービス提供者の責任は重くなる。

ちなみに、はてながCSSXSS対策をするべきかどうかについては、議論が分かれる部分だが、私は以前メモで書いたとおり、

CSSXSSはサーバー側のコーディングで対応できるレベルを超えた穴なんで、ブラウザ（IE）側で対処するべきだと思う。CSSXSS対策まで含めてWebアプリを作るとなると、安全を考えれば設計からやり直しになっちゃうし。

と考えている。CSSXSSは（もしそれへの対策が必須と言われた場合）既存のWebセキュリティに関する常識を覆すほど、大きな影響が出る問題だ。

「はてなダイアリーにはいいユーザも悪いユーザもいます。悪いユーザは退会させます」これでいいと思う。

全然よくない。というか、徳保さんははまちやさんの仕掛けるわかりやすいデモンストレーションのようなものが、XSSの代表例だと思っているのではないか？　あれはあくまでもわかりやすいデモンストレーションであって、本来のXSSによる攻撃の危険性はああいうものにはない。

悪質な（本来警戒すべき）XSSによる攻撃は、認証情報を盗み、それを利用して認証情報で保護されたはずの情報を盗み、あるいは認証情報で保護されたはずの機能を利用し、それでいて利用者にはそのようなことが起こっていることをまったく気づかせない、というものだ。そのような攻撃はそう簡単には発覚せず、発覚しない間に被害は広がっていく。そのような攻撃でも、（攻撃が見つかったら）その仕掛けたユーザーを排除すればそれで対策は十分？

文章が修正されました

徳保さんの「ブログサービスの XSS 脆弱性対策はいらない」は「ブログサービスの設計思想とユーザ側の制約」というタイトルに代わり、XSSなどのセキュリティ用語をほとんど使わない内容に変更されました。変更後の文章表現ではもともとの文章にあった問題（セキュリティ関連の用語の使い方の間違いやその意味あいに対する誤解）がなくなっており、私が当初挙げた問題点は一掃されていると思います。

_ テニス朝練

昨日ガットを張り替えたラケットでの初打ち。

すげー反動がある。最初の数球はかなり手首に来た。けど、それはそれで、今までみたいに手応えなく飛びすぎたりすることなく、球を打ったフィードバックがきちんと手に返ってくる感じで、悪くない。

あとガットを硬くしたぶん全体的に飛ばないようにはなったけど、ちゃんと打っているぶんには飛ばなすぎるということもなく、今まで一番いやだった、軽く当てただけで飛びすぎるということがなくなり、とてもコントロールしやすくなった。

ただ、今まで身につけてきた飛びすぎるのを抑えるような打ち方が反射的に出てしまうんで、それを矯正しないと無駄に低く狙いすぎてネットにかかる率があがりそうだ。あと、芯を食わないとぼてぼてのひどい当たりになるんで、ミスヒットでもごまかすことができなくなった。

ボレーも飛ばなくなってしまうかなーと思いきや、そんなこともなかった。窮屈なボレーなんかだと、今まではぼよよーんって感じで高く浮いてしまうことが多かったんだけど、高く弾まなくなってコントロールしやすくなった。前後方向の跳ね返りの強さは特に変わっていない気がする。

サーブはコントロールは良くなったけど、スピードがなくなった感じ。今までガットの跳ね返りでスピードを出していたんだろうなー。同じ感じで当ててもあまり速いサーブにならない。けど、伸びがなくなったぶん、ネットの比較的高いところを通しても入ってくれるんで、余裕ができた。スピードの方は、ひとまずサーブが安定したら、少しずつ手首と肘を使うようにして出していこう。

といった感じで、今回のガット交換は機能的には成功だったけど、問題はRQS11HGのさわやかな白＋青のカラーリングに、ポリプラズマ118のオレンジ色が全然あわないってところか。同じような機能のガットで、白とか青とかのやつはないかのー。