最新 追記

高木浩光@自宅の日記

目次 はじめに 連絡先:blog@takagi-hiromitsu.jp
訪問者数 本日: 849   昨日: 2524

2008年08月02日

Yahoo!ケータイ初回利用時のユーザID通知に関する告知

ソフトバンクモバイルのケータイWeb(「Yahoo!ケータイ」と呼ぶらしい)では、https:// ページへのリンクが妙な動作をするらしいというのが以前から気になっていたのだが、これは自分で調べるしかないと決意し、ソフトバンクモバイルの回線を契約し携帯電話を購入した。

早速「Y!」ボタンを押してみたところ。以下のページが現れた。最初に一回だけ表示される告知だと思われる。

図1: Yahoo!ケータイ初回利用時の告知

SoftBankをご利用いただきありがとうございます。Yahoo!ケータイをご利用いただくにあたって必要な、お客様情報(ユーザID, ローミング情報)の通知設定を行います。

現在の情報: 未登録

ユーザIDの通知とは?
(必ずお読みください)
通知する

通知しない

ここで「ユーザID通知とは?(必ずお読みください)」のリンク先を見に行くと、図2の説明が現れた。

図2: ソフトバンクモバイルによる「ユーザID通知とは」の説明

ユーザID通知とは、ソフトバンクネットワークにて保存されているお客様情報(ユーザID及びローミング情報)を自動的に情報提供者側に通知する機能です。お客様情報を通知することによって、Yahoo!ケータイでインターネット上のコンテンツを利用する際に、情報提供者がお客様情報を使った様々なサービスを提供する事が可能になります。

どんな事ができるようになるの?

有料サービスを使うことができたり、お客様個々の嗜好に応じたサービスを情報提供者より受けることが可能になります。

ユーザID通知登録をしないとどうなるの?

有料サービスが使えなくなったり、一部の情報提供者(サイト)のサービスが使えなくなることがあります。

コンテンツパートナー等にお客様のユーザID、及びローミング情報が通知されたことに起因する紛争については、当社は一切の責任を負いかねますので、あらかじめご了承ください。

ユーザID通知に同意いただいた場合、暗証番号を入力することなく有料情報の登録および解除が行えますので、あらかじめご了承ください。

iモードや、EZweb、EMnetでは、このような重要事項告知を目にした記憶がない。ソフトバンクモバイルだけが、こうしてユーザに告知している。これはどのように評価され得るだろうか。

「ユーザに知らせているだけ良い態度だ」と評価する人もいるだろう。しかし、この告知文が言わんとすることの要点は、「コンテンツパートナー等にお客様のユーザID(略)が通知されたことに起因する紛争については、当社は一切の責任を負いかねます」という部分だろう。ユーザが自ら「通知する」を選択した以上、ソフトバンクモバイル社に責任はないとする態度だ。

これは、ユーザID通知に何らかの危険性が存在することを、ソフトバンクモバイル社自身が認識していることの現れであろう。しかし、危険性が存在することをこの告知文は何ら示していない。

「どんな事ができるようになるの?」と「ユーザID通知登録をしないとどうなるの?」の説明を読めば、「通知する」に設定する以外に選択肢がないと感じるのが普通だろう。賢い人ならば、「通知する以外にないのに、どうしてこんな告知が出るんだろう?」とか、「当社は一切の責任を負いかねます」とわざわざ書くのはどうしてなんだろう?」と、何かおかしいことに気付くかもしれないが、普通の人、ましてや知的弱者の方々は、「何コレ、通知するしかないじゃん」と「通知する」を選択してしまうだろう。

このような、危険性の存在を認識しながら、危険性の説明をすることなく、都合の良いことだけ説明して、ユーザに「通知する」を選択させるような方法で、はたして、「ユーザの同意を得た」「当社に責任はない」という主張が通るものだろうか?

なお、英語版の告知では「I agree to allow my User ID and Roaming Information to be transmitted.」(図3)と書かれている。日本語版では「同意する」という文にはなっていないのに、英語版ではそのように書かれている。

図3: 告知の英語版

なお、取扱説明書にも、ユーザIDを通知した場合の危険性に関する説明はない。

図4: 取扱説明書

ちなみに、ユーザIDを「通知しない」に設定すると、「オンライン料金案内」さえ使えなくなる(図5)。

図5: ユーザIDを「通知しない」に設定すると「オンライン料金案内」さえ使えない

これでは事実上の強制ではないか。

ソフトバンクモバイルでは暗証番号入力なしで課金されてしまう

上の図2の画面にある、「暗証番号を入力することなく有料情報の登録(略)が行えます」という文が気になった。

iモードでもEZwebでも、私がこれまでに使ってきた経験からすると、携帯電話の利用料金と一緒に請求されるタイプの有料サービスの課金システムでは、料金が発生する際には必ず暗証番号の入力を必要とするようになっていたが、もしかして、ソフトバンクモバイルでは、そうでないのだろうか?

実際に試してみた。画面の流れは図6の通りで、「OK」ボタンを押したら即座に課金されてしまった。

図6: 暗証番号を入れていないのに、ボタンを押しただけで課金さされてしまった様子

これにはゾッとした。改めてこうやって画面の流れを見てみると、ワンクリック不当請求のサイトと同じ画面構成に見えてくる。「こりゃ、ワンクリック詐欺が流行るのも無理ないわ」と思った。

このことに関して、2004年4月24日の日記「モバイルコマースが架空請求詐欺を助長する」に書いていたのを思い出した。

そもそも、架空請求詐欺などというものがどうしてこれほどまでに増えてしまったのか。手口自体は昔からあったと聞くが、詳細は知らない。ここ数年で増えた要因はいろいろあるだろうが、人々が騙されやすくなってきたことが最大の要因ではなかろうか。

架空請求では、「有料サイトの利用料金」が未納だという理由で請求をすることが多い。5年くらい前であれば、「有料サイト」などと言っても、一般の人たちには意味すら理解できなかっただろう。今では、国民の大半が携帯電話を持ち、多くの人たちが着メロダウンロードなどの有料サービスを利用している。

5年前に架空請求詐欺をしようとすれば、何の利用料金を請求するだろうか。「電気代が未納です」という請求に騙される人はそういないだろうし、「指輪のご購入代金が未納です」と言われても、買っていない人は買っていないことをはっきりと認識できるだろう。

それが、ここ数年で情報課金サービスの利用が消費者に広く普及し、また、サービスの提供が、一部の有名大手事業者に限らず、有象無象の事業者によっても行われるという、「自由なネットビジネス社会」が訪れたことによって、買ったのか買っていないのかを消費者がはっきり認識しない世の中になってしまった。「有料サイトの利用料金」と言われれば、「もしかすると利用したかもしれない」と思ってしまうわけだ。

インターネットでの情報課金や購買契約は、携帯電話に限らず、古くからパソコンでも行われてきた。しかし、パソコンユーザが架空請求に騙されるということはあまりなかったように思う。

パソコンの場合、購買契約にあたって、自らの意思でクレジットカード番号を送信するか、物を買う場合は送付先の住所を送信することになる。何かを入力するという積極的な意思が働かない限り契約が成立しないというのが普通だ。

それに対して携帯電話のサービスはどうか。ボタンを押すだけである。情報課金では、暗証番号を入れるだけですぐに利用できる。支払いは電話会社が代行してくれるので、カード番号や住所などを自ら入れることはない。自分が誰であるかを入力する必要はない。電話番号の入力はしないし、氏名やユーザ名の入力もしない。これはパソコンでは実現できないことである。携帯電話でこそ可能なことである。

なぜそれが可能かというと、携帯電話会社からサービス提供者のサーバに対して、アクセス者のサブスクライバIDが暗黙的に送信されているからだ。iモードの場合では、サブスクライバIDは「公式サイト」のみに送信されている。

こうした「利便性」は、携帯電話だからこそ求められるものであろう。契約にあたってできるだけ文字を打ち込みたくないからだ。

しかし、そういう、寝転びながらできるような契約行為に消費者が慣らされてしまった結果、架空請求詐欺に騙されやすい人々を大量に生み出してしまったのではないだろうか。

モバイルコマースが架空請求詐欺を助長する, 2004年4月24日の日記

このときは「暗証番号を入れるだけですぐに利用できる」と書いていたが、ソフトバンクモバイルでは、さらに、その暗証番号入力さえ省略してしまっている。正規サイトでこういう使い方に慣らされていく消費者は、どんどん騙されやすくなっていく。

カード番号の入力や暗証番号の入力という、ユーザの積極的な行動が要求されるのが売買契約において当然に必要とされるのが常識として確立した社会であれば、消費者は、「カード番号を入れたら課金される」「暗証番号を入れたら課金される」と認識できるはずだ。それらの情報は他人に教えてはならないものという認識とちょうど対応するからだ。

ケータイWebはそうした常識まで取っ払う。簡単操作で契約させることばかりを優先し、知的弱者から搾取していく。

出鱈目なURLで運営されているケータイWebの実態

上の図6の「dwango.jp」会員登録の画面で、「この画面のURLはどうなっているのだろう?」と思い、URLを確認してみた。

私の買った機種「816SH」では、Webブラウザの「メニュー」に「URL入力」という機能があり、これを選択することで、現在のURLを表示できるようである。

図7は、「dwango.jp」の会員登録画面のURLを確認した様子である。

図7: 「dwango.jp」の会員登録画面はニウエ島のドメイン上にある

これには目が点になった。「dwango.jp」というくらいだから「dwango.jp」ドメインにあるのかと思いきや、よりによって「b.nu」というニウエ島のドメインにあった。

ドワンゴスタッフの悪趣味ぶりにも辟易するが、誰もこれを気にしていない様子であることが恐ろしい。

私はこのときは、Yahoo!ケータイのトップ画面から公式メニューらしきものを辿って「dwango.jp」のサイトを訪れたので、まあ、本物サイトだろうと思われるところだが、最近は検索でたどり着いて使うというのも普通だろう。検索でたどり着いた「dwango.jp」のサイトで、誰もURLを確認せずに使っているということだろう。(Yahoo!検索からたどり着いた「dwango.jp」のトップ画面のURLも http://v-cd.b.nu//jskycmi/...... と、ニウエ島ドメインにある。)

「ケータイWebでもアドレスバーを表示するべきである」ことは、これまでに何度となく口を酸っぱくして各方面に言ってきたが、コンテンツ業者側にこういう実態があるせいで、キャリアも下手にアドレス表示するわけにもいかないのかもしれない。そもそもコンテンツ業者がこういう安易なドメインを使ってしまうようになったのは、ケータイWebにアドレスバーがなかったから(コンテンツ業者も気にしない)なわけで、愚かなデッドロック状態だ。

ところで、上の図7で私の画面のURLを一部墨塗りしているのは、ここに認証キーとして働いてるかのように見える文字列が含まれていて、公開するのは危なそうだったからだ。

このURLの中にある「jskycmi」という文字列が気になった。他のサイトでもしばしばこの文字列がURLに含まれているようだ。「jskycmi」でググってみたところ、大丈夫なのかと心配になるようなページがたくさんヒットした。

どうやら、Yahoo!ケータイの利用者が、自分のブラウザに表示されたURLを、掲示板などに書き込んでしまっているようだ。WASForumコンファレンス2008で耳にした話(ユーザがURLを貼る)は、こういうことなのだろう。

検索結果のひとつに、「サーバ装置」(特開2006-67323)」というボーダフォン株式会社が出願人の特許情報がヒットした。

【課題】サービスを提供する過程において表示されたURL情報を元にした不正なアクセスを防止する。

【解決手段】有料コンテンツの取得要求に先立つ移動端末の有料コンテンツの購入同意に対するレスポンスにユーザチェックフラグ、Jskycmi生成時刻、UIDをセットする。有料コンテンツの取得要求のHTTPリクエストを受けた際に、ユーザチェックフラグがONか判定し、ONと判定された際に、Jskycmi生成時刻が有効期限内か判定すると共に、UIDが一致するか判定する。この判定結果がOKの場合に有料コンテンツの取得要求のHTTPリクエストをCPに送出して、有料コンテンツを取得する。

「サーバ装置」, 特願2004−248605, 特開2006-67323

これは興味深い。そのうち読んでみたい。

7月27日の日記に追記

7月27日の日記の内容に対して、以前にお目にかかったことのあるソフトバンクモバイル(旧ジェイフォン)の方からメールで指摘を頂いた。

7月27日の日記では、携帯電話事業者各社が「IPアドレス帯域」と称して公表している情報について、https:// での閲覧方法を用意しておらず危険である旨を示したが、ソフトバンクモバイルについては、今年4月に開発者向け情報のページをリニューアルしたのだそうで、以下のURLに移転しており、そちらでは https:// での閲覧も可能だとのこと*1

また、これらのページにおいて、注意書きの表現を改めているとのこと。それ以上の説明は受けていないので定かではないが、おそらく、以下の部分のことだと思う。

PCサイトブラウザにて利用するIPアドレス帯域からは、Xシリーズ端末(Internet Explorer)からもアクセスされます。

ゲートウェイのIPアドレス帯域について, ソフトバンクモバイル

Internet ExplorerからのゲートウェイIPアドレス帯域からはXシリーズ以外の端末(PCサイトブラウザ対応機)からもアクセスされます。

XシリーズにおけるIPアドレス帯域について, ソフトバンクモバイル

いまいち意味がわかりにくい。こんな説明で、巷のケータイWeb開発者らが理解できるのか?

これは、つまり、Internet ExplorerからアクセスするときのIPアドレスは、「PCサイトブラウザにて利用するIPアドレス帯域」または「XシリーズにおけるIPアドレス帯域」となるはずで「Yahoo!ケータイにて利用するIPアドレス帯域」とはならない(だから、ユーザIDを「認証」に使う場合は、「Yahoo!ケータイにて利用するIPアドレス帯域」にアクセス制限すればよい)と言いたいのだろうか? 私は知らない。

「本IPアドレス帯域以外からソフトバンク携帯電話のアクセスがない事を保証するものではありません。」という注意書きをしていることの真意についても、そのメールでご指摘頂いたが、そういうことは公式に公表してもらいたいことであって、私が代弁することじゃないので、ここでは割愛する。

*1 それならば、古いページは削除するべきだろう。


2008年08月03日

ケータイWebはどうなるべきか

(未完成、あとで書く。)

技術的なセキュリティの話

先月27日の日記では、契約者固有IDによる「簡単ログイン」の危うさについて書いた。このログイン認証の実装方式は、携帯電話キャリアの「IPアドレス帯域」情報に基づいて、キャリアのゲートウェイからのアクセスのみ許すことによって、成り立ち得るものと考えられている(ケータイWeb開発者らには)ようだが、そもそも、その「IPアドレス帯域」なるものの安全な配布方式が用意されておらず、ケータイWeb運営者に対するDNSポイゾニング攻撃等によって、当該サイトに致命的な成り済まし被害が出かねない危険を孕んだものであることを書いた。

仮に、「IPアドレス帯域」の配布が安全に行われるようになったとしても、他にもリスクがある。通信路上に能動的盗聴者が現れたときに、致命的な成り済まし被害が出る。たとえば、6月3日の日記「通信路上の改竄攻撃発生に、Webサイト運営者が説明責任を負うのか?」で触れたように、データセンター内でARP spoofing攻撃が発生した場合、通信路上の攻撃者は、契約者固有IDをヘッダに入れてアクセスすることで、全てのユーザに成り済ましてログインできてしまう。*1

「ARP spoofingの脅威なんてあり得ない」という考え方もあるだろう。安価なレンタルサーバサービスのように、悪意ある者とLANを同居し得る状況で発生するものだから、安価でないレンタルサービスを使っていれば、その脅威は十分に小さいとする考え方だ。キャリアからデータセンターまでの通信回線上に盗聴者が入り込む危険性については、「電気通信事業者の回線しか通らないはずだから、電気通信事業者の取扱中に係る通信の秘密は法律によって十分に守られているのだ」とみなすわけだ。

昔の話(5年くらい前だろうか)になるが、「iモードの公式サイトは安全な場所に置かれているんですよね?」とどなたかに尋ねた記憶がある。というのは、ある大手銀行のケータイバンキングのサービスがSSLを使用していないのを見て、きっと、サーバは物理的に安全な場所に置かれているのだろうと思ったからだ。たとえば、NTTドコモのiモードセンター内に、公式サイト用のレンタルサーバが置かれていて、盗聴者の入る余地がないように設計されているとか、サーバは外にあるが、iモードセンターとそのサーバはVPNで接続されているとか、そういうふうになっているんじゃないかと思った。

しかし、それに対するお返事は、「ぜんぜんそんなことはない」というものだったように記憶している。その後も、何度か、「公式サイトは安全だと思っている人がいるようだけど、ぜんぜんそんなことはない」という発言を、掲示板等で何度か見た記憶がある。

たしかに、今や「公式サイト」は膨大な数にのぼっており、それらが全部、安全な場所に置かれている、あるいは安全な方法で接続されているとは考え難い。ただ、さすがに銀行等の一部の大手サイトは、安全な場所に設置されているか、安全な方法で接続されているに違いないと思っている。

携帯電話会社の技術者(あるいは研究者)の方々も、IPアドレス帯域制限と契約者固有IDによるログイン方式が危険なものであることは認識されていると私は理解している。

このことについては、2003年8月24日の日記でも触れている。モバイルITフォーラムという、携帯電話会社と一部のコンテンツ業者、SI事業者らが集まった団体があり、この団体が、安全で簡単に利用できる認証方式を提唱していた。

この研究成果は、NTTドコモの「FirstPass」、KDDIの「Security Pass」として実用化に至っている。*2

これは、個人でも簡単に利用できるように設計されたものであるが、ケータイサイト側で対応しているところを見たことがない*3。おそらく、企業が社員用の用いている事例はあるのだろうと思うが、コンシューマー向けにはぜんぜん普及していないと認識している。

これら「FirstPass」や「Security Pass」は、SSLのクライアント認証を用いてログインを実現するもので、通信路上の盗聴者の存在を仮定する場合に対して、ログインが安全なものとなる方式である。

これは、利便性と安全性を両立させようとした試みで、これが成功していないのは残念である。何が原因で普及していないのかが究明されるべきだと思う。

このように、ケータイWebにおいて、契約者固有IDによる「簡単ログイン」などという方式が不適切なものであることは、中心的な関係者の間では十分に認識されていることであり、その解決方法は、既に示されているし、実用化もされている。

ただし、2003年8月24日の日記にも書いていたように、「FirstPass」や「Security Pass」でも、プライバシー上の問題が残る。どのサイトに行っても同じクライアント証明書を使うようになってしまうと、クライアント証明書のcommon name(氏名等ではないが、ユニークなID文字列)でアクセス者を同定できるようになるわけで、「日本のインターネットが終了する日」で書いたのと類似の懸念がある*4。私としては、このままこれが大規模に普及してしまうのは避けて欲しいと思っているので、悩ましいところだ。

また、これらが普及しない原因として、「SSLを用いること自体が重くて嫌だ」と考えるケータイサイト運営者も少なくないことがあるのではないかと思うが、SSLを使わないのを許すのを前提とした場合において、リスクをPCと同程度に引き下げるためには、cookieをサポートすれば良いだけの話である。NTTドコモはcookieをサポートするべきだ。

発信者情報開示請求のためのID送信の話

日本のインターネットが終了する日」で書いたように、ケータイWeb(iモード、EZweb、Yahoo!ケータイ、EMnet)では、キャリアのゲートウェイが匿名プロキシサーバ化してしまっているため、ゲートウェイでIDを付けて送信していないと、悪質な書き込み等があったときに、発信者を特定する際に困難が生じてしまうという問題があった。

しかし、これは、「日本のインターネットが終了する日」で書いたように、契約者固有IDである必要はない。1日から1週間ほどで別のIDに変化する番号を送信するようにしておけば十分である。発信者情報開示請求する際には、そのIDとその時刻のペアで指定して、携帯電話会社に請求することになる。

これは、現在のIPv4におけるPCのインターネットの環境と同じ仕組みであり、また、IPv6で一時アドレスが用いられたときとも同様である。

問題は、携帯電話会社がそのようなシステムを構築することを、コスト負担上、嫌がるのではないかという点である。今年3月末から、NTTドコモが「iモードID」の全サイト自動送信を開始したのは、複合的な理由からだったと思うが、おそらく、急いで対応する必要があったために、安易な仕様を選択せざるを得なかったのではないかと思う。

楠正憲氏は、私の「日本のインターネットが終了する日」に対して、「日本のネットは終わらないよ」と題したブログエントリで、次のように意見を表明されている。

サイトを超えて一意のIDを利用することの危険性は、1990年代末から国際的に広く共有されているのだから、携帯キャリアは一刻も早く個体識別番号等の提供形態を見直すべきだ。具体的には、

  • 携帯サイトに個人情報を書き込むことの危険性を広く国民に啓発する (可及的速やかに)
  • 個体識別番号等の無条件送信をドコモが勝手サイトに対して以前提供していたオプトインに改め、クッキーやサイト毎に異なる個体識別番号等の代替手段を早急に提供する (1年以内に実施)
  • ネットに展開可能なオープンかつ安全な通信プラットフォームを早急に整備して移行を促し、個体識別番号等の提供を廃止する (3年以内に実施)

といった安全対策を取ることが考えられる。

日本のネットは終わらないよ, 雑種路線でいこう, 2008年7月22日

実際に廃止できるかどうかはともかく、廃止せざるを得なくなる時の到来を想定して、携帯電話会社は、代替手段を今から準備しておくべきだと思う。

つまり、現在の契約者固有IDに加えて、発信者開示請求用の別のID(1日から1週間で変化するもの)もヘッダに載せて送信するようにするべきだと思う。

システムのコストがどれだけになるかわからないが、DHCPサーバがやっているような仕組みを、数千万ユーザに対して処理することになると思われる。技術的にそれが実現性が低いのであれば、何らかの代替方式を検討できないものだろうか。

なお、イーモバイルについては、「emb」で接続した場合(EMnetを契約しない、あるいは使わない場合の接続)には、通常のPCのインターネットと同様に、電話機にIPアドレスが割り当てられてのアクセスとなるので、発信者情報開示請求の観点からは、そのままIPアドレスを用いればよいのであるから、IDをヘッダに含めて送信する必要性は全くない。*5

コンテンツ課金のための利便性の話

(未稿。あとで書く。通信プラットフォーム研究会のことについて書く。)

青少年ネット規制対応のための悪質ユーザ排斥の話

(未稿。あとで書く。)

今後私は何をするべきか

(未稿。あとで書く。関係者の中に入って行動するべきか、それとも外野から批評し続ける方が得策か。)

*1 もっとも、この脅威は、SSLを使用していない全てのサイトにおいて元々存在するリスクではある。たとえ、セッションIDを用いたログイン機能実装がなされていたとしても、通信路上の能動的盗聴者は、ログイン中のユーザのセッションIDを盗聴して、それを持ちいて成り済ましアクセス(セッションハイジャック)することはできるし、ユーザのパスワード入力時にパスワードを盗聴して、それを用いて成り済ましログインすることができてしまう。しかし、この場合は、攻撃者の攻撃中にログインした人だけが被害者となるのに対し、契約者固有IDによる「簡単ログイン」方式の場合には、それ以外の全ユーザが即座に成り済まし被害に遭うという点で、リスクの甚大さが異なる。

*2 あれ? ソフトバンクモバイルは?

*3 今調べたところ、イーバンク銀行が採用しているようだ。

*4 ただし、違いとして、「FirstPass」や「Security Pass」ではおそらく、アクセス時には、証明書送信時に確認ボタンを押す、あるいはPINコードの入力する等の、ユーザの動作を必要とするようになっていると思われる(未確認)。したがって、現在のケータイWebの契約者固有IDの全サイト自動送信とは違い、ユーザが警戒していれば、悪意あるサイトに証明書IDを送信してしまうことを避けられるかもしれない。それでも、この方式が普及すると、どこのサイトに行っても確認が出るようになってくるから、ユーザは、悪意あるサイトでもボタンを押すようになってしまう(サイトを表示する前に確認が現れるため、サイトの内容を確認できない)と考えられ、プライバシーの問題は、現在の契約者固有IDと同様に生じると思う。これを解決するには、複数のクライアント証明書を使うようにすればよいわけで、それをユーザが使い分けられるかという問題はあるかもしれないが、ユーザインターフェイスを工夫することで解決する方法はあるように思う。

*5 その意味で、イーモバイルが、なぜ契約者固有ID送信機能付きのEMnetをわざわざ導入したのかが謎であり、NAVITIMEのような安直なアプリケーション構築手法を温存するためではないかと危惧している。(青少年ネット規制対応のための悪質ユーザ排斥の目的で導入された可能性もあるが。)


2008年08月04日

続・出鱈目なURLで運営されているケータイWebの実態

2日の日記「 出鱈目なURLで運営されているケータイWebの実態 」では、「dwango.jp」のサイトが「b.nu」というドメイン上にあることを示したが、他にも、以下のようなケースもあった。

Yahoo!ケータイのトップ画面から、検索機能で「日本航空」を検索し、トップに出てきた「日本航空」のサイトを訪れて、URLを確認してみたところ、図1のとおり、数値形式のIPアドレスが現れた。

これはひどい。

「172.22.101.1」とプライベートアドレスが使用されているので、セキュリティ上の目的もあってか、おそらくソフトバンクモバイルのセンター内か、VPNで接続されたどこかにサーバが設置されているのであろう。

しかし、こんな形式では、ユーザに本物サイトであることの説明がつかないし、SSLサーバ証明書の取得とかもできないんではないだろうか。EV SSLの取得も無理だろう。

iモードの場合では、「nttdocomo.ne.jp」ドメインの下にホスト名を付けて、そういったサーバが設置されているのを見た記憶がある。イントラネットのような運用であるわけだが、それなら、ユーザに本物サイトであることの説明になるし、証明書もとれるのではないか。

数値形式のIPアドレスなのに誰も問題にしていないことが恐ろしい。

私が普段使用しているEZwebでは、URLの確認方法が存在せず、多くのサイトで確認不可能にされている(2007年12月8日の日記「EZwebブラウザの「お気に入り登録」は偽サイトを見分ける手段にならない」参照)ため、これまでこういった事実を確認できなかったが、EZwebも実態は似たようなものか、もっと酷いのではないだろうか。

こういったことから直していかないと、アドレスバーの表示もするわけにいかないのだと思われる。

続・Yahoo!ケータイ初回利用時のユーザID通知に関する告知

2日の日記「Yahoo!ケータイ初回利用時のユーザID通知に関する告知」の件について、ソフトバンクモバイルのサポートセンターに電話して聞いてみた。電話に出たのは、三十歳くらいと感じる女性オペレータ。


ソ: 大変お待たせいたしました。操作担当○○でございます。

私: もしもし、高木と申します。

ソ: はい。お願いします。

私: あのー、「Y!」ボタンを押したんですけども、そうしたところ、何か登録をというふうな説明が出たんですね、これの意味を教えて頂きたいのですが、

ソ: ヤフーのYのボタンを押すとということですね。ご利用の機種をちなみに、何になりますでしょうか。

私: 816SHです。

ソ: 816のSH。登録をと、いきなりトップに出てきたんですかねー?

私: ユーザID通知設定、

ソ: あ、ユーザIDの、はい。かしこまりました。ユーザIDの通知設定なんですけれどもー、えーまず、Yahoo!のYのボタンを押して頂いてー、

私: えー、押したところ、これがいきなり出たんですけども、

ソ: あ、ではそれを、「通知する」とか「通知しない」ていうのを選べるようになってますのでー、そこで「通知する」を選んで頂ければ、と思います。

私: えー、「通知する」を選ぶしかないんですか?

ソ: や、「通知しない」でも大丈夫なんです、メールアドレスの変更とかができないですね。

私: 料金照会とかもできるんですか?

ソ: あ、できないですね。

私: 料金照会もできないんですか?

ソ: そうですねえ。ユーザIDが必要になってくるものが結構ありますので、「通知する」にしておかれた方がいいと思います。

私: えー、じゃあなんでこれ選べるようになっているんですか?

ソ: そーですねー、とくにあのー、まあー、そうでうすね…、必要ないものもありますのでえ、

私: え?

ソ: それはお客様におまかせします。

私: あの、

ソ: 説明を読んで頂いて。

私: ええ、説明を読んでも意味がわからかったのでお尋ねしているん…

ソ: そうですねー、電話番号以外の、あのーお客様を特定する番号の通知になります。

私: はい。でー、通知するにしないと使えないんですよね?

ソ: ものもありますね、メールアドレスの変更とか、

私: 料金照会も

ソ: そうですね。

私: 基本的な機能ですよね?電話の。

ソ: さようでございますね。

私: これ、通知しないにしたら使い物にならないということですか?

ソ: んー、さようでございますねー。

私: 最初から「通知する」にしておけばよいのでは?

ソ: いや、そういったメールアドレスの変更とか、まあ、そういう料金照会使われないお客様もいらっしゃいますので。

私: でもべつに、「通知する」にしておけばいいですよね?

ソ: ええ、

私: なんでこれ、

ソ: それはまあ、お客様におまかせします。

私: 選ぶようになっているかを、聞いているんですよー。つまり何か、通知しないにしないとまずいことがあるからこうしるんですかね?

ソ: とくにそれはないですけれども。

私: ない。

ソ: あのー、説明を読んで頂ければいいと思います。はい。

私: 説明を読んでもわからないから電話しているんですよね。

ソ: んー、そうですねー、こちらでご案内できるのは、先ほど申し上げた、電話番号以外にお客様を特定する番号の通知、ということになります。

私: じゃあ、そうなんでしょうけども、これ、それだったら、常に通知するで最初からやればいいのに、こうやってね

ソ: そういったご要望があったことはー、担当部署にご報告させて頂きますので。

私: ……。いやいや、ですからね。「通知にする」にすると私にとって何か不利益なことがー、あるから本人に選ばせるようにしているんじゃないですか? だったら、どういう不利益があるのかちゃんと説明してもらわないとー、わからないと思いまして。

ソ: 少々お待ちいただけますか。

私: はい。

(音楽)

ソ: お待たせいたしました。

私: はい。

ソ: とくに「通知する」にしてもー、あのー、デメリットはございませんので。メールアドレスの変更とか、料金照会をされない方の、ために「通知しない」というふうに選べるようになってます。

私: えーと、じゃあなんで最初っから、「通知する」にしておけば

ソ: (大きな声で)そういったー、機種もございます。もともとデフォルトでー、

私: デフォルト?

ソ: 通知するに、はい。なってるのもあります。あのー、はじめの設定が「通知する」にいきなりなってる機種もあります。

私: でもー、じゃあー、新しい機種では最初にこれをユーザに選ばせるようにしたわけですからー、なにかそうしないといけない理由があったんじゃないかと思

ソ: そういったものを今確認したところではございませんでした。

私: ない?

ソ: はい。

私: あのー、……………。

ソ: こちらでご案内できるのは以上となりますので。

私: でもー、………。なんか不自然じゃないですかねー。

ソ: 確認したところでは先ほど申し上げたことが以上です。申し訳ございませんが。

私: あのー、…………。

ソ: (ブツ。プー、プー、プー、プー、プー、プー)


一方的に切られて終わった。


2008年08月10日

通信プラットフォーム研究会 傍聴録 (Google社の発言あり)

通信プラットフォーム研究会が一般公開されているのを最近になって知り、先週7日に開かれた第6回会合を傍聴してきたので、討議の様子を書き留めておく。

それまでの会合の議事録を事前に読んで行ったのだが、これほど大きな会合(たくさんの人に発言権があり、たくさんの人が傍聴するもの)とは予期していなかった。構成員だけに発言権があると思っていた(各回のヒアリング対象が「オブザーバー」として発言することもあると理解していた)が、そうではなく、「オブザーバー」(傍聴者のことではない)全員に発言権がある形式だった。「オブザーバー」の今回の出席者は、配布資料の座席表によると以下の通り。

ヤフー、モバイル・コンテンツ・フォーラム事務局、マイクロソフト、東日本旅客道、日本インターネットプロバイダー協会、テレコムサービス協会、情報通信ネットワーク産業協会、ジェーシービー、KDDI、グーグル、エヌ・ティ・ティ・ドコモ、エヌ・ティ・ティ・コミュニケーションズ、ウィルコム、インデックス、イー・モバイル、ACCESS

会合では冒頭、事務局から、「通信プラットフォーム研究会におけるこれまでの議論」と「通信プラットフォーム研究会における検討の方向性(第一次案)」について、配布資料に沿った説明があった。配布資料はそのうち研究会Webサイトで公開されると思われるので割愛する。

そしてすぐに自由討議に入った。以下は、私がとったメモから発言内容をまとめたものであり、発言者の趣旨を正確に再現できていない部分があるかもしれない。


マイクロソフト(楠正憲オブザーバー)
9ページ目のIDについて、支配管理できることが非常に重要である。そのための社会的ルールとして3点ご検討いただきたい。

1つは、先日の迷惑メール法改正の議論にもあったように、オプトインか、オプトアウトかという問題がある。弊社の事例で言えば、Windowsがハングアップした際に、クラッシュダンプをマイクロソフトに送信して、問題を起こしたコンポーネントを特定し、早くバグを修正するのに役立てているが、ダンプの中には文書データなど非常にセンシティブな情報も入っているので、これについては必ずユーザに、目的を説明し約束して、送ってもよいかの事前承諾をとるようにしており、これはオプトインという形である。一方、最近日本でも始まったGoogleストリートビュー、素晴らしいサービスだが、住所を打ち込むだけで車のナンバーがわかるというのはどうかという話があって、「問題があるものは消します」という対応をとられている。これはオプトアウトという形である。多くのユーザは約款等は読んでいないので、デフォルトがどうであるかが極めて重要であり、どうあるべきか一意に決まるものではないが、直感に反することがないようにするべき。

2点目は、事前規制か事後の問題解決かということ。個人情報の利用方法にはいろいろあり、様々な脅威が想定されるが、問題が起こってから手当てするのか、それとも問題が合理的に予期できる場合は先回りして検討するかは非常に重要な点である。

3点目は、国が研究会で決めていくのが良いのか、民間で決めていくのが良いのかという問題がある。EUは米国と違って非常にプライバシーに厳しいが、米国が緩いかというと、米国ではクラスアクションや消費者団体が積極的に活動していて、民民の手続きで事業者の規律が維持されている。たとえば、弊社の事例で言えば、2002年にWindows Media Player 9をリリースしたときに、個人のIDをデフォルトで送る設定になっていて、意図せずに送られるのは非常に問題があると、送らないようにと消費者団体から抗議されて、標準設定では送らないように設定を変更したことがあった。日本でも同様に、端末識別子の問題については携帯電話の方で議論されているところで、日本はセキュリティに関して甘い考えであり、このまま世界に出て行くのはリスクがある。

以上3点についてご検討いただきたい。

会津泉構成員(財団法人ハイパーネットワーク社会研究所副所長)
今の楠さんのご意見におっかけになるが、このこれまでの議論のまとめは、良くできているが、問題点について明確に切り出していない。ポジティブなことばかり、連携強化すると良いことばかり起きるというトーンが強すぎる。予測される問題点や予測されない問題点について深めておいた方が良いのではないか。今の3点のご指摘もそうだが、連携が多様化していくと、一時的には良いが、金融プレイヤーが入ってきて、クレジットカード会社は数社しかなく新規参入はないわけで、利便性が高まると集中化していき、そこのプラットフォームが強くなり、独立にやりたいという新規参入が難しくなるのではないか。

プライバシーマネージメントの問題もそうだが、IDが一旦流出した場合の被害は、連携していればしているほど被害が大きくなりかねない。異なる事業者に直接氏名情報が行かなければ、ID情報だけが行っていれば、被害はそのレベルでとどまるかもしれないが、連携のやり方次第では、アンダーグラウンドのところへ流れかねない。これまででも個人情報の流出は必ずあるわけで、利便性が高いところは不正に入手すれば非常に大きな利益になる。国際的な組織犯罪は今系統的にやろうとしており、一番弱いところで流れると、他ががんばっていても、その場合の被害は困ったことになる。特に、自分が変えたくないアイデンティティとリンクしたものが流れてしまったら非常につらい。最小限にする予防策や、事故が起きないという前提ではなく、起きたときに何が起きて、どんなペナルティを与えて、再発防止ができるかということも考えておく必要がある。

楠氏は国がどこまでやるのかということをおっしゃったが、同時に、事業者だけで連携をやって、利用者が選択してくださいというだけで本当にいいのか。プライバシーについて、国際的に言うと、利用者団体の方が先に取り組んでいる例があり、アメリカやイギリスなどのIDマネジメントの政策を議論するときは必ずそういうグループも入れた議論をしている。そういう点を検討して頂きたい。

また、地域に限定したプレイヤーが使いたいという場合にはたしてできるのか。決済について、非営利的な、NGOとかが寄付をといった場合がある。営利的な利用だけがIDを使うのではない。事業者だけでルールを決めることがよいのかは検討する必要がある。

柳川範之構成員(東京大学大学院経済学研究科准教授)
今のとかなり関係するが、連携強化という言葉、何が連携強化なのか明確でない。連携強化の必要性はわるが、どうやって連携させるのかがポイントであり、連携のさせ方について細かく見ていく必要がある。

また、トラブルにどう対処していくのか。

もうひとつは、いろいろなところと連携させることがうまくいくのかという懸念があり、他産業とのつながり、影響がどう及んでくるのか、ビジネス的にも、規制の適用がどうなるかという問題がある。プラットフォームのレイヤだけでなく、通信レイヤーとアプリケーションレイヤーとがうまく活性化するのか、考えておく必要がある。つまり、うまくつながるのかという問題もあるし、設備投資のインセンティブがあるかというのは簡単にいく話ではない。上と下のレイヤのインセンティブの拡大につながるような仕組みを考えないといけない。 


佐藤治正座長(甲南大学経済学部教授)
参考になる過去の事例はないか。ネットワークは変わっているので過去の例が参考になるとは限らないが、ダイヤルQ2はあんまり参考にならないのではないか。他のケースで、活性化するのか、プレイヤーが増えるのか、過去の例で参考になるのものを集めて欲しい。

モバイル・コンテンツ・フォーラム事務局(岸原孝昌オブザーバー)
今のIDの情報管理のことについて。当然連携すれば危険性が高まるところもあると思うが、システムを厳密に考えないといけない。IDは単なる識別情報、つまり、ユニーク性を担保するものなのか、認証まで入って個人情報を含むのかによって、流出したときの危険性は大きく違う。システムを作るときはIDはユニーク性を担保するものにする。システム上の不備による問題点というよりは、個人情報管理をきちんとやるかどうかという問題である。そこをきちんとわけて議論して頂きたい。

たとえば、SNSでハンドルネームが一つしかつくれませんよという仕組みは、単なる携帯電話のユーザIDと同じようなものであり、そういうものが公開されただけのときの管理の話とは、違うのではないか。危険性を考える上では、IDと単に片付けるのではなく、IDが何を持っているかの危険性を議論して頂きたい。

マイクロソフト(楠正憲オブザーバー)
今ご指摘の、IDが個人情報にあたるのか、端末のユニーク性を保障するものにすぎないのかという点は、弊社も90年代後半から苦労してきた問題である。90年代末の段階で、ユニーク性しかないものであっても、サイトを超えて名寄せができてしまうものについては、本人が意図しない問題が起こってしまうとし、Internet Explorerのバージョン3のころには許されていたクロスサイトのcookieは、その後のバージョンでセキュリティ対策でオフにしている。

また、インテルCPUの識別子についてもBIOS設定でデフォルトでオフになっている。IPv6でも同様の議論があり、temporary addressというものがあるが、これは、使い難くてプログラムを書くのが難しくなるため、弊社の中でも開発の人たちからこの仕様を捨てられないかと異論もあったが、ユニークなIDであっても、サイトを超えて同じものが流通することはプライバシー上問題があるというのが、国際的な通念になっていると理解している。

河村真紀子構成員(主婦連合会副常任委員)
オプトイン、オプトアウトのことについて。どうすればビジネスが活性化するかという点からだけでなく、いろいろなことが自覚的に行われるようにしてほしい。デフォルトを完全に閉じた状態から始まって、ひとつひとつ自覚的にわかる人がそれをといて連携なりオープンにしていくのがよい。

さきほど、個人情報の管理をしっかりすればという意見があったが、しっかりすれば保証できるとはまったく思っていない。クレジットカード番号と有効期限、これらだけからは個人が特定できないということで、番号の羅列だけだからと個人情報保護法の対象になっていない。

一消費者として言えば、全ての情報がひとつに集まるような、そのような仕組みは全く望まない。見たWebサイトの情報や、買い物履歴とか、全部一緒にどこかにあるというのは絶対に望まない。自分が信頼したサイトだけで残る、たとえば何を買ったとか、というのは良い。それを自覚的にやるのはいい。しかし、きちんとやると言われただけでどこかにたくさんの情報が集まって、複数の事業者間に渡って行くというのは、全く望まない。

望まないなら閉じれるようにしてほしい。むしろ、閉じられた状態から始まるようにして欲しい。一般の、とくに携帯電話は子供からお年寄りまで持つわけなのだから、よくわからない人をおいてけぼりにしないで頂きたい。ビジネスとしてマイナスであっても、利便性が低まっている状態をデフォルトにして頂きたい。

競争でという話がたくさん出てくるが、競争さえされれば消費者が良いものを選ぶという言い方がされるが、事業者にとっての公平性ばかりが言われていて、消費者から見て公正な競争が行われるためには、消費者が自覚的に選択できるよう、情報が理解できる形である必要がある。それで選択したら良いものが残るのであれば良い。そのためには、わかりやすいことが重要である。どのような危険性があるかの情報とセットであるべきであり、それをわかった上で自覚的に選ぶようになって初めて、公正な競争となる。

そういう視点がなければ、ここの論理だけで進められるのは非常に危険である。

岡村久道構成員(弁護士 国立情報学研究所客員教授)
岸原氏のおっしゃることもわかるが、元々ここの話は、課金や認証を中心にプラットフォームが組み立てられているので、個人識別性があるのが前提となるはずだ。IDポータビリティについても、複数の認証基盤の連携という前提なので、識別性があるのがデフォルト状態となるものとして議論しないと、違うのではないか。どこまでがプライバシーか、どこまでが個人情報保護法で大丈夫なのかというのは、別途議論を深めることが必要だが、ここでは、識別性ありきが通常状態となることが強調されるべき。

また、会津先生の話ともからむが、捨て去る権利というのがなければ、万が一漏洩した場合に大変危ない。オプトインが望ましいという話があったが、契約書に判を押すのと違って、ネット上で同意するときは、ほとんど読まずに瞬間的に「はい」を押してしまうものだ。そうしないと先に進めないので。ネット上でオプトインをやるにしても、インフォームドコンセントのように十分な説明の上での同意ができないと、ひとつのIDでくくるというのは別のトラブルが起きる原因となるだろう。

太田清久構成員(株式会社SOZO工房取締役パートナー)
いろんな技術の革新があって、今のIDの認証がどれだけ危ないのか十分に考慮しないと話が進まない。先日OpenIDの話があったが、認証、セキュリティについては日進月歩であり、今どこまできているのか、事務局で状況を示して欲しい。このままでは議論が進まない。消費者から見ても満足いくものになっているんではないかとか、そこを確かめてから議論しないと永遠に終わらない。

事務局(谷脇康彦情報通信政策課長)
OpenIDが出たが、他にもLiberty Allianceとか認証の仕組みがある。必要だと思うので次回用意する。

マイクロソフト(楠正憲オブザーバー)
プライバシーの問題は、環境規制と似ている。これは産業界にとって悪い話ではない。弊社は、Windows 2000でファイアウォール機能を搭載していたがオフにしていたため、2003年に100万台以上のコンピュータがウイルスに感染してしまい、その反省から、secure by default、つまり、最初から閉じておくように変えていった。最初からそうしていれば多大なコストをかけずに済んだ。

国際競争力という話になってくるので、日本がこれから市場に出す技術は当然海外に胸を張って出せるものにすることが重要である。ハードルがやや高くても、研究開発投資を促して、中長期的に産業競争力になるという考え方もある。

佐藤治正座長(甲南大学経済学部教授)
携帯電話なくした人。どこにも連絡がとれない。非常に困る。IDがポータブルになり、全部動くようになると、盗まれたとき、なくしたとき、ちゃんと消費者の利益を確保するのかという観点からも検討頂きたい。ひとり一つのIDではなく、複数持つとか、問題があったら捨てて新しいものにできるという枠組みを当然考えなければならない。

エヌ・ティ・ティ・コミュニケーションズ(オブザーバー 発言者未確認)
事業者同士でインターフェイスを作るときに、エスクローの要素を入れるとか、第三者だとわかるが各プレイヤーは自分のことしかわからないとか、消費者からすれば消せるとか、そういった、そういう議論をお願いしたい。ビジネス事業者間からどうかという話というより、ここでは社会的な議論をしてほしい。

(発言者未確認)
資料にあるライフログの件について。一か所に集めるタイプと、分散させる方法がある。議論を進めていくとどうしても公的な一か所に集めてという話になりがちである。それだけは避けたい。

IDと個人情報とをはっきりと切り分けることが重要。IDをひきまわすと情報をひっぱり出せるとあるが、必ずしもそれが必要ないタイプもあるので、レベル感も含めて検討する必要がある。IDと個人情報を一括りにすると面倒なことになる。適用すべき範囲をしっかりしていく必要がある。たとえば、OpenIDのようなものは、セキュアな課金体系には向かないといった議論がある。レベル感に分けて考える必要がある。

ヤフー(別所直哉オブザーバー)
実態にあわせて考えて欲しい。OpenIDで実際に利用されているのは非常に限られたものであり、単に認証されたというだけになっている。サービスによってはそれだけで十分なものもあるし、公的な目的での認証にも使えると言う人もいるが、インターネットでの認証の利用を発展させるには、やはり公的な認証も必要だと考える。その際に、必要となるのが存在の証明であるとか年齢の確認だけで、それ以外の情報はいらないということもある。

個人情報の取扱いについては、どういう情報をどこに配備するかの問題。個人情報といってもセンシティブなものとそうでないものがある。氏名だって社会的に認知されなければ識別情報としての機能を果たさないこともある。個別具体的に整理しないと、一般的に危険だという話にはならない。報道によるとここ数年で3500万件の個人情報の漏洩があったそうだが、どういう情報が漏れてどんなリスクが生じているのかあまり議論されずに、心配だ心配だと言われている。セキュリティの問題にせよ、個別具体的にどの情報がどうなったときにどうなるのか整理しないといけない。

インターネットプロバイダー協議会(オブザーバー 発言者未確認)
電子的決済機能を日本でも構築していかないと、海外のものに流出していく。私の利用経験でも、決済が全部アメリカに行っているだけということがある。通信サービスを使うという通信としての認証に加えて、IDそのものが決済機能を持っているとなると、その部分が電子的に行われた場合国境を越えるので、そこをどう考えるかが重要な課題である。そこのところを避けて通ると、たとえば私の場合で言えば、AppleのID、GoogleのIDがある。消費しているのは日本だがアメリカから買っている。

IDの連携の話だが、リスクはあると思うが、大元のIDを持っているのは一社であり、クレジットカードで決済しているならその会社であり、それが流出した場合はそこで止めればそこから先には波及しないはず。クレジットカード情報がばらまかれたときに、電子的なものは大元のところがきちっとしていれば、情報漏洩があったとしてもそれで止める手段がある。リスクもあるが何か起きたときの対処方法もある。リスクばかりに目を向けがちだが、メリットにも目を向けていかないと、ほとんど海外のIDを使うことになってしまう。決済が外へ出て行くだけではないかと懸念している。

会津泉構成員(財団法人ハイパーネットワーク社会研究所副所長)
さきほどエスクローの話があったが、ICANNで、レジストラーのサービスに対してエスクローの義務付けが行われた。客から登録情報を扱っているレジストラーが機能を停止したところがあり、ドメイン名を取っている事業者が更新できなくなるという問題が生じた。ICANN側は登録情報を持っておらず事業者が持っているだけだったという反省に基づき、エスクローを義務づけた。そのように、個人情報の預かり方、破綻したときにどうするかといったことも考えておく必要がある。

次に、資料6-4の29ページにある、携帯電話のユーザIDの一般サイトへの通知の仕組みのところについて。ちょっとネットを検索してみると、携帯電話の番号だけ入力すれば、お金払えば、個人情報全部教えますよというサイトが何社も出てくる。これが現実。あまり問題が起きていないというのであれば心配する必要はないだろうが、携帯電話のユーザ識別番号の通知が簡単にできるというのは、悪意を持った業者、あるいは不注意で、起きているトラブルというのは既にあるんじゃないか。あんまり心配しなくていいのか。

岡村久道構成員(弁護士 国立情報学研究所客員教授)
さきほど、国際的にどう対抗していくのかの議論でも、米国は米国、EUはEUで電子商取引指令がある。個人情報保護の関係でどこまで許されているのか整理しておかないと、EUにつまはじきされてしまうことになる。整理をお願いしたい。

さきほど、実害なんて乏しいのではないかという話があったが、実際に漏洩した後で対応している弁護士の立場から言えば、カード番号だけでネットゲームに使われて事後策に走り回るなど並大抵なものではない。実害がないとかいうものではない。また、ネットバンキングで悪用の事件が起きており、その点でも、なんとかなるよとか、実害ないよとか、そんな甘い状態ではない。

事務局(谷脇康彦情報通信政策課長)
資料6−3の趣旨についてだが、今の認証基盤をシステムとして連携させていくという話と、ID情報をどのようにマネージしていくかという話を分けないと、違う議論。

会津泉構成員(財団法人ハイパーネットワーク社会研究所副所長)
さきほどの事業者への質問について答えて欲しい。

エヌ・ティ・ティ・ドコモ(オブザーバー 発言者未確認)
私ども認識が一致していないので調査して回答したい。大きな問題に直面したことは私の経験ではない。

ヤフー(別所直哉オブザーバー)
問題の整理をお願いしたい。個人情報漏洩が問題ないといったわけではない。クレジットカードの場合は、チャージバックでリスクを事業者が負担するようになっている。ネットバンキングの件も、報道されているが、リスクを銀行側がとって対応しているという実態がある。

河村真紀子構成員(主婦連合会副常任委員)
さきほどの、3500万件の個人情報の漏洩があったがどういう被害が出たのかという話に反論したい。クレジットカードの漏洩はお金に換算される被害だし、チャージバックされるのはわかっている。しかし、プライバシーというのが丸ごと、通信の秘密とか、いろいろなログとか、買い物の内容だとか、プライベートな情報が私の名前とセットで見られるとうことは、実害があるのかと言ったら、実害がないと言われるのかもしれないが、私は絶対に嫌だという気持ちが強い。

たしかに、個人情報保護法で行き過ぎた面もあって、たとえば学校の名簿を作れないだとか馬鹿げた話もあるが、そういう話とセットにされて個人情報漏洩に実害ないという言われ方はいかがなものか。人間の心の中までつながったプライベートの情報、そこは切れるものは個人的に切っていきたい。利便性が低まってもいいので、選べる仕組みを作っていただきたい。

(発言者未確認)
個人情報の議論が盛り上がっているが、IDポータビリティが必要か、どういうIDポータビリティを実現するかをこれから検討しようという趣旨だと理解しているので、まだ曖昧なものを今現在いろいろ言うのではなく、さしあたって、IDポータビリティというのはどういうものなのか、議論するべき。資料6-3は、検討の方向性について何も言っていない。(会場笑い。)こういうことを考えていかないといけないよということなのだろうが。

誰も最終解をわからないのではないか。一番いいのはどういう形なのかこれから考えていくことが重要。お金の流れを新しくするのがプラットフォーム。民間が考えていると思うけども、それを推してあげるのがこの研究会。

野原佐和子構成員(イプシ・マーケティング研究所代表取締役社長)
(よくわからずメモできなかった部分略)

これからの将来に向けて何も決まっていない中で議論するときに、事前対応を厚くしてしまうのは、あるかもしれないリスクはあるが、それを考えていくことも重要だが、具体論で議論しないと、なんとなくで議論するのは避けたい。

Googleの村上社長が別の委員会で発言されて印象に残っているが、日本がグローバルな展開をするときに、日本だけが勝手に兎跳びしている。みんなは走って競争しているのに、日本は勝手に自己規制して、あれもやっちゃいけないだろうと自己規制していると感じていると。

情報セキュリティの政策会議にも出ているが、アメリカには事例があるが日本では市場が小さいために起こらないことが多々ある。そういうリスクについて、一生懸命考えてガイドラインを作ってしまうことがあるが、起こるかもしれないことと、実際に起こっていることとは分けて考えるべき。

柳川範之構成員(東京大学大学院経済学研究科准教授)
別の側面から。9ページに多様な認証基盤の相互なインターフェイスの技術的検討が必要とあり、そこが重要なこと。その点で経済学者的に気になるのは、今の段階でインターフェイスをうまく作ってしまったがゆえに、新しい認証基盤の技術、やり方に参入しにくくなったり、技術の芽が出なかったりとなるとまずい。

決済とか課金とかが、ダイレクトにプラットフォームに入ると、金融システムの安定性、金融システムの規制とバッティングする。金融庁の話ということになる。オーバーラップする。政府としてはどう切り分けるのか。事業者はどうバランスをとるのか。

次に、5ページに、コンテンツアグリゲート機能と認証課金機能があるが、課金認証機能が強調されているが、コンテンツアグリゲートも将来的に重要になってくる。

藤原まり子構成員(博報堂生活総合研究所客員研究員)
(よくわからずメモできなかった部分を略)

今が世界で最も進んだネットワークを使っている国であるというアドバンテージを活かせるタイミングではないか。であれば、どういう危ないことがあるか、それはどうしても阻止しなければならないことなのか、それとも、利用者が順次学ぶことによってリスクを軽減することができる範囲のものなのか、仕分けをする必要がある。

事務局(谷脇康彦情報通信政策課長)
今回の資料は舌足らずだった。次回に向けて直していく。言いたかったのは、モバイルのことと、モバイルと固定を合わせたものの2つ。モバイルは認証課金。合わせた方は認証のことしか言っていない。前者がそうなのは、今現在携帯事業者が課金を担っているから。後者は、認証のことしか言っておらず、金融の話は切り離せる。認証の連携をする話と、IDあるいは個人情報のマネージメントの話は分けて議論しないといけない。IDあるいはプライバシー、重要だと思っているが、次回整理してくる。

マイクロソフト(楠正憲オブザーバー)
決済における匿名性の議論、IDを巡る議論は、十数年前に論点は出尽くしている。電子マネーの議論として。過去にあったSETの例のように、理念に基づいて作ったからといって必ずしも普及しない。全部やるというのは難しい。国がやるべきことは何なのか、かなり絞れるのではないか。絞らないと実現性は厳しいのではないか。今後論点として、有効な政策手段のあるところに絞って欲しい。技術は複雑で進歩が速い。将来予見できるとは考えないで議論していく必要がある。事前に規制しきるのは難しい。しかし、原則を作っていかないと、技術開発の民間での方向性が見えてこないし、本来行政として入っていくべき所が後手後手になるところもある。

予見できないから何もしないでいいということではなく、是非やっていただきたいのは、セキュリティの世界ではスレットモデリングという考え方がある。これをやったらこういう悪いことができるという。悪い具体的なシナリオに対しては、きっちり事前に措置をしていくことが最低限必要。論点の絞り込みとその実現手段を議論して頂きたい。

グーグル(藤田一夫オブザーバー)
大変ありがとうございました。事務局の資料はすばらしい内容で、ぜひ実行して頂きたい。民民でやれることは積極的にやっていきたいが、民で解決できないことは、行政からの力とお知恵をお借りせざるを得ない状況である。ユーザが自由に選べるような環境作りをして頂きたい。

最後にプライバシーについて。確かに問題があるかもしれないが、日本のプライバシーに対する感覚は、アメリカ、イギリスとでは違うのではないか。日本では、マンションとかはまた違うかもしれないが、一戸建てでは名前を表札に書いている。名前まで。わざわざ自分の名前を公道に出しているわけだから、プライバシーなんて気にしていない。(会場苦笑。)それが、ネットの世界でだけ気にするというのはうーんどうかなと思う。(会場冷笑。)これは最近のフィルタリングのことを彷彿させる。有害情報、有害情報と声高に言われるが、たしかにそういうところもあるが、人によって有害無害と価値観が違うのだから、一人の学者さん、偉い学者さんの倫理観で縛るというやり方というのは、いかがなものかなと考えている。

会津泉構成員(財団法人ハイパーネットワーク社会研究所副所長)
アメリカでは、マイクロソフトの人が中心になってID管理の7つの法則というのを作っている。事務局に送ったので見て頂きたい。アメリカやEUでは議論されていて、EUはそうとう進んでいて、ID管理についてはプライバシーを守りながら自由な選択といった、プロジェクトがいっぱいある。「アメリカと比べてリスクばっかり考え過ぎじゃないか」というのではなく、新しいことをやるときには必要な投資をしていくというのはグローバルに展開する上で必然。やりすぎにしろと言うつもりはまったくない。ある程度の範囲できちんと政策的な検討をすることが重要だ。


感想:

Google日本法人の代表者は、「日本人は公道にわざわざ表札を出しているくらいでプライバシーなんか気にしちゃいない」としたうえで、プライバシー問題の話を、有害情報の話と対比させながら、「偉い学者さんの倫理観で縛るというやり方はいかがなものか」と言っていた。

私の理解では、日本ではこれまで、官による取組み、あるいは、事業者間の横並びによる倫理的自主規制によって、事前にリスクが避けられ続けてきたところがあり、そのおかげで、消費者達の間に「関係者にまかせておけば大丈夫、変なことにはならないだろう」という安心感が定着していて、そのため、米国のプライバシー擁護団体のような、プライバシーに関する組織立った声というものが表に出ていないのだと思う。

Google社には、プライバシーに対する懸念が、「偉い学者さんの倫理観」で言われているだけのものと認識されているようで、ずいぶんとナめられたものだなと思った。日本でもちゃんと嫌なことには市民が団結してNO!と声を出していくようにしないと、そろそろ古き良き時代にあったようなバランスは保たれないのではないか。


2008年08月12日

日本の家屋の塀はグーグル社に適応して70センチ伸びるのか

前回の日記に傍聴録を記したように、その研究会では図らずもグーグル社の考え方を聞くことができた。そのタイミングから、Googleマップの「ストリートビュー」について述べられたものと解釈している人がいるようだが、このご発言は、携帯電話や固定通信網における個人識別子の扱いに関連する議論の文脈において出たものである。

さて、Googleマップの「ストリートビュー」だが、日本でも開始されたと知って早速いろいろなところを見てみたところ、それは予期していたのとは違うものになっていた。車一台スレスレ通れるか通れないかのような細い道にまで撮影車が積極的に入り込んでおり、特に予想外なことに、住宅密集地で、高い視点から塀の中を見下ろして撮影している。

これは通常の通行人の目線で見える風景との違いを比べる必要があると思った。そこで、現地を訪れて実際の塀の様子を確かめてみることにした。

今回は、東京のJR目白駅の周辺を訪れ、特に塀の中が見えてしまっている3軒の住宅をお訪ねし、居住者にインタビューを試みた。残念ながら、お盆休み中のせいか、うち2軒は家主がご不在で、留守番の方しかいらっしゃらなかったためインタビューはできなかった。以下は、インタビューのできた1軒についてである。

訪れたのは、Googleマップで示される以下の場所。

(準備中(10月15日修正))
図1: Googleマップ「ストリートビュー」で公衆送信されている写真

同じ場所を訪れて、通常の目線の高さ(約1メートル55センチ)からデジカメで撮影した写真が下の図2である。

図2: 図1の地点を通行人の通常の目線の高さで撮影した写真

このように、塀しか見えない。

同じ地点で塀に垂直に向いた様子が、以下の図3と図4である。

(準備中(10月15日修正))
図3: Googleマップ「ストリートビュー」で公衆送信されている写真

図4: 図3の地点を通行人の通常の目線の高さで撮影した写真

Google「ストリートビュー」と通行人の視点ではこれだけの違いがある。

また、仮に通行人が手を伸ばして上の方から撮影しようとしたらどうなるか、図2の位置で手を上に伸ばしてデジカメで撮影した(約2メートル10センチの高さからの撮影)のが、図5の写真である(居住者の承諾を得て掲載)。

図5: 図2の位置で手を上に伸ばして撮影した写真

手を伸ばしても、Google撮影車の視点にはほど遠かった。

お住まいの方にインタビューするため、インターフォンで「お話を伺いたい」と趣旨を説明したところ、快く対応してくださり、玄関先でしばらくお話を伺うことができた。

「ストリートビュー」について存在は既にご存知だった。新聞で見たとのことで、インターネットは使っていて、Googleマップも知っているが、「ストリートビュー」はまだ試していないとのことだった。

図1、図3の画面コピーをお見せして感想をうかがった。ブログに掲載するという趣旨でお話をうかがったのだが、やはり、語っていただいたことをここに記すというのは気がひける。ここまで明確に家の場所を示した状況で、それを書くというのは、ご本人の同意を得ているにしても気がひけてしまう。

かといって、場所を示さずに、つまり、「ストリートビュー」を使わずにこの話を書いたのでは、「ストリートビュー」の実態を示すという目的が達成されない。これはやっかいなジレンマだ。

今回の方は、インターネットの利用者で、Googleマップもご存知という方だったからこそ、快く掲載の承諾を頂けたのだと感じた。もし、他の家で、インターネットも使ったことがない方だった場合には、どうなっていただろうか。そういう状況に備えて、イー・モバイル接続するノートPCを持参したので、何が起きているかを実物で説明することはできただろうし、感想を聞くことはできただろうが、否定的な感想を話される方ほど、ブログへの掲載には承諾を頂けないのではないかと予想する。やっかいなジレンマだ。

どうやればいいのかわからないが、「ストリートビュー」の視点と通常の通行人の視点の違いの実態は、もっと世間に明らかにされるべきだ。

Googleの撮影車がなぜこんなにも高い位置にカメラを設置しているかというのは、おそらく、低い位置では、車の屋根が視界を遮るために、画面を下に向けたときの写真に死角ができてしまうためだろう。しかし、対策は考えられる。たとえば、高い位置と低い位置にカメラを設置して、下向きの写真は上のカメラで撮り、横向きの写真は下のカメラで撮って、お得意の高度な情報処理技術で合成すれば、通行人視点の映像を死角なく生成できるのではないか。

先行して始まっていた米国では、これほどまでに狭い場所に入り込んでおらず、この角度が問題になることはなかったのだろう。それをそのまま日本に持ち込み、何が起きるのかを気にせず、対策をとらなかったため、こうなったのではないか。

ちなみに、類似の先行サービスである「LOCATION VIEW」では、視点の高さが低い(下には撮影車が映っている)し、ここまでの狭い路地には入り込んでいないようである。

訪ねた場所は本当に狭い道で、自動車が来たら人は止まって避けないといけないようなところだった。住人の車の通行しか想定されていないところだ。路地の入り口から見た写真は図6のとおりで、用もないのに入っていくのは気がひける場所だった。奥の方(図1で「北」に進んだところ)はさらに狭くなっており、「ここを通って行ったんですかね、よく通れましたね」とインタビューした家の方もおっしゃっていた。奥の方の塀も高さが2メートルほどあり、通行人の視点では窓は隠れていたが、「ストリートビュー」では窓が映し出されている。たまたまカーテンが閉まっているからよいものの、閉まっていなければ部屋の中が映っていただろう。

図6: 路地の入り口から見たときの写真

図7: 目白駅

15日追記

続きを書いた。


2008年08月15日

「この先自動車通り抜けできません」を通り抜けていたGoogleストカー

前回の日記を読み返していたところ、「ストリートビュー」(最近は「ストビュー」と呼ぶ人もいる)で南東に2ステップ移動した地点に、何やら標識のようなものが写っていることに気付いた。


大きな地図で見る
図1: 路地の入口に標識のようなものが見える

これは何だろうかと気になり、もう一度現地に出向いて確認してきた。前回の日記で最後の写真に示した路地の入口は、もう一歩引いて撮影すれば、以下のようになっていた。

図2: 現地で撮影してきた標識のようなもの(通常の目線の高さから)

「二輪の自動車以外の自動車通行止め」のマークがあるが、これは道路交通法上の規制を意味するのだろうか? それとも、単に「通り抜けできないような道ですよ」と言っているだけなのだろうか。

気になったので目白警察署に尋ねてみたところ、これは「標識」ではなく「看板」であり、道路交通法上の規制の効力は及ばないものとのことだ。ではどういう意味があるのかと尋ねたところ、「地域住民の要請でこのような看板を出すことがある」「部外者に入ってこられては迷惑になる場所や、実際に車が入り込んで動けなくなったような場所に出している」「区役所と協力してやっている」とのことだった。

Googleのストリートビュー撮影カー(以下「Googleストカー」とする)はそのような場所にまで入り込んでいたわけだ。住民の方も「よく通れましたね」とおっしゃっていたが、奥の方の地点を見てみると、こんな感じで通り抜けている。


大きな地図で見る
図3: Googleストカーが通り抜けている様子

Googleストカーの目線と常人の目線を比較する

前回の日記で民家の塀の中が丸見えになっている事例を示したが、それは稀なケースではない。

図4は、ある地点について、Googleマップ「ストリートビュー」での表示と、現地で私が撮影した通常の目線の高さ(約1メートル55センチ)からの写真と、LOCATION VIEW(Googleマップより先に開始されていた類似のサービス)での表示を比較したものである。(今回は、前回のように居住者の承諾を得たわけではないので、Googleマップにはリンクしない。できるだけ無難な絵を選んだ。)

図4: 左からGoogleマップ、私、LOCATION VIEWの視点

このように、LOCATION VIEWの視点は、私の視点より少し高い程度であまり違わないのに対し、Googleのストリートビュー撮影カー(Googleストカー)の視点は大幅に異なって高い。

図5は、別の地点について同様に比較したものである。(LOCATION VIEWはこの通りには入っていなかった。)

図5: 民家の見え方の違い(左: Googleストカー、右: 通行人)

通行人の目線では洗濯物が見えないのに対し、Googleストカーでは洗濯物が見える角度で撮影されている。(この日は洗濯物は干されていなかったようだが。)

図6は、さらに別の地点についての比較。(ここの通りもLOCATION VIEWは入っていなかった。)

図6: 民家の見え方の違い(左: Googleストカー、右: 通行人)

図7は、ある地点で、通りからアパート側を向いたときの比較である。(ここもLOCATION VIEWにはない。)

図7: 通行人からの目隠しがGoogleストカーからは透けている様子(左: Googleストカー、右: 通行人)

通行人からの目隠しであろうか、通行人にはちょうど垂直となる位置に設置されており、日光や風を通すための斜めのスリットが開いている。これが、Googleストカーの撮影角度では、スリットを抜けて向こう側が透けてしまっている。

同様の状況は他にも無数にあるように思える。

ここに書き込まれたコメントなどによると、グーグル社は以下の内容のメールを送っているらしい。(事実かどうかはまだ確認できていない。)

Google ユーザー様、

Google へご連絡いただきありがとうございました。Google Maps ストリートビューは、日本の法律にもとづいて公共の通りから集められるイメージのみを表示しており、例えば道を歩いていて見ることができるイメージと同じです。

大変申し訳ございませんが、このフォームからいただいたメールからでは住所、詳細および、削除希望のイメージを正しく把握することができない場合がございます。ストリートビューの画像を削除希望の場合、下の手順に従っていただくか、ビデオをご覧になってください。

1. 問題のストリートビューの画像を表示します。
2. ウィンドウの右上に表示されている [ストリートビューヘルプ] をクリックします。
3. [不適切な画像を報告する] をクリックします。
4. 必要事項を記入して、報告してください。

http://www.youtube.com/watch?v=LjPufjGBKiM

お客様のご理解に感謝いたします。今後とも Google をどうぞよろしくお願いいたします。

Google チーム

「道を歩いていて見ることができるイメージと同じ」というのは事実に反する。

ところで、前回の日記に対するはてなブックマークの中に、こんなコメントを書いているのがいた。

atsushieno これが問題なら、むしろ車高の高い車を規制すべきという議論もしなければならないだろう。あと、将来車が空中を走るようになったらどうするのか。/ (略)

いったいどんなのなのかと調べてみたところ、驚いたことにMIAUの発起人の一人らしい。

10日の日記のはてなブックマークには

K-Ono はいはい、MIAUの出番ですよ(笑) / (略)

というコメントが見られたように、大きなものに対抗する手だてとしてMIAUに期待する向きもある(他に団体が存在しないため)が、MIAUはプライバシー問題に取り組める団体ではないのではないかと私は感じている。MIAUは自由を追求する集まりであって、消費者保護やIT弱者救済を対象としているわけではなさそう*1だからだ。

*1 自由の追求がたまたま消費者保護にもなる事例があるというだけで。


2008年08月22日

「LOCATION VIEW」のプライバシーへの配慮状況

Googleマップの「ストリートビュー」よりも先に日本で類似のサービスを提供していた「LOCATION VIEW」だが、以下のページに「G社」との比較表が掲載されていた。

  • ロケーションビューとは, 株式会社ロケーションビュー
    LOCATION VIEW(公開サービスサイト)LOCATION VIEW(法人向けサービス)他サイト(G社)
    撮影方法 視点ほぼ人間の目線の高さほぼ人間の目線の高さ高い(おおよそ2.5m程度)
    解像度低(G社サイトと同等解像度のものを1/10程度に圧縮して配信)最高〜低(用途に応じて)
    (引用時、一部略)

なるほど、これはプライバシーへの配慮だろうか。

ロケーションビュー社にプライバシーへの配慮状況について問い合わせてみた。

件名: 住宅地映像のプライバシー保護に関する公開質問

株式会社ロケーションビュー個人情報保護方針問い合わせ窓口御中

貴社の「LOCATION VIEW」サービスにおけるプライバシー保護へのお取り組みについて質問いたします。

「LOCATION VIEW」が公開している映像には、住宅地で撮影されたものも含まれていますが、その映像を一般公開するにあたって、貴社では何らかのプライバシー上の配慮に取り組まれていますか。特に以下の2点についてお答えいただけましたら幸いです。

(1) 撮影視点に関する方針
住宅地を撮影するにあたり、カメラの視点の高さについての規定あるいは方針はありますか。またその理由は何ですか。

(2) 撮影する道路の幅員等に関する方針
住宅地を撮影するにあたり、一定幅に満たない道路では撮影しない、もしくは撮影しても一般公開しないといった規定あるいは方針はありますか。またその理由は何ですか。

以上の点、お尋ねします。

公開前提のこの問い合わせに対し、(前回の日記が既に読まれていたようで)以下の回答を頂くことができた。(強調部は、転載時による)

(1) 撮影視点に関する方針
住宅地を撮影するにあたり、カメラの視点の高さについての規定あるいは方針はありますか。またその理由は何ですか。

弊社では従来の地図、航空写真で応えられないニーズに対応するため、空からでなく地上からみた地図という新しい概念にもとづいてロケーションビューの開発を行っています。ロケーションビューは公開サイト以外にも新しい地図サービスとして官公庁・地方自治体・電力・ガス事業者など含め広く利用されており、公開サイトにおきましても目的地までの道順の確認や、待ち合わせ、(特に小規模な)飲食店への案内、不動産の現地案内などの場面で従来の地図になく便利であると評価をいただいています。実際に公開サービス開始時点からのダウンロード数は2億ダウンロードを超え(およそ地球5周相当)、現在も安定してサービスを提供しています。弊社ではこの新しい地図サービスを安定して提供することも責任のひとつと考えています。

事業の計画、撮影仕様の決定段階においては、利用者として想定される官公庁・地方自治体などの意見を取り入れるとともに、地図としての著作権、プライバシーや個人情報の保護のありかたに関しても国土交通省所轄の財団法人にも調査を依頼しその結果も踏まえています。公的サービスとして利用されている側面もありますので、事業運営においても各種利用規定を設けること、個人情報保護方針を定めこれに基づき対応窓口を設け一定の手順のもとに対応すること、捜査当局からの要請に基づき速やかに協力体制を整えることなどの取り組みを行っています。

弊社では撮影用に複数台の車両を保有しています。撮影の品質を確保するため、各車両でカメラまでの地上高がほぼ同じになるように設定しています。その地上高に関してはカメラの性能、有効な撮影範囲(画角)などの観点から実証実験を行った上で決定しています。その中にはブログのご指摘にもあるとおりプライバシーに配慮して目線の高さに近いという点も含まれています。

(2) 撮影する道路の幅員等に関する方針
住宅地を撮影するにあたり、一定幅に満たない道路では撮影しない、もしくは撮影しても一般公開しないといった規定あるいは方針はありますか。またその理由は何ですか。

ロケーションビューに関する業務を受託する際、地図としての網羅性を確保することが業務仕様の重要な要素になる場合があります。この点から申し上げますと、撮影は公道から行なうことを原則としていますが、自動車が物理的に入れない場所以外はできるだけ撮影するようにしています。ただ、車両には一般に販売されているものと同等のカーナビゲーションシステムを搭載し使用している関係から、通常の場合カーナビで表示されないような道路は撮影範囲には入りません。通常の場合と申し上げますのは弊社では自動車の進入が困難な地下街や建物の中、鉄道や遊園地などカーナビの地図で道路が存在しない場所についても撮影ができる体制を整えており、この場合施設の所有者、管理者などの監督のもとに撮影を行うこともあります。しかし実際の撮影時には撮影現場の状況により撮影範囲が影響されることもあり、例えば大規模な地震被害の把握業務を実施する場合など、道路状況は現場に行ってはじめて判断しなければならないこともあります。

次に弊社サイトで公開する場合、撮影エリアと公開エリアは必ずしも一致するわけではありません。さらに公開にあたっては新しい地図としての利便性を損ねない範囲で肖像権、個人情報保護などの観点から必要な画像処理などを施し、表札や車のナンバープレートなどが見えないように調整した上で公開サイトでサービスを提供しています。具体的な例をひとつ申し上げますと、公開にあたっては画像のすべてについて画像認識プログラムによりチェックを行い、さらに人間の目によるチェックを行なっています

ご質問の住宅地の道路幅員に関してですが、以上のような多様なサービスを提供していることもあり一概には申し上げにくい部分もあります。また先に述べましたとおり道路状況は常に一定でないこと、後ほど例として挙げる建築基準法などの法令も条例、地域の実情に応じた運用がされる場合があり必ずしも全国で一律ではないことなどから、撮影・公開の基準につきましても統一したものを設けることは困難なのが実情です。さらに一方で観光案内などの場合では、お客様からの依頼により狭い道路、私道や私有の施設であっても撮影・公開することが業務仕様に含まれる場合もあります。

その点ご理解いただいた上でご説明するならば、繰り返しになりますが撮影は公道から行うことを原則とし、公開時のエリアのおおよその判断としまして道路幅員3mから4mをひとつの基準として考えております。これはもともと不動産調査や不動産物件案内としての利用方法も想定していることもあり、建築物が建築できる道路、すなわち建築基準法第42条、43条における道路の定義も参考にしています(その場合幅員が4mに満たないとしてもセットバックにより建築物が建築できることがあることも考慮しています)。また住宅地おきましては、明確に私道と分かる場合(例えば私有地の看板がありそのように判断できる場合、現場において建築基準法上の位置指定道路と判断できる場合など)では撮影・公開しないことを原則としています。

株式会社ロケーションビュー
運営企画部
〓〓〓〓(担当者氏名、転載時略)

撮影の視点の高さはやはりプライバシーにも配慮した結果としての設定のようだ。前回の日記の図2の場所も、以下の図1のように、概ね通行人の目線と同じくらいで、20センチほど高いかもしれない程度のようだ。おそらく、自動車の天井から30センチくらいの位置にカメラを設置しているのではないか。


LOCATION VIEWサイトで見る
図1: 前回参照した場所のLOCATION VIEWでの見え方(この通りには入れない)

一方、撮影する道の狭さの基準については歯切れの良い回答は頂けなかった。図1の周辺地域では狭い道に入ってはいないようであったが、もう少し調べてみたところ、狭い道でも撮影されて公開されているところがあるのを確認した。以下の図2は、私にとって馴染みのある場所で、「ここに車で入るのか」と驚いてしまうほど狭い道だ。20年前に比べて家々も建て替えが進んでおり、広くなった場所もあるようだが、当時はここを歩くだけで怪しまれるのではないかと感じるほど通行するのが申し訳ない道だった。


LOCATION VIEWサイトで見る
図2: LOCATION VIEWも狭い路地に入って撮影している事例

狭い道で撮影することの何が問題かと言えば、被写体までの距離が短くなるため、(1)撮影視点が高い場合には見下ろし角度が急になり通行人には通常見えないはずのものが見えてしまう範囲が広くなるという点と、(2)被写体の解像度が高くなるという点にある。

見下ろし角度については、LOCATION VIEWの場合は撮影視点が十分に低いので、距離が近くても問題にならないと思われる。

解像度の問題については、LOCATION VIEWでは、一般公開サービスにおいては映像の解像度を下げて配慮がなされているようだ。*1

それに対し、Googleストリートビューには、そういった配慮がみられない。

また、今回頂いたご回答には次の記述があった。

表札や車のナンバープレートなどが見えないように調整した上で公開サイトでサービスを提供しています。(略)公開にあたっては画像のすべてについて画像認識プログラムによりチェックを行い、さらに人間の目によるチェックを行なっています。

住宅地おきましては、明確に私道と分かる場合(例えば私有地の看板がありそのように判断できる場合、現場において建築基準法上の位置指定道路と判断できる場合など)では撮影・公開しないことを原則としています。

車のナンバープレートについて、Googleストリートビューではどうなっているかというと、「日本では人の顔や車のナンバーなどは消されている」などと書いている記事も散見される*2が、INTERNET Watchの報道によれば、車のナンバーは消す処理を施していないとグーグル社が公式に述べている。(「解像度の問題でほとんど識別できない」が嘘か真かは、実際に使ってみればわかることである。)

河合氏は(略)撮影地点については、「撮影する道路は公道からに限っており、私道や敷地内に入っての撮影はしていない」と説明。また、映っている人の顔については自動認識によりぼかし処理を行っており、米国では車のナンバープレートなどについても一部処理を行っているが、日本では解像度の問題でほとんど識別できないと思われるため、現時点では顔以外には自動的な処理は行っていないとした。

「ストリートビュー」のプライバシー問題、グーグルが方針説明, INTERNET Watch, 2008年8月5日

LOCATION VIEWでは、「人間の目によるチェックを行なっています」とのことだっが、Googleは、少しなりとも人間の目によるチェックを行なっていたのだろうか? マスコミはそこを聞き出すべきだと思うが、残念ながらそれに関する情報は出ていない。

サービス開始早々、立ち小便する人やラブホテルに入る人など不適切な写真が続々と発見されたわけだが、こういった画像の公開前チェックをグーグル社は少しなりとも行っていたのだろうか?

グーグル社の河合敬一氏は、「私道や敷地内に入っての撮影はしていない」と公言しているが、あきらかに私道*3に進入している事例が多数報告されている。たとえば、図3、4の事例では、集合住宅の駐車場に入って撮影していることがわかる。こうした事例は無数にあるようで、ストリートビュー開始直後にたまたま会話した知人も、自分のマンション前の私道に入られていると言っていた。


大きな地図で見る
図3: 集合住宅の駐車場にまで入り込んで撮影している事例


大きな地図で見る

図4: 集合住宅の駐車場にまで入り込んで撮影している事例

図4の事例は、地図にない場所(赤い線で示した位置)に入り込んでしまったのだと思われる。地図にないため、Googleマップでは青い線がずれた位置の道に表示されてしまっている。

このように撮影作業員が誤って入った場所の他、撮影作業員が休憩に立ち寄ったコンビニのシーンや給油所でのシーンも見つかっており、おそらく撮影は全自動で行われていて、誤った撮影のキャンセル作業は行われていない様子がうかがえる。

撮影作業員の頭には「誤って入ってしまった」という認識はあったに違いないが、機械任せに撮りっぱなしにし、記録しっぱなしにしたデータを、ダダーっと機械に突っ込んで公衆送信してしまっている。

グーグル社には人間らしい配慮が微塵もない。人に風景を撮影する自由があるのは責任を伴うからこそではないのか。

Googleストカーの撮影風景を再現しよう

先日の日記への反応を見ていると、ストリートビュー撮影カー(ストカー)がどんな仕組みになっているのか(どのようにカメラが設置されているのか)まだご存知でない方も少なくないようだった。ストカーの目撃情報は日本でもいくつも報告されており、複数の写真が紹介されている。

車の上に取り付けられた棒の先端にある赤い物体がカメラで、以下の市販製品が使われているらしい。

車はプリウス。プリウスのスペックによると「全高 1,490mm」とのことなので、上の写真からカメラの高さを算出すると2,470mm、2メートル50センチくらいのようだ。

これを前回の日記の図2の風景に重ねてみた。

図1: Googleストカーの撮影風景(合成写真による想像図)

写真の構図が異なるので正確な再現はできないが、この道の幅はちょうど3メートルで、右の壁の高さが2メートルなので、概ねこんな感じだ。カメラはこのように壁より高く突出してパシャパシャと撮影して行ったのだろう。

中の家から塀の方を見ていたらどう見えただろうか。プリウスは低速走行時は電気モーターのみで走るので、音をたてることもなく、赤いものが塀の上をすーっと動いていく様子が見えたことだろう。

そんな様子を再現してみたいと思っていたところ、エクステリア専門工事業者の方のブログに、「Googleストカーの視点をCGで検証する」という記事が掲載された。歩行者目線に配慮して設計したフェンスのある家について、ストカーから撮影すると中の窓がどう見えてしまうか、三次元CGでシミュレーションされている。

これはすごい。さすがプロ。車がフェンスに近いときの全体図、それから、家の中から見るストカーのシーンを見てみたいです。3メートル幅の道の両脇に家があり、間を通るストカー。それがどのくらい異常な事態なのかを示す意味で。


23日追記

さっそく、エクステリア明日香様が検証してくださった。

すばらしい。ありがとうございます。

私たち良識を持つ人間は、こうして架空の絵を作成して問題点を指摘するほかない。実例をおおやけに示すのは憚られる。その一方でグーグル社は、問題のある写真を大量に今なお公衆に対し送信可能化している。

*1 LOCATION VIEWの現在の方針であれば十分と言えるかついては、私はとくに考えを持たない。

*2 実際にストリートビューを使ってみればすぐにわかることなのに、ろくに使いもせずに書いているのか。

*3 「公道」「私道」という言葉をグーグルの河合敬一氏はどういう定義で言っているのかわからないが、少なくとも、LOCATION VIEWの場合では、建築基準法上の位置指定道路は私道として扱い「撮影・公開しない」とされている。


2008年08月24日

グーグル株式会社の広報姿勢が嘘八百なことを示す事例

ストリートビューについて、グーグル株式会社は、公道から撮影していて私道や敷地内には入っていないと説明している。このことは次のように報道されている。

しかし、ネットを「公道 私道 グーグル」などでサクって*1みると、自宅が私道から撮影されていると不満を漏らす声がいくつも見つかる。また、8月16日の朝日新聞の投書欄には、「グーグル側は『人の顔はぼかし、車のナンバーは映らないようにしている』と説明しているが、大うそではないか。『公道から撮影した画像は基本的に公開が可能と判断した』ですって? うちの周りは私道です。」という声が掲載されている。 
グーグル株式会社の出鱈目な広報姿勢はどんどん皆で証拠を示して指摘していけばいいところだが、皮肉にも、自宅が私道から撮影された証拠を示すには、自宅の場所か写真を公表することにもなってしまうため、せいぜい匿名掲示板に文章で不満を書くくらいのことしかできず、実態が広く周知されない状態に陥っている。(グーグル株式会社がそのことを予見しつつやっているのかどうかは知らない。)

そこでここでは、公表することによる問題が公表しないことによる問題よりも十分に小さいと考える事例について、私の責任でいくつか具体的に示しておく。

事例1

大阪北摂霊園の事例。


大きな地図で見る


大きな地図で見る

図1:「関係者以外通行禁止」と掲示された霊園の私道にグーグルの撮影車が進入する様子

管理事務所に電話して確認したところ、この墓地一帯は財団所有の私有地で、ここから奥の道路は私道(市道ではなく「わたくしみち」)であるとのこと。表門の看板には「関係者以外通行禁止」と掲げており、実際、改造車愛好者らの集会で入られた際などに「何しにきているのか」と問い質し追い払っているとのこと。墓参者のための道路だとのことだ。

グーグル株式会社が許可をとって撮影した可能性もあると考えたので、管理事務所に確認したところ、「あり得ない」とのことだった。目的が明らかでないものを許可することはないし、撮影が目的であれば撮影場所を必ず確認するし、そもそも墓が写る撮影ではそれぞれのお墓の家の承諾をとらなければ許可できないとのこと。

撮影車は図2のように霊園をくまなく撮影しようと廻っており、単に誤って通過したというレベルのものではない。

図2: 撮影車が霊園内を巡った様子

そして最も高い地点まで上り詰めて、むしろ墓を写す目的で行ったのかと思われるほどの写真が撮られている。


大きな地図で見る


大きな地図で見る


大きな地図で見る

図3: お墓まで撮影してグーグル社が公衆送信している様子

事例2

茨木国際ゴルフ倶楽部の事例。


大きな地図で見る


大きな地図で見る

図4: 「関係者以外立入禁止」のゲートがあるゴルフ場の私道にグーグルの撮影車が進入する様子

ゴルフ場に電話して確認したところ、このゲートより奥は私有地であり、この道路は私道であるとのこと。

撮影車はゴルフ場の奥まで進み、以下の図のように、わざわざ駐車場に入って、駐車場内をずんずん進み、駐車されている自動車群を何枚にもわたって撮り続けている。






図5: 駐車場に入り駐車中の自動車ばかり写し続けている様子

ここでは示さないが、ストリートビューで横に向きを変えると、駐車中の自動車のナンバープレートはそれぞれ丸見えで、グーグル株式会社の河合敬一プロダクトマネージャーが言うような「識別できない」といったレベルのものではない。

8月6日の朝日新聞報道によると、グーグル株式会社は、

と言っているそうだが、どう見ても「なるべく映り込まないようにしている」というのは嘘偽りで、駐車場に入って自動車を撮りまくっている。

これが撮影作業員のミスということはあるかもしれないが、前回の日記にも書いたように、撮影作業員が誤って入った場所の他、撮影作業員が休憩に立ち寄ったコンビニのシーンや給油所でのシーンも見つかっており、撮影は全自動で行われていて、誤った撮影のキャンセル作業は行われていない。

マンションの敷地などの細かい所の私道進入をチェックで見落とすくらいはあり得るにしても、これほど明確な進入さえもグーグル株式会社はチェックできていない。「私道や敷地内に入っての撮影はしていない」というのはまるっきりの嘘っぱちではないのか。

グーグル株式会社に確認しようと、土曜日の16時50分頃に代表電話に電話してみた。すると、

こちらはグーグルでございます。ただ今の時間は、弊社の営業時間外となっております。お手数ですが発信音の後に、お名前、電話番号とメッセージを録音してください。こちらから折り返しご連絡させて頂きます。なお、電話でのサポートは行っておりません。サポートをご希望の方は、弊社ホームページよりヘルプセンターをご利用ください。

という自動応答メッセージが流れ、同じ内容の英語メッセージが流れた後、電話は切られた。「発信音」が流れることもなく、メッセージを残すことはできなかった。事故かもしれないので日曜にもう一度試したが、やはり「発信音」は流れずにブツ切りされる。

Webで文句を言おうとしても、「約87文字以下で入力してください」と、そもそも説明させないようにされている。

こんな傍若無人で噓つきな会社を放置しておいたら、この先何をされるかわかったものじゃない。

その他の事例

無断で入ったのかどうか私は事実確認をしていないが、進入禁止の私道に自動車で進入しているのではないかとの指摘が、他にも出ている。

*1 Webの検索サービスで検索することを「サクる」と私は言うようにしている。


2008年08月29日

グーグル社がゲートのある敷地内に進入して撮影した事例 その2

前回の続き。

大阪市立弘済院付属病院及び特別養護老人ホームの事例

タレコミを頂いた。豪快に敷地内に進入して撮影した事例が他にもあるという。


大きな地図で見る
図1: 当該場所とゲートの位置


大きな地図で見る
図2: 青のゲートを公道から見た様子


大きな地図で見る
図2: 青のゲートに入ろうとする位置(「南」および「東」)


大きな地図で見る
図3: 「南」に進むと敷地内を通って行き止まり


大きな地図で見る
図4: 黄色のゲートに入ろうとする位置


大きな地図で見る


大きな地図で見る

図5: 「関係車両以外の進入を禁止する」の立て札がある様子


大きな地図で見る
図6: 緑のゲートを公道から見た様子

これは「誤って入った」というものではなかろう。撮影されている通路は一筆書きのできない経路であり、積極的な意思を持って全部の道を辿ったようにしか見えない。

このようなゲートがあるところに入って撮影するという神経がよくわからない。撮影作業員はいったいどんな指示を受けていたのだろうか。迷路に入り込んだマイクロマウスのように、ひたすら路側づたいに走れとでも言われたのだろうか。

ただし、病院と特別養護老人ホームの承諾を得て撮影した可能性がないとは限らず、病院への確認はしていない。

高槻市公園墓地の事例

上の事例の周辺地域をぼんやりと見ていたら、他にも墓地に進入している事例を見つけた。

図7: 墓地の中をわざわざ巡っている様子

画面キャプチャ
図8: 入り口にゲートがあり何か立て札がある様子

立て札に何と書かれているかは残念ながら読み取れず、確認はまだしていない。

30日追記:高槻市公園墓地管理事務所に電話で聞いた。ここの道路は「敷地内道路」であり、たとえば自動車が事故を起こしても駐車場内と同様に警察は対応しにくい、そういう道路だという説明。入構を許可したか否かは本庁でないとわからないので月曜に市役所に聞いてくれとのこと。ちなみに、この管理人さんは、グーグルストリートビューというもので墓の写真が出ていることは既に本庁から聞かされているとのことだった。ほほう。

その他の事例

住宅の私有地に入っている事例もたくさん見つかるが、普通はゲートがない。集合住宅の駐車場用の通路に入った事例も数多く見つかる。ここでは、あまりに人で無しな事例を一つ挙げておく。


大きな地図で見る
図9: 行き止まりで転回のために住宅の駐車場に入りついでに写真撮影して公衆送信している事例

この先の踏切が車両通行止めのため、撮影作業員は、左側の土地に車を進入させて転回して戻ったのだと推定される*1

たしかに私たちは、ドライブ中にこうした行き止まりにたどり着いてしまった場合、やむを得ず個人宅の敷地内に入らせていただいて、車を転回させていただくことはしばしばある。入ったときそこに住人の方がいらっしゃったなら「すみません、道を間違えまして。ちょっと失礼します」くらいの声をかけて急いで転回するだろう。そこで写真をとったりすることはない。

ところがこの、グーグルの撮影作業員は、その転回に入った他人様の敷地で無断撮影したうえ、その静止画写真に洗濯物等が大きく写っているにもかかわらず、それをWebで公衆送信可能化しているのである。まるで、ドアを開けて先に通してくれる人に屁を放って行くような所業だ。

撮影作業員に常識があるなら、このような場所では撮影装置のスイッチを切ってしかるべきであるし、誤って撮影してしまったにしても、その場で削除するか後で削除できるようキャンセル用マークを付けるなどするのが当然だろう。そして、グーグル株式会社の河合敬一プロダクトマネージャーは、事前にこれをチェックすることなく公衆送信用サーバに放り込み、写真を送信可能化している。

ITmediaの記事によると、河合敬一プロダクトマネージャーは、最初に故郷の母校周辺を検索して懐かしい思いがこみ上げ「涙が出そうになった」と記者発表会で話したそうだ。その前に見るところがあるんじゃないのか。

*1 地図では左の住宅の手前にある狭い道に少し入ったように青い線が描かれているが、これは処理の誤りで、道のない所に入って撮影したためにずれた位置の道がマークされている。


2008年08月30日

ストリートビューに写った自動車ナンバープレートは機械判読され得るレベル

Googleマップのストリートビューについて「問題ない」と発言する人は、綺麗なところしか見てないのだろう。問題のありそうな場所を自力で少し見渡してみればわかることでも、見ようとしないから理解しない。「日本版ではナンバープレートはぼかし処理が施されていない」と、いくら文章で説明したところで、そういう人は自力で確かめないし、確かめるまで実感として理解しない。したがって、面倒であるがやはり、実際にナンバープレートが具体的にどう判読可能な状況になっているのか示す必要がある。ここまで示せば「やっと理解した」という人が出てくるだろう。

以下は、東京と大阪の適当に選んだ3か所の地域から、集合住宅の駐車場に進入して撮影された写真を各2枚ずつ選び、駐車中の自動車のナンバー部分にズームインしたものである。


図1: 事例A


図2: 事例B


図3: 事例C


図4: 事例D


図5: 事例E


図6: 事例F

人間の目にはこのままでも判読できる。

機械が判読し易いように、いくつかを画像処理してみた。

図7: ズームインしたナンバープレートを画像処理した例

これを、汎用のOCRソフトにかけて数字認識を試してみた。使用したのは「読んdeココ!! Ver.13」の「無料体験版」である。

図8: 汎用のOCRソフトで数字認識した例

汎用のOCRでは無理があったか、残念ながら十分な認識結果は得られなかったが、図8の例では1桁読み間違えただけで他の桁は認識できた。ナンバープレート写真専用の認識プログラムを作成すれば、十分な認識精度が得られるように思える。今回はナンバー部分の抽出を手作業で行ったが、それを自動化するプログラムが作成されたら、Googleマップで公衆送信されている大量の写真から自動抽出されてしまうおそれがある。

今回の事例では、ナンバープレートのうち、認識できそうなのは4桁数字の部分で、分類番号は認識が難しそうな解像度だった。平仮名部分は人間には判読困難なケースが多いが、機械なら識別可能かもしれないレベルと感じた。地域名も同様かそれよりやや識別困難なレベルであるが、これは、写真の撮られた場所から概ね推定できてしまうだろう。

犯罪捜査等では、4桁数字のナンバーと車種と色から概ね特定できると聞く。ストリートビューの写真からは車種や色を概ね識別できるだろう。地域名が場所から確定するなら、分類番号や平仮名部分が識別できなくても、数台くらいに絞られ得るのではないだろうか。

日本では、自動車の写り込んだ写真を公開するときはナンバープレートを隠すのがマナー*1として常識だと思っていたが、グーグル株式会社はどういうつもりなのか。INTERNET Watchの報道によれば、グーグル株式会社の河合敬一プロダクトマネージャーは、「日本では解像度の問題でほとんど識別できないと思われるため、現時点では顔以外には自動的な処理は行っていない」と説明したそうだが、「ほとんど識別できない」というのはまるっきりの嘘っぱちだ。

河合氏は(略)また、映っている人の顔については自動認識によりぼかし処理を行っており、米国では車のナンバープレートなどについても一部処理を行っているが、日本では解像度の問題でほとんど識別できないと思われるため、現時点では顔以外には自動的な処理は行っていないとした。

「ストリートビュー」のプライバシー問題、グーグルが方針説明, , INTERNET Watch, 2008年8月5日

ナンバープレートが隠されないと何が問題なのか、常識だと思うが、念のため書いておく。

ナンバーが判明すると、陸運局に照会することで所有者の住所を調べることができる。ただし、正当な理由がなければならない。道路運送車両法第22条は、「何人も、国土交通大臣に対し、登録事項その他の自動車登録ファイルに記録されている事項を証明した書面(略)の交付を請求することができる。」としているものの、同第5項に「請求の事由又は請求に係る委託の事由その他国土交通省令で定める事項を明らかにしてしなければならない。」とあり、同第6項で「国土交通大臣は、第一項の規定による請求若しくは第三項の委託が不当な目的によることが明らかなとき又は第一項の登録事項等証明書の交付若しくは第三項の登録情報の提供により知り得た事項が不当な目的に使用されるおそれがあることその他の第一項又は第三項の規定による請求を拒むに足りる相当な理由があると認めるときは、当該請求を拒むことができる。」とされているので、興味半分で調べることはできないようになっている。

グーグル社を擁護する人は「自宅に駐車した車のナンバープレートが公開されたところで、自宅はそこにあるのだから、ナンバーが見えていても問題ない」と言うかもしれないが、正当な目的でなければナンバーから住所を調べることはできないところに、Googleのストリートビューが登場したことによって、何者かが自動認識処理によってナンバーと緯度経度の対応表を作成してしまうおそれが生じた。そうなると、ナンバーから誰でも簡単に住所を調べられる(すべての車ではないにせよ)ようになってしまう(A)。

そしてもう一つの問題は、車で出かけた先で写真を撮られ(て公開され)た場合に、その場所に居たということが誰にでも知られてしまうという点である。たとえば、ゴルフ場の駐車場の写真から判読できるナンバーから、 上記(A)の方法で自宅を特定できた場合には、誰がそのゴルフ場に行っていたかがバレる。隣りに駐車した自動車も判読、検索できてしまうなら、誰と行ったかもバレてしまう。従来ならその場にいた人にしか知り得ないはず情報が、Googleストリートビュー撮影カー(Googleストカー)に撮影されると、万人に知られるようになってしまう。

自動車のナンバープレートもCAPTCHAのような字体にしろというのか。ひき逃げに遭ったら「CAPTCHA文字を読んで記憶してください」と?

*1 Googleストカーを撮影した場合では、ナンバーは隠さず公表する方が公益性があるのかもしれないが。


2008年08月31日

グーグル株式会社の3つの虚偽(まとめ)

もし日本にプライバシー擁護団体があったなら、ただちに次の3点について抗議声明を出していたことだろう。私が個人でこのようなことを言ってもニュースとして扱われることはない。団体の声明という形式が重要であるのだが、残念ながら日本にそのような活動のできる団体はまだなさそうだ。

「通りに立った目の高さで」という嘘

Googleマップのヘルプの「ストリートビューとは」には、「通りに立った目の高さで移動しながら周辺の景色を見ることができます」と、説明されている。

図1: Googleマップのヘルプ「ストリートビューとは」

これは全くの嘘偽りで、実際には、約2.5メートルの高さから見下ろす景色であり、狭い路地では民家の塀の中まで覗き込む景色が撮影、公衆送信可能化されている。

グーグル株式会社は少なくとも次のどちらかの対応をとるべきである。

  1. 約2.5メートルの高さから撮影した写真(少なくとも被写体までの距離が短く塀などを越えて覗き込む形となっている写真のすべて)をただちに廃棄すること。
  2. Googleマップのヘルプの「ストリートビューとは」の説明を訂正し、「約2.5メートルの高さから見下ろす視点で移動しながら周囲の景色や狭い道では民家の塀の中なども見ることができます」と、実態に即した説明に差し替えること。

「私道や敷地内に入っての撮影はしていない」という嘘

京都新聞の記事INTERNET Watchの記事によれば、グーグル株式会社は「公道から視覚的に見えているものだけを使っている」、「撮影する道路は公道からに限っており、私道や敷地内に入っての撮影はしていない」との公式見解を示しているが、それは事実でない。

「関係者以外進入禁止」等の警告があるにもかかわらず、ゲート等を越えて私有地に入り、目的外活動(敷地の所有者がその道路を開放するに際して想定している正当な目的以外の活動)を行っている事例が複数存在する。また、集合住宅の駐車場内に進入して撮影された写真も多数存在する。撮影作業員のミスで進入したと思われる事例でも、撮影作業員は誤りを認識していたはずと推定される写真においてさえ、撮影のキャンセル処理や写真の自主的な削除処理が行われていない。

グーグル株式会社は少なくとも次のどちらかの対応をとるべきである。

  1. 私道や敷地内に入って撮影したすべての写真をただちに廃棄すること。
  2. 「公道から視覚的に見えているものだけを使っている」、「撮影する道路は公道からに限っており、私道や敷地内に入っての撮影はしていない」との発言が誤りであったことを公式に認め、「私道や敷地内に入っての撮影も行っており、公道からでは見えない写真も使っている」と見解を訂正すること。

「自動車ナンバーは日本では解像度の問題でほとんど識別できない」という嘘

INTERNET Watchの記事によれば、グーグル株式会社は「米国では車のナンバープレートなどについても一部処理を行っているが、日本では解像度の問題でほとんど識別できないと思われるため、現時点では顔以外には自動的な処理は行っていない」との公式見解を示しているが、「解像度の問題でほとんど識別できない」というのは事実に反しており、番号が丸見えのナンバープレートが無数に撮影されて公衆送信可能化されている。

グーグル株式会社は少なくとも次のどちらかの対応をとるべきである。

  1. 自動車ナンバープレートの不可視化処理を直ちに実施し、番号が識別できないようにすること。
  2. 自動車ナンバープレートの不可視化は不要であるとの立場である旨を公式に示すこと。

以上。

グーグル株式会社は新聞社の取材申し込みをシカトしているらしい

8月30日の東京新聞朝刊に「ストリートビューの是非」という特報記事が出ている。記事は数々の問題点を挙げた上で、最後に次のように結んでいる。

こうした状況への対応も含め疑問に答えてもらおうと、グーグルに二十六日から再三、取材を申し込んでいるが、二十九日現在、何の音さたもない。

東京新聞2008年8月30日朝刊

日本社会は、説明することさえ拒否するような企業でも存在し続けられるようなところだっただろうか。

児童生徒の視点で考え出されたストリートビュー等の用途とは

ストリートビューは何の役に立つのかという疑問があちこちで呈されている。これについては、Googleより先に類似のサービスを開始していたロケーションビュー社の「LOCATION VIEW」が、既に興味深い答えを示してくれていた。

  • たった一日でできちゃう!夏休み自由研究inロケーションビュー, 株式会社ロケーションビュー, 2008年8月6日

    「夏休み自由研究inロケーションビュー」の画面

    • Let's人通り調査! ・渋谷の交差点との人数を比べよう (LOCATION VIEWで見る)
    • ファッションチェック! ・原宿を歩くヒトと近所を比べよう (LOCATION VIEWで見る)
    • 「決戦!姫路城 ・お城の弱点をさがして攻め込め」 (LOCATION VIEWで見る)
    • 変な建物を見つける ・ぶらり歩いて変な建物を見つけよう(LOCATION VIEWで見る)

なるほどこれが本音ですか。わかります。

つまり、この種のサービスを一般公開したときの用途というのは、撮影された人間を観察するためのものでもあるし、建造物の弱点を探して攻め込む方法を考えるためのものであり、また、変なものを探して晒しものにするためのものであると。少なくとも児童生徒向けにはそうであると。

これは冗談では済まないかもしれない。実際、小中学生が夏休み中にストリートビューを使って何らかの資料を作成している可能性は十分にあるのではないか。「子供が同級生の家の写真を集めていじめに使うのではないか」という懸念の声はしばしば耳にしていた(そのときは杞憂だと思った)が、資料を作成する子供自身には悪気がなくて無邪気にリストを作成するくらいのことはありそうだ。それが夏休みの自由研究などとして学校に持ち込まれたときに、悪意ある児童生徒によって使われたりしないだろうか。

既にストリートビューの対象地域となっているところでは、学校関係者は夏休み明けに警戒が必要ではないか。また、今後対象地域となりそうな名古屋、福岡、沖縄等では、ストリートビューが公開された際の児童生徒の行動に注意した方がよいのではないか。一般にはいじめの原因は様々であり、予見できない原因のものは事前防止策をとることはできないものだろうが、「同級生の家の写真リストを作成するコストが急激に下がる」という事態は予見できる。

東京新聞の街角アンケートの結果によると、ストリートビューがどういうものか知らない人がほとんどだという。各地の教育委員会は、少なくともストリートビューの実態を学校関係者に周知した方がよいのではないか。


最新 追記

最近のタイトル

2000|01|
2003|05|06|07|08|09|10|11|12|
2004|01|02|03|04|05|06|07|08|09|10|11|12|
2005|01|02|03|04|05|06|07|08|09|10|11|12|
2006|01|02|03|04|05|06|07|08|09|10|11|12|
2007|01|02|03|04|05|06|07|08|09|10|11|12|
2008|01|02|03|04|05|06|07|08|09|10|11|12|
2009|01|02|03|05|06|07|08|09|10|11|12|
2010|01|02|03|04|05|06|07|08|09|10|11|12|
2011|01|02|03|05|06|07|08|09|10|11|12|
2012|02|03|04|05|06|07|08|09|
2013|01|02|03|04|05|06|07|
2014|01|04|07|09|11|12|
2015|01|03|06|07|10|11|12|
2016|01|02|03|04|06|07|08|10|11|12|
2017|01|02|03|04|05|06|07|10|12|
2018|03|05|06|10|12|
2019|02|03|05|06|07|08|10|
2020|08|09|
2021|07|08|10|12|
2022|01|04|06|12|
2023|03|
2024|03|04|07|11|12|
2025|01|02|03|04|05|06|10|11|12|
最新 追記