顎≠The Stig

理系と文系の壁

最近話題の岡崎図書館問題についてちょっとだけコメント。

まあ一開発者として「MDISが糞」ということは大前提としてあるわけですが、その上でこのへんの記事を読むと、感情的な部分での憤りと法律の現場の乖離ってなかなか埋まらないんだなぁ、という感触が。

ざっとTogetterのまとめと講演者のブログを幾つか読んだだけなので外してるかもしれませんが、法律家の立場から「過去の判例に従えば逮捕は妥当」という理屈が導かれるのも元法学部の学生としては理解できますし、一方で「あの程度で逮捕されていては何もシステムが作れない」という現場の叫びもわかります。全体的な雰囲気としては、なんか昔のWinny事件で金子氏が逮捕された直後のノリに近いものがあります。

個人的な独断ですが、よく理系の方々が「技術の問題は技術で解決すべきで、警察や法律なんかの介入は余計」と主張されるのに対し、文系の人間はその「理系的な考え方」自体に対し得体のしれない恐怖を感じている、という壁があって、今回の件もその恐怖心が故に「問題を解決するためには手段を選んでいられない」として警察への被害届→逮捕につながったのかなぁ、なんて考えます。昔ライター時代に取材したRFID絡みのシンポジウムでもなんか似たような対立がありましたし。

誤解を恐れずに端的にまとめると

○理系的な考え方：「便利に使える＝絶対的な善、技術の勝利」
○文系的な考え方：「あえて不便さを選ぶ自由だってあるべき」「"便利"な機能の押し付けこそ悪」

てな感じですかねぇ。ちょっと方向性は違いますが、古くはネット上でモヒカン族論争なんてのもありましたし。

私も実際会社の業務の一環として、求人サイト相手に似たようなクローラ作ってますし、業務で接続するシステムの中には逆に「クローラを使うこと前提のシステム」（XMLで新着情報が配信されるので、それをクロール・parseした上で未取得のデータがあったらそれを取りに行く形式）もあったりしますから、正直「明日は我が身」「この程度で逮捕されたくない」という恐怖はあります。ただ一方で「実際クローラのせいでシステム止まってるんだから、外形的には犯罪の構成要件満たすし、逮捕されても仕方ないよね」と言われてしまうと反論できん自分もいたりして、なかなか悩ましいです。
こーゆーのは結局ある程度類似の事例が貯まったところで社会的合意みたいなものが成立して、ある一定のところに結論が自然と収束していくのを待つしかないのかなぁ、という気がしてます。

まあ岡崎の一件の場合は、問題が全国的に広まって本質的な問題点を有志の方がさんざん分かりやすい形でまとめられているのにもかかわらず、当事者の図書館職員やMDISなどがそれに対し聞く耳を持たない（ように見える）という点が最大の問題だと個人的には思いますが。

IEでオートコンプリートが効く条件

今新宿で開発中の案件で、とある事情でWebサーバから外部のSMTPサーバ経由でメールを送信できる機能を実装することになったのだが、今時なのでSMTP AUTHで認証を行わなければならない。
ところがこれまた特殊事情で「SMTPサーバのID・パスワードはWebサーバ側には保存しないで、ユーザにその都度入力させる」ことになり、さすがにユーザの利便性を考えて「ブラウザ側のオートコンプリート機能でアカウント情報を保存できるようにしよう」という方針が固まったのだが、いざ開発にかかると「どういう条件でオートコンプリート機能が効く（＝ブラウザにID・パスワードが保存される）のか」という情報がなかなか見つからない。

ネット界隈にはいろいろガセネタも多いので、この際「Internet ExplorerでオートコンプリートでID・パスワードが保存される条件」についてまとめてみた。
＃今回の案件はターゲットブラウザがIEのみなので。他のブラウザは知らん。

○条件
基本的には以下の2つの条件を満たせば、ブラウザ側にID・パスワードが保存される。

・対象となるformの中に、<input type="text">と<input type="password">のテキストボックスが1つずつ存在する。
・ユーザが<input type="submit">もしくは<input type="image">のボタンを押すことでformがsubmitされる。ただしその際onClick等のイベントハンドラでfalseを返してはいけない。

基本的にJavaScriptでformをsubmitした場合は×。Ajaxだと<input type="button">などを使って、onClickイベントからJavaScriptでformをsubmitしたりすることがよくあるけど、その場合はオートコンプリートが効かない。
あと<input type="text">が2つ以上あるようなformも×。

詳しくは
・Internet Explorer のオートコンプリートの動作について（マイクロソフト）
・autocomplete ができなくなる理由
あたりを読むこと。

○ガセネタ
以下の情報は全てガセネタ（IE8で検証済み）。

・そもそもSSLではオートコンプリートが効かない
・HTTPヘッダで「Pragma: no-cache」や「Cache-Control: no-cache」が指定されているとオートコンプリートが効かない

他にもガセネタはあると思うが、とりあえず気になったのはこの2つ。後者はひょっとしたらIE6ではありえない話でもないが（IE6はSSL接続時のバグが結構あるので）、前者はIE6の時もふつーにオートコンプリートが使えてたし。

携帯cookieの真の問題

えー、おなじみ高木浩光先生がクッキー食えないのはドコモだけなんて記事で「携帯でもユーザ認証のセッション管理にCookieを使うべき」と書かれてますが、元高木番記者・現プログラマとして一言。

実は携帯のユーザ認証の真の問題は「Cookieが食えない」ことではなく、「SSL環境と非SSL環境でCookieが変わってしまう」ことなのですよ。

高木先生が参照している元記事（携帯Webのクッキー利用について調べてみたメモ【update】）でも書かれてますが、まずauは
・SSL接続時：端末にCookieを保存
・非SSL接続時：EZサーバ（ゲートウェイ）にCookieを保存
という構成になっているため、SSL接続状態で認証を済ませても非SSLに戻った瞬間にCookieが変わってしまう（＝セッションが引き継がれない）ため、非認証状態に戻ってしまいます。

またSoftBankは、通常SSL接続時にはURLを勝手に「https://secure.softbank.ne.jp/～」という形に書き換えて、半強制的にソフトバンクのSSLゲートウェイを通る接続にしてしまいますが、このためSSL時に発行したCookieは「secure.softbank.ne.jp」の中でしか有効になりません（おそらく端末まで届いてないと思われる）。このため非SSLに戻った瞬間に同様にCookieが変わってしまいます。

＃ドコモのCookie対応端末の挙動がどうなるかは、i-mode 2.0対応端末が手元にないのでまだ調べてません。誰か検証可能な方よろしく。
＃e-mobileは細かいところは未検証ですが、確か以前試した記憶では、SSL・非SSLを問わず同じCookieが使えたような…（うろ覚え）。

これを防ぐには、結局
○ユーザ認証後の全ての処理をSSL上で行う
○セッションIDをURLの引数として引き回す
の2択を迫られることになり、現実的に現在の携帯電話では全てをSSL上で行うのはまだまだ非現実的なのと（性能的にはAll SSLでも行けると思うんですが、いちいち「SSLで接続します」等のダイアログが出てしまうため、あまりサイト提供者側の受けがよろしくない）、ドコモの旧機種がCookieが使えないことの関係から、後者を選択せざるを得なくなるのが現状なわけです。

とりあえずau・SoftBankの両社には、今からでも遅くないので
○Cookieは全て端末側で管理
○SSL接続時に余計なURLの書き換えを行わない
の2つを行って欲しいところ。

JASRAC定例会見

えー、昨日毎年恒例の「JASRAC賞」の発表があったそうで、それに伴って定例の記者会見があったとのこと。
んで発表資料を読んでみたら、いろいろ興味深い内容が出てたので、かいつまんでご紹介。

「著作物利用料収入が前年比3.1%減」ってのはあちこちのニュースで紹介されてますが、細かく内訳を見ていくと、目についたのは以下のような点。

○ついに「ビデオグラム」からの収入が「オーディオディスク」からの収入を上回る
確かJASRAC的には「DVD付きアルバム」がビデオグラムに含まれるはずなのでその影響なんでしょうが、それにしてもここまではっきり映像シフトが進むとは。ビデオグラムは対前年比で99.1%とほぼ横ばいなのに対し、オーディオディスクは同82.6%で大幅減ですからねぇ。

○ダウンロード販売は順調な伸び
着メロ（前年比70.9%）・着うた’（同79.4%）が大幅減なのに対し、ダウンロード販売は118.2%でプラス。あと動画ストリーム系も前年比143.8%（まあ絶対額が少ないですが）と伸びているので、こっちもそのうち動画配信が伸びてくるのかなぁ、と。

○出版不況の影響？
ここんとこ雑誌の休刊・廃刊が相次いでますが、その影響もあってか出版等の収入が前年比89.5%と減少。

ただ結局のところ、昨年度の収入源の原因って結局「ヒット曲がなかった」点に尽きるのではないかと。
なんせJASRAC賞の金・銀・銅賞（よーするに著作物利用料収入の上位3曲）に、当該年度に発売されたシングル曲が一曲も入ってません。これってたぶんJASRAC賞史上初めてのはず。この点からも「去年は一般に広く知られるヒット曲が皆無だった」ことは裏付けられるでしょう。
「ヒット曲が出ない」原因を探るのは私の専門外なのでやめときますが、ヒット曲があればカラオケとかで歌う人も増えるはずなのに、カラオケ分配額ベスト10にも去年発売された曲が一曲もないという異常事態ですからねぇ。
これがたまたまなのか、今の音楽業界が進んでいる方向が間違っているのか、どちらなのかはもう少し様子をみる必要があるでしょうが。

光ルータより速い技術

なんか28日の事業仕分けで、NICTの光ルータ研究のところで「もし仮に、明日光よりももっと速い、光を使わなくても速くて、熱効率も良くてですね、そうしたものがどっかからポンと出て来た時に、これは続けられるんですか？」という質問があったことが話題になってるみたいですが（Geekなページなどを参照）、一応技術的には「光ルータよりも速い技術」の研究はあることはあるんですよね。

昔ライター時代に毎コミの取材で「光通信最先端を垣間見る - 究極の光スイッチ「光パケットスイッチ」の実現ももうすぐ?」なんて記事書いたことあるわけですが、この記事の中でも「光ルータを超える『量子通信』」的な話が出てます。（しかし、まさか5年近くも経ってこの記事引っ張り出すことになるとは予想できんわ）
もし仕分け人の方々が、この手の「量子通信」の開発状況を知ってて「光ルータよりも量子ルータに力入れた方がいいんじゃないの？」というつもりで前記の発言をしてたんだとしたら、これはものすごい話ですが…。確かにどっちもNICT所管の研究だし、NICT内の予算の組み換えで済む話だからなぁ。（もちろんNICT内部で得する人・割を食う人が出てくるわけですが、それはまた別の話）

つかNICT側も、次々世代技術としての量子ルータ技術の話も「こーゆーのがあって一応研究もしてますが。それとも光ルータを捨ててそっちに予算を振れと？それならそれでこちらも好都合ですが」ぐらい切り返せばよかったのに。まあ技術的に実用化一歩手前まで来てる光ルータと、まだまだ基礎研究の域を出ない量子ルータでは、NICT的には事業成果を出しやすい光ルータに力を入れたいんでしょうから、「量子ルータにシフトしろ」と言われたらそれはそれで困るんでしょうが。