W3C Workshop for Permissions and User Consentに行ってきた (2) 本編

本編です。思ったよりめちゃめちゃ長くなってしまった。2000文字くらいであることが多いのに11000文字とか出てるんですが???

背景

本ワークショップに至る特に重要な背景として、Cambridge Analytica事件とGDPRの施行という2つのできごとがある。これらのできごとによって、Webにおける情報共有とそれへの同意・許諾のあり方への企業やユーザーの見方が大きく変わり、今までのあり方を見直さざるを得なくなった、ということが本ワークショップにつながっていると考えられる。

Cambridge Analytica事件

2018年3月に表面化した、選挙活動へのコンサルティングなどを行うCambridge Analytica社がFacebookユーザーの個人情報を同意なく政治利用していた、という事件。

もともとGlobal Science Research社がthisisyourdigitallifeというappで学術目的かつ同意のあった人のみを対象かつ協力者に謝礼を支払うという形で性格診断テストを行い、その際に該当ユーザーのFacebookプロフィールを取得していたが、このとき本来同意していないはずであるFacebook上の友達の情報まで取得していた。本来広告利用のためのFacebookフレンドの情報の取得はplatform policyで禁止されているが、これに違反した形での取得となった。結果として、(報道によってばらつきがあるが)5000万〜8000万ユーザーぶんのpublic profile、ページへのいいね、誕生日、現住所の都市、appに許可を与えた場合はニュースフィード、タイムライン、メッセージを含むデータセットが作られ、これによって作られた個人の心理学的プロファイルが政治的キャンペーンの広告のために使われたとされている。

一連の事件に関する報道としてはThe Guardianの特集記事が詳しい。

General Data Protection Regulation(GDPR)

日本語ではEU一般データ保護規則とも。2016年4月に採択、移行期間を経て2018年5月25より施行。EU(厳密にはEEA: European Economic Area)住民のデータに関する権利を定め、それらの権利に基づくデータの利用を義務付ける規則。EU内にユーザーがいればEU外の企業でも対象となり、違反すると厳しい処罰の対象となる、ということで全世界的に対応を迫られ、日本国内でもGDPR対策セミナーのようなものが多く開かれるようになった*1

主な内容として、データの収集および利用目的について有効な同意が明示的に得られていなければデータの利用をしてはならないことの取り決め、特定の場合でのデータ保護最高責任者の設置と連絡先通知の義務付け、消去権の定義(忘れられる権利の再定義)、データ可搬性の権利*2の定義、設計段階でのprivacy by designの要求、などがある。

米系IT企業がこれまでデータ利用の前提としていた「法に触れさえしなければ明示的同意がなくても使ってよい、使ってほしくなければopt-outで」という原則に真っ向から対抗するもので、グローバル企業は必然的にこれへの対応を迫られる、ということで、データ利活用のあり方を必然的に見直さざるを得なくなった。

主要なテーマ、繰り返し現れたテーマ

そもそもpermissionの必要な機能はWeb platformに必要か?

W3Cの会合という性質上Webプラットフォームそのものに関わっている企業からの参加が多く見られ、「許諾におけるプラットフォームの役割とは」というテーマでパネルディスカッションが開かれたほどに、許諾とWebプラットフォームの機能の範囲は関連が深く、Webプラットフォームが機能を増せば増すほどユーザーはその許諾を求められるようになる(なってしまう)、というテーマが繰り返された。

JavaScript以前のWebは単純に要求されたページをrenderするだけであり、ユーザーはその操作に対して一切危険が及ぶということを想定しないで済んでいた。しかし、JavaScript以後のWebでは、「この部屋に入ったからにはあなたは全身にスプレーをかけられることに同意したんだね?」と言わんばかりに、ページへのアクセスによって危険が及ぶ可能性が高まった。本来ユーザーはWebページへのアクセスでJavaScriptに危害を及ぼされるなど想定してはいないハズだがどうしてこうなってしまったのか?本来「カジュアル」であるハズのWebに強力な力を与えてしまったのがいけないのではないのか?という意見が参加者から出された。「installed app」の世界観ではインストールという「セレモニー」を行うことでアプリの実行内容について合意する(合意しなければ購入しないしインストールしなくてよい)のでアプリが強力な権限を持っていても問題になることは少ないが、カジュアルにアクセスしただけで強力な権限を振るわれることが問題ならばWebプラットフォームには最低限の権限・能力だけ与えればいいのでは?という主張だ。これはWeb技術でできることの範囲を広げようとする世界観とは相容れないものであるが、Progressive Web Applicationでしか使えない強力な機能を実現する、というのはともすればインストールしなくてはいけないアプリにのみ強力な機能を許可する、ということと近いことを言っているのかもしれない。一方でinstalled webとcasual webをフォークすることはinstalled appの世界が抱えているアプリマーケットプレイス管理者による囲い込み(walled garden)をWebにもたらしてしまうという、プライバシーをとった結果別の自由を失うというジレンマを導入してしまう可能性があることも指摘された。

なんでもかんでも許可を求めればいいわけではない

プライバシー保護を厳密に実現するだけであれば全ての項目について事細かに許可を求めればよいのだが、そうしてしまうことでユーザー体験を損なってしまうだけでなく、ユーザーはかえって正常な判断をできなくなってしまう可能性がある(→decision fatigue, analysis paralysis)。

そもそも許可の内容が伝わらない恐れ

主にVR/AR/XRの機能への許諾のセッションで出てきた話として、「6自由度のセンサーへのアクセスを許可します」と許可を求められたところで、それがどのような機能を有効にし、どのような脅威をもたらす可能性があるか、ユーザーに適切に伝わるだろうか?もっと広義にVR/ARを有効にします、といって、それの内在しているセンサーによるとフラッキング・fingerprintingの脅威についてユーザーにcommunicateするのは非常に困難である。

ブラウザが認識する共通の許諾に関する語彙を定め、それらに対する国際化やより簡便な説明の提供をプラットフォームでやりやすくする、ということも考えられるが、新しい機能がプラットフォームに導入されるたびにその語彙のメンテナンスをするのは容易なことではない。

許諾の問題は誰の問題?

プラットフォームが解決すべき問題なのか、Webサイトが解決すべき問題なのか。

許諾っていうけど、データの許諾なの?機能への許諾なの?

この問題はワークショップに行くにあたっても明らかになっておいてほしかった部分ではあった。「データ共有」のための許諾のあり方をどうするべきかというテーマを期待していた部分があったが、どちらかというと「ブラウザにおける」「機能に対する許諾」をどのように扱うべきかが主眼であり、データに対する利用許諾についてはそこまで扱われなかった。

それもある意味そうで、プライバシーを強く気にする人にとっては、データが相手に渡ってしまったらおしまい、という世界観で生きているので、これこれこういう理由でデータ利活用のためにデータの許諾をください、なんていうのが嘘っぱちである、と見てても不思議ではない(現に、悪意のあるデータ利用者からすれば「consent is a lie」という発言すら出ている)。

各セッションまとめ

生ログURL

Introduction/Context

導入。参加者がどんな関心事をもって来ているかや問題意識の共有のためのセッション。

Accountability

許諾におけるAccountability(→説明責任)を考える。Accountabilityは「行為は説明される必要がある」「説明に反する行いは処罰される必要がある」という二つの意味を内在し、Condition(事前条件)、Accounting(説明;スライドでは行われていることの説明がどのようになされるか、に相当)、Redress(救済・矯正;スライドでは間違った行為がなされたときにどのようにしてそれを止めるか、に相当)の3つの要素からなる、とする。スライドは、今までのWebがいかにしてAccountabilityを実現してきたか、例をもって示している。

JavaScriptはよいaccountingを行っていない。行うこと・行っていることに対する十分な説明はなされていないし、なんなら間違った行為が行われた場合に止める手段がほとんどない。このような状況のもと、JavaScriptの実行に許諾を与えたとはいかなる状況か?Webサイトへのアクセスを以って与えた、として十分なのか?GDPRにおいてはimplicitな許諾では不十分としているがこれはどうなのか?

位置情報への許諾はWebで初めてsensitiveな情報の利用への許諾を求めたものであり、初めてdoorhanger prompt(ポップアップで出てくる許諾プロンプトのこと。一般語ではないらしい)を使ったもの。位置情報の許諾へのredressはWebの許諾におけるredressの極端なケースを提示していて、一度間違った方法で位置情報が使われてしまったとしても「一度送られたデータは取り返すことができない」のでredressとして不十分になってしまっている。

議論

  • WebサイトがAccountabilityの問題を背負うべきなのか?これはユーザーに許諾に対する責任を求めるよりも多くのことを求めてしまっているのではないか?
  • 「悪い行いをする人をトラックしておけばよいのでは?」→「0dayみたいにして悪さをする人を止めることはできない。"break things fast and patch"はいいアプローチではない」
  • 出された事例として、CSSのvisited属性を利用してユーザーを識別する攻撃の例がある。
    • ここに限らず、capabilityに対する許諾をどうするかという問題には、悪意のある広告主によるfingerprinting(個人識別)対策をどのようにするか、という問題が共通した背景としてある。
    • HSTSですらやろうと思えばfingerprintingに悪用することができる!
  • サイトの利用頻度(engagement)ベースで機能を許可するようにすれば暗黙のうちに機能を許可できるようになるのでは?→これは危険なパターンである可能性が高い

Duration and Timing

一般に許可を与えるタイミングはどのようにするべきか、許可を与えたら与えっぱなしではなく有効期間を設けるべきか、という議論。

プッシュ通知の許諾は許諾の判断をするタイミングと実際に許諾したアクションが起こるタイミングが離れている。これでユーザーは適切な判断ができるのか?

「許可の有効期限はその許可を与えた行為が及ぼしうるダメージの大きさに反比例するように(→大きなリスクのある行為ほど頻繁に聞く)するのはどうか?」

参考: 現在のWebのcapabilityの一覧とそれがどのようなガード機構を持っているかの表

Permissions in New Contexts

またの名をVR/AR/XR(以降XRとまとめる)での許諾どうするよ問題。

WebにおけるXRはImmersive Web Working Groupで作業が進行中。WebXR Device APIというのが定義される予定。

XRにおけるfingerprintingの脅威として、特定のセンサーの機能を持っているかどうかの組み合わせを得ることでfingerprintingができてしまう可能性が指摘されている。また、XRで取得できる現実世界のジオメトリデータはかなりsensitiveなものであるがこれは現在法律で守られている個人情報には含まれていない*3。XRの利用と一括りに許諾しても個人情報漏洩へのリスクは伝わりにくい。

カメラ利用の許諾について。カメラを利用せずにXR機能を提供できるデバイスがある一方、カメラをpolyfillとして使うデバイスがあるため、抽象的な機能の許諾としてしまうとユーザーはカメラが使われているかどうか知ることが難しい。またその逆の問題もあって、実はカメラを使う必要がなく使っていないのにアプリがカメラを使っているかのような感覚を与えてしまうとユーザーは許可を下しにくい、という問題もある。

どのタイミングで許可を与えるか?どのように与えるか?必要なタイミングで与える、というようにしてもいいが、VR空間で突然ポップアップが出てくるのはいかがなものか?VR空間でモーダルなポップアップが出てきて選択するまで脱出できない、というユーザー体験はかえってユーザーの判断を阻害するのでは?

Permission Bundling

たくさんの許諾を、例えば「私はテレビ電話です、テレビ電話的な機能を許可してくれるかい?」とまとめる話。

「そんなことしたら、App Storeに大量のテレビ電話が出てきそうだね!」

標準的な語彙の定義につながる話だが、標準的な語彙のメンテナンスは大量の新規の語彙の導入につながって大変。

Research Presentations on Permissions and Context

許諾についての研究成果の発表。

  • カスタムAndroid buildにおけるカスタマイズされた許諾モデルのユーザー試験の話。通常のAndroidと比べて、Webブラウザやアプリが特定の機能への許諾を出すタイミング等に変更を加えて、ユーザーがどれだけの頻度で許可したかを取得できるようにしているもの。特に、ユーザーへ許諾を求めるタイミングを、ユーザーがプロンプトを期待するタイミングにすることを目的とし、ask on install/ask on first useではなく特定の文脈で機能が要求されたときに限るように変更した。
  • Alexa Top 50のサイトでどのようなpermissionを要求しているか、それが現実的なpermissionか、その説明が適切になされているかについて調査し、ベストプラクティスのガイドラインの制定を目指した研究の話。許諾を要求しているサイトのプライバシーポリシーを確認し、その語彙や表現が他のサイトと比べて共通しているかどうか、それらの示しているものは共通しているかどうか、どのくらいプライバシーポリシーを深読みしないとそれにたどり着かないか、などを調べたもの。
  • アメリカにおけるプライバシー保護法制やこれまでの技術的なプライバシー実現方法のまとめ。PICS, P3P, DNTとそれらと同時に進んでいた法整備の関係、California AB 375(California Consumer Privacy Act)について、など。

Role of Platforms

Apple, Brave, Google Chrome, Mozillaの代表者によるパネルディスカッション。

Immersive Webの観点(ここでのMozillaの代表者はImmersive Webに関わっているとのこと)からは許諾プロンプトが体験の妨害をする状況は避けたい。なので過度に標準化するのではなくほどよいユーザー体験を探る路線にしていきたい。

ブラウザがパーミッションについて責任を負うのならば、ブラウザがローカル環境のサービスのdiscoveryの責任を負う必要があるので、ハードウェアベンダーにどのようにすれば発見してもらえるかのガイドラインを提示してほしい。このようなブラウザベンダーとサードパーティの間のコミュニケーションはどうするのか?"Intent to Implement"がそのへんをカバーしているといえばしているが…

ブラウザへの信頼というのはブラウザ間で「ブラウザとは何をするものか」というベースラインを持つことに由来している。ブラウザ間で共通した体験を与えるためにも、許諾のUIは標準化して縛るのではなくガイドラインで定義するべき。代わりにサイトがブラウザとやり取りをするインターフェースは適切に標準化しておきたい。

パスワードマネージャーはデータ流出を知るための非常にいいツール。しかしブラウザのパスワードマネージャーは専門のツールに比べると少々遅れている…

Changes in the Environment in 6 Years

breakout session。6年間というのはDo Not Trackが始まってから6年間ということ。同じ議論を繰り返しているけれど、どのような環境の変化があったか?

  • "hey, there's IoT now"
  • ジャーナリズムにおけるプライバシー報道が増えた。
  • 広告収入が減った。新しい収入モデルが出てきている。
  • ad blockingが増えた。
    • DNTは本来ad blockingしないで済むようにするためのものだったハズ
  • "just trust me"で済んでいた牧歌的な時代は終わった
    • Equifax事件, Cambridge Analytica事件
    • スタックのあらゆるところにNSAバックドアが入っている
    • 「暗号化を使っているって?それはなんか悪いことをしようとしているんじゃないの?」
  • ターゲティング広告が社会不安を煽動している
  • 「もしかしたら西洋民主主義の運命はこの部屋の動向如何で決まるかもしれない」
  • アドテクはハックの上にハックを積み重ねて成立している
  • 「なんで今までみたいな広告じゃダメなの?」→広告事業者はインプレッションを計測する方法を持っている必要がある。最初はサーバーサイドでのcountingで十分だったが、unique impressionを数えるためにトラッキング広告が必要になった
  • TVではopt-inで視聴率調査を報酬を支払ってやっているが、これと同じモデルをWebでやるのではダメなの?本質的にトラッキングとか不要なのでは?→トラッキングのほうが広告事業者にとって都合がよく、もうすでにトラッキングのための方法論ができてしまっているのでそれを言っても仕方がない…
  • 広告利用のためのIDを追加すればトラッキング・クッキーとか不要なのでは?→もっと強力な悪用が可能でして…

Contexts and IoT

breakout session。許諾を聞くにあたっての文脈の話、それとAutomotiveとIoTとの関連。

モバイルAppの世界ではユーザーにYesと無理やり言わせるための慣行が横行している。どのようにしたらユーザーをexploitしない文脈に沿った許諾を聞くことができるか?

許諾を聞く際に質問が文脈と離れて聞かれるのがよくない。文脈とはタイミングも含む。通知だと実際のアクションまで時間が離れているので何の許諾を求められているかわからない。位置情報は例えばページ上に地図が表示されていたら「地図のために使うんだな」ということをユーザーが理解しやすい。ユーザーが許諾を与えるデータについてのメンタルモデルが形成しやすいようにアプリを設計するべき。

また、一度許可を与えてしまうと今のモデルでは与えっぱなしなのがマズい。許諾をタイムアウトさせるような仕組みも必要では?

車の世界ではWebとは違って「法的なIDを持っていないと運転できない」、よって車におけるデータの許諾はWebよりも慎重に行う必要がある。traditional Webに近いのはどちらかというと車内エンターテイメントシステムか。

IoT分野では室内に設置したデバイスについて同じ室内にいるユーザーすべてに許諾を求めないといけないのか、といった"bystander problem"が必然的についてまわる。また、UIを持っていないセンサーやデバイスについてどのように許諾を求めたらいいのか?という問題がある。

Vocabulary

breakout session。SPECIAL projectという、リンクドデータを用いてプライバシー情報利用の透明性を実現しようとする計画の紹介。これを用いてプライバシーポリシーを記述すればGDPRに準拠しているかどうかの判定を機械的にできるようになる、ということを目指している。W3C Workshop on Privacy and Linked Dataというワークショップが開かれ、語彙の標準化を行うためのCommunity Groupが作られた。

Scary Permissions

breakout session。Progressive Web Applicationsに関連して、ファイルシステムアクセスなどの強力な(で「恐ろしい」)権限についてどのように考えるか。

これらの機能への許諾はユーザーに説明しきれないかもしれない。マイクやカメラはわかりやすい、クリップボードのアクセスを求めることがどれだけの脅威かを説明するのはなかなか難しい、ファイルシステムはその間くらい、加速度センサーへの許諾はどうやって説明するか?

現状フォントの一覧へのアクセスは各サイトのengagement scoreをベースに行われている。しかしこれはこれでよいのか?サイトにたくさん行くからといって許可を与えたとは言っていないのでは?例としてはFacebookはよく使うけどFacebookはCambridge Analyticaでやらかしたし…。

「このサイトを信頼します」チェックがあればいいのでは?プライバシーに配慮するチェックをいろいろ入れてかえって悪用する余地を生んでしまうくらいだったらシンプルにこれくらいにしてしまったほうがわかりやすいのでは?

Geolocationや通知APIの存在自体がユーザーがWebへの信頼を損なう結果になってしまった原因かもしれない。「Webがこれやるべきなの?」みたいな議論をする場が必要。

Webがscary capabilityを必要としている理由には「WebがAndroid化している」、Webにwalled gardenができるようになってきているから、というのがあるが、一方でWebにcapabilityを追加するのを急ぐことは「村を守るために村を焼く」ことにほかならないのでは?

Dangers in OAuth Innovation

breakout session。OAuthはデータ可搬性の向上に大きく貢献したが、一方で課題も多く、その課題をどう解決するべきか。

アメリカでは医療データを民間が利用するためにOAuthベースでデータを利活用するためのプラットフォームを作ろうという動きがあった…がCambridge Analytica事件で潮流が変わってしまった。CA事件で問題となったappもOAuthで許諾を得るもの。data breachであると報道されたが、IDコミュニティは「data breachではなく明示的に許諾とったでしょ!」という立場だった。

ユーザーは何を期待していたのか、ユーザーに対して何がcommunicateされるべきだったのか?

ユーザーが許諾の内容を理解しない、というのは頻出のテーマだが、その中でもOAuthは難しく、OAuthはService Providerに「ユーザーに成り代わる手段を与える」ものなので許諾内容を正確に伝えることがひときわ難しい。

現在のOAuthはいきなりscopeの羅列を求めてくるが、そのscopeがそれぞれどのように使われるか、という人間可読な情報を伝えるフィールドがない。SPはoptionalなscopeを求めることも仕様上できるが、それがrejectされたとしてSPが更に少ないscopeで再度IdPに問い合わせをするような実装になっていることは少なく、結局SPはall-or-nothingでscopeへの利用許諾を求めてしまっている。

ログアウトの問題もある。OAuthはSingle Sign-Onを実現するがSingle Sign-Outを実現しない。アメリカの人口の半分がデバイスを共有している(そしてその事実は「比較的高所得であるアプリを実装しているエンジニア」からは観測しにくい!)という調査結果があるなかで、連携アプリからログアウトしたのか連携元アプリからログアウトしたのかわかりにくいのはマズいのでは?

*1:実際これのまとめ書くために調べたときも広告記事ばっかり出た

*2:可搬性実現のためにopen standardな形式で保管されている自身の個人データを事業者に要求できる権利だって!?

*3:少なくともこの時点でのUSの法律ではそうらしい