Privacy
序章
インターネットでは、あなたが犬であることを誰も知らない 確かに、そのようにインターネットを使うため匿名にすることはできるかもしれませんが、個人情報を完全に非公開にすることはかなり難しいでしょう。
業界全体は、ターゲット広告、詐欺検出、価格差別化、あるいは信用スコアリングなどの目的で詳細なユーザープロファイルを構築するために、オンラインでユーザーを追跡することに専念しています。ウェブサイトと地理位置情報を共有することは、日常生活において非常に便利ですが、企業があなたのすべての行動を見ることができるようになる可能性もあります。たとえサービスがユーザーの個人情報を真摯に扱っていたとしても、個人情報を保存するという行為だけで、ハッカーはサービスに侵入し、数百万の個人記録をオンラインで流出させる機会を与えてしまうのです。
欧州ではGDPRなど、最近の立法化の動きもあります。カリフォルニア州のCCPA、ブラジルのLGPDや、インドのPDP Billは、いずれも企業に個人データの保護を求め、オンラインも含めてデフォルトでプライバシーを実装しようとするものです。Google、Facebook、Amazonなどの大手テクノロジー企業は、ユーザーのプライバシー侵害の疑いで、すでに巨額の罰金を受け取っています。
この新しい法律により、ユーザーは個人情報を共有することにどれだけ抵抗がないか、より大きな発言権を持つようになりました。おそらく、すでに多くのクッキー同意バナーをクリックし、この選択を可能にしていることでしょう。さらにウェブブラウザは、機密データを隠してサードパーティのクッキーをブロックすることから、個人の属性に関する正当なユースケースと個々のユーザーのプライバシーのバランスをとる革新的な方法まで、ユーザーのプライバシーを改善する技術的解決策 を実装しています。
この章では、ウェブにおけるプライバシーの現状を概観する。まず、ユーザーのプライバシーがどのように害されうるかを考える。ここでは、ウェブサイトがどのようにオンライントラッキングによってあなたをプロファイリングし、どのようにあなたの機密データにアクセスしているかについて議論します。次に、ウェブサイトが機密データを保護する方法と、プライバシー設定シグナルによってユーザーに選択肢を与える方法について掘り下げます。最後に、今後のブラウザによるプライバシー保護への取り組みについての展望を掲載します。
ウェブサイトがあなたをプロファイリングする方法：オンライントラッキング
HTTPプロトコルは本質的にステートレスなので、デフォルトでは2つの異なるウェブサイトへの訪問、あるいは同じウェブサイトへの2つの訪問が、同じユーザーによるものかどうかをウェブサイトが知る方法はありません。しかし、このような情報はウェブサイトがよりパーソナライズされたユーザー体験を構築するために、また第三者がウェブサイト間でユーザー行動のプロファイルを構築しターゲット広告を通じてウェブ上のコンテンツに資金を提供したり、不正行為の検出などのサービスを提供するために有用であると思われます。
残念ながら、この情報を得るには、現状ではオンライントラッキングに頼ることが多く、それを中心に多くの大小の企業がビジネスを展開している。これにより、侵襲的な追跡はユーザーのプライバシーと矛盾するため、ターゲット広告の禁止を求める声にもつながっているのです。とくにデリケートな話題のウェブサイトを閲覧する場合、ユーザーは自分の足取りを誰にも知られたくないかもしれません。ここでは、オンライントラッキングのエコシステムを構成する主な企業や技術について見ていきます。
サードパーティトラッキング
オンライントラッキングは、多くの場合、サードパーティのライブラリを通じて行われます。これらのライブラリは通常、何らかの（有用な）サービスを提供しますが、その過程で各ユーザーに固有の識別子を生成、それを使ってウェブサイト全体でユーザーを追跡し、プロファイルすることができるものもあります。WhoTracksMe プロジェクトは、もっとも広く展開されているオンライントラッカーを発見することに専念しています。私たちはWhoTracksMeのトラッカーの分類を使用していますが、トラッキングが主目的の一部であるサービスをカバーする可能性がもっとも高いため、カテゴリの4つに限定しています。広告、ポルノグラフィティ、サイト分析およびソーシャル・メディアです。
オンライントラッキング市場では、Googleの所有するドメインが広く普及していることがわかります。ウェブサイトのトラフィックを報告するGoogle Analyticsは、全ウェブサイトのほぼ3分の2に存在しています。約30%のサイトがFacebookライブラリを含んでおり、他のトラッカーは一桁のパーセンテージにしか達しません。
サイト分析は73.53%と70.46%、広告は68.83%と67.99%、ソーシャル・メディアは12.89%、11.66%、ポルノ広告 0.56%、0.60%でそれぞれ使用されていることがわかります。全体では、モバイルサイトの82.08%、デスクトップサイトの83.33%が少なくとも1つのトラッカーを含んでおり、通常はサイト分析または広告目的のために利用されています。
4つのウェブサイトのうち3つはトラッカーが10個以下ですが、それ以上のトラッカーを持つサイトもあり、あるデスクトップ・サイトでは133個（！）の異なるトラッカーに接続しています。
サードパーティークッキー
クロスサイトのユーザー識別子を保存および取得するための主な技術的アプローチは、ブラウザに永続的に保存されるクッキーを通じて行われます。サードパーティのクッキーは、クロスサイトトラッキングによく使われますが、サイト間でサードパーティのウィジェットの状態を共有するような、トラッキング以外のユースケースにも使われることがあることに注意してください。私たちは、ウェブを閲覧しているときにもっとも頻繁に表示されるクッキーと、それを設定するドメインを検索しました。
doubleclick.netはデスクトップページの30.49%、モバイルページの28.72%、facebook.comはそれぞれ23.07%、21.43%、youtube.comでは10.02%と8.83%、google.comは8.62%と8.45%、 yandex.ruは4.42%と5.17%、pubmatic.comは3.82%と4.73%。rlcdn.comが4.01%と3.99%、openx.netが3.57%と4.42%、adsrvr.orgが4.00%と3.90%、そして最後にyahoo.comが3.80%と3.70% といったところです。グーグルの子会社であるDoubleClickは、デスクトップサイトの31.4％、モバイルサイトの28.7％にクッキーを設定し、首位に立っています。もう1つの主要なプレーヤーはFacebookで、モバイルウェブサイトの21.4%にクッキーを保存しています。クッキーを設定する他の上位ドメインのほとんどは、オンライン広告に関連しています。
test_cookieはデスクトップサイトの30.20%、モバイルサイトの28.66%、facebook.comのfrはそれぞれ23.04%、20.96%、 doubleclick.netのIDEは18.03%、16.96%、 google.comのNIDは4.92%、5.09%、yandex.ruのyandexuidが4.38%、5.14%、yandex.ruのyuidssが4.38%、5.14%、yandex.ruのiが4.34%、5.09%、yandex.ruの ymex が4.32%と5.08%、yandex.ruの yabs-sid が4.32%と5.08%、adsrvr.orgの TDIDが3.71%と3.89% であることを示しています。これらのウェブサイトが設定する特定のクッキーを見てみると、トラッカーからのもっとも一般的なクッキーは、doubleclick.netのtest_cookieです。次に多いのは広告関連のクッキーで、ユーザーの端末にずっと長く残ります。Facebookのfrクッキーは90日間、DoubleClickのIDEクッキーはヨーロッパでは13か月、その他の地域では2年持続する。
Lax が SameSiteクッキー属性 のデフォルト値になったため、ウェブサイト間でサードパーティのクッキーを共有し続けたいサイトは、この属性を明示的に None に設定しなければならなくなりました。サードパーティーの場合、モバイルでは85％、デスクトップでは64％が、トラッキングを目的とする可能性があるとして、これまでに実施しています。SameSiteクッキー属性については、セキュリティーの章で詳しく説明されています。
指紋認証
広告ブロックなどのプライバシー保護ツールの台頭やFirefox、Safari、そして2023年にはChromeなどの主要ブラウザからサードパーティCookieを段階的に排除する取り組みにより、トラッカーはサイト間でユーザーを追跡する、より持続的で密かな方法を探しています。
その1つがブラウザフィンガープリントです。ウェブサイトは、ユーザーエージェント、画面解像度、インストールされているフォントなど、ユーザーのデバイスに関する情報を収集し、それらの値のユニークな組み合わせを使用してフィンガープリントを作成できます。このフィンガープリントは、ユーザーがウェブサイトを訪れるたびに再作成され、照合することでユーザーを特定することができるのです。この方法は、不正行為の検出に使用できますが、繰り返し利用するユーザーを持続的に追跡したり、サイト間でユーザーを追跡するためにも使用されます。
フィンガープリントの検出は複雑です。メソッドコールとイベントリスナーの組み合わせにより効果を発揮し、追跡以外の目的にも使用されることがあります。そこで、これらの個々のメソッドに焦点を当てる代わりに、ウェブサイトがフィンガープリントを簡単に実装できるようにする5つの人気のあるライブラリに焦点を当てます。
これらのサードパーティ サービスを使用しているWebサイトの割合から、もっとも広く使用されているライブラリである Fingerprint.js は、デスクトップでは2番目に多く使用されているライブラリの19倍も使用されていることがわかります。しかし、ユーザーのフィンガープリントに外部ライブラリを使用しているWebサイトの割合は、全体としては非常に小さいものです。
CNAMEトラッキング
サードパーティトラッキングのブロックを回避するテクニックを続けると、CNAMEトラッキングは、ファーストパーティのサブドメインがDNSレベルでCNAMEレコードを使ってサードパーティサービスの使用をマスクするという新しい方法です。ブラウザから見ると、すべてがファーストパーティの文脈で行われるため、サードパーティの対策は一切適用されない。AdobeやOracleなどの大手トラッキング会社は、すでにCNAMEトラッキングソリューションを顧客に提供しています。 この章に含まれるCNAMEベースのトラッキングの結果については、この章の著者の一人（および他の人）によって完成した 研究 を参照し、DNSデータとHTTP Archiveからのリクエストデータに基づいてCNAMEベースのトラッキングを検出する方法を開発しました。
CNAMEベースのトラッキングを実行しているもっとも人気のある企業はAdobeで、デスクトップWebサイトの0.59％、モバイルWebサイトの0.41％に存在しています。また、規模ではPardotが0.41%、0.26%と顕著です。
この数字は小さな割合に見えるかもしれませんが、サイトの人気度でデータを分離すると、その意見は変わります。
CNAMEベースのトラッキングを使用しているウェブサイトのランクを見ると、モバイルの上位1,000ウェブサイトのうち5.53%がCNAMEトラッカーを埋め込んでいることがわかります。上位100,000サイトでは、その数は2.78%に減少し、データセット全体を見ると0.52%に減少しています。
comのデスクトップWebサイトの0.64%、モバイルWebサイトの0.42%がCNAMEトラッキングを使用しており、eduではそれぞれ0.18%と0.10%、jpでは0.03%と0.04%、orgでは0.04%、0.03%、 co.jp は0.03%、0.02%、 ca では0.02%、0.01%、 de では0.02%、0.02%、 ru では0.01%、0.01%、 com.au では0.02%、0.01%、最後に edu.au は0.02%、0.01% となりました。.com サフィックスとは別に、CNAMEベースのトラッキングを使用しているウェブサイトの多くは .edu ドメインを持っています。また、CNAMEトラッカーは .jp と .org ウェブサイトに多く存在します。
CNAMEベースのトラッキングは、ユーザーがサードパーティーのトラッキングに対するトラッキング保護を有効にしている可能性がある場合の対策になります。トラッカーブロックツールやブラウザは、すでにCNAMEトラッキングに対する防御機能を備えているものが少ないため、現在までに多くのウェブサイトで蔓延しているのが現状です。
（再）ターゲティング
広告再ターゲティングとは、ユーザーが見たが購入していない商品を記録し、その商品に関する広告を別のWebサイトでフォローアップすることを指します。ユーザーが訪問している間、積極的なマーケティング戦略を選ぶのではなく、ウェブサイトは継続的にブランドと製品を思い出させることで、ユーザーが製品を購入するように誘導することを選択します。
多くのトラッカーが広告再ターゲティングのためのソリューションを提供しています。もっとも広く利用されているGoogle Remarketing Tagは、デスクトップのウェブサイトの26.92%、モバイルのウェブサイトの26.64%で利用されており、それぞれ1.25%未満で利用されている他のサービスよりはるかに優れています。
ウェブサイトにおけるお客様の個人情報の取り扱いについて
ウェブサイトによっては、ジオロケーションデータ、マイク、カメラなどにアクセスすることで、ユーザーのプライバシーに影響を与える可能性のある特定の機能およびブラウザAPIへのアクセスを要求するものがあります。これらの機能は通常、近くの観光スポットを発見したり、人々が互いに通信できるようにするなど、非常に有用な目的を果たします。これらの機能はユーザーが同意した場合にのみ有効になりますが、ユーザーがこれらのリソースの使用方法を十分に理解していない場合や、サイトが誤動作した場合、機密データが、公開されるリスクがあります。
Webサイトが機密性の高いリソースへのアクセスを要求する頻度を調べました。さらに、サービスが機密データを保存する場合は常に、ハッカーがそのデータを盗み出し、漏えいさせる危険性があるのです。ここでは、この危険性が実際に存在することを証明する、最近のデータ漏洩事件について見ていきます。
デバイスセンサー
センサーは、ウェブサイトをよりインタラクティブへするのに便利ですが、指紋認証のために悪用される可能性もあります。JavaScriptのイベントリスナーの使用状況から、モバイル、デスクトップクライアントで、デバイスの向きがもっともアクセスされていることがわかります。なお、Webサイト上でイベントリスナーの存在を検索したが、実際にコードが実行されたかどうかはわからない。したがって、本節のデバイスセンサーイベントへのアクセスは、上限値です。
deviceOrientation はデスクトップサイトの3.32% とモバイルサイトの3.23%、deviceReady は1.12%と1.23%、devicemotionは0.65%と0.66%、deviceChangeは0.03%と0.02%、最後に deviceproximity は0.03%と0.02% で確認されました。メディアデバイス
MediaDevices APIを使用すると、カメラやマイク、画面共有などの接続されたメディア入力にアクセスできます。
MediaDevicesEnumerateDevices APIを使用したデスクトップページの割合。
デスクトップのウェブサイトの7.23%、モバイルのウェブサイトの5.33%で enumerateDevices() メソッドが呼び出され、接続されている入力デバイスのリストが提供されます。
ジオロケーションサービス
ジオロケーションサービスは、GPSやユーザーのその他の位置情報（IPアドレスなど）を提供し、トラッカーはとくにユーザーにより関連性の高いコンテンツを提供するために利用できます。そこで、Wappalyzerで検出したライブラリをもとに、Webサイトにおける「ジオロケーションサービス」技術の利用を分析します。
もっとも人気のあるサービスであるipifyは、デスクトップWebサイトの0.09%とモバイルWebサイトの0.07% で使用されていることがわかります。つまり、ジオロケーションサービスを利用しているウェブサイトは少ないようです。
GeolocationGetCurrentPosition はデスクトップサイトの0.59%とモバイルサイトの0.63% で、GeolocationSecureOrigin はそれぞれ0.59%と0.62% で、GeolocationInsecureOriginは0.01%と0.02%, GeolocationWatchPositionが0.02%と0.02%, GeolocationSecureOriginIframeが0.02%と0.02%, GeolocationDisabledByFeaturePolicyが0.02%と0.01% そして最後に GeolocationInsecureOriginIframeは0.00%と0.01%となりました。また、WebサイトからはWebブラウザAPIを介して、ジオロケーションデータにアクセスすることが可能です。デスクトップクライアントで0.59%、モバイルクライアントでは0.63%のWebサイトがユーザーの現在位置にアクセスしていることがわかります（ブリンク機能に基づいています）。
情報漏えい
企業におけるセキュリティ管理の不備は、お客様の個人情報にも大きな影響を及ぼします。Have I Been Pwned は、ユーザーが自分のメールアドレスや電話番号がデータ漏洩で流出したかどうかを確認することができるサービスです。この記事を書いている時点で、Have I Been Pwnedは562件の情報漏えいを追跡し、6億4000万件の記録が漏れていることが判明しています。2020年だけでも40のサービスが侵入され、数百万人のユーザーの個人情報が流出した。このうち3件はセンシティブとされ、誰かがそのユーザーのデータを見つけた場合、ユーザーに悪影響が、及ぶ可能性があることを指しています。機密漏洩の一例として、盗まれたクレジットカードが、取引されるプラットフォーム「Carding Mafia」が挙げられます。
なお、前年度の40件の違反は、多くの違反が発生してから数カ月後に発見、または公表されるため、下限値であることに注意してください。
Have I Been Pwned が追跡したすべてのデータ侵害では、電子メールアドレスが漏れています。これは、ユーザーが自分のデータが侵害されたかどうかを問い合わせる方法だからです。電子メールアドレスの設定には、多くのユーザーがフルネームや認証情報を採用しているため、電子メールアドレスの流出は、すでに大きなプライバシーリスクとなっています。さらに、ユーザーの性別、銀行口座番号、完全な物理的住所など、他の多くの非常に機密性の高い情報が流出するケースもあります。
ウェブサイトが機密情報を保護する方法
ウェブサイトを閲覧していると、閲覧したページ、フォームに入力した機密データ、位置情報など、非公開にしたいデータがあります。セキュリティの章では、91.1%のモバイルサイトがHTTPSを有効にし、インターネットを通過するデータを盗聴から保護していることをご紹介しています。ここでは、機密性の高いリソースのプライバシーを確保するために、ウェブサイトがブラウザにどのように指示できるかに焦点を当てます。
パーミッションポリシー／フィーチャーポリシー
パーミッションポリシー（以前はフィーチャーポリシーと呼ばれていました）は、ウェブサイトがどのウェブ機能を使用するつもりで、どの機能がユーザーによって明示的に承認される必要があるか（たとえば、第三者から要求されたとき）を定義する方法を提供します。これにより、埋め込まれたサードパーティーのスクリプトがどのような機能へのアクセスを要求できるかを、ウェブサイトがコントロールできるようになります。たとえば、パーミッションポリシーを使用すると、ウェブサイトは、サードパーティーが自分のサイトでマイクアクセスを要求しないようにできます。このポリシーにより、開発者は allow 属性で指定することで、使用する予定のWeb APIを細かく選択できます。
ジオロケーションはデスクトップ2,222サイト、モバイル2,323サイト、マイクでは2,199サイト、カメラでは2,082サイト、2,197サイト、支払いでは1,748サイト、1,879サイト、usbでは1, 354と1,492、ジャイロスコープが1,145と1,025、磁力計が1,141と1,024、インタレストコーホートが1,037と1,019、フルスクリーンが940と873、加速度センサーが892と852です。フィーチャーポリシーに関連して、もっともよく使われるディレクティブは上記の通りです。モバイルでは3,049サイト、デスクトップでは2,901サイトで、マイク機能の利用が指定されています。これはデータセットのごく一部であり、まだニッチな技術であることを示しています。その他によく制限される機能は、ジオロケーション、カメラ、支払い機能です。
ディレクティブの使われ方をより深く理解するために、よく使われるディレクティブの上位3つと、そのディレクティブに割り当てられた値の分布について調べてみました。
マイクロフォンは、モバイルサイトの0.08%でselfに、0.49%でnoneに、0.03%で*に設定されています。geolocation はモバイルサイトの0.17%で self に設定され、0.34%で none に設定され、0.05%で * に設定されています。カメラ はモバイルサイトの0.09%で self に設定され、0.46%で none に、0.03%で * に設定されています。none がもっともよく使われる値です。これは、トップレベルおよびネストされたブラウジングのコンテキストで、その機能が無効であることを指定します。2番目によく使われる値である self は、現在のドキュメントと同じオリジン内でその機能を許可することを指定するために使われます。一方 * は、オリジンをまたいだ完全なアクセスを許可します。
Refererポリシー
HTTPリクエストはオプションで Referer ヘッダーを含むことができます。これはリクエストがどのオリジンまたはWebページのURLから行われたかを示すものです。Referer ヘッダーはさまざまなタイプのリクエストに含まれる可能性があります。
- ユーザーがリンクをクリックしたときのナビゲーション要求。
- サブリソースリクエスト。ブラウザが画像、iframe、スクリプトなど、ページが必要とするリソースを要求すること。
ナビゲーションやiframeの場合、このデータはJavaScriptで document.referrer を使用してアクセスすることもできます。
Referer の値は、洞察力を高めることができます。しかし、パスとクエリ文字列を含む完全なURLが Referer としてオリジン間で送信される場合、プライバシーを侵害する可能性があります。URLには、個人情報、時には個人を特定するような重要な情報が含まれていることがあります。このような情報は、送信元を越えて静かに流出することで、ユーザーのプライバシーを侵害し、セキュリティ上のリスクをもたらします。Referrer-Policy HTTPヘッダーは、開発者が自分のサイトからのリクエストで利用できるリファラーデータを制限して、このリスクを軽減することを可能にします。
まず注目すべき点は、ほとんどのサイトがリファラーポリシーを明示的に設定していないことです。デスクトップ用ウェブサイトの11.12%、モバイル用ウェブサイトの10.38%だけが、明示的にリファラーポリシーを定義しています。残りの部分（デスクトップでは88.88％、モバイルでは89.62％）は、ブラウザのデフォルトポリシーにフォールバックされます。最近ほとんどの主要なブラウザは、2020年8月にChrome 、2021年3月にFirefoxなど、 strict-origin-when-cross-origin というデフォルトポリシーを導入しています。strict-origin-when-cross-origin はクロスオリジンリクエストの際にURLのパスとクエリフラグメントを削除し、セキュリティとプライバシーのリスクを軽減します。
no-referrer-when-downgrade はデスクトップサイトの3.63% とモバイルサイトの3.31% で、 strict-origin-when-cross-origin はそれぞれ1.95%、1.56%。alwaysで1.08%、0.82%。unsafe-urlでは0.47%、0.52%。same-originは0.51%、0.44%。originが0.39%、0.51%。no-referrerは0.34%、0.31%。origin-when-cross-originで0.31%、0.29%。strict-originが0.26%、0.23%。最後に no-referrer, strict-origin-when-cross-origin が0.09% と0.08% になりました。明示的に設定されるもっとも一般的なReferrer Policyは、no-referrer-when-downgradeです。モバイルクライアントのウェブサイトの3.38%、デスクトップクライアントのウェブサイトの3.81%で設定されています。no-referrer-when-downgradeはプライバシーを強化するものではありません。このポリシーでは、ユーザーがあるサイトで訪れたページの完全なURLが、クロスオリジンのHTTPSリクエスト（リクエストの大部分）で共有され、この情報は他の当事者（オリジン）がアクセスできるようになります。
さらに、約0.5%のウェブサイトがリファラーポリシーの値をunsafe-urlに設定しており、受信者のセキュリティレベルに関係なく、あらゆるリクエストでオリジン、ホスト、クエリー文字列が送信されるようになっています。この場合、リファラーが平文で送信され、個人情報を漏えいさせる可能性があります。心配なことに、この動作を可能にするようにサイトが積極的に設定されているのです。
注：ウェブサイトは、リファラー情報をURLのパラメータとして送信先サイトに送ることもあります。このレポートでは、そのような仕組みの使用状況は測定していません。
User-Agent クライアントヒント
ウェブブラウザがHTTPリクエストを行う際、クライアントのブラウザ、デバイス、ネットワーク機能に関する情報を提供するUser-Agentヘッダーが含まれます。しかし、これを悪用してユーザーをプロファイリングしたり、フィンガープリンティングによって一意に特定することが可能です。
User-Agentクライアントヒント は User-Agent 文字列と同じ情報へのアクセスを可能にしますが、よりプライバシーを保護する方法でアクセスします。これにより、Chromeが User Agent削減 の段階的な計画で提案しているように、ブラウザが User-Agent 文字列をデフォルトで提供する情報量を最終的に削減することができるようになります。
サーバーは Accept-CH ヘッダーを指定することで、これらのClient Hintsをサポートすることを示すことができます。このヘッダーは、デバイス固有またはネットワーク固有のリソースを提供するために、サーバーがクライアントに要求する属性をリストアップしています。一般に、Client Hintsはサーバがコンテンツを効率的に提供するために必要な最小限の情報のみを取得する方法を提供します。
しかし、現時点では、クライアントヒントを導入しているWebサイトはほとんどありません。また、人気のあるWebサイトとそうでないWebサイトでは、クライアントヒントの利用状況に大きな差があります。モバイルで人気のある上位1,000のWebサイトのうち、3.67%がClient Hintsをリクエストしています。上位10,000のウェブサイトでは、実装率は1.44%に低下しています。
ウェブサイトがプライバシーを選択できるようにする方法 プライバシー・プリファレンス・シグナル
冒頭で述べたような近年のプライバシー規制の導入に伴い、ウェブサイトは、マーケティングや分析といった本質的でない機能のための個人データの収集について、ユーザーの明確な同意を得ることが求められています。
そのため、ウェブサイトは、クッキーの同意バナーやプライバシーポリシー、その他の仕組み（経時変化）を利用して、これらのサイトが処理するデータについてユーザーに知らせ、選択を与える方向に向かいました。このセクションでは、このようなツールの普及状況について見ていきます。
同意書管理プラットフォーム
同意書管理プラットフォーム（CMP）は、ウェブサイトがユーザーのためにクッキーの同意バナーを提供するために組み込むことができるサードパーティライブラリです。約7%のWebサイトがCMPを利用していることが確認されています。
もっとも人気のあるライブラリは、CookieYes と Osano ですが、ウェブサイトがクッキー同意バナーを掲載できるライブラリは20種以上見つかりました。各ライブラリは、それぞれ2％未満と、わずかな割合でしか存在しない。
IABの同意フレームワーク
透明性と同意のフレームワーク (TCF) は、インタラクティブ広告協会ヨーロッパ（IAB）が主導する、広告主にユーザーの同意を伝えるための業界標準を提供するためのものです。このフレームワークは、ベンダーが処理するデータの正当な目的を指定できるグローバルベンダーリストと、ベンダーとパブリッシャーの仲介をするCMPのリストで構成されています。各CMPは、法的根拠を伝達し、ユーザーから提供された同意の選択肢をブラウザに保存する責任を負っています。私たちは、保存されたクッキーをコンテントストリングと呼んでいます。
TCFは、欧州ではGDPRに準拠した仕組みとして意味づけられていますが、ベルギーデータ保護局による最近の決定では、この仕組みはまだ侵害されていると判断されています。カリフォルニア州でCCPAが施行されたとき、IAB Tech Lab USは同じコンセプトでU.S. プライバシー (USP) 技術仕様を策定しました。
上図は、TCFとUSPの両バージョンの使用率分布を示したものです。なお、今回のクロールは米国をベースにしているため、TCFを導入しているウェブサイトは多くないと思われる。TCFを使用しているサイトは全体の2%以下ですが、USプライバシーフレームワークを使用しているサイトはその2倍です。
フレームワークに含まれる同意管理プラットフォームでもっとも人気のある10個の中で、トップはQuantcastでモバイルでは0.34%となっています。その他、Didomiが0.24％、Wikiaが0.30％と、人気の高いソリューションとなっています。
USPフレームワークでは、ウェブサイトとユーザーのプライバシー設定は、プライバシー文字列でエンコードされています。
1----はデスクトップWebサイトの0.87%、モバイルWebサイトの0.80%、1YNYはそれぞれ0.72%、0.64%、1YNNでは0.07%、0.06%、ブランクが0.01%、0.00%で使用されていることがわかります。もっとも一般的なプライバシーに関する文字列は、1----です。これは、CCPAがウェブサイトに適用されないことを示し、したがってウェブサイトはユーザーに対してオプトアウトを提供する義務がないことを示します。CCPAは、個人情報の販売を主業務とする企業、またはデータ処理を行う企業で年間売上高が2500万ドル以上の企業にのみ適用されます。2番目に多い文字列は、1YNYです。これは、ウェブサイトが「データの販売をオプトアウトするための通知と機会」を提供したが、ユーザーが個人データの販売をオプトアウトしていないことを示すものです。
プライバシーポリシー
現在、ほとんどのウェブサイトにはプライバシーポリシーがあり、ユーザーは自分について保存、処理される情報の種類を知ることができます。
「プライバシーポリシー」「クッキーポリシー」などのキーワードを多くの言語で検索してみると、モバイルサイトの39.70%、デスクトップサイトの43.02%が何らかのプライバシーポリシーに言及していることが分かります。一部のウェブサイトでは、このようなポリシーの策定が義務付けられていませんが、多くのウェブサイトでは個人情報を取り扱っているため、ユーザーに対して十分な透明性を確保するために、プライバシーポリシーを策定することが必要です。
追跡禁止 - グローバルなプライバシー管理
追跡禁止 (DNT) HTTPヘッダーは、ユーザーが追跡を希望しないことをウェブサイトへ伝えるために使用できます。以下に、DNTの現在値にアクセスしていると思われるサイトの数を、Navigator.doNotTrack JavaScriptコールの存在に基づいて確認できます。
NavigatorDoNotTrack機能を使用してDNTの価値にアクセスするウェブサイトの割合を示す棒グラフ。デスクトップサイトの17.37％、モバイルサイトの17.39％がアクセスしています。モバイルクライアントとデスクトップクライアントでは、ほぼ同じ割合のページでDNTが使用されています。しかし、実際には、DNTのオプトアウトを尊重するウェブサイトはほとんどありません。DNTを規定するTracking Protection Working Groupは、2018年に閉鎖された。「サポート不足」のためです。Safariはその後、DNTのサポートを止め、フィンガープリント への悪用の可能性を防止するようにしました。
DNTの後継となるグローバル・プライバシー・コントロール（GPC）は2020年10月にリリースされ、より強制力のある代替手段を提供するものであり、より良い普及を期待するものです。このプライバシー設定シグナルは、すべてのHTTPリクエストに1ビットで実装されています。まだ取り込みは確認できていませんが、主要なブラウザがGPCを実装し始めているため、今後改善されることが期待できます。
ブラウザはどのようにプライバシーへのアプローチを進化させているのか
ウェブ閲覧中のユーザーのプライバシー保護を強化するため、主要ブラウザはユーザーの機密情報をより安全に保護する新機能を実装しています。Referrer-Policy ヘッダーやSameSiteクッキー に対して、ブラウザがよりプライバシーを保護するデフォルト設定を強制し始めたことは、すでに説明しました。
さらに、Firefoxはトラッキング防止機能の強化、Safariはインテリジェントなトラッキング防止によりトラッキングをブロックしようとしています。
トラッカーのブロックにとどまらず、Chromeはプライバシー・サンドボックス を立ち上げ、広告や詐欺防止などさまざまなユースケースでよりプライバシーに配慮した機能を提供する新しいウェブ標準を開発中です。サイトがユーザーを追跡する機会を減らすために設計された、これらの新進気鋭の技術について詳しく見ていきます。
プライバシー・サンドボックス
エコシステムのフィードバックを求めるため、プライバシー サンドボックスAPIの初期および実験バージョンは、最初は個々の開発者によるテストのために 機能フラグ の背後に用意され、その後 オリジントライアル を通じてChromeで使用されるようになります。このオリジントライアルに参加することで、Webプラットフォームの実験的な機能をテストし、その機能の使い勝手、実用性、有効性について、すべてのWebサイトにデフォルトで提供される前にWeb標準化コミュニティへフィードバックできます。
免責事項： Originのトライアルは限られた時間のみ利用可能です。以下の数字は、この記事を書いている2021年10月時点のプライバシーサンドボックスのオリジントライアルの状態を表しています。
FLoC
プライバシー・サンドボックスの実験でもっとも話題になったものの1つが、コホートのフェデレート学習、略してFLoCです。FLoCのオリジントライアルは、2021年7月に終了しました。
ウェブ上では、興味関心に基づく広告選択が一般的に行われています。FLoCは、その特定のユースケースを満たすために、個々のユーザーを識別し追跡する必要のないAPIを提供しました。FLoCは、いくつかのflakを取りました。Firefox や Chromiumベースの他のブラウザは実装を拒否し、電子フロンティア財団は 新しいプライバシーリスクをもたらすかもしれないという懸念を唱えている。しかし、FLoCは最初の実験でした。今後のAPIの改良で、これらの懸念が解消され、より広く採用される可能性があります。
FLoCでは、ユーザーに固有の識別子を割り当てる代わりに、ブラウザがユーザーのコホート（同じようなページを訪れた、したがって同じ広告主が関心を持つ可能性のある何千もの人々のグループ）を決定したのです。
FLoCは実験的なものであったため、広く展開されることはなかった。その代わり、オリジン・トライアルに登録することで、ウェブサイトが、テストすることができました。デスクトップとモバイルでそれぞれ62と64のウェブサイトがFLoCをテストしていることがわかりました。
最初のFLoC実験の仕組みはこうです。ユーザーがウェブ上を移動すると、ブラウザはFLoCアルゴリズムを使って、最近の閲覧履歴が同じような何千ものブラウザに対して同じ興味のあるコホートを算出します。ブラウザは、個々の閲覧データをブラウザベンダーや他の関係者と共有することなく、ユーザーのデバイス上で定期的にコホートを再計算しました。コホートをワークアウトする際、ブラウザは センシティブなカテゴリーを明らかにしなかった というコホートの間で選択を行っていました。
個々のユーザーやウェブサイトは、コホート計算の対象から外れることも可能です。
上位1,000サイトのうち、4.10%がFLoCをオプトアウトしていることがわかりました。全ウェブサイトのオプトアウト率は1%未満です。
その他のプライバシー・サンドボックスの実験
GoogleのPrivacy Sandbox構想の中では、さまざまな実験が行われています。
アトリビューションレポートAPI（旧称：換算測定）は、広告とユーザーのインタラクションがいつコンバージョンに結びついたか、たとえば広告クリックが最終的に購買につながったかなどを測定できるようにするものです。最初のオリジントライアル（2021年10月に終了）が10オリジンで有効になっているのを確認しました。
FLEDGE（第1回「グループ上の局所実行型判定」実験）は、広告ターゲティングに対応することを目指したものです。このAPIは、現在のバージョンのChromeローカルで個々の開発者で試すことができますが、2021年10月現在、オリジントライアルは行われていません。
トラストトークン は、ウェブサイトがある閲覧状況から別の閲覧状況へと限られた量の情報を伝達し、パッシブ追跡なしで詐欺へ対抗できるようにするものです。私たちは、サードパーティのプロバイダーとして多くのサイトへ組み込まれていると思われる7つのオリジンで、最初の オリジン トライアル（2022年5月に終了予定）が有効になっていることを確認しました。
CHIPS (Cookies Having Independent Partitioned State) では、ウェブサイトがクロスサイトのクッキーを「パーティションド」としてマークし、トップレベルのサイトごとに別のクッキー入れへ入れられるようにします。（Firefoxでは、Cookieのパーティショニングについて、同様の トータル・クッキー・プロテクト 機能がすでに導入されています）。2021年10月現在、CHIPSのオリジントライアルはありません。
フェンスフレーム は、埋め込みページからのデータへのフレームアクセスを保護します。2021年10月現在、オリジントライアルはありません。
SamePartyは38のデスクトップサイトと73のモバイルサイトで使用されており、サードパーティークッキーでは、2,527のデスクトップサイトと1,805のモバイルサイトで使用されています。
最後に、First-Party Sets により、ウェブサイトの所有者は、実際には同じエンティティに属している個別のドメインのセットを定義できます。所有者は、サイトが同じファーストパーティセットである限り、クロスサイトコンテキストで送信されるべきクッキーに SameParty 属性を設定できます。最初のオリジン・トライアルは2021年9月に終了しました。私たちは数千のクッキーに SameParty 属性があることを確認しました。
結論
現在もWeb上ではユーザーのプライバシーが危険にさらされています。全Webサイトの80%以上が何らかのトラッキングを有効にしており、CNAMEトラッキングのような新しいトラッキングメカニズムも開発されています。また一部のサイトでは、ジオロケーションなどの機密データを扱っており、注意を怠ると、潜在的な侵害によってユーザーの個人情報を流出させる可能性があります。
幸いなことに、ウェブ上でのプライバシーの必要性についての認識が高まり、具体的な行動につながっています。現在、ウェブサイトは、機密性の高いリソースへのアクセスを保護するための機能を利用できるようになっています。世界中の法律が、個人データの共有について、ユーザーの明示的な同意を義務付けています。ウェブサイトは、プライバシーポリシーやクッキーのバナーを実装し、これに準拠しています。最後にブラウザは、広告や不正行為の検出などのユースケースをよりプライバシーに配慮した方法でサポートし続けるために、革新的な技術を提案し、開発しています。
最終的には、ユーザーは自分の個人データがどのように扱われるかについて発言する権限を与えられるべきです。一方、ブラウザやウェブサイトの所有者は、ユーザーのプライバシーが保護されていることを保証する技術的な手段を開発し、配備する必要があります。ウェブとのインタラクション全体にプライバシーを組み込むことで、ユーザーは自分の個人データが十分に保護されていることをより確信できます。
