<前の日記(2009年01月31日) 次の日記(2009年02月04日)> 最新 編集

高木浩光@自宅の日記

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

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件) [TrackBack URL: http://takagi-hiromitsu.jp/diary/tb.rb/20090201]
検索

<前の日記(2009年01月31日) 次の日記(2009年02月04日)> 最新 編集

最近のタイトル

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|
<前の日記(2009年01月31日) 次の日記(2009年02月04日)> 最新 編集