最新 追記

高木浩光@自宅の日記

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

2009年02月01日

Googleドキュメントの「招待メール」の危険

ことの始まり

先々週の話。1月23日に次の記事が出ていた。

この記事の趣旨は、「Googleスプレッドシート」の共有設定の画面の説明文「Let people edit without signing in」が誤解を招くために、誤って、誰にでも閲覧や編集を許す設定にしてしまいかねないという話である。この画面は、日本語表示では図1の表記となっている。

画面キャプチャ
図1: Googleスプレッドシートの「他のユーザと共有」設定

WIRED VISIONの記事の言い分では、「people」が上の招待メール送信先の人々のことを指すように読めて、下の「プライバシー」設定も変更しないといけないように誤解してしまうという。

そもそも、この機能の意図されている動作はどういうものか。私も試しているうちに一時混乱してわけがわからなくなったが、改めて実験して確認してみると、次の理解(最初に感じた直感どおり)でよいようだ。

  • 「招待」の機能と「プライバシー」の機能は独立のもの。
  • 「ログインしていないユーザに閲覧/編集を許可する」に設定すると、この文書のURL「http://spreadsheets.google.com/ccc?key=XXXXXXXXXXX」を知っている人であれば誰でも、ログインしていない状態で閲覧/編集ができるようになる。つまり、Googleマイマップの「限定公開」と同様。
  • 「招待」と「プライバシー」を組み合わせた使い方としては、「招待」者には編集を許して、ログインしない全ての人には閲覧だけを許すというケースが考えられる。

「ログインしていないユーザ」という表現が、「ログインしていないのにユーザとは?」という疑問を感じさせなくもないので、「ログインしていない全ての人に」くらいに改善した方がよいかもしれない。また、そもそもこの機能を指して「プライバシー」と表現するは適切なのか?という疑問もある。

Pathtraqで調べてみると

さて、先々週の土曜のこと。WIRED VISIONの記事を見た私は、日本でも間違えて設定している人がいるかもしれないと思い、11月23日の日記「Googleカレンダーでやってはいけないこと」のときと同様の方法で、「Pathtraq」で検索して調べてみた。

スプレッドシートのURLは、図1のように「http://spreadsheets.google.com/ccc?key=」で始まっているので、Pathtraqにそれを入力して検索してみた。すると、図2のように、たくさんのスプレッドシートがヒットした。

画面キャプチャ
図2: PathtraqでGoogleスプレッドシートがヒットした様子

これらが本当に公開を意図したものかを確認するために、ヒットしたURLをクリックして、スプレッドシートを閲覧してみた。

すると、Webサイト開発の行程管理表や、イベントの作業割当表、広告効果の集計表など、非公開と思われる業務文書ばかりだった。

これはまずいと思い、まず、Pathtraqを運営するサイボウズ・ラボに通報した。その結果、検索でヒットしないよう対策がとられた。

ここまでなら、「Googleカレンダーでやってはいけないこと」のときと同じパターンだが、この件はそうではなかった。これらは、利用者が設定を誤った(WIRED VISIONの記事のように)ためにこうなったのかと思いきや、そうではないのだった。

とんでもない事態に

Pathtraqでリンクをクリックしていくつかを閲覧した後、自分の「Googleドキュメント」のホームページに戻ってみたところ、図3のように、とんでもないことになっていた。

画面キャプチャ
図3: クリックした文書の共有者として登録されてしまった様子

つまり、Pathtraqでクリックしたファイルについて、自分が共有者として登録されてしまったのだった。墨塗りした部分には、他社の業務文書のタイトルと、その文書の作成者や共有者である、他社の関係者の名前が表示されていた。左側の「共有者別」のところには知らない人がずらっと出ていた。

この共有者別のところに現れたユーザをクリックしたところ、図4のように、その人のメールアドレスが表示されたので、それぞれのメールアドレスに事実関係をお知らせして、対処をお願いした。

画面キャプチャ
図4: 他の共有者のメールアドレスが表示された様子

招待メールのURLが第三者の手に

これはいったい何が起きたのか。ようするに、Pathtraqでクリックしたリンクは、Googleスプレッドシートの「招待」メールに記載されたURLだったのだ。よく見ると、クリックしたリンクのほとんどは次のようになっていた。「inv=」の部分に招待された人のメールアドレスが書かれていた。

http://spreadsheets.google.com/ccc?key=XXXXXXXXXXXXXXXXXXXXXX&inv=XXXX.XXXX@XXXX.co.jp&t=6389XXXXXXXXXXXXXXXX&guest

おそらく、このメールアドレスの人がPathtraqのツールバーを導入していて、Googleスプレッドシートの招待メールに書かれたこのURLをクリックしたときに、Pathtraqに登録されてしまったのだろう。

Googleスプレッドシートの「招待」機能を試してみると、招待メールは以下の文面になっている。

「共有招待テストのスプレッドシート」というドキュメントを共有したのでお知らせします:
http://spreadsheets.google.com/ccc?key=pxtiWyFxXXXXXXXXzteocaA&inv=test1@takagi-hiromitsu.jp&t=302490XXXXXX67684&guest

これは添付ファイルではなく、Google ドキュメントでウェブ上に保存されています。このドキュメントは上のリンクをクリックすると開きます。

Pathtraqのツールバーは、アクセスしたすべてのページ*1のURLを送信するものであるから、この種のメールでクリックしたURLも送信され、公開される。

招待URLを入手した人は誰でも共有者になれる

ここで問題点は2つある。

  • 招待メールの宛先メールアドレスは、Googleアカウントとは無関係なのか?
  • 招待メールの有効期限はいったいいつまでなのか?

Googleアカウントは基本的にメールアドレスがユーザ名であるから、図1の画面で共有者を招待するときに入力するメールアドレスは、Googleアカウントを指していると(直感的には)思えたが、実際にはそうではなかった。

実験してみたところ、「招待」で入力するメールアドレスは何でもよく、Googleアカウントに無関係なメールアドレスでもよい。とにかく、そのメールを手に入れた人であれば、誰でも共有者となれるのである。

図1の画面をよく見てみれば、うっすらとした色で「どのメールアドレスでも使用できます」と書かれている。これがその仕様を表しているのだろう。これは予想できなかった。

(注:これは、図1の「プライバシー」の設定とは関係なくそのようになる。つまり、「常にログインが必要」の設定であっても、招待メール(のURL)を入手したら誰でも(ログインすれば)共有者になれてしまう。)

画面キャプチャ
図5: 「どのメールアドレスでも使用できます」という仕様が明記されている様子

最初はバグじゃないかと思った(じつは、そういうバグがあるというタレコミを11月に頂いていた)が、これは仕様なのだろう。たとえば、何十人も招待する必要があるときは、メイリングリストに流してしまえば気楽に招待できる。ちょうど、今年の正月にグーグル社が「Google からのビデオ年賀状 2009」で実演していたような、おもしろ作業をするには適している。

招待メールの危険性

しかし、ビジネスで使うにはあまりに危険ではないか。招待メールの有効期限も不明である。

少なくとも、私がPathtraqで検索してクリックした招待用URLは、何か月も前に送信されたものだったのだろう。図3を見ると、2007年10月に作成されたものについて、招待URLが有効だったことがわかる。

Pathtraqのサービスが開始されたのが2007年8月なので、もしかすると、Googleスプレッドシートの招待URLは無期限に有効なのかもしれない。

こんなサービスは見たことがない。URLに認証キーを載せてメールで送る方式は、パスワードリマインダなどでも用いられているが、有効期限を数分程度に短く設定することで、どうにかセキュリティを確保しようとするものであるし、一回アクセスされたら無効化するものだ。

Googleの招待メールは、その性格上、有効期限は1日くらいは確保する必要があるだろうし、複数回のクリックも認めざるを得ないのは理解できるが、せめて、有効期限や有効回数を招待メール送信時に指定できるようになっているべきではないか。

このままでは、招待メールやそこに記載されたURLが、何らかの原因で第三者の手に渡った場合に、閲覧されたり改竄されてしまう危険がある。

「Googleドキュメントの共有はメールの添付ファイルより安全だ」などと言われているのを耳にしたこともあるが、これでは台無しだ。

Google Appsでは「ドメイン外では共有できない」の設定に

この危険は、Google Apps版のGoogleドキュメントでなら防ぐことはできるようだ。

Google Appsでは、管理者の設定で、当該ドメインの一般ユーザの利用形態を制限できるようになっており、「ドキュメントの設定」の「共有オプション」で、「このドメイン外ではユーザーはドキュメントを共有できない」に設定することができる(図6)。

画面キャプチャ
図6: Google Appsの「ドキュメントの設定」

この設定でなら、招待メールを入手した第三者がアクセスしても、共有者として登録されてしまうことはないようだ。

その代わり、社外の人との共有はできなくなる。もし、図6の設定で「共有できるが、毎回警告メッセージを表示する」にしたとしても、招待メールの送信時に警告が出るだけであり、招待メール(やそこに記されたURL)がひとたび第三者の手に渡ってしまったら、共有者として登録されてしまうことは防げない。

過去に招待メールを送信したファイルにも注意

今回はPathtraq側で対策されたが、他にも同様にURLが公開されてしまうサービスは存在し得る。

また、招待メールが何らかの原因でどこかで残存していて、いずれどこかで公開状態になってしまう可能性もあり得ると想定する場合もあるだろう。

そのような場合は、これから招待メールを使わないようにするというだけでなく、過去に招待メールを送ってしまったファイルは削除してしまった方がよいように思う。

スプレッドシート以外も同様か

ここまでは、Googleドキュメントのうち「スプレッドシート」についてだけ調べたが、Googleドキュメントには他に、「文書」、「プレゼンテーション」などがある。

これらは、共有設定に関する機能がバラバラで統一されていない(少なくともユーザインターフェイスを見る限りバラバラ)ので、同様の問題が起きるのかどうか、よくわからない。

「文書」でも、「招待する」という機能があり、メールで誘うようになっているが、「どのメールアドレスでも使用できます」とは書かれていない。しかし、試してみたところ、誰でも共有者になれてしまうようだ。

ただし、有効期限が短く設定されている可能性もあるので、同様の事故が起きるのかどうかは不明である。

追記(2日)

少しわかり難かったので本文を2か所修正した。冒頭の設定ミスの話と後半の招待メールの話は別で、設定がどれであっても、招待メール(のURL)が手に入れば誰でも(ログインすれば)共有者になれてしまうことを強調。

追記2(2日)

念のため再現手順と実験記録の画像を示しておく。

  1. いつものGoogleアカウント「blog」とは別に、3つのメールアドレス「test1」と「test2」と「test3」を用意し、「test1」と「test2」だけGoogleにアカウントを作成する。(「test3」のメールアドレスはGoogleアカウントとして登録しない。)
  2. いつものGoogleアカウント「blog」で、スプレッドシート「テスト1」を作成し、「共有」の「他のユーザと共有」で「プライバシー」欄を「常にログインが必要」としたまま、「招待」欄に、「test2」のメールアドレスを記入し、「送信」ボタンを押す。
    画面キャプチャ
  3. この直後に、ドキュメントホームを見る(リロードする)と、当該ファイル「テスト1」の共有者は「自分, Test2」となっている。(まだ招待メールからの閲覧をしていないのに。)
    画面キャプチャ
  4. Googleをログアウトし、ブラウザのcookieを全て消去する。
  5. Googleに「test1」でログインする。
  6. 「test2」のメールを受信し、招待メールに記載されたURLをクリックする。その結果、「test1」でログイン中なのに当該ファイルが閲覧できる。(招待されたのは「test2」のメールアドレスなのに。)
    画面キャプチャ
  7. この直後に、ドキュメントホームを見る(リロードする)と、当該ファイル「テスト1」の共有者は「Blog, Test2, 自分」となっている。(「自分」とは「Test1」のことである。)
    画面キャプチャ
  8. ここで、ログアウトし、文書の作成者である「blog」でログインし、ドキュメントホームを見ると、当該ファイル「テスト1」の共有者は「自分, Test2, Test1」となっていて、確かに「test1」が共有者として追加されたことがわかる。
    画面キャプチャ

  9. 同様に、Googleアカウントの存在しないメールアドレス「test3」に対して招待した場合についても検証するため、「blog」で新たなスプレッドシート「テスト2」を作成し、「test3」のメールアドレスに対して招待する。
    画面キャプチャ
  10. この直後に、ドキュメントホームを見る(リロードする)と、当該ファイル「テスト2」の共有者は「自分, Test3」となっている。(まだ招待メールからの閲覧をしていないし、test3に対応するGoogleアカウントは存在しないのに。)
    画面キャプチャ
  11. Googleをログアウトし、ブラウザのcookieを全て消去する。
  12. Googleに「test1」でログインする。
  13. 「test3」のメールを受信し、招待メールに記載されたURLをクリックする。その結果、「test1」でログイン中なのに当該ファイルが閲覧できる。(招待されたのは「test3」のメールアドレスなのに。)
    画面キャプチャ
  14. この直後に、ドキュメントホームを見る(リロードする)と、当該ファイル「テスト2」の共有者は「Blog, Test3, 自分」となっている。(「自分」とは「Test1」のことである。)
    画面キャプチャ
  15. ここで、ログアウトし、文書の作成者である「blog」でログインし、ドキュメントホームを見ると、当該ファイル「テスト2」の共有者は「自分, Test3, Test1」となっていて、確かに「test1」が共有者として追加されたことがわかる。
    画面キャプチャ

ちなみに、ドキュメントホームの画面で「共有者別」として表示される人々は、Googleのアカウントを表したものと直感的には思えるが、下の図のように、Googleアカウントが存在しない「Test3」が表示されており、これはそういうものではないことがわかる。Googleドキュメントで人はメールアドレスで管理されているということのようだ。

画面キャプチャ
図7: Googleアカウントが存在しない「共有者」「ユーザー」

それから、共有しているファイルについて、自分を共有から解除するには、そのファイルをゴミ箱に入れればよいようだが、それでうまくいく場合もあれば、うまくいかずに以下のエラーが出ることもある。

画面キャプチャ
図8: 共有解除しようとしても意味不明のエラーが出る様子

どういうときにこうなるのかわからない。エラーメッセージの「技術上の問題により、現在、すべての文書を表示することはできません」も意味不明だ。

ヘタに共有すると解除できなくなるので注意が必要と思われる。もしかして、グーグル社の人たちも、社内文書の作成や共有でGoogleドキュメントを使ってはいないのではなかろうか。

*1 https:// のページは除外されるらしい。

本日のリンク元 TrackBacks(100)

2009年02月04日

東京都情報公開・個人情報保護審議会を傍聴してきた

2月15日補足:日付を間違えていた。「今日は」とは2月3日のこと。2月3日の日記として書いたつもりが、2月4日で登録してしまっていた(書き始めたのは2月3日だが書き上がったのは2月4日の朝だった)。既にあちこちからリンクされているので変更はしない。


ストリートビューについてグーグル社との意見交換があるというので、今日は休暇をとって、東京都情報公開・個人情報保護審議会の傍聴に行ってきた。録音も撮影もOKとのことで、公開の場であることが強調されていたので、今回はメモはとらず、会話は録音して、会場の様子を写真やビデオに収めてきた。

グーグル社からは、執行役員で広報部長の舟橋義人氏とポリシーカウンセルの藤田一夫氏が出席し、主に藤田氏が説明と質疑への応答にあたった。事務局から前回議事録等への補足の後、藤田氏から25分ほどのプレゼンテーションがあり、その後、委員との意見交換が65分ほど続いた。

以下、録音を聴きながら重要な部分をかいつまんで要点をまとめた。グーグル側の発言はできるだけ発言に忠実な文にした。なお、傍聴して私が感じたことは脚注に記す。

前回審議会資料の事実誤認について

冒頭、事務局から次の説明があった。

「前回の審議会資料の中において、『グーグル社では人の顔や表札、ナンバープレートなどが判別できないようにぼかしを入れている』という記載がございましたが、この点については、『人の顔については自動認識によりぼかし処理を行っているが、日本ではナンバープレートについては解像度の問題でほとんど識別できないと思われるため、現時点では顔以外には自動的な処理は行っていない。表札についての自動認識によるぼかしは検討中。』とグーグル社が表明しているとのご指摘を頂きましたので、この点については、正確なところを本日、直接ご説明頂ければと思います。」

この点について、藤田氏のプレゼンテーションの中で次の説明があった。

「さきほどご指摘がありましたけども、顔は自動的にぼかしが入りますけども、車のナンバープレートはぼかしは入っておりません。ヨーロッパではナンバープレートは現時点でぼかしが入っております。この差はなぜなのかといいますと、ヨーロッパの方が画像がスペックが高くてはっきり見えると。日本のストリートビューの画像はヨーロッパよりも劣るものでございます。よって、ナンバープレートははっきりと認識できないという関係で、自動ぼかしは入れておりません*1。万が一、所有者の方やご家族の方に見えるんだというご指摘がありましたら、それはそれに従って削除するなりぼかしを入れるなり措置はこちらのサイドから取らせて頂きます。」

グーグル「自治体の意見書には事実と異なることが記載されていて残念」

最初に藤原静雄委員から質問:「これだけ多くの自治体、あるいは弁護士会、あるいは各種団体が懸念を表明しているが、それについてどう思うか。また、国内の現状は、現在進行形で粛々と進んでいるのか。」

グーグル藤田氏:「たくさんの地方自治体、弁護士会から頂戴していて真摯に受け止めております。全部ではないんですけども、ほとんどこちらに意見書にまとめられた内容というのは確認させて頂いております。まあ、意見書をまとめられるのは勝手(笑)、自由なものですから、(笑)止めることはできませんけども、内容をちょっと拝見しまして、けっこう残念なのは、具体名は申しませんけども、実は、事実と異なることを記載されていたというのがあります。たとえば、具体例で言いますと、カナダ・フランス等ではですね、条例規制等々ヨーロッパではストリートビューを規制するものがあるのだと、名前は申しませんが某自治体(笑)*2ではですねそういった記載がありました。それは非常に我々としては事実とは異なるので、残念だなあと思うのと同時に、我々のコミュニケーション活動がまだまだ足りないなと考えております。それから、2番目の質問ですけども、今後どういった町等々に展開するうんぬんかんぬんですけども、これはですね(笑)、なかなかちょっと社内上ですね(笑)、どこの町にストリートビューを展開するかは申してはならない(笑)ということがありまして、ご勘弁を願いたいと思います。するともしないとも現時点では言えません。」

正確を期すために動画で

再び藤原委員:「やるともやらないともわからないし、どこへ行くともわからないというお話だが、環境保護の世界にアセスメントというものがあるように、カナダでは、これは行政機関だが、プライバシー・インパクト・アセスメントと言って、個人情報を収集するといった影響を与えるだろうと事前影響評価手続きがあるが、それは公的部門なのだが、たしかにグーグルは民間の事業者だというのは承知しているが、これだけ世の中に反響を呼ぶことをするときに、こういうことをやったら世の中の人はどう思うだろうかとか、こういう結果がどう対処しようだとか、事前の手続き的なものはなかったのか。」

続けて藤原委員:「それから、先ほど(プレゼンテーションで)、情報の民主化を進めていらっしゃるとのことだが、民主主義は大変多様なものであって、かつ、民主主義は個人の参加を前提としているものであり、グーグルが情報の民主化と言われるのであれば、このサービスに関係する個々の個人が、事前に嫌なものは嫌、あるいは異議を申し立てる権利を事前に表明するというようなことは全く考えておられないのか。」

<中略>

続けて藤原委員:「今日頂いたパンフレットの『よくある質問』によると、「Q.規制を受けたことはありますか? A.ありません。」とあるが、事前調整はやっているわけですよね。事前の規制を受けたことはあるんじゃないですかね。たしかに、グーグルを狙った法律等はないけども、各種法律とどうなるかという調整を、先ほど(プレゼンテーションで)おっしゃられたようにやっているとのことなので、この『よくあるご質問』の書き方は必ずしも正確でない*3。『アドバイスを頂いて運営しています』と書いてあるのだから、やっぱり事前の調整はやっているんですよね? であるとすると、『規制を受けたことはありますか』というのは……、ドイツでは強硬に反対している自治体がございますよね? そこについて議論はしているのですよね? 」

高橋和之委員:「今の質問とほぼ同じになるかと思うが、この事業を始められる前に、デメリット、問題になりそうなことについても検討されたんだろうと推測しているが、内部の検討過程で、どういうことを検討をされたのか。プライバシーについて当然考慮されたと思う。主務官庁に相談はされていないのか。」

<中略>(主務官庁はないという話)

グーグル「日本にはプライバシーコミッショナーが無いので事前調整しなかった」

グーグル藤田氏:「プライバシーについて、サービス開始前に関係者への説明はなかったのかですけども、日本では関係者への説明というのはしておりません。今考えると、しておけばよかったなと。意図的にしなかったのではなくて、海外では、先ほど(プレゼンテーションで)表に見せましたように、サービス開始前に接触しているではないかとご指摘がありましたが、これは呼びつけられてなんかこう(笑)無理矢理行ったというのではなくて、我々から率先して自ら説明したいとして接触したもので、とくにそこに、こういった規制が法律があるがために、許諾を得るためという趣旨で訪れていたわけではありません。では、どうして外国と日本でそういった違いがあるのかと思われるかもしれませんが、各委員ご存じのように、海外には、プライバシーコミッショナーと言いまして、プライバシー専門の中央政府機関が存在していて、日本もプライバシーを扱っているのは地方自治体で各課レベルではありますが、国の、霞ヶ関の政府で、プライバシー専門に扱っている専門機関というのは、私の勉強不足かもしれませんが、存在していない、窓口がないと判断しまして、そういった関連もございまして、事前に評価等、検討をさせて頂きます機会がなかったというわけでございます*4。総務省、経済産業省も、我々の事業に関係していますけども、各省ともプライバシーを専門に扱う局、課というのは存在していないと認識しております。もしあれば、もちろん我々は行ってたと思います。」

<中略>

藤原委員:「今進んでいることについて、事後でなくて、事前に展開することは可能なのではないか。」

グーグル藤田氏:「今後新しくサービスを展開する地方自治体には事前にお知らせしていきたいと思います。事前調整というのは、今考えると、我々の反省材料と思っています。言い訳にはなるかもしれませんが、プライバシーコミッショナーが存在していないというのが大きな点でした。2番目としては、地方自治体に事前に協議の場を持てばよかったと、今となっては反省しています。

高橋委員:「ということは、プライバシーの問題はあり得るということの認識はあったわけですよね。始められる前に。」

グーグル藤田氏:「そうですね、あの、苦しい言い訳(笑)かもしれませんが、えーと、私じゃないんですが、ストリートビューを担当する者が、社内で法律を担当している者がおりまして、法律を担当している者が、個人情報保護法と道路交通法の法律のチェックをしていまして、プライバシーはもちろん議論の俎上にはのぼったんですけども、優先、そのときは、なんといいますか、深く検討していなかった。地方自治体と協議を持つべきだという声はなかったです。その後、私がこういった関係の職務をしておりますので、サービスほぼ直前に近いくらいのときに、こういったサービスを開始するということがありまして、プライバシーに対して<聞き取れず>したんですけども、まあ、今からではちょっと、詰めが甘かったと言わざるを得ません。今後はこういうことはないようにしていきたいと思っています。

高橋委員:「私は、なぜこういうことを訊いたかというとですね、デメリットがあるというご認識があればね、バランスの問題だと思うんですよ。メリットはもちろんある。しかしどういう場合にデメリットの方が大きくなるかということを考えられ得たんではないかと思うんですね。その一つの場合として、おそらく、住宅専用地域、これについていろいろ批判が出ていますよね。予め考えれば、住宅専用地域については除外するとしてもいいんじゃないかとする考慮が、なされなかったのかと、確認したいという意味があったのですよ。住宅専用地域でもメリットとしてさきほど説明、パンフレットにありましたけども、不動産業者が使うだろうとか、たしかにそれはメリットだろうと思います。でも、他方で、家というのもプライバシーだというご認識があればね、どちらの方を重視すべきかという考慮になり得たんでないかなという趣旨なんですよ。ですから、さきほどの説明では、家もプライバシーと理解しているから、要求があれば削除しましょうと、それはそれで解決方法であり得ると思うんですけども、もうひとつの解決方法としては、今後の問題として、住宅専用地域なんかはやはりデメリットの方が大きいんではないかというバランスのしかたもあり得るんではないかなと、意見として申しておきます。」

中村輝子委員:「さきほど、自治体の意見書について、間違いがあるとだけおっしゃったので、ちょとまだ、自治体の方から具体的な形で懸念表明されていることについて、グーグルの社内で本当にどこまでそれを、真摯に受け止めているとおっしゃいましたが、検討されておられるのか。」

<中略>

続けて中村輝子委員:「それから、顔のぼかしも自動的にとおっしゃったけれども、それにしてはずいぶん初めからいろいろ<聞き取れず>、つまりそれは、技術的な面、その他の情報提供ということのグーグル社側の、これでいいのかという<聞き取れず>どの程度なされたのか。」

グーグル藤田氏:「意見書の内容が誤りだったという点、自治体側に100%責任があるとは申しておりません。我々のコミュニケーションが足りなかったと。内容に関しては、ほぼすべて目を通させて頂いておりますし、全部ではないですが大方の地方自治体に連絡を取らさせて頂いて、どうしてこういう意見書を書かれたのかというのも問い合わせさせて頂いております。中には、ほとんどコピーペーストとい言いますか、ある地方自治体とそっくりな内容のものがあって、それについて私どもが質問したのですけども、特に、ヨーロッパやドイツ<聞き取れず>ある地方自治体がそういう意見書を書かれていたので、それを参考としてコピペしたというふうなことを(笑)言われまして、これはもうますます我々としては、待っているんではなくてですね、こちらから各自治体にはこちらからコミュニケーション活動をしてでも、積極的に<聞き取れず>思っております。で、どのくらい真摯に捉えているかと言いますと、ここに載っている自治体のみならず、他の地方自治体にもですね、機会あるときに連絡はさせて頂いています。そしてまたお問い合わせがありましたら、<聞き取れず>。今後は、<聞き取れず>。」

グーグル「カメラの高さを変えるとなると各国でバラバラになる」

続けてグーグル藤田氏:「また、住宅の指摘ですけども、これは、気持ち悪いとかですね、不快だと言わるともう反論の余地がなくてですね、非常に悩ましい問題でございます。<聞き取れず>こういった反応が起きるだろうという想像力が欠けていたというふうに認めざるを得ないと思います。カメラ高さで、塀を越えて中庭が見えるということがありますけども、車とカメラ高さは米国とおそらく一緒でございます。ご存じのように、米国では公道からといっても、一戸建てはかなり距離がありまして、とくに中庭が見えるというのに関しては、問題は、ゼロではありませんけども、それほど強くないと。日本の場合、一般の一戸建ての場合、公道に面しているという住宅事情がありましたので、そういったことを我々、事前にきちんと把握していなかったというのは、認めざるを得ないかと思います。今後は我々の教訓とさせて頂きたいと思います。」

続けてグーグル藤田氏:「で、実際にどうするかというのは、本国、それからストリートビューの担当の者、法務の者、役員ときちっと情報は絶えず共有しております。実際にどうするかですけども、まさに今、社内で議論中で、どう議論するかと言いますとですね、たとえばこう、カメラ位置なり仕様なりサービスのし方を変えるというのは、変えるのは物理的にできなくはないんですが、ひとつを変えると、アメリカもオーストラリアもヨーロッパもたくさんありまして、試行錯誤を重ねたのになぜ変えるんだという、なぜ日本だけそうカメラ位置を変えるんだという、社内の説明責任というのが出ます。日本がやるとなるとじゃ今度は、ベルギーでもフランスでもイタリアでもノルウェーでも、各国の要望があればすべてをその国に対応をして、もうバラバラなサービス展開ていうことも社内的にはあります。そうしますと、ストリートビューの写真を見た場合に、アメリカで見るものと、日本で見るものと、ノルウェーで見るものと、イタリアで見るものとバラバラになりかねないということがございます*5。だから何もしないってわけではないんですけども、こういったことは社員に激しい議論を要求しますので、これは、我々としては社内、外もそうですが、内側でも非常に激しい議論が要求されますので、軽々にこの場で、いついつどこまで(笑)<聞き取れず>(笑)社内で議論していくことは、日本だけでなくグローバルで議論していくことは間違いございません。」

堀部政男会長:「音声が聞き取り難いのはスピーカーのせいですか。調整してみてください。」

<中略>

藤原委員:「さきほど、データ保護当局がないからとおっしゃですけども、それは議論のすり替えじゃないですかね。データ保護当局がなくても、プライバシー侵害の危険があると思えばですね、法務部なり社内で議論を詰めるべきものであって、慎重に調査をすべきであってですね、日本での<聞き取れず>について。何もせずにやってしまって、後で考えたら、各国には保護当局があったというのは、後付けとしか発言がとれないと思いますけども。保護当局があるかどうかということと、プライバシー侵害があたることを知っててやっていいかどうかというと、なお悪いんじゃないかという気がします。」

続けて藤原委員:「それから、各国バラバラになってはいけないというグローバルな観点からとおっしゃいいますけども、今のグローバル企業というのは、多様性を、地域の多様性を認めると言っているのではないかという気がしますけども。とくにプライバシーの問題というのは、当該国の文化等によって規定されるされるわけですから、その多様性、固有性、個性というのを尊重してこそグローバル企業ではないかと私としては申し上げておきたい。バラバラになるからできないっていうことだと、不安に思っている方々に対しての説明になっているのかなと。」

<中略>

修正前のデータは消去されているのか

続けて藤原委員:「それから質問ですけども、さきほど、表札とか顔でも、顔がきっちり認識されるもの修正しますとのことでしたが、修正される前のデータは誰がどう保存しているのですか。つまり、表札消すわけですよね。削除するわけですよね。削除前のデータは必ず消去されるのですか? これは文字通り個人情報保護法上の問題ですよね。<略>」

<中略>

グーグル藤田氏:「最後の部分だけが質問というふうに捉えてよろしいでしょうか。」

藤原委員:「元データはどうしているのですか?」

グーグル藤田氏:「元データは保管しております。」

藤原委員:「ああそうですか、個人情報保護法上、元データを保管しているとしたら、取り扱い事業者……」

グーグル藤田氏:「元データ削除です。元データ、削除された画像ということですか?」

藤原委員:「削除する前の画像は保管されておられるかどうか。」

グーグル藤田氏:「保管、保管はしてないです。」

藤原委員:「削除後も、保有しておられるのかどうかという。」

グーグル藤田氏:「保存していないです。はい。」

正確を期すために動画で

<中略>

高橋委員:「グーグルさんとしては個人情報保護法上の個人情報ではないという理解で事業を展開してこられたのかなと推測しているのですが、まあこれ難しいのですけどもね、住宅なんかは、プライバシーの問題は別にして、個人情報保護法上の個人情報になるかどうかですね、名前住所がわかれば出てくるわけですね。そうすると容易に照らし合わせて判別できるということになり得るんではないかという、今のところ私自身は考えているのですが、個人情報保護法の適用内に入って来得るんではないか、まあちょっと難しいんでですね、もっとよく考えてみないといけないと思ってるんですが、仮に個人情報保護法が適用されるとした場合には、個人情報保護法で要求していることを考慮して、違反しないように事業をしていっていただかないといけないことになると思うんですが、そういった点についてどうお考えになるのか。たとえば、第三者提供を目的とした事業ですけども、その場合に、情報を違法に取得しちゃいけないというのがありますよね。騙して取ったりしちゃいけないというのが中心になっているかもしれませんけども、私自身は、プライバシー侵害的に取得するのも違法な取得に入ってくるんではないかなというふうには思っているんですよ。特に住宅地域なんかを、相手の同意なしにバッと写していくということですね、これは違法取得に該当するかもしれないという問題が、出てくるかなという気がしますし、オプトアウトはやっていらっしゃるとそれはよいのですが、第三者提供を目的とした事業の条件というのがありますからね、それとの関連を詰めてもらったほうがよいかと思います。」

<中略>

藤原委員:「私がさきほど個人情報ということを申し上げたのは、原則的に個人情報データベースに当たるかという議論が難しいことを前提に、そうじゃなくて、表札とか顔がわかる元データを、完全に個人を認識できるものをずっと、提供しているものとは別に保管しておられたら、それは別の次元の話になるのではないかと、そういう意味でございます。」

グーグル藤田氏:「住所を打ち込むとその場所が表示されます。ただ、名前を打ち込むと本人の自宅とか勤め先が出るとかそんなサービスは一切持っておりません。ただ、個人情報保護法に関して、あるいはプライバシーに抵触するので撮影すること自体が違法ではないかという点については、貴重な専門家からのご指摘と受け止めまして、社内で検討させていただきたいと思います。」

<中略>(どうやって利益を得るつもりなのかの質問とその回答)

グーグル「今後は各国事情を考慮する」

中村委員:「各国でばらばらになるとさきほどおっしゃいましたが、まさに各国事情というものを考えなければならない技術であるというのが、前提ではないかと思うんですね。表札ひとつとっても、これは日本の社会の独特なひとつの表現の形態でありますし、東京都など大都市の、住居と公共施設が非常に混在しているあり方、大規模な都市であること、こういうことひとつとっても、ベルギーの町とかですね、同一の基準、同一の価値観で運営できるわけがない。ですから、そういうようなことも全て含めてですね、これからになるかと思うんですけども、そちらとしては本社に対して、それこそ説明責任を持たねばならないんではないかと思うんですね。最初からアメリカで発信された<聞き取れず>ということだけで情報の民主主義というのは語れないのではないかと思います。」

グーグル藤田氏:「各国事情を考慮する。おっしゃった通りかと思います。最近、日本代表の社長が替わりまして、プレスの方々にも説明しましたが、今後は対外的な説明責任を新体制では旧体制と違って、率先して活動していきたいと思っております。それは、当然本社等、海外等を含めて、ポリシーチームというのが社内にありまして、かなりこの問題には意見を述べておりまして、かなり煙たがられている状況です。日本の事情をかなり上げていて、日本はなんでそんなにリクエストが多いんだと言われるくらいにやっております。もちろんそれで十分だとは認識しておりませんで、さらにもっとうるさいと思われても、社内調整を今後進めていきたいと思っております。」

グーグル舟橋氏:「ちょっと補足させてください。各国事情を配慮するというのはまさしく今後そういう戦略、方針で行きたいというふうに考えております。会社としてですね。責任、ストリートビューに関しても、説明すべきところは説明し、製品の仕様、サービスのあり方を改善すべきところは改善して、技術的に解決できるものもございますので、技術的にもチャレンジしていくというのが今後の方針です。」

堀部会長のまとめ:前回の11月25日と今日2月3日、当審議会としてはストリートビューについてとりあげました。今日は直接話を聞いてまた質問をしていただいた、こういう機会<聞き取れず>。一昨年からこういう個人情報とかプライバシーに関わる会議では何かにつけて話題になってきたテーマでして、そういう中でいろいろ議論してきた点からしますと、今日の委員の点など踏まえて、こういうふうなことが言えるのではないかと思います。一つは、グーグル社としてテクノロジーの発展を最大限利用して、世界中の情報を<聞き取れず>されていくと。それはひとつ重大な意味を持つと思います。その場合にどうしても現行の法のコンセプト、あるいは現行法とうのをどう見ていくのか。これはテクノロジーの発展、テクノロジーをどう発展させていくのかというのは、現在の法がどうであろうということをむしろ無視してでも、一々どの法律に照らしてどうなのかということを考えながら進めていくというのはまあないわけで、むしろ現行法には違反してでもどんどんテクノロジーを発展させていくということがあります。たとえば、これはよく言われる例でいきますと、グーグルの検索システムというのも、日本の著作権法との関係で問題があるわけですが、アメリカではフェアユースの考え方もあって、<聞き取れず>ということは可能だし、コンピュータも国内にあるわけではないから日本の現行との関係では、日本ではそれについて<聞き取れず>。この検索システムが発展して大変便利なものをこちも利用しておりますけども、逆に日本の著作権法の改正をどうするかとこういう議論になってきておりますよね。そういう点で、技術の発展と現在の意識あるいはそれに支えられている法というものとの関係というのは常にあるわけで、技術的にできるから現行法を無視していいのかというとなると、やっぱり、公的ルールとの関係で何か考えなければならないということはあるのではないかと思います。もう一つは、グーグル社はグローバルな企業でして、そのためにどうしても、特にアメリカのスタンダードに基づいて技術についても考えるという傾向があるように思います。これは他のグローバルな企業の方と議論していても、だいたい他のそうですね、国の考え方で各国の事情などはあまり考えないで<聞き取れず>しているということもあるわけでして、そういう中で、しかし一方では、これだけ多様化している世界の中でそれぞれの文化なり考え方なり、先ほどからも出ていますように、日本の場合では住宅地では表札を掲げるというのが慣行としてありまして、中には家族の名前まで掲げているところもあるわけですね。イギリスとかアメリカですと表札はない。ストリートの名前と番地だけで、実際家族と生活してみましても、前に住んでいた人の手紙がどんどん来るわけです。場合によってはそれは請求書であるようなものも入ってきていますが、いちおうポストマンにはこの人はもう住んでいないからと対処していましたが、そこも表札でその家に住んでいる人が誰であるかということを日本では重視するのに対して、少なくともイギリス、ロンドン市内ですが、アメリカでもハーバードの近郊などですと、そういったことはないといったことからしますと、そういうアメリカ的なスタンダードで見ていくと、日本社会との軋轢がやっぱり生じてくる。いろんな住宅の<聞き取れず>についていろんな意見が日本で特に出てきたということもあるのですが、そういった違いがあるからではないか。そういったあたりを今後どうしていくのかというのがあります。そういう中で、今日の議論で結論を出してどうするという話ではないんですが、今日いろんな意見が出ましたので、それをもとに、またおそらくこういう形で各委員がそれぞれ良識ある観点から意見を述べるというのは非常に貴重だと思いますので、ひとつひとつは申しませんが、今日出された意見などにつきまして、グーグルでも少しご検討頂いて、もし可能であれば、3月にこの審議会開かれますので、回答を頂ければと思います。特にその中で、当審議会の事務の範囲で言いますと東京都の個人情報保護条例なのですが、国の個人情報保護に関する法律、この中で、法律に基づいて自治体がというのもございますので、ここでは単に東京都の個人情報保護条例ばかりではなくて、個人情報保護法も含めて議論することになると思います。プライバシーの問題というのは<聞き取れず>、個人情報保護法との関係について、今日も個人情報に当たるのではないかという意見もありました、あるいは個人情報保護法の適用もあるのではないかという意見もありました。そのあたりをグーグルとしてはどのように考えられるのか、個人情報保護法の適用があるとなりますと、法律に従った通知をしていかなければならない。前回も出たんですが、プライバシーポリシーを見ていても、ストリートビューについては、11月に見た範囲では、全然書いてない。そうしますと、そこはどうなのか。それと、要請があれば削除はしますとなると、これも個人情報保護法23条2項のオプトアウト類似のもの、となると、グーグル自身も個人情報保護法の適用をいちおうあると観念しているようにも見えるんですね。そうでないとたぶん言われると思うんですけども。そういうふうになっていきますと、それぞれの程度の関係でどうなるかということもあろうかと思います。その他、海外の状況も今日ご説明頂いた<聞き取れず>、それぞれの法文化といいますか、リーガルカルチャーというのがありまして、それとの関係で考え方も違いがあるという点が、どうしてもグーグルのようなグローバルな企業からすると、そのあたりをどこまで各国の法文化、法を念頭においてサービスを提供するのかというあたりは、おそらく、技術の面、グローバルな面からしますと、あまりそのあたりを考えずに展開されているということかと思います。しかしどうしても、具体的なサービスとの関係では問題が出てきますので、そういう点についても、どうしたらいいのかということについては、ご回答頂ければと思いました。ということで、いずれにしましても事務局の方でまとめて頂きます。ということで、最後に、いろいろさらにご発言されたいこともあるかと思いますので、ぜひおきかせ頂きたいと思います。

グーグル藤田氏:「本日は、お招き頂き大変ありがとうございました。皆様からの貴重なご意見ご指摘を頂きまして、これはきちっと社内に持ち帰りまして、必ず検討させていただきたいと、もちろん日本だけでなく他国のオフィスの方にもきっと<聞き取れず>させて頂きます。地域の事情への我々の判断が足りなかったのではないかと思います。グーグルという会社は、舟橋も私もエンジニアではないのですが、エンジニア中心の会社で、新しい技術はどんどんどんどん開発していって、リーガルとか倫理とかというのは、チェックしないわけではないんですが、最優先事項ではない、イノベーションが第一というのがあったかと思います。ただ、そうは言っても、創立10年を越えまして、大人の会社といいますか、成熟した会社としての振る舞いというのは今後求められていくんはないかと思います。そういった面で、関係者の皆さまとエンジニアではない私どもがコミュニケーションをとりながら、どうしたら各国で、受け入れられるのか、法律のみならず、習慣にも敏感に感じ取って社内に共有して事業を運営していかなきければならない。同時に、エンジニアの方はなぜそんなことをやらなきゃいけないんだ。イノベーション、イノベーションなんですけども、社内調整に非常にエネルギーを使うんですけども、これはもう成熟した大人の会社運営に向けてですね、越えなければならないハードルだと思っております。今後は機会があればいつでも我々はオープンにしてですね、ご質問やご意見を賜ればいつでも<聞き取れず>。本日はどうもありがとうございます。」

グーグル舟橋氏:「本日はこういう機会を与えて頂いて本当にありがたく思っております。今後、グーグルの考え方を皆様により深く正しくご理解頂くために、できるだけこういう場には出席させて頂いて、いろんなご説明を差し上げたいと思いますので、ぜひまた機会を頂ければと思います。それから、さきほど、エンジニアが強くて、リーガルが甘いという話がありましたが、そんなことはありません。強力なリーガル部隊がおります。しかしながら、各国の事情、文化、風習などを考えるとですね、各国でサービスを展開していく上で、それだけでは不十分であるということが、明らかになりつつあるのかなあというふうには感じております。その辺は、今後グローバルな企業としてですね、しっかり強化していかなければならないと思っております。本日はありがとうございました。」

<以上>*6

関連報道:

2月15日追記

「堀部会長のまとめ:<略(あとで)>」と記載していた部分について、堀部会長のまとめ部分を書いた。

*1 画像が荒いせいで画像処理によるナンバープレートの自動認識がうまくいかないというのが、本当の理由ではないだろうか。ヨーロッパでは、プライバシー法制上、ナンバープレートの消去が必須で、そのため、高解像度の撮影システムを用意するまで始めることができなかったというのが、本当のところではないだろうか。

*2 笑いながら話す癖のある人はよくいるけれど、なぜそうなるのだろうか。笑わずに話した方がよいのに。

*3 私もそれは思う。ナンバープレートの件ひとつとってみても、ヨーロッパでは消さずには開始できなかったという点で既に規制されている(日本とは違って)。

*4 これは正論だと思う。日本のプライバシー法制が根本的なところから立ち後れているのが、事態の根源と思う。

*5 むしろ、現状の方が、見えるものが違っている。なぜなら、住宅環境の異なる国に同じ仕様を適用したのだから。まさに、見えるもののレベルを合わせるためにこそ、仕様の方を変えるべきだ。

*6 削除要請の件数、実際に削除された件数はどれだけなのか、他国と比べてどうなのかについて、委員からの質問はなかった。答えないにしても、答えられないという回答が議事録に記載されることに意義があるのに、残念。「今後は機会があればいつでも我々はオープンにして、ご質問やご意見を賜ればいつでも」と言う一方で、削除の件数は答えないというのはおかしいのではないか。

本日のリンク元 TrackBacks(100)

2009年02月07日

ターゲット公共広告「AC4ny」を開始

先月25日の日記で書いた「行動ニーゲティング広告」のひとつとして、Winny利用者に向けたメッセージを表示する公共広告「AC4ny」を実験的に設置してみた。Winnyを使用中のIPアドレスからこの日記にアクセスした際に、図1のメッセージを表示する。

画面キャプチャ
図1: Winnyを使用しながらWebを閲覧した際の画面

ただし、最大約2時間遅れで反映される*1ので、その間にIPアドレスが変わっていた場合、自分は使っていなくても、そのIPアドレスの前の使用者がWinnyを使っていた場合に、この広告が表示されることも起こり得る。また、ケーブルテレビ系ISPなど、NAT内からのアクセスになっている場合、自分は使っていなくても同じアドレスで誰かが使っていれば、この広告は表示される。

ざっと過去のアクセスログと突き合わせてみたところ、この日記の閲覧者のつこうてる率*2*3は、平常時で 1% 弱、特別に関心を呼んでいるケースで 2% 弱くらい*4のようだ。

追記(8日)

これを発展させれば、流出ファイル収集家や、ウイルス入りファイル頒布者、児童ポルノ収集家などに向けて、それぞれにそれ相応のメッセージを出すこともできる。ただ、そこまでやってよいのかどうかだ。

2006年から稼働させているクローラでも、すべてを記録しているわけではない。ノードに接続すると先方から検索クエリが送られてくることもあり、そこにはどのファイルをダウンロードしようとしているか、どんな検索をしているかが書かれているはずだが、プライバシーに配慮して(検索サイトで検索語のログを不用意に公開したりしないのと同様に)これまでは記録してこなかった(クラスタワードは記録しているが)。

一方、キー情報は、不特定多数に向けてファイルを送信可能にしていることを示すものであり、プライバシーを主張するべきものではない。不特定多数への送信は、送信可能にする者が自覚を持って責任を負うべきことであるからだ。そのように考えて、これまではキー情報を中心に観測してきた。

ただ、実態解明の目的で、検索クエリの内容を集計することも有意義かもしれず、今後どうするかはわからない。

追記(8日)

ちなみに、「特別に関心を呼んでいるケース」とは、具体的には1月3日と24日で、通常の倍くらいになっていた。なぜこれらの日がそうなのかは謎だ。

*1 直前のクローリング一回(巡回の一周)で観測されたキー情報に記されたIPアドレスを用いている。巡回の一周に約1時間、キーの有効期限が25分、データのアップデート間隔が20分なので、最大約2時間前に使用していたものが反映される。隣接ノード情報を使用していないので、キーを発信せず稼働しているだけのノードは「使用中IPアドレス」と判定されない。最初は、隣接ノード情報も含めて(クローラで検出している全ノードを使用して)いたが、隣接ノード情報はかなり長時間にわたって残存するようで、(IPアドレス変更時の)誤判定率が高くなりそうなので、それは除くようにした。これを除いたところ、当該アドレスは約10万個から約4万個に減った。たまたま一回の巡回でキーが観測されなかっただけでも対象外になるので、何周か分をまとめた方がよいかもしれないが、そうするとIPアドレス変更時の誤判定率が高まる。このあたりの調整は難しい。余談だが、じつは同様に、ノード数調査においても、隣接ノード情報を含めて用いていることは、実際よりもノード数を多めにカウントしてしまっている疑いがある。隣接ノード情報の残存期間とノード数カウントへの影響量について調べる必要がありそう。金子勇著「Winnyの技術」には、「ノード情報テーブル」から古いノードをどういう条件で破棄するかについての記載がない。おそらく、接続を試みて接続に失敗するまでは残存し、その間にも他ノードへ隣接ノード情報として配布してしまっていると思われる。昨年9月に参加した「P2P の現状 〜Winnyp の解析と P2P ノードの見せる化〜」で発表のあった「見知らぬ接続要求を受信する」事象の継続時間の件も、主に隣接ノード情報が影響したものだろう。一旦使用をやめたWinny利用者が、何日か経って再び使用し始めたときに、Winnyは古い隣接ノードへ接続することになるので、それがこの事象をもたらすし、クローラも有効なノードとしてカウントしてしまう。

*2 IPアドレスの割合であり、人の割合とは一致しない。たとえば、平日のこの日記の閲覧者の多くは企業からのもので、アクセスログにはプロキシやファイアウォールのIPアドレスで記録されるため、かなり多くの人が1つのアドレスで記録されている。そのため、人の割合としては、母数が大きくなるので、つこうてる率はより小さいと考えられる。

*3 ボットアクセスを可能な限り集計から除いている。

*4 現在の使用中アドレスを、過去の(1月1日から昨日までの)アクセスログのアドレスと突き合わせたたところ、平常時で 0.5% 〜 0.8% だった。日に日に増加しており、これは、古い日はIPアドレスが変わっていてカウントされないことを示している。リアルタイムの突き合わせならば、これより少し多くなると思われるので、1% くらいではないかと予想する。これは後日集計する予定。サイトごとに訪問者のつこうてる率を表示できるようになると面白そうだが……。

本日のリンク元 TrackBacks(100)

2009年02月14日

「poeny」の使用は禁止できるか

1月25日の日記で、「ある国立大学の事務系部局のものと思われるドメイン名のIPアドレスが、2006年からずっとWinnyネットワーク上に観測されている。これは何なのかと以前から気になっていた。」と書いた件、その後の調査で、それはWinnyではなく「poeny」であることが判明した。*1

2009-02-09.12:14:20 ***.jimu.********-u.ac.jp/133.**.**.***: Command 0: versionNumber=12710, versionString=Winny Ver2.0b1 (poeny)

ポエニー(poeny)」とは、2006年初めに開発された、Winnyプロトコル互換のファイル共有ソフトであり、Winnyからいくつかの機能があえて削られたものである。

poenyのWinnyとは異なる主な点は次の通り。

  • poenyは、Winnyの最大の特徴であるところの「中継」動作をしないように作られており、自分が知らないファイルを公衆送信してしまうことがない。
  • poenyは、Winnyのような自動ダウンロード機能を用意しておらず、Winnyにおける「地曳」(検索語にマッチする任意のファイルを根こそぎダウンロードして共有状態にする)のような使い方を想定していない。

これらの性質から、自分が意識的にダウンロードしたものしか、公衆送信可能化することがないため、意図しないファイルの共有に加担することがない。これは、BitTorrentと共通する性質であり、完全に適法な用途で使用することも可能なように設計されたのだと思われる。

poenyだけでファイル共有をしようとすると、おそらく効率が悪く、BitTorrentを使った方がよいと思われるが、poenyは、Winnyとプロトコル互換であり、Winnyネットワークに参加することができるため、Winnyネットワークに既に流通しているファイルをダウンロードできる点で、意義があるのだと思われる。

また、poenyは、Winnyの「port0」機能にも対応していないため、外部からのTCP接続を受付けない環境(ファイアウォールやNAT内のコンピュータ)で使用すると、ファイルの公衆送信が一切行われなくなり、ダウンロード専用として使うことができるものと理解している。(確認していないので、間違っているかもしれない。)

さて、昨今、会社や団体が従業員や職員に対して、私生活においてまでWinny等の使用を禁止し、使わないと誓わせるようなところまで現れてきているが、それらは、いったいどのような正当な根拠でもって、従業員の私生活を縛るのであろうか。

それについては、2007年2月25日の日記に書いたことがある。つまり、Winny等は違法性のない使い方をするのが難しいソフトウェアであるので、私生活においても違法性のある行為は厳に慎むよう求められる職業の者(たとえば警察官)に対しては、私生活での使用を禁止するというのも正当性のあることではないか、と書いた。

では、BitTorrentはどうであろうか。公衆送信すると違法になるファイルをダウンロードしてはならないことさえ理解し、それを遵守して利用するなら、使うことに問題はないはずだ。どういう根拠でもって、私生活でのBitTorrentの使用を禁止できようか。

ならば、poenyはどうだろう。禁止することができるだろうか。

私生活でのWinny等の使用を禁止する根拠として他にあり得るのは、「漏洩事故をひき起しやすいから」というものであるが、それはどういう基準で決められるのか。たしかに、Winny等にはそれを標的にした暴露ウイルスが蔓延しているという現実があるから、使用を禁止するというのもわからなくもない。今のところ、poeny経由でファイルを流出させられるようなウイルスは出回っていないと思われる。ウイルスが出てきたら禁止ということになるのだろうか。

しかし、この理屈を突き詰めると、電子メールも危ないということになるし、より発展的なウイルス(Winnyを使っていなくてもWinnyネットワークに接続して放流するようなウイルス)が登場した際には、インターネットに繋ぐこと自体が危ないという話になってしまう。注意喚起くらいならともかく、私生活での使用禁止の根拠となり得るのか。

もうひとつのあり得る根拠は、ファイル共有ネットワークに出回っているファイルは、出所不明なものがほとんどであるから、危険なのでそういうのを拾うことがないよう、使用禁止だとする理屈だ。Winny等では実際そうかもしれない。

しかし、BitTorrentでは、信頼あるサイトに置かれた .torrentファイルからダウンロードするようにしていれば、安全に使うことができるのであるから、一律にBitTorrentの使用を禁止する正当な根拠とはならない。poenyでも、(公衆送信が適法であるファイルについて)信頼あるサイトに掲示されたファイルID(ハッシュ値で表記される)だけ使うようにすることで、安全に使うことも可能だろう。

出所不明なファイルが危険だからという根拠を突き詰めると、怪しいWebサイトも見るなということになる。私生活で怪しいWebサイトを閲覧することを禁止するのが妥当だとは思えない。

そもそも、業務上の外部への持ち出しが禁止されるべきファイル(その組織によって規定されるべき)を、私生活に持ち込むことが誤りであるから、その禁止事項さえ遵守されていれば、従業員が私生活でウイルスに感染して何が起きようとも、雇用主にとっては無関係のことであるはずだ。たとえ、会社に関係するファイルが流出したとしても、持ち出しが禁止されるべきとまでは言えないファイルであれば、流出しようが非難されるべきことではない。

それにもかかわらず、その程度の流出事案で糾弾しようとする輩が現れてくるのは、当事者が、何の目的でそれらのファイル共有ソフトを使っていたかが(ウイルスによって暴露されたことにより)問われる(ことが慣例化してしまった)からだろう。

しかし、現行法では、ダウンロードだけで違法になるファイルというものは存在しないのであるから、共有状態になる(ダウンロードしたものが公衆送信可能化される)ことを何らかの方法で防いでいれば、非難されるほどのことではない。糾弾されるのは、たいていの場合で、そのような対策はとっておらず、共有状態にしていたに違いないと疑われるからである。

このように話を整理した上で、最初の話に戻る。

大学でpoenyを使用することは許されるだろうか。しかも、そのpoenyのポートは解放されておらず、ダウンロード専用になっている場合において。

ダウンロードしかしないし、自動運転もしないとなれば、Webの閲覧と何が違うのかということになる。

もちろん、組織内のネットワークを使うのであるから、組織はどのようにでも利用規程を定めることができるわけで、変なもの(たとえば猥褻動画等)をダウンロードすること自体、Webの閲覧も含めて、禁止することは可能だろう。大学によっては、Webの閲覧にフィルタリングをかけて、猥褻サイト等の閲覧をできなくしているところもあるかもしれない。

だが、大学というところは、そこまで厳格な管理をしなくてはならないものだろうか。個人的には、大学はある程度自由であるべきと思う。大学でもWinny等の利用が禁止される主な根拠は、違法な公衆送信が行われる可能性が高いからではないか。1月25日の日記で例に挙げた(poenyの件とは別の大学の)事例では、Winnyで違法な公衆送信が行われている様子だったからこそ、即刻対処されたようだった。

そのように考えると、ある国立大学で稼働しているpoenyについては、外からとやかく言うことではないとの結論に至った。当初は大学に通報した方がよいかとも考えていたが、出過ぎた真似であると思うので、通報しない。

ただ、事務系のパソコンでpoenyが何年にも渡って使われ続けているというのは、ちょっとどうかなという気はする。*2

poenyノードはごく僅か

Winnyノード数の調査で運転しているクローラに手を加えて、接続先がpoenyかどうかを記録するようにしてみた。その記録を元にpoenyのノード数を調べてみたところ、次のようになった。

2009年2月12日の24時間の観測で、見つかったpoenyノードは、92個。
(ただし、こちらから接続できないノードはpoenyかどうか判明しておらず、これに含まれていない。)

この日のWinnyノードは全体で約18万個なので、poenyの占める割合はごくわずかのようだ。

*1 1月25日の時点では、クローラで観測したキー情報だけからこのノードの存在を推定しており、このノードはこちらからは接続できないものであったため、本当に存在するとの確証はなかった。そこで、接続を待ち受けるWinnyプロトコル互換プログラムを作成して、先方から接続してくるのを待ち構えていたところ、2月9日と10日にこのアドレスから接続が来たことを確認した。

*2 本当に事務職員が使っているのかはわからないが、こちらの観測では、平日だけ、朝10時ごろから午後4時ごろまでの間で観測されることから、事務職員によるものである可能性は高いように思える。もしかすると、空運転(何もダウンロードしていない)していて、そのパソコンの使用者はそれが稼働していることに気付いていないのではないかとも考えたが、検索キーワードが飛んできたので、どうやら人が意図して使っているようではある。

本日のリンク元 TrackBacks(100)

最新 追記

最近のタイトル

2024年11月11日

2024年07月28日

2024年07月27日

2024年07月07日

2024年04月07日

2024年04月01日

2024年03月23日

2024年03月19日

2024年03月16日

2024年03月13日

2024年03月11日

2023年03月27日

2022年12月30日

2022年12月25日

2022年06月09日

2022年04月01日

2022年01月19日

2021年12月26日

2021年10月06日

2021年08月23日

2021年07月12日

2020年09月14日

2020年08月01日

2019年10月05日

2019年08月03日

2019年07月08日

2019年06月25日

2019年06月09日

2019年05月19日

2019年05月12日

2019年03月19日

2019年03月16日

2019年03月09日

2019年03月07日

2019年02月19日

2019年02月11日

2018年12月26日

2018年10月31日

2018年06月17日

2018年06月10日

2018年05月19日

2018年05月04日

2018年03月07日

2017年12月29日

2017年10月29日

2017年10月22日

2017年07月22日

2017年06月04日

2017年05月13日

2017年05月05日

2017年04月08日

2017年03月10日

2017年03月05日

2017年02月18日

2017年01月08日

2017年01月04日

2016年12月30日

2016年12月04日

2016年11月29日

2016年11月23日

2016年11月05日

2016年10月25日

2016年10月10日

2016年08月23日

2016年07月23日

2016年07月16日

2016年07月02日

2016年06月12日

2016年06月03日

2016年04月23日

2016年04月06日

2016年03月27日

2016年03月14日

2016年03月06日

2016年02月24日

2016年02月20日

2016年02月11日

2016年02月05日

2016年01月31日

2015年12月12日

2015年12月06日

2015年11月23日

2015年11月21日

2015年11月07日

2015年10月20日

2015年07月02日

2015年06月14日

2015年03月15日

2015年03月10日

2015年03月08日

2015年01月05日

2014年12月27日

2014年11月12日

2014年09月07日

2014年07月18日

2014年04月23日

2014年04月22日

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|
最新 追記