これは技術的ガイドラインを含む文書です。しかし、これらのガイドラインを文脈に置くためには、まずいくつかの用語を定義し、ここで「プライバシー」が何を意味するのかを説明する必要があります。
ウェブは情報の流れ で構成される社会的かつ技術的なシステムです。この文書はウェブに適用されるプライバシー に特に関するものであるため、情報の流れに関するプライバシーに焦点を当てています。
ウェブはすべての人のためのものです（[For-Everyone Ethical-Web-Principles
情報は人々を予測し影響を与えるために使われ得るだけでなく、人々の行動を制御するオンライン空間を設計するためにも用いられます。情報の収集および処理 が、より大規模に、より高精度かつ信頼性を持って、増え続ける種類のデータ間で相互運用性を高めつつ、加速して行われることにより、私的・公共の自由を脅かす権力の集中が進んでいます。さらに、自動化と生活のあらゆる面の電算化が進むことで、情報の力は増し、加害者が被害者と同じ部屋にいなければならないような多くの侵入的行為のコストが下がっています。
あるアクター がデータ を収集し、それを自動的に処理でき、かつその人 が自分のデータ を保護したり処理を制御したりするために手動の行動を取らなければならない場合、この自動化の非対称性 は当該アクター に有利な権力の不均衡を生み、その人 の主体性を低下させます。本書はデータ の処理 が人々に与える影響に焦点を当てますが、企業や政府のような他のアクター にも影響を及ぼし得ます。
すべての人が権力の不均衡に対して同じように抵抗できるわけではないことを念頭に置くことが重要です：ある人 はより脆弱 であり、したがってより多くの保護を必要とします。
データガバナンス は情報の流れ を規制する原則の体系です。
データガバナンス は、どのアクター がどのようなデータ を収集できるか、どのように収集できるか、そしてどのようにそれを処理 できるかを決定します（[GKC-Privacy IAD データガバナンス のためのビルディングブロックを提供します。
原則は文脈 によって異なります（[Understanding-Privacy Contextual-Integrity プライバシー に対して異なる期待を持ちます。プライバシー状況を理解し評価するには、次を明確に特定することが最も良い方法です：
そのアクター （情報の主体だけでなく、情報の送信者や受信者を含む）。（受信者が常に受信者でありたいとは限らない点に注意。）
その情報の流れ に関与するデータの種類。
その文脈で使用されている原則。
常にプライバシー原則が働いています。ある原則の方が寛容である集合があっても、それが中立であることを意味しません。すべてのプライバシー原則は人々 に影響を与えるため、どの原則がウェブの文脈 における倫理的ウェブ価値と最も整合するかを決定する必要があります（[Ethical-Web-Principles Why-Privacy
情報の流れ とは、アクター によって交換または処理される情報を指します。人のプライバシーは、彼らから他のアクターへ情報が流れることによっても、彼らへ情報が流れることによっても侵害され得ます。後者の例には、予期せぬ衝撃的な画像、睡眠をとろうとしているときの大きな音、操作的な情報、何かに集中しているときの中断的なメッセージ、または社会的なやり取りを求めているときの嫌がらせなどが含まれます。（これらのいくつかの場合、情報は個人データ でないかもしれません。）
ウェブ上では、情報の流れ には、特定の相互作用内でユーザーにとって常に認識可能または明白でない多様なアクター が関与する場合があります。ウェブサイトを訪問することは、そのサイトの運営に関与するアクターだけでなく、ネットワークアクセスを持つアクターも含む可能性があります。これにはインターネットサービスプロバイダー、その他のネットワーク事業者、学校・図書館・大学などネットワーク接続を提供する地域の機関、政府の情報機関、ネットワークや他のアクターのシステムにアクセスした悪意あるハッカーなどが含まれ得ます。監視などのハイレベルな脅威はこれらのアクターによって追求され得ます（[RFC6973 RFC7258
情報の流れには他の人々も関与する場合があります — たとえば、サイトの他の利用者 —
これには友人、家族、教師、見知らぬ人、政府当局などが含まれ得ます。開示や嫌がらせを含むプライバシーへの脅威のいくつかは、情報の流れに関与する他の人々に特有である場合があります（[RFC6973
ある人 の自律性 とは、他のアクター からの過度な影響を受けずに、自分自身の意志で決定を下す能力を指します。人々は決定を熟考するための知的資源と時間が限られており、決定を下す際に近道に頼らざるを得ません。これにより、プライバシーに関する選好を含む彼らの選好が操作され得ます（[Privacy-Behavior Digital-Market-Manipulation 人 の自律性 は、その人が無制限の時間と知的能力を持っていた場合に下したであろう決定により近い近道をシステムが提供すると向上します。逆に、そのような理想的条件でなされた決定に反する近道が提供されると、自律性 は低下します。
自律性を低下させるアフォーダンスや相互作用は、欺瞞的パターン （またはダークパターン）として知られています。欺瞞的パターン は故意である必要はありません（[Dark-Patterns Dark-Pattern-Dark 自律性 に影響を与える可能性のある何かを構築する際には、複数の独立した観点からのレビュー担当者が介入して、それが欺瞞的パターン を導入していないかを確認することが重要です。
今日のデータ経済における潜在的なデータ 関連の決定の量が大きいため、人々が自分のデータの処理方法を詳細に制御することは不可能です。この事実はプライバシーが終わったことを意味しません。研究は、人々が自分のデータ の処理 に関して依然として懸念を抱き、無力感を感じ、主体性を失ったと感じていることを示しています（[Privacy-Concerned データ に関してより大きな自律性 を持てるようにできます。これは、適切でプライバシーを保護するデフォルトを設定し、ユーザーフレンドリーな選択のアーキテクチャを設計することで行われます。
人々がデータ処理システムとの相互作用を制御することを可能にする仕組みはいくつか存在します。処理される目的 の数や、処理されるデータ の量を増やす仕組みは、オプトイン または同意 と呼ばれます。目的や処理されるデータの量を減らす仕組みは、オプトアウト として知られています。
これらの仕組みは慎重に導入されれば人々の自律性 を向上させ得ます。しかし多くの場合、どの種類の処理 が適切かを決定するという困難な仕事を回避する手段として使われ、プライバシー労働 をシステムを使用する人々に負わせることになります。
人々は写真や位置情報へのアクセス許可を与えるなど、通常は制限されるようなデータ共有に同意 できるべきです。アクター は、ユーザーがこの同意 を与える際に十分に情報を得て 認識 できていることに注意を払う必要があります。データ処理への同意 とウェブプラットフォームAPIへのアクセス許可の付与は類似の問題です。どちらも、ユーザーが別のことをしているときに答えるのを遅らせたり回避したりできるように要求されるべきです。ユーザーがデータへの永続的なアクセスを与えた場合、その継続的なアクセスをユーザーが認識でき、それをいつでもオフにできる指標があるべきです。一般に、同意 はまれで、意図的で、一時的であるべきです。
オプトアウトメカニズム が存在する場合、望ましくは
グローバルオプトアウト メカニズムと連携して動作するべきです。概念的には、グローバルオプトアウト メカニズムは
ユーザーエージェント の一部として動作する自動装置です。これは、ロボットが
個人 の指示に従って、オプトアウトボタン （または
個人 の権利の同様の表現）を、その個人 がサイトとやりとりするたびに押すことのようなものです。（例えば、個人 が正当な利益に基づく処理 に異議を唱えたり、特定の目的 への同意 を撤回したり、自分のデータの販売や共有を拒否したりする場合です。）ユーザー は実質的に、自身のオプトアウト意思表示 をユーザーエージェント に委任しており、これは自動化の非対称性 の是正に役立ちます。Global Privacy Control
(GPC) グローバルオプトアウト メカニズムの好例です。
このモデルにおいて、グローバルオプトアウト 信号は、個人 がかつて設定を切り替えたり、特定のユーザーエージェント を選択したときに行った決定として理解されるべきではなく、むしろサイトとのあらゆるやりとりごとにその選択を自動的に再確認するという好みとして理解されるべきです。
オプトアウト や他のデータ権利 の実装戦略の一つは、個人 に安定した識別子 を割り当て、中央レジストリでそれらの識別子 を個人 の選好とマッピングして管理することです。特定の個人のデータを処理したい事業者 は、中央レジストリからその個人の選好を取得し、それに従って処理内容を設定することが求められます。この方式は、電話番号や住所のマーケティング利用に関するオプトアウトの記録などに用いられてきましたが、多くの理由から推奨されません――悪意のある事業者に対して技術的な防御にならず、単一障害点を生み、（特にウェブシステムが暗示する処理規模では）真に監査することが困難であり、既存システムの経験から個人が権利を行使しにくくなることが明らかになっているためです。
プライバシー労働 とは、ある人 に自分が主体または受信者であるデータ処理 が適切であることを保証する作業をさせる慣行であり、処理を行うアクター に責任を負わせる代わりに行われます。人々 に同意 を求めるデータシステムは、プライバシー労働 を増やす傾向があります。
より一般的には、プライバシー の実装はしばしば人々に労働 を負わせます。これは特に1970年代にデータベースに関する懸念に対抗して個人の自律性を支援するために最初に展開された緩やかな原則群である公正情報慣行（FIPs） に由来する制度で顕著です。FIPs は、当時の想定では処理が十分に少なく、各人が十分な注意義務を果たして意思決定において自律的であり得ると仮定していました。FIPs は、プライバシー労働を人々に負わせ、無制限の自律性 を仮定しているため、特定の種類のデータ処理 を禁止するのではなく、それらを異なる手続き的要件の下に置くだけです。このアプローチはもはや適切 ではありません。
手続き的アプローチの一つの顕著な問題は、同じ要件が、モノポリー的なプラットフォームが提供する必須サービスを利用する人のように別のアクター との間に重大な権力の非対称性を抱える状況と、人と他のアクターがほぼ対等である状況、あるいは小規模事業者のように人の方がより大きな権力を持つ場合とで同じ要件を課す傾向がある点です。また、一つのアクター が他のアクター に不適切な慣行を促すよう強要する場合（広告やコンテンツ集約における支配的プレイヤーにしばしば見られるように）を考慮していません。
FIPs への言及は今日まで残っています。しばしば「透明性と選択」と呼ばれますが、今日のデジタル環境では、これはしばしば不適切な処理 が説明されている兆候であることが多いです。
ときに、子どもや高齢者のような特定の集団が脆弱な人々 として分類されます。しかし、どの人 も、ある文脈では脆弱になり得ますし、時にはそれに気づかないこともあります。ある人 は個人データを開示したときに自分が脆弱であることや将来脆弱になる可能性があることに気づかないかもしれませんし、アクター がその人の脆弱性を知る方法を持たない場合もあります。システム設計者はこれを設計において考慮すべきです。
個人データの収集、誤用、紛失、または盗難の結果として、ある個人がプライバシーリスクや被害に対してより脆弱である場合があります。その理由としては：
属性、関心、意見、行動によること；
情報の非対称性やその他の権力の不均衡がある状況や設定によること；
リスクを完全に評価する能力を欠いていること；
選択がわかりやすく意味のある方法で提示されないこと（例：欺瞞的パターン ）；
プライバシーのニーズや期待について相談されていないこと；
製品やサービスの設計における意思決定で考慮されていないこと。
追加のプライバシー保護は、脆弱な人々の個人データや、個人データが収集・使用・共有された場合に誰かを脆弱にする可能性のある機微情報 に対して必要とされる場合があります（例：トラッキング要素、センサーデータ、インストールされているソフトウェアや接続されたデバイスに関する情報のブロック）。
時には他者（親、保護者 、仲間など）が脆弱な人々がプライバシーリスクを評価しプライバシーに関する決定を行うのを助けることがありますが、誰もが独自のプライバシー権を有します。
一部の脆弱な人々 は、自分のウェブ利用に関して適切な決定を行うのを助けるための保護者 を必要とします（例：子どもで、その親がしばしば保護者として行動する場合）。保護者を持つ人は被保護者（ward） と呼ばれます。
被保護者 は、情報に基づいた決定を行い、自分のプライバシー権に関して自律性を行使する権利を有します。保護者 には、その被保護者の能力が十分でないときに、その被保護者が自己決定できるよう助けるという義務 があります。実際には、多くの
保護者 が被保護者の最善の利益に沿った決定を行わないことがあり、ウェブプラットフォーム技術がこの状況に内在するリスクを悪化させないことが重要です。
ユーザーエージェント は、慈悲深い保護者 が被保護者を危険から守る必要性と、被保護者が悪意ある保護者 から自分を守る必要性のバランスを取るべきです。
ユーザーエージェント は、被保護者 を、2.8
デバイスの所有者と管理者
ある子どもが自分がLGBTであると気づき、オンラインで支援リソースを探す必要があるかもしれません。もしその子の親が同性愛嫌悪やトランス嫌悪である場合、親は子どもがLGBT関連のページを訪れたときにブロックしたり親に通知したりするようにユーザーエージェントを設定しているかもしれません。ユーザーエージェントはその構成を子どもに警告する必要があり、子どもが必要な支援を得るためにより良い保護者 に頼むことを知っておけるようにしなければなりません。
プライバシー原則は社会的プロセスを通じて定義されるため、ある文脈でのプライバシー の適用される定義は争われ得ます（[Privacy-Contested GKC-Privacy データ処理 は、個人が同意 できるという楽観的な仮定の下でも、集団や個人に影響を与え得ます。例えば、ある人が特定のアクターに明かすことを望む唯一のことがその人が特定のグループの一員であるということかもしれません。しかし、同じグループの他のメンバーは同じアクターとやり取りしてもっと多くの情報を明かしており、その結果、情報を提供しない人々についても効果的な統計的推論が可能になることがあります。
したがって我々が考慮するのは、データを共有する人々 とその共有を招くアクター の関係だけでなく、同じく別の人々がグループの一部として間接的に分類され得るという点でもあります。こうした関係は非識別化 されても持続し得ます。さらに、そのような人々のカテゴライズ（任意であれそうでなかれ）は世界の運営の仕方を変えます。これは自己強化的なループを生み、個人やグループの両方に害を与え得ます（[Seeing-Like-A-State
一般に、データにおける集団的問題は集団的な解決を必要とします。ウェブ標準はデータガバナンス を支援し、ユーザーエージェントに構造的制御を定義し、研究者や規制当局がグループレベルの乱用を発見できるようにし、プライバシーの問題を扱える機関を確立または委任することで役立ちます。ガバナンス は主に個人のコントロールを増やすことで機能しようとすると、その目標を達成するのに苦労することが多いでしょう。
大規模でのデータ収集は重大な公益的成果をもたらすことがあります。問題は、しばしばあるアクター が集団の利益のためにデータを処理しつつ、同時に不誠実な（disloyal ）目的のためにも処理する場合に生じます。不誠実な目的はしばしば公益的成果の資金として正当化されますが、それが適切 であるためには集団的な監視が必要です。
人々がグループのメンバーになる方法は異なります。自発的に参加してクラブのように自己構成されたグループになる場合もあれば、官僚機構やその電算化された同等物によって外部のアクターにより分類される場合もあります（[Beyond-Individual
グループのプライバシーを保護することは二つのレベルで行えます。グループの存在や少なくともその活動は、メンバーが匿名のままであることが保証されている場合でも保護される必要があるかもしれません。これを「グループのプライバシー」と呼びます。逆に、人々はたとえグループの存在や行動が広く知られていても、自分がそのグループのメンバーであるという知識を守りたいかもしれません（例えば権威主義体制下の反体制派運動への参加）。これを「メンバーシップのプライバシー」と呼びます。前者の例としては、フィットネスアプリのStravaが個々の行動や法的身元を公開しなかったが、人気のあるランニングコースのヒートマップを公開することで米軍基地周辺の秘密の拠点を明らかにした事例が挙げられます（[Strava-Debacle Strava-Reveal-Military
少人数のグループに関する情報が処理されると、個別のデータが露出していなくても人々のプライバシー利益が影響を受けることがあります。例えば、教室の生徒たちの閲覧活動は、教師がどの生徒が特定の健康問題に関するリソースにアクセスしたかを正確に知ることがなかったとしても敏感であり得ます。特定の診療所を訪れた人々や特定の陪審員に選ばれた人々に情報をターゲティングすることも、個人を特定するデータがなくても侵襲的である場合があります。
人々が自分がグループのメンバーであることを知らないとき、権利を共同で主張するために他のメンバーを容易に見つけられないとき、あるいはなぜ自分があるグループに分類されているのかを容易に理解できないとき、自己統治的アプローチで自分を守る能力はほとんど失われます。
グループのプライバシーにおける一般的な問題の一つは、グループのあるメンバーの行動が他のメンバーが共有されたくない情報を明らかにしてしまう場合です。例えば、ある人がイベントの写真を公開するとき、その写真に写っている他の人々は自分の参加が明らかにされることを望まないかもしれません。連絡先をアップロードできるサイトの例では、アップロードを行う人が自分のソーシャルネットワークを公開することにより寛容であっても、接続されている他の人々はそれを望まないかもしれません。こうした問題には単純で明快な解決策が存在しない場合が多いですが、ウェブサイトを構築する人々はそれらを慎重に検討する必要があります。
透明性は個々の人々が行う選択を十分に助けることはまれですが、研究者や記者がプライバシー原則に関する集合的な意思決定を情報提供することを可能にする上で重要な役割を果たします。この考慮は、TAGのStrong and Secure Web
Platform に関する決議を拡張し、「情報の流れ」や自動化された決定が関与する場合に広範なテストと監査が継続して可能であること を確保するものです。
そのような透明性は、（自分の個人データから派生したデータを含む）データへの強いアクセス権と、自動化された決定の結果を説明する仕組みが存在する場合にのみ機能します。
ユーザーエージェント は、人 （そのユーザー ）とウェブとの間の仲介者として機能します。ユーザーエージェント は、可能な限り集団的ガバナンスが個人に有利に定める原則を実装します。情報の非対称性の創出を防ぎ、ユーザー のために自動化によって自動化の非対称性を是正するオートメーションを提供します。可能な場合には、侵入的なメッセージの受信からユーザーを保護します。
ユーザーエージェント は、それを使用する人 と完全に整合し、その人 の利益のみで動作することが期待されます。それは第一当事者 ではありません。ユーザーエージェントはそのユーザーを優先する信頼できる代理人（trustworthy
agent ）として機能します：常にその人の利益を第一にします。場合によっては、危険な決定の実行を防いだり、決定を遅らせたりして、その人から自分自身を守ることを意味することもあります。例えば、ユーザーエージェントはサイトの正当性を検証できない場合にそのサイトへの接続を難しくするでしょう。ページに対して敏感なデバイスを公開しようとする人が本当にそう意図しているかを確認します。行動の恒久的な監視に同意させることを防ぎます。そのユーザーエージェントの義務 には以下が含まれます（[Taking-Trust-Seriously
保護の義務（Duty of Protection）
保護はユーザーエージェント が単なるセキュリティ対策を超えてユーザーのデータを積極的に保護することを要求します。保存時や送信時の暗号化だけでは不十分です。ユーザーエージェントは保持期間を制限し、厳密に必要なデータのみが収集されるよう支援し、データが共有されていることをユーザーエージェントが合理的に認識できるようにするためにどのようなアクター から保証が得られるかを要求する必要があります。
裁量の義務（Duty of Discretion）
裁量はユーザーエージェントが管理する個人データ の開示方法に注意を払い、原則を施行するために最善を尽くすことを要求します。裁量は機密性や秘密性と同一ではありません：ユーザーエージェントがある程度の個人データを共有しても、適切に配慮された方法であれば信頼は維持できます。
誠実さの義務（Duty of Honesty）
誠実さはユーザーエージェントがユーザーに対して、ユーザーエージェントが合理的に把握し得る、その人に関連し自律性を高める情報を提供することを要求します。ただし、それはユーザーが理解できるものであり、適切なタイミングで行われるべきです。これはユーザーがページを読んだり機能を起動したりしている時など、ほとんどの場合には適切ではありません。誠実さの義務は、従来のプライバシー体制に含まれる透明性の義務をはるかに超えます。透明性とは異なり、誠実さは関連情報を複雑な法的文書に隠したり、同意ダイアログでの非常に短い要約に依存したりすることはできません。もしその人が自分の個人データの処理 に同意 している場合、ユーザーエージェントはその人に進行中の処理について、処理の合理的に予測される影響の大きさに比例した明白さのレベルで通知するべきです。
忠誠の義務（Duty of Loyalty）
ユーザーエージェントは信頼できる代理人であるため、実装者よりも含め常にそれを使用する人 に忠実であると見なされます。ユーザーエージェントが行う処理 がユーザーの利益に反し、代わりに他のアクター に利益をもたらす場合、これは不忠（disloyal） です。多くの場合、これはユーザーエージェント自身に利益をもたらし、その場合は「自己取引（self-dealing）」と呼ばれます。ある行為が同時にユーザーの利益に沿った処理を行っている場合でも、それが他方の利益と潜在的に矛盾するならば行為は不忠 であり得ます。さらに、追加の処理はほとんど常に追加のリスクを意味することを忘れてはなりません。したがってユーザーの利益に明示的に沿っていない処理は不忠である可能性が高いです。不忠 は常に不適切 です。
これらの義務により、ユーザーエージェント がそのユーザーを配慮して世話する ことが保証されます。学術研究では、この信頼できる代理人との関係はしばしば「受託者的（fiduciary）」と表現されます（[Fiduciary-Law Fiduciary-Model Taking-Trust-Seriously Fiduciary-UA Fiduciary-Law
この文書の残りで説明される多くの原則は、ユーザーエージェントの義務を拡張し、それらをより明確にします。
プライバシー原則は互いに連携して補完するよう設計されていますが、あるプライバシー原則の順守を改善するための提案が別の原則の順守を減少させることが稀にあります。
Principle 1.5.1 :
明白なトレードオフに直面した場合、まずすべての原則を同時に改善する方法を探してください。
全ての原則を完全に満たしていない初期設計があるとき、通常は他のいくつかの設計があり、それらはある原則に関して状況を改善しつつ他の原則に関しては何も犠牲にしないことができます。そのような設計を見つけるよう努めてください。
別の言い方をすると、原則の間でトレードオフを始める前にパレート改善 を探してください。
ウェブサイト ユーザーエージェント API
デザイナー
パレートフロンティア上の異なる設計の間で選択する場合、どのプライバシー原則を優先するかの選択は複雑で、各状況の詳細に大きく依存します。人々のプライバシーは非プライバシー上の懸念とも緊張することがあります。Ethical Web
Principles Ethical-Web-Principles
Principle 1.5.2 :
サービスが利用者または他の利用者を保護するために追加データを収集する必要がある場合、そのデータがサービスの成長などの他目的に使用されないように追加の技術的および法的措置を講じる必要があります。
これは、データが収集されたときに指定された目的以外にデータを使用すべきでないというより一般的な原則の特別なケース です。
サービスは時折、人々のデータを使用してその人自身や他の人々を保護します。そのようなサービスは、どのデータをこの目的で使用しているかを説明すべきです。また、サービスはその人がサービスのルールに違反したと信じる場合に、その人のデータをどのように使用または共有し得るかも述べるべきです。
ウェブサイト ユーザーエージェント
誰かが使用しているサービスのルールに違反した場合、その人はプライバシー保護を相応に犠牲にするという考えは魅力的ですが、
しばしばサービスは違反を防ぐために無実のユーザーからもデータを収集しなければならないことがあり、この追加収集は常に適切 であるとは限らず、常時監視を可能にすることがあります（[RFC7258 RFC7687
サービス事業者が追加データを収集したい場合、収集を可能にするようなルールや比例性を定義しがちです。
次の例はこれらの緊張のいくつかを示しています：
ある人は、多数のアカウント（「sockpuppets」）を作成したり、個人所有アカウントの所属を偽装したり（「astroturfing 」）して他者を騙し、ある信念が実際よりも支持されているように見せかけたいかもしれません。これは他の人々の操作から自由である権利を侵害します。
一方で、これらのケースを検出するのに十分な詳細で全員を識別することは、監視や相関から彼らを守る権利を侵害する傾向があります（[RFC6973
子どもがサービスを利用する（またはその保護者が）場合、彼らのそのサービスとのやり取りが他の子どもにのみ見えるようにしたいかもしれません。それを実現するには、サービスはすべてのユーザーの年齢を確認する必要があります。
サービスはユーザーに自分が指定年齢未満であると自己申告させるか（検証せず）、学校のような信頼できる機関に年齢を確認してもらうことに頼るかもしれませんが、年齢を直接検証することはプライバシー侵襲的であり得ます。自動顔認識、生体画像の収集、または強く個人を特定する識別（例：[NIST-800-63A
サービスのアカウントは、単なるユーザー名とパスワードより強く保護される必要があります。乗っ取られたアカウントはアカウント内に保存されたすべての機密情報を露出させるため、これは単なるセキュリティの問題ではなくプライバシーの問題です。サービスはしばしば、不審なログインを難しくするために過去にアカウントにアクセスした位置情報やマシンの特性を保存します。また、実際のアカウント所有者からのログインであるかを確認するために電話番号や住所のような個人データを保存することもあります。
ウェブ上の一部のアクターは、サイト間で各ユーザーの行動の詳細なプロファイルを構築することに高い価値を置いています。ユーザーエージェントは2.1
ウェブ上のアイデンティティ2.1
ウェブ上のアイデンティティ
ユーザーエージェントは、ユーザープロファイルの最も一般的で最も害の少ない用途を促進するAPIを構築することで、これらの代替追跡手法を生み出すインセンティブを減らすことができます。しかし、これらのAPIは通常、ユーザーの行動に関するいくつかの情報を依然として明らかにします。例えば、最もプライバシーを尊重するコンバージョンアトリビューションAPIでさえ、広告キャンペーンの成功を測るために各ユーザーについて限定的な量の情報を明らかにします。このような少量の情報であっても依然として個人データ です。
このセクションでは、一般的なウェブの文脈 に適用されるよう設計された一連の原則について述べます。ウェブ上の特定の文脈 では、より多くの制約や別の考慮が必要な場合があります。今後、より特化したウェブ上の文脈 に向けた、より専門的なプライバシー原則が公開されることが期待されます。
これらの原則はユーザーエージェント によって実施されるべきです。これが不可能な場合は、他の主体がそれらを実施する方法を見つけることを推奨します。
個人 のアイデンティティ は、その人を定義する特性の集合です。ある文脈 における アイデンティティは、特定の状況下で提示される特性の集合を指します。
人は異なる文脈に対して異なるアイデンティティを提示でき、また単一のアイデンティティを複数の文脈で共有することもできます。
人は一時的または匿名のアイデンティティを提示したいと望むことがあります。これは、時間を通じて追跡するのに有用でないほど小さいか不安定な特性の集合です。
人のアイデンティティ は、しばしば本人が持つ法的なアイデンティティとは異なる場合があります。
場合によっては、この原則を守るためにユーザーエージェント が認識 を防ぐことが最良の方法であることがあります（例：あるサイト が別のサイトでの利用者の振る舞いについて何も学べないようにする場合）。
別の状況では、この原則を守る最良の方法はユーザーエージェント が認識 を支援する ことです（例：利用者があるサイトに対して別のサイト上で特定のアイデンティティを持っていることを証明するのを助ける場合）。
同様に、ユーザーエージェント は、同一のサイト への繰り返しの訪問において、認識を防止または支援することで利用者を助けることができます。
ユーザーエージェント は、サイト内の文脈 を可能な限り区別し、利用者の希望に応じてそれらのサイト内文脈間での認識 を防止または支援するために自らのパーティション を調整すべきです。
Principle 2.2.2 :
Web API は、サイトがユーザーの目標を達成するために要求するデータ量を最小化するよう設計されるべきです。
Web API はまた、サイトに送信される個人データ に関して粒度やユーザーによる制御を提供するべきです。
APIデザイナー
データ最小化は、データが露出または誤用されるリスクを制限します。また、ユーザーエージェント や他のアクター が、そのユーザーが行う必要のある意思決定をより意味のある形で説明するのにも役立ちます。詳細は Data Minimization in Web
APIs
データ最小化の原則は、特定の識別性、機微性、または他の有害性が知られていない場合でも、すべての個人データ に適用されます。参照：
2.4 機微情報
単純な <input type="email"> 要素は通常二つの情報を提供します。
一つ目はそのユーザーがそのメールアドレスで送られたメッセージを受け取れるということ、二つ目はそのアドレスがそのユーザーに関連付けられた数少ないメールアドレスの一つであるということです。
二つ目のデータは、そのアドレスを文脈間で人を認識 するために有用になります。曝露されるデータを最小化する一つの方法は、各文脈ごとに新しいメールアドレスを自動生成することです。
サイト は時にユーザーの一次的な目標のために必要ない方法でデータを使用することがあります。例えば、広告主に請求したり、サイトのパフォーマンスを計測したり、開発者にバグを知らせたりすることがあります。これらは付随的使用 の例です。
付随的使用 とは、データの処理 が、そのデータの主体である個人 以外のアクターに主に直接的な利益をもたらすような場合を指します。個人データの付随的使用は、その個人に間接的な利益をもたらすことはありますが、その利益は間接的です。
例えば、広告主に課金できることはサイトの運営を維持し将来的な利用を可能にするという利益をもたらしますが、この利益は主にサイト所有者が享受するものです。
サイト は付随的使用のために多様な場所から必要なデータを取得することがあります：
非付随的API
ユーザーの即時の目標をサポートするよう設計された Web API（例：DOM
イベント や 要素位置監視 ）。
既存情報から計算される付随的API
Event
Timing API IntersectionObserver
のように、非付随的APIから利用可能な情報をフィルタリング、要約、または時間シフトするAPIです。
既存の非付随的APIを新しい付随的APIの正当化に使用する際の制限は、2.3 Information access
新しい情報を提供する付随的API
付随的使用を支援するために主に有用な新しい情報を提供するAPI（例：element paint timing 、メモリ使用測定 、および deprecation
reports ）。
これらすべてのデータ源は、人の設定、デバイス、環境、または振る舞いに関する個人データ を明らかにする可能性があり、それらは機微な情報 であったり、ブラウザフィンガープリンティングの一部として人を認識 するために使用されたりすることがあります。2.2 データ最小化サイト やユーザーエージェント は、人々のこのデータ使用に関する目標や好みを理解し尊重するよう努めるべきです。
作業部会は、ユーザーエージェント が既存情報から計算される付随的APIをどのように扱うべきかについて合意に達していません。これらのAPIの支持者は、それらが個人データを抽出するのが難しく、同じ情報を非付随的API経由で収集するより効率的であり、多数のユーザーがそれらをオフにするとサイトがそれらを採用しにくくなり、それらをオフにする行為自体がブラウザフィンガープリンティングに寄与する可能性があると主張します。一方、反対者は、データがより容易または安価に収集できるならばより多くのサイトがそれを収集するようになり、リスクは依然としてあるため、ユーザーはサイトの機能を直接壊すことのないこのクラスのAPIを無効にできるべきだと主張します。
異なるユーザーは異なる好みを持つ可能性があるため：
データ権利だけではウェブのすべてのプライバシー原則を満たすには不十分ですが、それらは自己決定を支援し説明責任を改善するのに寄与します。こうした権利には次が含まれます：
この権利には、自分について収集または推論された情報を確認できることや、自分について情報を収集したアクター を発見できることが含まれます。その結果、人々についての情報を含むデータベースは秘密に保持することができず、人々が自分に関するデータを意味のある形で発見できる必要があります。
個人は、サービスの使用を完全に終了するかどうかにかかわらず、自分に関する情報を消去する権利を有しますが、どのデータ が消去可能かはその二つのケースで異なるかもしれません。ウェブ上では、個人はデバイス上やサーバー上、あるいはその両方のデータを消去したい場合があり、データの所在が常にその人に明確であるとは限りません。
移植の権利 ：自分が他のアクター に預けたデータを含め、簡単に再利用または他へ転送できるようにする権利。
移植性は、異なるデータ慣行を持つサービス間で選択するために個人が能力を持つことをサポートするために必要です。再利用のためには相互運用性の標準が不可欠です。ユーザーデータの移植は
Portability-Threat-Model に記載されたようなセキュリティとプライバシーのリスクを伴います。
重大な結果を伴う種類の意思決定については、自分を自動プロファイリングから除外できることにプライバシー上の利益があります。例えば、あるサービスは製品価格（価格差別）やクレジットや保険に関するオファーをその人について収集されたデータに基づいて変更するかもしれません。これらの変更は重大であり（例えば金銭的に）不正確または不当であると信じる人々にとっては異議を唱え得ます。また、サービスがカメラデータ上で顔認識アルゴリズムを実行してユーザーのアイデンティティや人間性、存在を推定することがあり得ます。顔認識アルゴリズムや訓練データセットは誤りやバイアスを示すことがあるため、人々はその種の自動認識に基づく決定に服したくない場合があります。
異議を唱える権利、同意を撤回する権利、および使用を制限する権利 ：自分に関するデータに対して。
人々 は同意を変更したり、自分に関するデータの後続使用に異議を唱えたりするかもしれません。データ権利は、収集時の選択だけでなく継続的なコントロールを個人が持つことを意味します。
OECD プライバシー原則、Records, Computers and the Rights of Citizens、GDPR
などは、人々がデータ主体として持つ多くの権利を記述しています。これらの参加的権利は、自律性に固有のものです。
データは、当該データだけ、または他の利用可能な情報と組み合わせても、そのデータで記述された個人 が直接的または間接的に（例：識別子、ユーザーエージェント、デバイスとの結び付けによって）識別できないという高い信頼度が存在するときに非識別化 とみなされます。多くの地域の規制はデータが非識別化と見なされるための追加要件を定めていますが、それらの要件をプライバシー保護の最大限度として扱うべきではありません。集団に関連するさらなる考慮は
集団における問題 セクションで扱われます。
管理された非識別化データ とは次のような場合を指します：
データの状態 が、個人を再識別するのに使える情報が削除または変更されていること、そして
個人を再識別しようとする試みや非識別化データの偶発的な漏洩を防ぐためのプロセス が存在すること。（[De-identification-Privacy-Act
管理された非識別化データに関するさまざまな状況は、異なる管理策を必要とします。例えば、管理された非識別化データが単一の アクターによってのみ処理される場合、典型的な管理には、データに使われる識別子 がそのデータセットに固有であることを確保すること、データにアクセスできる任意の人（例えばアクターの従業員）がデータをさらに共有することを法的条件等で禁じられていること、再識別や異なるデータセットの結合を防ぐ技術的手段が存在することなどが含まれます。
一般に、目標は技術的および手続き的手段によって擬名性の維持を保証するための監視と説明責任が実行可能な度合いで提供されるように、管理された非識別化データが使用されることを確保することです。
このような管理された非識別化データが複数のアクター 間で共有される場合、そのような場合はより困難になります。そのような場合に代表的な最良慣行の典型例には次を確保することが含まれます：
データに使用される識別子 が、そのデータと直接やり取りする第一当事者 の直接的かつ排他的な管理下にあり、それらがデータと突き合わせられないよう厳格な管理によって防がれていること。
これらの識別子が第三者と共有されるとき、それらは当該第三者ごとに固有にされ、複数の第三者に共有された場合でも互いに照合できないこと。
どの第三者も、その第一当事者とのやり取りを通じて得られた以外のデータと当該データを突き合わせられないという強い信頼性があること。
当該データを受け取る第三者は、そのデータをさらに共有することを法的条件等で禁じられていること。
再識別や異なるデータセットの結合を防ぐ技術的手段が存在すること。
第一当事者と第三者の間に、データが共有される限定的な目的を記述する契約条件が存在すること。
注意：管理された非識別化データそれ自体だけでは、データ処理を適切 なものにするには不十分です。
Principle 2.7 :
グループや組織は、データ共有を防止または可能にする決定を集団的に行い、データ処理ルールのデフォルトを設定することで自律性を支援するべきです。
ウェブサイト ユーザーエージェント
プライバシー原則はしばしば個人に権利を拡張するという観点で定義されますが、どの原則が適用されるべきかを決めるのがグループを代表して集団的に行うのが最適である場合があります。集団的意思決定を検討すべき場合：
グループのメンバーシップに関する情報やグループの行動に関する情報がある場合。Brent Mittelstadt
が説明するように、「アルゴリズムによってグループ化された個人は、グループについての情報の作成およびそれに代わって行われる行動に対して集団的な利益を有する」。(Individual-Group-Privacy 1.3.1 グループのプライバシー
個人が現実的に情報に基づいた決定を下すことが期待できない場合。これはデータ処理が複雑であったり、データ処理の要求が非常に頻繁に行われる場合に発生し得ます。
個人がデータ処理に同意するよう求める組織より体系的に力が小さい場合。([Relational-Turn
個人が匿名のままであっても、社会的レベルでデータ処理が不公正である場合。([Relational-Governance
どのデータが処理されるかによって、集団的意思決定の正当な形態は異なります。これらの形態は、さまざまな行政レベルの政府機関、標準化組織、労働者の交渉単位、あるいは市民社会のフォーラムなどであり得ます。集団的意思決定は個人にプライバシー労働を負わせるよりも優れていることがありますが、万能薬ではありません。意思決定機関は慎重に設計される必要があり、例えば
Institutional Analysis and Development フレームワークのような方法を使うべきです。
コンピュータデバイスには、プログラムのインストールや設定のためにデバイスに特権的アクセスを持つ管理者 がいます。デバイスの所有者 は、デバイス全体を管理するために管理者を認可することができます。いくつかのユーザーエージェント の実装は、ログインしているアカウントに基づいて特定のユーザーエージェントを管理する管理者を割り当てることもできます。
ときに、デバイスを使用している人 はデバイスを所有しておらず、管理者権限を持たないことがあります（例：雇用者が従業員にデバイスを提供する場合、友人がゲストにデバイスを貸す場合、親が幼い子にデバイスを提供する場合）。また、デバイスの所有者で主要な利用者であっても管理者アクセスを持つのがその人だけでない場合もあります。
これらの関係は権力の不均衡を含むことがあります。子どもは親が提供するデバイス以外のデバイスにアクセスするのが難しいかもしれません。虐待の被害者は、パートナーがデバイスに対する管理者アクセスを持つのを防げないかもしれません。従業員は職を維持するために雇用者のデバイスを使用することに同意しなければならないことがあります。
デバイスの所有者はデバイスが意図した方法で使用されることを確保する利害や時には責任を持ちますが、デバイスを使用する 人は使用中にプライバシー権を持ち続けます。この原則はこの使用中のプライバシー権を二つの方法で強化します：
ユーザーエージェント の開発者は、デバイス所有者や管理者からの要求が合理的かどうかを検討し、販売が減るとしても不合理な要求を実装するのを拒否する必要があります。所有者/管理者の必要性は利害関係の優先順位においてユーザーの必要を上回るものではありません。
情報開示が合理的である場合でも、その情報が開示される当該の人 はそれについて知る必要があり、望ましくない結果を招くような行動を避けられるようにするべきです。
いくつかの管理者からの要求は、従業員や子どものような特定の種類のユーザーにとっては合理的であるかもしれませんが、友人や親密なパートナーのような他の種類のユーザーには合理的でない場合があります。ユーザーエージェント は、管理者が何を学ぶことになるのかを説明し、異なるユーザーがそれに対して適切に反応できるようにするべきです。
Principle 2.9.1 :
ウェブ上でのコミュニケーションを可能にするシステムは、虐待 を報告するための有効な機能を提供しなければなりません。
ウェブサイト APIデザイナー
デジタル上の虐待 とは、デジタル手段を通じた人への不当な扱いを指します。オンラインの嫌がらせ は「有害な行為を通じてオンラインで個人または集団を執拗または重大に標的にすること」であり、これは虐待の一形態です（[PEN-Harassment
嫌がらせ はプライバシーの侵害自体であると同時に、他のプライバシー侵害によって助長または悪化され得ます。
嫌がらせには、望まれない情報の送信（unwanted
information ）、他者にある人へ連絡や迷惑をかけるよう指示する行為（"dogpiling"）、個人の機微情報の暴露、虚偽の情報の投稿、なりすまし、侮辱、脅迫、憎悪や侮蔑的な言動などが含まれます。
識別情報や連絡先情報の開示（ドキシングを含む）は、継続的な望まれない情報を送る追加の攻撃者を引き起こすためにしばしば利用され得ます。位置情報の開示はその人の身体的安全や空間への侵入に使われ得ます。
報告メカニズムは緩和策ではありますが、ホストやモデレーター、その他の仲介者が虐待を支持しているか共謀している場合には、特に嫌がらせを防げないことがあります。
有効な報告には次が必要です：
虐待報告の連絡先を特定するための標準化されたメカニズム。
サイトやユーザーエージェントが目に見えて使いやすい方法で虐待 を報告できるようにすること。
送信者やコンテンツを参照するための識別子。
被害の文脈や説明を提供する能力。
報告に迅速に対応する責任者。
緩和情報をプールするためのツール（例：共有のブロックリスト、共有のスパム検出情報、または不正行為をするアクターに関する公開情報）。
望まれない情報 は、個々には通常無害でも集積すると迷惑になるメッセージ（スパム）から、露骨でグラフィックな暴力画像の送信まで、広範囲の未請求の通信を含みます。
システム設計者は、望まれない情報の送信をより困難または高コストにし、送信者の説明責任を高める措置を講じるべきです。
目的に特化して設計された機能は、ある目的にのみまたは主に有用な機能を提供することでこれらの原則を促進します。目的特化の機能は、人々に目的を説明しやすくし、データの実現可能な二次利用を制限することもあります。目的特化機能を構築する際には、高レベル
API と低レベル API のトレードオフを検討してください。
管理された非識別化データ は、指定された目的と互換性のある追加目的で使用され得ます。
透明性は同意 にとって必要ですが不十分な条件です。関連する説明情報には、誰がデータにアクセスしているか、どのデータがアクセスされるか（そのデータから導かれる可能性のある推論や組み合わせを含む）、およびデータがどのように使用されるかが含まれます。透明性が人々にとって意味のあるものとなるためには、説明情報は関連する文脈 で提供されなければなりません。
Note
権限を伴う新しいウェブ機能を設計する際には、その権限が本当に必要か、そしてどのようにその権限を意味あるものにするかを検討してください（Adding-Permissions
を参照）。過去のワークショップもウェブ上のより良い権限のニーズを検討しています。
2022 W3C Workshop on Permissions
2018 W3C Workshop on Permissions and User Consent
2014 Next steps on trust and permissions for web applications
Principle 2.11.2 :
プライバシーに関連する慣行に関する情報は、分かりやすい平易な言葉での形式と機械可読形式の両方で提供されるべきです。
ウェブサイト APIデザイナー
プライバシー関連の慣行の機械可読な提示は、ユーザーエージェント が、人々が毎回ウェブサイトを訪れる前に文書を読むことができるかのように誤って依存するのではなく、一般的な意思決定を手助けするために必要です。機械可読の提示はまた、研究者や規制当局がデータ収集と処理を発見、文書化、分析して有害なケースを特定できるようにすることで、集団的ガバナンスを促進します。
分かりやすい平易な言葉での提示は、人々 が特定のケースで情報に基づいた決定を行うために必要です。サイト 、ユーザーエージェント 、およびその他のアクター は、プライバシー関連の慣行をアクセス可能な形で人々に提示する必要があります。
Principle 2.11.3 :
人を認識 するために使われ得るメカニズムは、その動作がユーザーエージェント、研究者、および規制当局にとって可視かつ識別可能となるよう設計されるべきです。
ウェブサイト APIデザイナー
非透明な方法での認識 は、それがユーザーに可視でないために有害であり、ユーザーコントロールを損ないます。データを最小化し、データ要求を明示にする機能を設計することで、検出可能性を可能にし、これはブラウザフィンガープリンティングに対する重要な緩和策となります。
Principle 2.12.1 :
いかなるアクター が同意 を個人から得る場合、アクターは同意要求をその人が本当に同意するつもりであるかどうかを学ぶように設計し、同意される処理を最大化するようには設計してはなりません。
ウェブサイト
人の真の好みに沿わない処理への同意を得ようとする試みは、その人に望まれないプライバシー労働 を課し、後で後悔するような誤った同意を人々が与えてしまう結果を招く可能性があります。
アクターは、個人が十分な情報を持たない可能性が高い場合に同意を求めるべきではありません。同意を尋ねるのにその人が十分に情報を得ているかどうかを考える際には、求めている処理を理解するためにどれだけの時間と労力が必要かを現実的に評価するべきです。単に複雑なポリシーへのリンクを提供するだけでは、その人が情報を得ているとは言えません。
ユーザーを同意要求で中断する代替案の例には次が含まれます：
サイトの想定する対象やカテゴリにおける情報共有の慣習を考慮し、サイトの目的に適した同意のみを要求する（例えば、写真共有サイトの利用者はアップロードした作品の共有に対する同意を促されることを期待するかもしれません）。サイトは人々のデータ処理に関する期待についてユーザーリサーチを行うことを検討すべきです。
グローバルオプトアウト 信号をユーザーエージェント から受け入れる。
要求を文脈に置くような行動をユーザーが行うまで同意プロンプトを遅らせることで、ユーザーが文脈のある情報に基づいて判断できるようにする。
Principle 2.12.3 :
人が同意を与えるのと同じくらい簡単に、与えた同意を確認し、撤回し、オプトアウトや異議を表明できるようにするべきです。
ウェブサイト
ある人が他の人に関するデータを共有する場合（例：自分と他者が写っている写真）、その人がそのデータの処理に同意しても、他の人々が同意したことを意味するわけではありません。
通知や他の中断的な UI
は注意を引く強力な手段になり得ます。使用しているオペレーティングシステムによっては、通知はブラウザの文脈の外（例：一般的な通知トレイ）に表示されたり、デバイスが振動したりアラート音を鳴らしたりすることがあります。
強力な機能であるがゆえに、通知は悪用されやすく、迷惑になったり、行動を操作するために使われたりして、自律性 を低下させることがあります。
Principle 2.13.2 :
ウェブのサイト は、ユーザーが明確に要求した情報にのみ通知を使用するべきです。
ウェブのサイト は、通知の許可を要求する際に、利用者がどのような特定の種類の情報を受け取ることを期待できるか、そして通知をどのようにオフにできるかをユーザーに伝えるべきです。サイトは、ユーザーがそのような情報（どの種類の通知にサインアップするのかについての情報）を得る可能性が低い場合に通知の許可を要求すべきではありません。そのような情報が提供される可能性が低い場合、ユーザーエージェント は緩和策を適用すべきです（例：通知 API
の潜在的な悪用について警告する）。許可は文脈の中で要求されるべきです。
ウェブサイト
人々は共有する私的情報の量を制限したり、アクターに既に共有したデータの使用を制限するよう要求したり、データの削除を求めたりする自由があるべきです。個人が自らのデータの使用を拒否または撤回することを選択したとき、報復は不適切です。
データがサービスの運営に不可欠である場合にサービスを終了することは報復ではありません。しかし、データの提供を拒否した結果がそのデータの使用に関連しない行動につながる場合、それは報復である可能性があります。報復の例には次が含まれます：
同意を与えるよりも撤回するプロセスをより面倒にすること。
人々が選択を再考するよう脅迫、嫌がらせ、またはトリック（ダークパターン）を使用すること。
データの使用に依存しないサービスへのアクセスを拒否すること。
A 人 （または ユーザー 、あるいは
データ主体 ）は、任意の自然人を指します。本書全体では、人間性を思い起こさせるために主に人 や
人々 という用語を用います。ユーザー という用語を使う場合は、ある特定のシステムをその時点で使っている特定の人 について述べていることを意味します。
A 脆弱な人 は、特定の文脈 において、通常よりも容易に自分の選択を奪われ得る人 を指します。彼らはより大きなデフォルトのプライバシー保護を受けるべきであり、システムとの様々な相互作用に対して同意 できないと見なされる場合があります。人々は様々な理由で脆弱になり得、特定の文脈 で脆弱となることがあります。例えば、子どもは多くの文脈で脆弱であるかもしれませんし、雇用者やその他のアクター との間に権力の不均衡がある人は、そのアクターが存在する文脈で脆弱になる可能性があります。参照：1.2 脆弱性
A 文脈 は、人々 が他のアクター と相互作用する物理的またはデジタルな環境であり、かつその人々 が他の文脈 と区別して理解するものです。
文脈 は、誰がそれを所有または制御しているかによって定義されるものではありません。単一の企業の異なる文脈 間でデータ を共有することは、無関係なアクター 間で同じデータが共有される場合と同様にプライバシー侵害 となり得ます。
アクター とは、個人 が合理的にひとつの「もの」としてやり取りしていると理解できる存在です。アクター は、個人 だけでなく、企業や団体、行政機関などの集合体も含みます。
ユーザーエージェント は、個人 に対し、見ているウェブページがどのオリジン やサイト によるものかを説明する傾向があります。このアクター が、そのウェブページの内容やデータの取扱い に関する意思決定を行う、または委任する場合、そのオリジンやサイトの「ファーストパーティ 」と呼ばれます。個人 がウェブページの一部とやりとりする場合、そのやりとりのファーストパーティは通常、そのページのファーストパーティ です。ただし、ページのその部分の動作方針を異なるアクター が決めていて、現実的な範囲で他のアクター がコントロールしていると合理的な個人が気づける場合は、そのやりとりのファーストパーティはそのアクター となります。
誰かがウェブページとのやり取りについてデータを取得した場合、そのやり取りのファーストパーティ は、そのデータがどのように処理 されるかについて責任を負うことになります。他のアクター が実際の処理を行っていたとしても、それは変わりません。
サードパーティ とは、ウェブサイトを訪れている個人 や、その個人がやりとりを期待しているファーストパーティ 以外のすべてのアクター です。
我々は個人データ を、識別された、または識別可能な人 に直接的または間接的に関連する任意の情報として定義します（例えば識別子 による参照など）（[GDPR OECD-Guidelines Convention-108
ウェブ上では、ある種の識別子 が、サイトから見た
アイデンティティ に対して割り当てられることが一般的であり、これによって自動化された
システムがその個人 についてデータを保存しやすくなります。
もしある人 が、あるデータの組み合わせによって合理的に識別または再識別され得るなら、両方のデータセットは個人データ と見なされます。
人々 は、ある文脈 において、当該文脈 の原則に従って情報を提示し、個人データ を使用する場合にプライバシーを有します。その文脈の原則が守られないとき、プライバシー侵害 が生じます。原則が遵守されるとき、ある相互作用は適切 であると言い、そうでない場合は不適切 であると言います。
あるアクター が処理 を行うとは、自動化手段かどうかに関わらず、収集、記録、整理、構造化、保存、適応または変更、検索、照会、使用、送信による開示、共有 、配布またはその他の利用可能化、販売 、整合や結合、制限、消去または破棄など、個人データ に対して操作を実施することを指します。
あるアクター が、他のデータ管理者 にデータを提供した場合、そのアクターはデータを共有 したことになります。この定義においては、あるアクター が自らのサービス提供者 にデータを提供する場合は、共有 には当たりません。
あるアクター がデータを販売 するとは、価値のあるものと引き換えにデータを共有 する場合を指し、その価値が金銭的である必要はありません。
あるデータの目的 とは、その取扱い によって、予期・意図・計画される成果であり、特定の文脈 の中で達成されたり、目指されたりするものを指します。目的 が説明される際には、その文脈に精通した人物が、その目的 を達成するための手段 を選べる程度に、具体的でなければなりません。
手段（means） は、特定の目的 を達成するためにデータがどのように処理 されるかの一般的な方法を指します。手段 は比較的抽象的で、実装の細部まで全てを指定するわけではありません。例えば、ある人の好みを回復するという目的 に対して、手段 は識別子を優先設定から検索することかもしれません。
データ管理者（data
controller） は、データ処理の手段 と目的 を決定するアクター です。サービス提供者でない任意のアクター は、データ管理者 です。
サービス提供者 または データ処理者 は次の通りです：
処理 を別のアクター に代わって行う；データがそのアクター の指示どおり、かつ明示的に指定された目的 の範囲内でのみ保持、アクセス、使用されることを保証する；
データ処理の実装上の詳細は決定する場合があるが、データが処理される目的 や、その目的を実現するための全体的な手段 を決定するわけではない；
データ処理に関して独立した使用権を持たず、識別不能化された形式でのみ使用できる（例えば、サービスの整合性の監視、負荷分散、容量計画、請求などのため）；
上記の制限に整合する契約を当該アクター と締結している。
認識 は、あるアイデンティティ が、別のアイデンティティ と同じ人 に対応していることを認識する行為です。その別のアイデンティティは別の文脈 で観察されたものか、同じ文脈内でも別の時点で観察されたものかもしれません。認識 は確率的であり得ます。つまり、二つのアイデンティティ が同じ人 に対応する確率が高いと気付く場合です。
人 は、その法的なアイデンティティや法的アイデンティティの特性が認識に含まれているかどうかにかかわらず、認識 され得ます。
発生し得るいくつかの種類の認識 があります。
クロスコンテキスト認識 は、異なる文脈 間での認識 です。
クロスコンテキスト認識 は、認識される当該の人 が認識が起きることを合理的に期待でき、かつそれを制御できる場合にのみ適切 です。
ある人が二つの異なる文脈で識別情報（例えばメールや電話番号）を使用する場合、それが自動的に両方の文脈で同じアイデンティティを使うことを意図していることを意味するわけではありません。彼らが単一のアイデンティティを使うつもりであるという別の兆候がない限り、その情報を使って彼らを認識 することは不適切 です。また、クロスコンテキスト認識を助けるために追加の識別情報を求めることも不適切 です。
文脈を跨いで人々を認識 するシステムは、ある文脈での原則を、別の文脈で得た情報の使用に関してそれを侵害するように適用しないように注意する必要があります。これは特に脆弱な人々 に対して重要です。なぜなら、異なる文脈で彼らを認識することが、彼らの脆弱性を明らかにしてしまう特性を表に出してしまう可能性があるからです。例えば、セラピストにパーティで会った場合、そのセラピストは通常とは異なる話題であなたと話すことを期待し、場合によってはあなたを知らないふりをすることすら期待されるかもしれません。
クロスサイト認識 は、異なるサイト 上でアイデンティティが観察されるときの認識 です。通常、サイトが異なる文脈である場合、クロスサイト認識 は、クロスコンテキスト認識 と同様の場合において不適切 です。
同一サイト内認識 は、単一のサイト が、二回以上の訪問を通じて人を認識 する場合を指します。
もしある人が単一サイトへの異なる訪問で異なるアイデンティティ を使うことを合理的に期待しているのに、そのサイトがそれでも彼らを認識 してしまうと、プライバシー上の害が生じます。
これらのカテゴリは重なり合うことに注意してください：クロスサイト認識 は通常クロスコンテキスト認識 です（常にパーティション 間での認識を含みます）；そして同一サイト内認識 は時にクロスコンテキスト認識 に該当することがあり（かつ複数のパーティション を含むかもしれません）。
パーティション は、ユーザーエージェント が、そのユーザーが文脈をどのように理解するかを一致させようと試みるものです。ユーザーエージェント は、ユーザーが訪れるサイトをどのように経験するかを完全には理解していないため、パーティションを構築する際に文脈の境界を近似する必要がしばしばあります。
より良い情報がない場合、パーティション は次のように定義できます：
一連の環境 （大まかに言えば：同一サイトおよびクロスサイトのiframe
そのトップレベルオリジン が同一のサイト にあるもの（注意：PSL-Problems
同じユーザーエージェントのインストール（およびそのブラウザプロファイル、コンテナ、またはコンテナタブ）内で訪問されるもの
そのサイトのクッキーやその他のストレージがユーザーまたはユーザーエージェントによってクリアされるまでの間の時点間（セッション終了時に自動的に行われることがある）
単一のサイトが複数の異なる文脈 を含む場合をユーザーエージェントが検出するのは難しいことがあります。ユーザーエージェントがこれを検出できる場合、例えばサブドメインやサイトパスごとにアイデンティティをパーティション化するなど、そのパーティション を適切に調整すべきです。ユーザーエージェントはサイト内の文脈を区別する能力を改善するよう努めるべきです。
ユーザーエージェント は、利用者が意図しない限り、パーティション間で人が認識 されるのを防ぐべきです。
サイトは、同じ人物からの訪問であると完全には確信できなくても害を及ぼす可能性があるため、ユーザーエージェント はそのような確率的な認識を防ぐための措置も講じるべきです。Target Privacy Threat
Model Privacy-Threat
もしユーザーエージェント が、そのユーザーが特定のサイト上で特定のアイデンティティを使用していると判断できるなら、当該のアクティブなアイデンティティをユーザーに明示すべきです（例えば、ユーザーが
Credential Management Level 1 のような API を通じてサイトにログインしている場合など）。