はてなフォトライフが実はプライベートな画像を全世界に公開している件
タイトルは釣りですJK。はしたなくてすみません。
以前書いたEye-fiを手に入れたので利用できる有料オンラインストレージサービスを比較検討してみた以降、Flickrの有料アカウントを利用してフォトライフを送っています。無意識的に何気なくパシパシ撮っていた画像がお構いなしにすべてUPされてしまうので、ひたすら便利なもののセキュリティという意味ではトレードオフかななんて思いつつ使っています。
さて、はてなフォトライフやFlickrに代表されるオンラインストレージサービスですが釣りタイトルのように、例えプライベートフォルダを作成して保存をしている画像であっても第三者に表示されてしまう、ということはご存じでしょうか(有名な話ですが)。
例をあげてみます。
id:komatakアカウントのプライベートフォルダにはハンバーガー食べてるkomatakさんがいらっしゃいました。このURLです。
http://f.hatena.ne.jp/komatak/20090125124416
ここは他の方にはアクセスできないURLになっています。当の本人でも一度ログアウトして再度上記URLにアクセスすると、私はWebブラウザ的な意味でkomatakさんではなくなっているので、プライベートなページにはアクセスできません。
GET /komatak/20090125124416 HTTP/1.1 Host: f.hatena.ne.jp HTTP/1.x 302 Found Location: /
その際のHTTPヘッダー情報です（抜粋）。Location: / 302リダイレクトではてなフォトライフのTopへと案内されました。
しかし画像「ページ」には有効なこのフィルタリングが、画像「リソース」に対してこのフィルターは有効ではありません。この写真リソース(komatakさんのハンバーガ.jpgのこと)のURLは
http://img.f.hatena.ne.jp/images/fotolife/xxxxxxx/xxx/xxx.jpg(xx部分は適当なものにしました)
という形になっているようですが、このリソースには誰でもGETできちゃいます。こんな感じ↓
はてなフォトライフのヘルプを確認すると、
公開範囲を指定する
特定のはてなユーザーや、なぞなぞに回答できた相手だけに写真・動画を公開する、「公開範囲」を設定することができます。手順2の際に「新しい公開範囲」を選択してください。
とのことですが、確かに写真「ページ」にはアクセスコントロールが可能なのだけど写真「リソース」に対してのアクセスコントロールは行っていないということになりますね。
Flickrの場合
このやり方を採用しているのははてなフォトライフだけではありません。私がEye-fiで絶賛利用中のFlickrも同様だったりします。
昨日作ったカレーの写真ページです(最近話題のcookpadの中毒チキンカレー！)。このページを同様にプライベートな扱いにしています。
アカウントをログアウトにして再度アクセスしてみます。このページのURLは
http://www.flickr.com/photos/komatak/3222442128/
です。
するとこちらはFlickrのログインページに案内されました。
GET /photos/komatak/3222442128/ HTTP/1.1 Host: www.flickr.com HTTP/1.x 302 Found Location: /signin/?acf=%2Fphotos%2Fkomatak%2F3222442128%2F
ログアウトしたままで画像リソースURLを取得してみます。プライベートな写真なのにはてなフォトライフ同様の結果となり残念です。。
DropBoxはすばらしい
一方でDropBoxでは画像リソースへのWebアクセスに対してのアクセスコントロールができています。
ローカル同期型として有名なDropBoxですが、個人がアップしたリソースはHTTPS経由でも取得可能です。
このように未ログイン前の状態で、プライベートな写真リソースのURLにアクセスしてみます。
https://dl-web.getdropbox.com/get/Photos/xxxxxx.jpg (xxxはナイショです)
GET /get/Photos/xxxxxx.jpg HTTP/1.1 Host: dl-web.getdropbox.com HTTP/1.x 403 FORBIDDEN
何が問題か
とはいえ実際には、これまでのURLを他人が知る機会自体はほとんどないです。普通の人がこれらのURLを知る手段といえば、一度プライベートな画像「ページ」にアクセスして、そこにリンクされている画像「リソース」のURLを知るくらいしかない訳で。なのでまあいいんじゃないの？という風に思っていた時期が私にもありました。
でも、Eye-fiを利用し始めて半自動的に画像UPをするようになると、自分が意識的に許可するまではリソースは公開されて欲しくないという気持ちは強くなりました。
あ、変な写真をWebにUPしてる訳ではないですよｗピンボケ写真とかもUPされるのでそれは公開したくないじゃないですか、とかそんなレベルですよって。言い訳がましいところが怪しいとか；）
システム観点でいくと、Webアプリケーションフレームワークベースの認証が、世の中のWebサイトには多いのだと思っています。たいていのフレームワークはWebアプリの「アクション」に対するフィルターをかけることによりユーザの認証を行っているのだと思っていて、これってこれまでの話のところでの画像「ページ」の表示が「アクション」にあたるところですよね。はてなとかのWebアプリが実際にどういう認証方式を採用しているか、詳しくは知りませんが。。
でも、これからRestFulな世界になるにつれて、またOpen Stackな世の中になって「リソース」の流通が当たり前になってくると、リソース単位のアクセスコントロールが必要だと思うのです。という風なことをSocailWeb勉強会に参加させて頂いた際に感じました。
とはいえWebアプリケーションの前段、つまりHTTPサーバによる認証では（Basic,Digest方式）主にUIの観点や、明示的ログアウトがしづらいなど、別の問題も多いのはわかってます。じゃあこれらの問題を解決するにはどうしたらいいか？という観点でもOpenうんちゃらな話には興味があるわけです。
今後ともよろしくお願いいたします。
