■ エコポイント申請画面が共用SSLサイト上にある件 「エコポイント」の情報システムがわずか３週間で完成した理由, 有賀貞一, NIKKEI NET, 2009年8月26日 こうした問題を解決するために、エコポイント事務局と関係省庁が選択したのが、米セールスフォース・ドットコムの基盤サービス「Force.com」だった。セールスフォースはこのForce.comを「クラウドコンピューティングプラットフォーム」と表現している。利用者はサーバーなどのインフラを持つことなく、この基盤上で独自のシステムを構築できる。 という記事を読んで、「エコポイント」のサイトを初めて訪れたのだが、これはまずい。 「エコポイント」公式サイトの運営者は、「グリーン家電エコポイント事務局」となっていて、プライバシーポリシーでも個人情報取扱責任者が「グリーン家電エコポイント事務局」として書かれている。しかし、国民の視点か

■ やはり退化していた日本のWeb開発者「ニコニコ動画×iPhone OS」の場合 一年前、「退化してゆく日本のWeb開発者」という題で、ケータイWebの技術面での蛸壺化について次のように書いた。 iPhoneに契約者固有ID送信機能が搭載される日 （略）こうして退化してゆくケータイWebが、日本のスタンダードとなってしまい、いつの日か、PC向けの普通のインターネットまで、単一IDの全サイト送信が必須になってしまうのではないかと危惧した。 （略）iPod touchでNAVITIMEを動かしてみたところ、下の図のようになった。 （略）契約者固有IDがないとどうやって会員登録システムを作ったらいいのかわからないんじゃないのか……というのはさすがに穿ち過ぎだと思いたい。NAVITIMEからソフトバンクモバイルに対して、契約者固有ID送信用プロキシサーバの用意を要請している……なんてことがなけれ

■ グーグル社の東京都への回答「元データは保管していない」は虚偽か 今年2月の東京都情報公開・個人情報保護審議会で、ストリートビューの問題が審議された際に、委員から、写真の顔などを自動認識や手動でボカシ修正するとき、修正前の元データはどうしているのかとの質問が出たが、これに対し、出席していたグーグル日本法人の藤田一夫ポリシーカウンセルと舟橋義人広報部長は、「元データは保管していない」と回答していた（2月4日の日記「東京都情報公開・個人情報保護審議会を傍聴してきた」参照）。このことは、審議会の公式議事録にも、以下のようにはっきりと記載されている。 ○藤原委員　質問ですけれども、先ほど表札や顔でも、顔がきちんと認識されたら修正します、ぼかしを入れる、周辺でもとおっしゃったのですけれども、文字どおり技術的な問題ですが、修正される前のデータは誰がどう保存しているのですか。つまり、（略） （中略）

■ Googleカレンダーでやってはいけないこと Googleカレンダーで公開前提ではないカレンダー（非公開を前提としたカレンダー）を作っている場合、以下の操作をしないよう注意する必要がある。 「設定」画面でカレンダーを選んだときに出てくる画面の「カレンダーの情報」タブのところの一番下に、「非公開URL:」という項目がある。そこには、「これはこのカレンダーの非公開 URL です。このカレンダーのすべての予定を他のユーザーに見せたい場合を除き、このアドレスを他のユーザーと共有しないでください。」という説明書きがあるが、何のことやらよくわからない。ここで、「XML」「ICAL」「HTML」と書かれた部分の「HTML」のところをクリックすると次の画面が出る。 ここで、表示されているURLのリンクをクリックしてはいけない。 マップとカレンダーでちぐはぐな設計 これがいったい何なのかは、「ヘルプ」に

■ SSLを要するモバイル環境でのパスワードマネージャの使い方に注意 Basic認証の話 この日記にSSLを導入した*1。基本的には自分用（編集時の安全を確保する）のもので、FirefoxとSafari（Mac OS版のSafari）からしか使えない*2*3。これにより、外出先の公衆無線LANからでも日記を編集できるようになった。 これまでは、自宅のコンピュータでしかログインしないようにして、http:// のままBasic認証を使っていた。パスワードが生のまま送信されるが、自宅の通信環境はまあ信頼できるので、（その先の通信路上で盗聴されるリスクがあるにしても）リスクは受容できると考えてきた。しかし、外出先で公衆無線LANを使うとなると、そのリスクは受容できない。6日の日記「公衆無線LANで使うと危ないiPod touchアプリに注意」にも書いたように、公衆無線LAN内の通信は簡単に傍受さ

■ 楽天CERTに対するブラウザの脆弱性修正を阻害しない意思確認 楽天は比較的早い時期からコンピュータセキュリティに真剣に取り組んできた希有な存在だと認識している。昨年には、企業内CSIRTを正式に組織し、組織名を「Rakuten-CERT」とした。*1 楽天、社内に「CSIRT」を設置, ITmediaエグゼクティブ, 2007年12月6日 「楽天ad4U」の「脆弱性を突いてブラウザの閲覧履歴を調べるという禁じ手」の問題（前回の日記参照）は、その手法自体が直接人々のプライバシーを侵害するか否かという問題ではない。実際、「楽天ad4U」について言えば、閲覧履歴の有無は参照するけれども履歴自体の送信はしないように作られており、開発元はこれを「プライバシー保護にも優れています」と宣伝している。 しかし、この問題の根本は、10月の日経の記事にも書いたように、この手法が広く使われるようになって、こ

■ 横浜市墓地条例に違反したグーグル社、市の削除要請にも真っ当に応じず 前回の日記で、横浜市日野公園墓地の事例について「1枚ではなくかなりの枚数が削除されているのだが、そのわりには全部を消しているわけではない。どういうことなのか」と書いたが、その点についてトラックバックを頂いた。 日野公園墓地の画像が一部削除されているのは横浜市が削除依頼をしたから, kABok, 2008年9月22日 なるほど、横浜市には「横浜市墓地及び霊堂に関する条例」という条例があり、グーグル株式会社の撮影行為はこの条例の第18条に違反しているのだという。 第18条 墓地又は霊堂において、次に掲げる行為をしようとする者は、規則で定めるところにより、市長の許可を受けなければならない。 （略） (2) 業として広告写真又は映画の撮影その他これらに類する行為をすること。 （略） 横浜市墓地及び霊堂に関する条例 このことにつ

■ 日弁連はストリートビュー問題に対して何か行動しないの？ 前回の日記に対して、弁護士の壇俊光氏よりご当人のブログ上にて以下のご批判を頂いた。 横浜市墓地条例とGSV, 壇弁護士の事務室, 2008年9月26日 高木浩光さんのところでこんな記事を拝見した。（略） 横浜市墓地条例の解釈としては（中略）刑事罰の予定されている条項の解釈は厳格になされなくてはならない。公道を墓地や霊堂に含むというのは無理である。 というわけで、道義的な問題や個人情報などの問題はあれどもGSVで公道から撮影する行為は条例に反しないというのが法律実務家としての結論である。 違法行為と決めつけた記述が見受けられるが、この問題は、謙虚に法律を学んだうえで論じる姿勢が望ましい。 9月26日時点での内容より http://danblog.cocolog-nifty.com/index/2008/09/gsv-a1b6.htm

■ ケータイWebはどうなるべきか （未完成、あとで書く。） 技術的なセキュリティの話 先月27日の日記では、契約者固有IDによる「簡単ログイン」の危うさについて書いた。このログイン認証の実装方式は、携帯電話キャリアの「IPアドレス帯域」情報に基づいて、キャリアのゲートウェイからのアクセスのみ許すことによって、成り立ち得るものと考えられている（ケータイWeb開発者らには）ようだが、そもそも、その「IPアドレス帯域」なるものの安全な配布方式が用意されておらず、ケータイWeb運営者に対するDNSポイゾニング攻撃等によって、当該サイトに致命的な成り済まし被害が出かねない危険を孕んだものであることを書いた。 仮に、「IPアドレス帯域」の配布が安全に行われるようになったとしても、他にもリスクがある。通信路上に能動的盗聴者が現れたときに、致命的な成り済まし被害が出る。たとえば、6月3日の日記「通信路上

■ 解放されたIPアドレスが別の人に割り当てられるまでの時間 昨日、某ISPから自宅に電話があった。セキュリティ係だそうだが、サポートセンター要員なのかマニュアル通りに話すだけで、こちらからの説明に対して、判断を要するような話になると会話が通じず、現場責任者の方と交代して頂いても埒が明かなかった。 今後の成り行きによっては、大変なことになる。 急遽調べておきたいのは次のことだ。 PPPoE接続のISPのように、ユーザのIPアドレスが頻繁に変わる回線において、IPアドレスの割当が解放されてから、同じアドレスが別のユーザに割り当てられるまでの時間。 たとえば、「48時間は割り当てられないようにされている」といった運用のISPがあるとか、「制限はなく、数分以内に別のユーザに割り当てられることもある」という運用が普通だとか、そういった事実関係を知りたい。

馬鹿じゃないのか。このようなセキュリティに関わる情報公開ページは https:// で提供する（閲覧者が望めば https:// でも閲覧できるようにする）のが当然なのに、携帯電話会社ともあろうものが、そろいもそろってこんな認識なのだ。 （8月2日追記: ソフトバンクモバイルについては「7月27日の日記に追記」参照のこと。） それをまた、ケータイWeb関係者の誰ひとり、疑問の声をあげていないことがまた、信じ難い。何の疑問も抱かずにこれをそのまま設定しているのだろう。 こんな状態では、ケータイWebの運営者は、DNSポイゾニング等で偽ページを閲覧させられても、気付かずに、偽アドレス入りの帯域表を信じてしまうだろう。 つまり、たとえば、example.jp というケータイサイトを運営している会社が example.co.jp であるときに、攻撃者は、example.co.jp のDNSサーバに