[要約] RFC 6462は、インターネットプライバシーワークショップの報告書であり、インターネットプライバシーの問題と解決策についての議論をまとめています。このRFCの目的は、インターネットプライバシーの向上と、ユーザーの個人情報保護に関するガイドラインの提供です。
Internet Architecture Board (IAB) A. Cooper
Request for Comments: 6462 January 2012
Category: Informational
ISSN: 2070-1721
Report from the Internet Privacy Workshop
インターネットプライバシーワークショップからのレポート
Abstract
概要
On December 8-9, 2010, the IAB co-hosted an Internet privacy workshop with the World Wide Web Consortium (W3C), the Internet Society (ISOC), and MIT's Computer Science and Artificial Intelligence Laboratory (CSAIL). The workshop revealed some of the fundamental challenges in designing, deploying, and analyzing privacy-protective Internet protocols and systems. Although workshop participants and the community as a whole are still far from understanding how best to systematically address privacy within Internet standards development, workshop participants identified a number of potential next steps. For the IETF, these included the creation of a privacy directorate to review Internet-Drafts, further work on documenting privacy considerations for protocol developers, and a number of exploratory efforts concerning fingerprinting and anonymized routing. Potential action items for the W3C included investigating the formation of a privacy interest group and formulating guidance about fingerprinting, referrer headers, data minimization in APIs, usability, and general considerations for non-browser-based protocols.
2010年12月8日から9日、IABは、ワールドワイドウェブコンソーシアム（W3C）、インターネット協会（ISOC）、およびMITのコンピューターサイエンスおよび人工知能研究所（CSAIL）とインターネットプライバシーワークショップを共催しました。このワークショップでは、プライバシーに対応するインターネットプロトコルとシステムの設計、展開、分析における基本的な課題のいくつかを明らかにしました。ワークショップの参加者とコミュニティ全体は、インターネット標準開発内のプライバシーに体系的に対処する最善の方法を理解することとはほど遠いものの、ワークショップの参加者は多くの潜在的な次のステップを特定しました。 IETFの場合、これらには、インターネットドラフトをレビューするためのプライバシー局の作成、プロトコル開発者のプライバシーに関する考慮事項の文書化に関するさらなる作業、およびフィンガープリントと匿名化されたルーティングに関する多くの探索的努力が含まれます。 W3Cの潜在的なアクション項目には、プライバシー関心グループの形成の調査と、指紋、リファラーヘッダー、APIのデータの最小化、使いやすさ、および非ブラウザーベースのプロトコルの一般的な考慮事項に関するガイダンスの策定が含まれます。
Note that this document is a report on the proceedings of the workshop. The views and positions documented in this report are those of the workshop participants and do not necessarily reflect the views of the IAB, W3C, ISOC, or MIT CSAIL.
このドキュメントは、ワークショップの議事録に関するレポートであることに注意してください。このレポートに記録されている見解とポジションは、ワークショップ参加者のものであり、IAB、W3C、ISOC、またはMIT CSAilの見解を必ずしも反映しているわけではありません。
Status of This Memo
本文書の位置付け
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントは、インターネット標準の追跡仕様ではありません。情報目的で公開されています。
This document is a product of the Internet Architecture Board (IAB) and represents information that the IAB has deemed valuable to provide for permanent record. Documents approved for publication by the IAB are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、インターネットアーキテクチャボード（IAB）の製品であり、IABが永続的な記録を提供する価値があるとみなした情報を表しています。IABによって公開されることが承認された文書は、インターネット標準のレベルの候補者ではありません。RFC 5741のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6462.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc6462で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2012 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
Table of Contents
目次
1. Introduction ....................................................3
2. Workshop Overview ...............................................3
2.1. Technical Discussion .......................................4
2.2. SDO Discussion .............................................5
3. Design Challenges ...............................................6
3.1. Ease of Fingerprinting .....................................6
3.2. Information Leakage ........................................7
3.3. Differentiating between First and Third Parties ............8
3.4. Lack of Transparency and User Awareness ....................9
4. Deployment and Analysis Challenges ..............................9
4.1. Generative Protocols vs. Contextual Threats ................9
4.2. Tension between Privacy Protection and Usability ..........11
4.3. Interaction between Business, Legal, and Technical
Incentives ................................................12
4.3.1. Role of Regulation .................................12
4.3.2. P3P: A Case Study of the Importance of Incentives ..13
5. Conclusions and Next Steps .....................................14
5.1. IETF Outlook ..............................................14
5.2. W3C Outlook ...............................................15
5.3. Other Future Work .........................................15
6. Acknowledgements ...............................................15
7. Security Considerations ........................................15
8. Informative References .........................................16
Appendix A. Workshop Materials ....................................19
Appendix B. Workshop Participants .................................19
Appendix C. Accepted Position Papers ..............................21
On December 8-9, 2010, the IAB co-hosted a workshop with the W3C, ISOC, and MIT's Computer Science and Artificial Intelligence Laboratory (CSAIL) about Internet privacy [Workshop]. The workshop was organized to help the Internet community gain some understanding of what it means for Internet-based systems to respect privacy, how such systems have been or could be designed, how the relationship between the web and the broader Internet impacts privacy, and what specific work the IETF and/or the W3C might pursue to address Internet privacy. An overview of topics discussed at the workshop is provided in Section 2.
2010年12月8日から9日、IABは、インターネットプライバシーに関するW3C、ISOC、およびMITのコンピューターサイエンスおよび人工知能研究所（CSAIL）とワークショップを共催しました[ワークショップ]。ワークショップは、インターネットコミュニティが、インターネットベースのシステムがプライバシーを尊重すること、そのようなシステムがどのように設計されたか、またはWebとより広範なインターネットの関係がプライバシーに影響するか、そして何を尊重することの意味を理解するのを支援するために組織されました。特定の作業IETFおよび/またはW3Cは、インターネットプライバシーに対処するために追求する可能性があります。ワークショップで説明されているトピックの概要は、セクション2に記載されています。
The workshop discussions revealed the complexity and broad-based nature of privacy on the Internet. Across numerous different applications, a number of fundamental design challenges appear again and again: the increasing ease of user/device/application fingerprinting, unforeseen information leakage, difficulties in distinguishing first parties from third parties, complications arising from system dependencies, and the lack of transparency and user awareness of privacy risks and tradeoffs (see Section 3). Workshop participants also identified a number of barriers to successful deployment and analysis of privacy-minded protocols and systems, including the difficulty of using generic protocols and tools to defend against context-specific threats; the tension between privacy protection and usability; and the difficulty of navigating between business, legal, and individual incentives (see Section 4).
ワークショップの議論により、インターネット上のプライバシーの複雑さと広範な性質が明らかになりました。多数の異なるアプリケーションにわたって、ユーザー/デバイス/アプリケーションの指紋の容易さの容易さ、予期せぬ情報漏出、第三者と第三者との区別の難しさ、システム依存関係から生じる合併症、および不足の欠如など、多くの基本的な設計上の課題が何度も現れます。プライバシーリスクとトレードオフの透明性とユーザーの認識（セクション3を参照）。ワークショップの参加者は、一般的なプロトコルとツールを使用してコンテキスト固有の脅威を防御することの難しさなど、プライバシー志向のプロトコルとシステムの展開と分析を成功させるための多くの障壁も特定しました。プライバシー保護と使いやすさの間の緊張。そして、ビジネス、法的、および個々のインセンティブをナビゲートすることの難しさ（セクション4を参照）。
Privacy challenges far outnumber solutions, but the workshop identified a number of concrete preliminary steps that standards organizations can take to help ensure respect for user privacy in the design of future standards and systems. For the IETF, these included the creation of a privacy directorate to review Internet-Drafts, further work on documenting privacy considerations for protocol developers, and initiating a number of exploratory efforts concerning fingerprinting and anonymized routing. Potential action items for the W3C included investigating the formation of a privacy interest group and formulating guidance about fingerprinting, referrer headers, data minimization in APIs, usability, and general considerations for non-browser-based protocols. These next steps and workshop outcomes are discussed in Section 5.
プライバシーはソリューションをはるかに上回っていますが、ワークショップは、将来の標準とシステムの設計におけるユーザープライバシーの尊重を確保するために、標準組織がとることができる多くの具体的な予備措置を特定しました。IETFの場合、これらには、インターネットドラフトをレビューするためのプライバシー局の作成、プロトコル開発者のプライバシーに関する考慮事項の文書化に関するさらなる作業、および指紋と匿名化されたルーティングに関する多くの探索的努力の開始が含まれます。W3Cの潜在的なアクション項目には、プライバシー関心グループの形成の調査と、指紋、リファラーヘッダー、APIのデータの最小化、使いやすさ、および非ブラウザーベースのプロトコルの一般的な考慮事項に関するガイダンスの策定が含まれます。これらの次のステップとワークショップの結果については、セクション5で説明します。
The workshop explored both current technical challenges to protecting privacy and the ways in which standards organizations can help to address those challenges. Links to workshop materials are listed in Appendix A.
このワークショップは、プライバシーを保護するための現在の技術的課題と、標準組織がこれらの課題に対処するのに役立つ方法の両方を調査しました。ワークショップ資料へのリンクは、付録Aにリストされています。
The workshop explored privacy challenges in three different technical domains: at the network level, at the browser level, and with respect to cross-site data exchanges. Example technologies were highlighted in each area to motivate the discussion.
ワークショップでは、ネットワークレベル、ブラウザレベル、およびクロスサイトデータ交換に関する3つの異なる技術ドメインのプライバシーの課題を調査しました。例のテクノロジーは、議論をやる気にさせるために各分野で強調されました。
At the network level, participants discussed IP address hiding in mobility protocols, privacy extensions for IPv6 addressing [RFC4941], and onion routing. Discussion about the Tor project [Tor] was particularly insightful. Tor is a circuit-based, low-latency communication service designed to anonymize protocols that run over TCP. End hosts participating in a Tor exchange choose a path through the network and build a circuit in which each "onion router" in the path knows its predecessor and successor, but no other nodes in the circuit. Each onion router in the path unwraps and decrypts received information before relaying it downstream.
ネットワークレベルで、参加者は、モビリティプロトコルに隠れているIPアドレス、[RFC4941]にアドレス指定するIPv6のプライバシー拡張、およびタマネギルーティングについて議論しました。TORプロジェクト[TOR]についての議論は特に洞察に富んでいました。TORは、TCPを介して実行されるプロトコルを匿名化するために設計された回路ベースの低遅延通信サービスです。TOR Exchangeに参加しているエンドホストは、ネットワークを通るパスを選択し、パス内の各「オニオンルーター」が前任者と後継者を知っているが、回路に他のノードはない回路を構築します。パス内の各タマネギルーターは、下流に中継する前に情報を受け取ったものを解き放ちました。
For Tor to provide anonymity guarantees, Tor nodes need to be able to strip out information elements that can be used to re-identify users over time. For example, web technologies such as cookies, large portions of JavaScript, and almost all browser plug-ins (including Flash) need to be disabled in order to maintain Tor's privacy properties during web use, significantly hampering usability.
TORが匿名の保証を提供するには、TORノードは、ユーザーを時間の経過とともに再識別するために使用できる情報要素を削除できる必要があります。たとえば、Cookie、JavaScriptの大部分、およびほぼすべてのブラウザプラグインなどのWebテクノロジー（Flashを含む）は、Web使用中にTORのプライバシープロパティを維持するために無効にする必要があり、使いやすさを大幅に妨げるものです。
At the browser level, the discussion focused first on experiences with "private browsing" modes. Private browsing puts a browser into a temporary session where no information about the user's browsing session is stored locally after the session ends. The goal is to protect the user's browsing behavior from others who may make use of the same browser on the same machine. Private browsing is not designed to protect the user from being tracked by malware (e.g., keyloggers), remote servers, employers, or governments, but there is some evidence that users fail to understand the distinction between protection from snooping among users who share a device and these other forms of tracking. The specific protections offered by private browsing modes also vary from browser to browser, creating privacy loopholes in some cases.
ブラウザレベルでは、ディスカッションは最初に「プライベートブラウジング」モードの経験に焦点を当てました。プライベートブラウジングは、ブラウザを一時的なセッションに入れます。このセッションでは、セッションが終了した後、ユーザーのブラウジングセッションに関する情報がローカルに保存されません。目標は、同じマシンで同じブラウザを使用する可能性のある他の人からユーザーのブラウジング動作を保護することです。プライベートブラウジングは、ユーザーがマルウェア（例：キーロガー）、リモートサーバー、雇用主、または政府によって追跡されるのを防ぐために設計されていませんが、デバイスを共有するユーザー間のスヌーピングからの保護の区別を理解できないという証拠があるという証拠があります。そして、これらの他の形式の追跡。プライベートブラウジングモードによって提供される特定の保護は、ブラウザごとにブラウザまでさまざまであり、場合によってはプライバシーの抜け穴を作成します。
The browser discussion also addressed proposals for "Do Not Track" (DNT) technologies to be built into browsers to provide users with a simple way to opt out of web tracking. At the time of the workshop, various different technical proposals had been designed to offer users the ability to indicate their preference to opt out or to block communication to certain web sites altogether. The discussions at the workshop illustrated a lack of agreement about what type of
ブラウザのディスカッションでは、ブラウザに組み込まれる「Do Not Track」（DNT）テクノロジーの提案にも対処し、ユーザーにWebトラッキングをオプトアウトする簡単な方法を提供しました。ワークショップの時点で、さまざまな技術提案が設計されており、ユーザーがオプトアウトをオプトアウトするか、特定のWebサイトへのコミュニケーションをブロックすることを示す能力を提供するように設計されていました。ワークショップでの議論は、どのタイプのタイプについての合意の欠如を示していました
tracking is acceptable, which technical mechanisms would be best suited for different scenarios, and how the mechanisms would interact with other aspects of privacy protection (such as notices to users).
追跡は受け入れられます。どの技術メカニズムがさまざまなシナリオに最適であり、メカニズムがプライバシー保護の他の側面（ユーザーへの通知など）とどのように相互作用するかに最適です。
The cross-site data-sharing discussion focused on current uses of Open Authorization (OAuth) (with Facebook Connect, for example). While improvements have been made in obtaining user consent to sharing data between sites, challenges remain with regard to data minimization, ease of use, hidden sharing of data, and centralization of identity information.
クロスサイトのデータ共有ディスカッションは、現在の公開認証（OAUTH）の使用に焦点を当てています（たとえば、Facebook Connectなど）。サイト間のデータの共有に対するユーザーの同意を得るために改善が行われていますが、データの最小化、使いやすさ、データの隠された共有、およびID情報の集中化に関して課題は残っています。
Participants discussed past experiences in approaching privacy within the IETF and the W3C. Individual protocol efforts within the IETF have sought to address certain privacy threats over the years. Protocol designers have taken steps to reduce the potential for identifiability associated with protocol usage, such as in the IPv6 privacy extensions case [RFC4941]. Protocols architected to rely on intermediaries have sought to minimize the user data exposed in transit, most notably in SIP [RFC3323]. Protocol architectures used in interpersonal exchange have sought to give users granular control over their information, including presence [RFC2778] and geolocation information [RFC3693]. Efforts to square privacy with usability are ongoing; the ALTO working group [ALTO], for example, is working out how to balance the needs of users and network operators to share data with each other about content preferences and network topologies against legitimate concerns about revealing too much of either kind of information.
参加者は、IETFおよびW3C内のプライバシーに近づいた過去の経験について議論しました。 IETF内の個々のプロトコルの取り組みは、長年にわたって特定のプライバシーの脅威に対処しようとしてきました。プロトコル設計者は、IPv6プライバシー拡張ケース[RFC4941]など、プロトコルの使用に関連する識別可能性の可能性を減らすための措置を講じています。仲介者に依存するように設計されたプロトコルは、輸送中に公開されたユーザーデータ、特にSIP [RFC3323]を最小限に抑えようとしています。対人交換で使用されるプロトコルアーキテクチャは、存在[RFC2778]や地理的情報[RFC3693]など、ユーザーの情報に対する詳細な制御をユーザーに提供しようとしています。使いやすさを伴うプライバシーを二乗する努力が進行中です。たとえば、ALTOワーキンググループ[ALTO]は、ユーザーとネットワークオペレーターのニーズのバランスを取り、コンテンツの好みやネットワークトポロジに関するデータを共有する方法を、どちらの種類の情報を明らかにしすぎていることについての正当な懸念を抱いています。
The IETF also has experience to draw on in building a culture of security awareness. Beginning with [RFC1543], RFCs were required to contain a Security Considerations section. But that simple mandate did not immediately translate into the extensive security consciousness that permeates the IETF today. Over many years and with much effort invested, a more systematic approach to security has evolved that makes use of a variety of tools and resources: the security area itself, guidelines to RFC authors about security considerations [RFC3552], the security directorate, security advisors assigned to individual working groups, security tutorials at IETF meetings, and so on.
IETFには、セキュリティ意識の文化を構築する際に基づいた経験もあります。[RFC1543]から始めて、RFCはセキュリティに関する考慮事項セクションを含める必要がありました。しかし、その単純な任務は、今日IETFに浸透する広範なセキュリティ意識にすぐに変換されませんでした。長年にわたり、多くの努力が投資されたため、さまざまなツールとリソースを利用するセキュリティへのより体系的なアプローチが進化しました。セキュリティ領域自体、セキュリティに関する考慮事項に関するRFC著者へのガイドライン[RFC3552]、セキュリティ局、セキュリティアドバイザー個々のワーキンググループに割り当てられ、IETFミーティングのセキュリティチュートリアルなど。
The W3C likewise has a number of past efforts to draw on. One of the earliest large-scale standards efforts aimed at improving web privacy was the Platform for Privacy Preferences [P3P]. The idea behind P3P was to have web sites provide machine-readable privacy policies that browsers could vet and possibly override according to the user's preference. The P3P policy expression language was robust enough to
同様に、W3Cには多くの過去の努力があります。Webプライバシーの改善を目的とした最も初期の大規模標準努力の1つは、プライバシーの好みのプラットフォームでした[P3P]。P3Pの背後にあるアイデアは、Webサイトに、ブラウザがユーザーの好みに応じて吟味し、おそらくオーバーライドできる機械読み取り可能なプライバシーポリシーを提供することでした。P3Pポリシー表現言語は十分に堅牢でした
allow sites to make complex assertions about how they intended to make use of data related to users, but market developments have created a number of challenges with deployed policies.
サイトは、ユーザーに関連するデータをどのように使用するつもりなのかについて複雑な主張をすることができますが、市場の開発により、展開されたポリシーに多くの課題が生まれました。
More recent work at the W3C centered around the appropriateness of various privacy features to be included in the Geolocation API [Geolocation], which gives web sites a way to access the user's precise location. The API requires that implementations obtain user consent before accessing location information and allow users to revoke that consent, but decisions about retention, secondary use, and data minimization are left up to individual web sites and applications. The geolocation effort and the P3P experience both raise questions about how to navigate usability, regulation, business incentives, and other aspects that normally lie outside the scope of standards development organization (SDO) work.
W3Cでのより最近の作業は、Geolocation API [Geolocation]に含まれるさまざまなプライバシー機能の適切性を中心としており、Webサイトにユーザーの正確な場所にアクセスする方法を提供します。APIでは、実装が位置情報にアクセスする前にユーザーの同意を取得し、ユーザーがその同意を取り消すことを可能にしますが、保持、二次使用、およびデータの最小化に関する決定は、個々のWebサイトとアプリケーションに任されています。地理的努力とP3Pの経験はどちらも、ユーザビリティ、規制、ビジネスインセンティブ、および通常標準開発組織（SDO）作業の範囲外にある他の側面をナビゲートする方法について疑問を投げかけます。
Workshop discussions surfaced a number of key issues that can make designing privacy-sensitive protocols and systems difficult: the increasing ease of user/device/application fingerprinting, unforeseen information leakage, difficulties in distinguishing first parties from third parties, complications arising from system dependencies, and the lack of transparency and user awareness of privacy risks and tradeoffs.
ワークショップディスカッションは、プライバシーに敏感なプロトコルとシステムの設計を困難にすることができる多くの重要な問題を表面化しました。ユーザー/デバイス/アプリケーションのフィンガープリントの容易さ、予期せぬ情報漏え、第三者と第三者を区別する困難、システムの依存から生じる合併症、そして、プライバシーのリスクとトレードオフの透明性とユーザーの認識の欠如。
Internet applications and protocols now share so many unique identifiers and other bits of information as part of their ordinary operation that it is becoming increasingly easy for remote nodes to create unique device or application fingerprints and re-identify the same devices or applications over time [Panopticlick]. Hardware identifiers, IP addresses, transport protocol parameters, cookies, other forms of web storage, and a vast array of browser-based information may be routinely shared as users browse the web. The ease of fingerprinting presents a significant challenge for any application that seeks to guarantee anonymity or unlinkability (such as [Tor], which uses onion routing to strip out data that identifies communications endpoints).
インターネットアプリケーションとプロトコルは、通常の操作の一部として非常に多くの一意の識別子やその他の情報を共有しているため、リモートノードが一意のデバイスまたはアプリケーションの指紋を作成し、時間の経過とともに同じデバイスまたはアプリケーションを再識別することがますます簡単になりつつあります[Panopticlick]。ハードウェア識別子、IPアドレス、トランスポートプロトコルパラメーター、Cookie、その他のフォームのWebストレージ、およびユーザーがWebを閲覧するにつれて、ブラウザベースの膨大な情報が日常的に共有される場合があります。フィンガープリントの容易さは、匿名性やリンク可能性を保証しようとするアプリケーション（[TOR]などのアプリケーションに大きな課題をもたらします。これは、[TOR]で、通信エンドポイントを識別するデータを削除するタマネギルーティングを使用します）。
In many cases, the information that can be used to fingerprint a device was not originally shared for that purpose; identifiers and other information are provided to support some other functionality (like IP addresses being shared in order to route packets), and may incidentally be used to fingerprint. This complicates the task of preventing fingerprinting, because each application or protocol likely needs its own identifiers and information to function.
多くの場合、デバイスのフィンガープリントに使用できる情報は、その目的のために元々共有されていませんでした。識別子やその他の情報は、他の機能（パケットをルーティングするために共有されるIPアドレスなど）をサポートするために提供され、偶然にもフィンガープリントに使用される場合があります。これは、各アプリケーションまたはプロトコルが独自の識別子と情報を機能させる必要がある可能性が高いため、フィンガープリントの防止タスクを複雑にします。
Furthermore, some services are increasingly coming to rely on fingerprinting in order to detect fraud or provide customized content, for example. Finding privacy-friendly substitutes for fingerprinting will only become more difficult as these services become more entrenched (see Section 4.3).
さらに、たとえば、詐欺を検出したり、カスタマイズされたコンテンツを提供したりするために、一部のサービスがフィンガープリントに依存するようになっています。フィンガープリントのプライバシーに優しい代替品を見つけることは、これらのサービスがより定着するにつれて、より困難になります（セクション4.3を参照）。
The space of fingerprinting mitigations requires further exploration. For example, workshop participants discussed the use of JavaScript queries to obtain a browser's (often highly unique) font list, and the tradeoffs associated with browsers instead (or additionally) supporting some small subset of fonts in order to reduce browser identifiability. As with many other privacy features, such a restriction presents a tradeoff between privacy and usability, and in the case of fingerprinting writ large, it may be difficult to find consensus about which mitigations appropriately balance both values. As a first step, the IETF may consider documenting the fingerprinting implications for widely used IETF protocols (TCP, HTTP, SIP, etc.).
フィンガープリントの緩和のスペースには、さらなる調査が必要です。たとえば、ワークショップの参加者は、ブラウザの（非常にユニークな）フォントリストを取得するためにJavaScriptクエリの使用と、ブラウザの識別可能性を低下させるためにフォントの小さなサブセットをサポートする代わりに（またはさらに）ブラウザに関連するトレードオフを取得することについて議論しました。他の多くのプライバシー機能と同様に、このような制限はプライバシーとユーザビリティのトレードオフを提示し、フィンガープリント令状の大規模な場合、どちらの緩和が両方の値のバランスをとるかについてのコンセンサスを見つけることは困難かもしれません。最初のステップとして、IETFは、広く使用されているIETFプロトコル（TCP、HTTP、SIPなど）のフィンガープリントの意味を文書化することを検討する場合があります。
Internet protocols and services tend to leak information in ways that were not foreseen at design time, as explored during the IETF 77 technical plenary [IETF77] and in recent research [PrivLoss] [PrivDiffus]. For example, the HTTP referrer header [RFC2616] (misspelled in the original specification as "Referer") provides a way for a web site to obtain the URI of the resource that referred the user to the site. Referrer headers provide valuable insights to web sites about where their users come from, but they can also leak sensitive information (search terms or user IDs, for example), because URI strings on the web often contain this information. The infrastructure of an individual web site is often designed solely with a view to making the site itself function properly, and embedding search terms or other user-specific information in URIs may serve that goal, but when those URIs leak out to other sites via a referrer header, it creates the potential for third parties to use and abuse the data contained therein.
IETF 77技術全体[IETF77]および最近の研究[Privloss] [PrivDiffus]で調査されたように、インターネットプロトコルとサービスは、設計時に予見されなかった方法で情報を漏らす傾向があります。たとえば、HTTPリファラーヘッダー[RFC2616]（元の仕様で「参照」としての間違い）は、ユーザーをサイトに照会したリソースのURIを取得する方法を提供します。リファラーヘッダーは、ユーザーがどこから来たのかについてのWebサイトに貴重な洞察を提供しますが、Web上のURI文字列にはこの情報が含まれていることが多いため、機密情報（検索用語やユーザーIDなど）をリークすることもあります。個々のWebサイトのインフラストラクチャは、サイト自体が適切に機能することを目的としてのみ設計されていることが多く、URISに検索用語やその他のユーザー固有の情報を埋め込むことができますが、その目標はそれらのURIが他のサイトに漏れているときに、リファラーヘッダーは、サードパーティがそこに含まれるデータを使用および悪用する可能性を作成します。
The use of URIs for authentication of identity or capabilities can be susceptible to the same kinds of problems. Relying on a "possession model" where any user in possession of an authentication or capability URI can gain access to a resource is only suitable in situations with some means of control over URI distribution, and can lead to wide leakage when used on the open web.
アイデンティティまたは機能の認証のためにURIを使用することは、同じ種類の問題を受けやすい場合があります。URIがリソースにアクセスできる認証または機能を所有しているユーザーが、URI分布を何らかの制御する手段を備えた状況でのみ適切であり、オープンWebで使用すると広く漏れにつながる可能性がある「所有モデル」に依存することで。
Distinguishing between "first-party" interactions and "third-party" interactions is important for understanding the implications of data collection, sharing, and use that take place during the normal course of web use. Unfortunately, the traditional meanings of these concepts do not always clearly match up with user expectations or evolving web technologies. Traditionally, the term "first party" has been used to refer to the domain of a web site to which a user agent directs an explicit request on behalf of a user. The term "third party" has been used to refer to the domain of a web resource that a user agent requests as a result of a first-party request, with the third-party resource hosted at a different domain from the first-party domain.
「ファーストパーティ」の相互作用と「サードパーティ」の相互作用を区別することは、通常のWeb使用のコースで発生するデータ収集、共有、および使用の意味を理解するために重要です。残念ながら、これらの概念の伝統的な意味は、ユーザーの期待や進化するWebテクノロジーと常に明確に一致するとは限りません。従来、「ファーストパーティ」という用語は、ユーザーエージェントがユーザーに代わって明示的なリクエストを指示するWebサイトのドメインを参照するために使用されてきました。「サードパーティ」という用語は、ファーストパーティのリクエストの結果としてユーザーエージェントが要求するWebリソースのドメインを参照するために使用されており、サードパーティのリソースはファーストパーティドメインとは別のドメインでホストされています。。
This distinction between first-party and third-party domains is in part a result of long-standing user agent practices for handling HTTP cookies. Typically, HTTP cookies are returned only to the origin server that set them [RFC6265]. Cookies set from first-party domains may not be read by third-party domains and vice versa. In some cases, cookies set from first-party domains that contain subdomains are accessible by all subdomains of the first-party domain. The distinction between first-party domains and third-party domains is reflected in browser-based cookie controls: major web browsers all offer distinct first-party cookie settings and third-party cookie settings.
ファーストパーティドメインとサードパーティドメインのこの区別は、HTTP Cookieを処理するための長年のユーザーエージェントプラクティスの一部です。通常、HTTP Cookieは、[RFC6265]を設定するOrigin Serverにのみ返されます。ファーストパーティドメインからセットされたCookieは、サードパーティのドメインによって読み取られることはなく、その逆も同様です。場合によっては、サブドメインを含むファーストパーティドメインから設定されたCookieは、ファーストパーティドメインのすべてのサブドメインがアクセスできます。ファーストパーティドメインとサードパーティドメインの区別は、ブラウザベースのCookieコントロールに反映されています。主要なWebブラウザはすべて、個別のファーストパーティCookie設定とサードパーティのCookie設定を提供します。
However, a user's perception or expectation of the difference between a "first party" and a "third party" may not fall neatly within these distinctions. Users may expect that content hosted on a first-party subdomain, but provided or used by a third party, would be treated as third-party content, but browsers often treat it as first-party content. Conversely, when third-party content appears from a source with which the user has an established relationship -- such as the Facebook "Like" button or other social widgets -- users may consider their interaction with that content to be a desirable first-party interaction, even though the content is hosted on a third-party domain.
ただし、ユーザーの「ファーストパーティ」と「第三者」の違いに対する認識または期待は、これらの区別の範囲内にきちんと落ちない場合があります。ユーザーは、第一党のサブドメインでホストされているが、第三者によって提供または使用されるコンテンツはサードパーティのコンテンツとして扱われることを期待するかもしれませんが、ブラウザーはしばしばそれをファーストパーティのコンテンツとして扱います。逆に、Facebookの「いいね」ボタンや他のソーシャルウィジェットなど、ユーザーが確立された関係を持っているソースからサードパーティのコンテンツが表示される場合、ユーザーはそのコンテンツとの相互作用を望ましいファーストパーティであると考えるかもしれませんコンテンツはサードパーティドメインでホストされている場合でも、相互作用。
Handling these expectations programmatically is difficult, since the same identifier structures (domains, subdomains) can correlate to different user expectations in different contexts. On the other hand, prompting users to express a preference about what kinds of data collection and use should be allowable by each party encountered on the web is not practical. Web and browser developers are actively seeking novel ways to address this challenge, but there are few clear-cut solutions.
同じ識別子構造（ドメイン、サブドメイン）が異なるコンテキストで異なるユーザーの期待と相関する可能性があるため、これらの期待をプログラム的に処理することは困難です。一方、ユーザーに、Webで遭遇した各パーティーが許可するデータ収集と使用についての好みを表現するように促すことは実用的ではありません。Webおよびブラウザの開発者は、この課題に対処するための新しい方法を積極的に求めていますが、明確なソリューションはほとんどありません。
There is no question that users lack a full understanding of how their information is being used and what the tradeoffs are between having their data collected and accessing services at little or no cost. Much of the tracking that takes place on the web is passive and invisible to users. Most companies disclose their data usage practices in written privacy policies, but these policies are rarely read, difficult to understand, and often fail to disclose salient details (such as data retention lifetimes). Even when web tracking is associated with some visual indication -- a highly targeted Gmail ad or the Facebook "Like" button, for example -- users often do not realize that it is occurring.
ユーザーが自分の情報がどのように使用されているか、およびデータを収集することと、ほとんどまたはまったく無料でサービスにアクセスすることとの間にトレードオフが何であるかについての完全な理解がないことは間違いありません。Webで行われる追跡の多くは、ユーザーには受動的で見えません。ほとんどの企業は、書面によるプライバシーポリシーでデータ使用慣行を開示していますが、これらのポリシーはめったに読まれず、理解するのが難しく、顕著な詳細（データ保持の寿命など）を開示していません。たとえば、Webトラッキングが視覚的表示（高度にターゲットを絞ったGmail ADまたはFacebookの「いいね」ボタン）に関連付けられている場合でも、ユーザーはそれが発生していることを認識していません。
Efforts abound to attempt to present information about data collection and usage in a more digestible way. P3P was one early effort, but because it sought to support the expression of the vast expanse of potential policies that companies may have, it developed more complexity than the average user (or user interface) could sustain. More recent efforts have focused on using a limited set of icons to represent policies or provide an indication that tracking is taking place.
データ収集と使用に関する情報をより消化可能な方法で提示しようとする努力がたくさんあります。P3Pは初期の努力の1つでしたが、企業が持っている可能性のあるポリシーの広大な広がりの表現をサポートしようとしたため、平均的なユーザー（またはユーザーインターフェイス）が維持できるよりも複雑さを開発しました。より最近の取り組みは、限られたアイコンのセットを使用してポリシーを表すか、追跡が行われていることを示していることに焦点を当てています。
Workshop participants identified a number of barriers to both deployment of privacy-protecting technologies and the analysis of the privacy properties of technological systems. These included the difficulty of using generic protocols and tools to defend against context-specific threats; the tension between privacy protection and usability; and the difficulty of navigating between business, legal, and individual incentives.
ワークショップの参加者は、プライバシー保護技術の展開と技術システムのプライバシー特性の分析の両方に対する多くの障壁を特定しました。これらには、一般的なプロトコルとツールを使用して、コンテキスト固有の脅威から防御することの難しさが含まれていました。プライバシー保護と使いやすさの間の緊張。そして、ビジネス、法的、および個々のインセンティブをナビゲートすることの難しさ。
Privacy is not a binary state. Rather than operating either entirely in private or entirely in public, individuals experience privacy contextually, resulting in differing requirements for privacy protection, depending on the circumstance and the individual. On the Internet, the contextual nature of privacy means that threats against it can vary, depending on the deployment scenario, the usage scenario, the capabilities of different attackers, and the level of concern that different kinds of attackers generate among different users.
プライバシーはバイナリ状態ではありません。個人的に完全に公共の場で動作するのではなく、個人はコンテキストでプライバシーを経験するため、状況と個人に応じて、プライバシー保護の要件が異なります。インターネットでは、プライバシーの文脈上の性質は、展開シナリオ、使用シナリオ、異なる攻撃者の機能、異なる種類の攻撃者が異なるユーザー間で生成する懸念のレベルによって、それに対する脅威が異なることを意味します。
Addressing the full waterfront of privacy threats within generic protocols and tools is largely intractable. As a result, existing privacy features developed at the network and application layers have taken more targeted approaches. For example, privacy extensions for stateless address autoconfiguration in IPv6 [RFC4941] support addresses constructed dynamically rather than generating addresses based on interface Media Access Control (MAC) addresses, which for most users are persistent and unchangeable unique identifiers that could be used for long-term tracking. While IPv6 privacy extensions provide important protection against tracking and re-identification by remote endpoints, they do not prevent -- and were not meant to prevent -- all parties from being able to associate an IP address with a particular user. ISPs and governments still have means to make such associations, and remote endpoints have many other mechanisms at their disposal to attempt to identify users persistently, albeit without using IPv6 addresses.
一般的なプロトコルとツール内のプライバシーの脅威のフルウォーターフロントに対処することは、ほとんど手に負えないものです。その結果、ネットワークおよびアプリケーションレイヤーで開発された既存のプライバシー機能は、よりターゲットを絞ったアプローチを取りました。たとえば、IPv6 [RFC4941]のステートレスアドレスAutoconfigurationのプライバシー拡張は、インターフェイスメディアアクセス制御（MAC）アドレスに基づいてアドレスを生成するのではなく、動的に構築されたアドレスをサポートします。用語追跡。 IPv6プライバシー拡張は、リモートエンドポイントによる追跡と再識別に対する重要な保護を提供しますが、すべての当事者がIPアドレスを特定のユーザーに関連付けることができないことを防止することはできませんでした。 ISPと政府には依然としてそのような関連性を作成する手段があり、リモートエンドポイントには、IPv6アドレスを使用せずに、ユーザーを永続的に識別しようとする他の多くのメカニズムがあります。
This kind of experience with developing privacy tools shows that designing privacy features into systems and protocols requires a clear understanding of the scope of the threats they are designed to address. This scope is currently being debated in discussion about developing "Do Not Track" (DNT) mechanisms for the web and other online contexts. A number of different approaches have been proposed, including browser functionality to retain opt-out cookies, an HTTP header that expresses the user's preference not to be tracked, and a browser-based block list mechanism that prevents the browser from communicating with tracking sites (for an overview, see [OptOuts]). Regardless of the approach, these mechanisms function based on some understanding of which "tracking" users should be able to control, which in turn is based on some notion of the threats presented by different kinds of tracking conducted by different kinds of entities on the web. Should DNT mechanisms apply to sites with which the user already has an established relationship? Or sites that use only aggregate, non-individualized data? Does tracking for fraud prevention or customization present different threats than tracking for advertising or marketing purposes? The answers to these questions will dictate DNT design choices.
プライバシーツールの開発に関するこの種の経験は、プライバシー機能をシステムとプロトコルに設計するには、対処するように設計された脅威の範囲を明確に理解する必要があることを示しています。この範囲は現在、Webおよびその他のオンラインコンテキストの「追跡しない」（DNT）メカニズムの開発に関する議論で議論されています。オプトアウトCookieを保持するためのブラウザ機能、追跡しないようにユーザーの好みを表すHTTPヘッダー、ブラウザベースのブロックリストメカニズムを、ブラウザが追跡サイトと通信するのを防ぐブラウザベースのブロックリストメカニズムなど、さまざまなアプローチが提案されています（さまざまなアプローチが提案されています。概要については、[Optouts]を参照してください。アプローチに関係なく、これらのメカニズムは、どの「追跡」ユーザーが制御できるかについての何らかの理解に基づいて機能します。 。 DNTメカニズムは、ユーザーがすでに確立された関係を持っているサイトに適用されるべきですか？または、個別化されていないデータのみを使用するサイト？詐欺の予防またはカスタマイズの追跡は、広告やマーケティングの目的で追跡するよりも異なる脅威をもたらしますか？これらの質問に対する答えは、DNT設計の選択を決定します。
The space of privacy threats on the Internet may appear particularly broad from a protocol design perspective, because many of the protocols in widest use are designed generically to support a variety of applications and functionality. HTTP, for example, is used for a wider variety of purposes than its original designers likely anticipated; it is unsurprising that some of these purposes include obtaining and using data about web users in ways that may be privacy-infringing. It is unreasonable to ask protocol designers to mitigate the potential privacy risks of every possible deployment that may result from a particular protocol design; the key questions are about
インターネット上のプライバシーの脅威の空間は、プロトコル設計の観点から特に広く見える場合があります。これは、最も広い使用のプロトコルの多くは、さまざまなアプリケーションと機能をサポートするために一般的に設計されているためです。たとえば、HTTPは、元のデザイナーが予想されるよりも幅広い目的で使用されています。これらの目的の一部には、プライバシーの侵害である可能性のある方法でWebユーザーに関するデータの取得と使用が含まれることは驚くことではありません。プロトコル設計者に、特定のプロトコル設計から生じる可能性のあるあらゆる展開の潜在的なプライバシーリスクを軽減するように依頼することは不合理です。重要な質問はについてです
how the responsibility for protecting against privacy intrusion should be split between protocols, APIs, applications, and services, and which kinds of privacy features can best be implemented in each place.
プライバシー侵入から保護する責任をどのようにプロトコル、API、アプリケーション、およびサービス間で分割する必要があり、どの種類のプライバシー機能を各場所で実装できるか。
The workshop discussions highlighted the tension between providing privacy protections and maintaining usability. Tor [Tor] provides some salient examples of this tradeoff. Tor seeks to provide protection against network surveillance, but by lengthening the routing path, it may significantly increase round-trip time. Tor obscures endpoint IP addresses; thus, it also interferes with IP-based geolocation. Web browsing using Tor is particularly challenging, as most browser plug-ins, much of JavaScript, and a number of other browser-based features need to be blocked or overridden in order to meet Tor's anonymity requirements. With Tor, privacy clearly comes at a price.
ワークショップの議論は、プライバシー保護を提供することと使いやすさを維持することとの緊張を強調しました。tor [tor]は、このトレードオフのいくつかの顕著な例を提供します。TORは、ネットワーク監視に対する保護を提供しようとしていますが、ルーティングパスを延長することにより、往復時間を大幅に増加させる可能性があります。TORはエンドポイントIPアドレスを不明瞭にします。したがって、IPベースのジオロケーションにも干渉します。TORを使用したWebブラウジングは、TORの匿名性要件を満たすために、ほとんどのブラウザプラグイン、JavaScript、および他の多くのブラウザベースの機能をブロックまたはオーバーライドする必要があるため、特に困難です。TORでは、プライバシーには明らかに価格があります。
Even less aggressive privacy features may come with usability tradeoffs. One example is the blocking of HTTP referrer headers for privacy protection reasons. Some sites provide a customized experience to users based on the referring page, which means that disabling referrer headers, as some browsers allow users to do, may sacrifice user experience features on certain sites. Part of the challenge is the level of nuance involved in making decisions about privacy -- how can users be made to understand the privacy tradeoffs of blocking HTTP referrer headers, for example, when the effects of doing so will vary from site to site, or when there is limited UI space to communicate the tradeoffs? Even seemingly simple privacy controls like private browsing are not well understood.
積極的なプライバシー機能は、ユーザビリティトレードオフが伴う可能性があります。一例は、プライバシー保護の理由でHTTPリファラーヘッダーのブロッキングです。一部のサイトでは、参照ページに基づいてユーザーにカスタマイズされたエクスペリエンスを提供します。つまり、一部のブラウザが許可するように、リファラーヘッダーを無効にすると、特定のサイトでユーザーエクスペリエンス機能を犠牲にすることができます。課題の一部は、プライバシーに関する意思決定に関与するニュアンスのレベルです。たとえば、サイトごとに異なる場合、ユーザーはHTTPリファラーヘッダーをブロックすることのプライバシートレードオフを理解する方法をどのように理解できますか。トレードオフを伝えるためのUIスペースが限られている場合は？プライベートブラウジングのような一見シンプルなプライバシーコントロールでさえ、よく理解されていません。
The feature set that implementors choose to make available is often reflective of the tension between usability and privacy. For example, SIP [RFC3261] supports Secure/Multipurpose Internet Mail Extensions (S/MIME) to secure SIP request bodies, but given its user experience impact, few implementations include S/MIME support. Although usability challenges are generally thought of as user-level issues that are out of scope for the IETF, to the extent that they trickle down into implementation decisions, they are highly relevant.
実装者が利用可能にすることを選択する機能セットは、多くの場合、ユーザビリティとプライバシーの間の緊張を反映しています。たとえば、SIP [RFC3261]は、Secure/Multipurpose Internet Mail拡張機能（S/MIME）をサポートしてSIP要求ボディを保護しますが、ユーザーエクスペリエンスの影響を考えると、S/MIMEサポートなどの実装はほとんどありません。ユーザビリティの課題は、一般に、IETFの範囲外であるユーザーレベルの問題と考えられていますが、実装の決定に抑える程度まで、それらは非常に関連性があります。
Although workshop participants reached few firm conclusions about how to tackle usability issues arising from privacy features, the group agreed that it may be beneficial for the W3C to do some more thinking in this area, possibly toward the end of including usability considerations in individual specifications. The challenge with such an effort will be to provide useful guidance without being overly prescriptive about how implementations should be designed.
ワークショップの参加者は、プライバシーの特徴から生じるユーザビリティの問題に取り組む方法についての確固たる結論にはほとんど到達しませんでしたが、グループは、W3Cがこの分野でさらに考えていることが有益である可能性があることに同意しました。このような努力の課題は、実装の設計方法について過度に規範的になることなく、有用なガイダンスを提供することです。
The Internet has sustained commercial content for decades. Many services are offered at little or no cost in exchange for being able to sell advertising or collect user data (or both). As the commercial value of the web in particular has exploded in recent years, the paradigm for regulating privacy has also begun to change, albeit more slowly.
インターネットは何十年もの間、商業コンテンツを維持してきました。多くのサービスは、広告を販売したり、ユーザーデータ（またはその両方）を収集できることと引き換えに、ほとんどまたはまったく費用で提供されています。特にWebの商業的価値が近年爆発したため、プライバシーを規制するためのパラダイムも、よりゆっくりと変化し始めています。
At the dawn of the commercial Internet, few web sites had written privacy policies that explained what they did with user data. Under regulatory pressure, sites began to document their data collection and usage practices in publicly posted policies. These policies quickly became lengthy legal documents that commercial sites could use to limit their liability, often by disclosing every possible practice that the site might engage in, rather than informing users about the salient practices of relevance to them.
商用インターネットの夜明けに、ユーザーデータで何をしたかを説明するプライバシーポリシーを作成したWebサイトはほとんどありませんでした。規制上の圧力の下で、サイトは公開されたポリシーでデータ収集と使用法の実践を文書化し始めました。これらのポリシーはすぐに、商業サイトが責任を制限するために使用できる長い法的文書になりました。多くの場合、ユーザーに関連性の顕著な慣行について通知するのではなく、サイトが従事する可能性のあるあらゆる実践を開示することにより。
Because so many businesses are fueled by user data, any move to give users greater control over their data -- whether by better informing them about its use or providing tools and settings -- often requires the force of regulatory influence to succeed. In recent years, regulatory authorities have put pressure on companies to improve their privacy disclosures by making them simpler, more concise, more prominent, and more accessible (see the 2010 Federal Trade Commission privacy report [FTC]). Certain companies and industry sectors have responded by developing privacy icons, using short notices in addition to privacy policies, and making the language they use to describe privacy practices more accessible and easier to understand.
非常に多くの企業がユーザーデータに燃料を供給されているため、ユーザーがデータをより強く制御できるようにするために、その使用についてよりよく通知するか、ツールや設定を提供することで、成功するために規制の影響の力が必要です。近年、規制当局は、よりシンプルで、より簡潔で、より顕著で、よりアクセスしやすくすることにより、企業にプライバシーの開示を改善するように圧力をかけています（2010年の連邦取引委員会のプライバシーレポート[FTC]を参照）。特定の企業や産業部門は、プライバシーアイコンを開発し、プライバシーポリシーに加えて短い通知を使用し、プライバシーの実践をよりアクセスしやすく理解しやすく説明するために使用する言語を作成することで対応しています。
Regulators play an important role in shaping incentive structures. Companies often seek a balance between acting to limit their liability and pushing the envelope with respect to uses of consumer data. If regulators take a strong stand against certain practices -- as, for example, European legislators have against cookies being set without user consent [Directive] -- legitimate businesses will feel compelled to comply. But where there is regulatory uncertainty, business responses may differ according to different market strategies. The variety of potential responses to the emerging discussion about mechanisms to control web tracking demonstrates this variation: some businesses will embrace support for enhanced user control, others may restrict their offerings or charge fees if they are unable to track users, and still others may elect to circumvent any new mechanisms put in place. The absence of regulatory pressure tends to make the line between "good" and "bad" actors less evident.
規制当局は、インセンティブ構造を形成する上で重要な役割を果たします。多くの場合、企業は、責任を制限するために行動するための行動と、消費者データの使用に関する封筒を推進することとのバランスを求めています。規制当局が特定の慣行に対して強い立場を取っている場合 - たとえば、ヨーロッパの議員がユーザーの同意なしに設定されているCookieに対して[指令]に設定されているため、合法的な企業は従わざるを得ないと感じます。しかし、規制当局の不確実性がある場合、ビジネスの対応は異なる市場戦略によって異なる場合があります。Webトラッキングを制御するメカニズムに関する新たな議論に対するさまざまな潜在的な反応は、このバリエーションを示しています。一部の企業は、ユーザー制御の強化に対するサポートを受け入れ、ユーザーを追跡できない場合は提供または請求料を制限する可能性があります。導入された新しいメカニズムを回避するため。規制上の圧力の欠如は、「良い」俳優と「悪い」俳優の間の境界線をあまり明白にする傾向があります。
That absence of regulatory pressure revealed itself in the case of P3P. The first version of P3P was standardized in the early 2000s, when legalistic privacy policies were the norm and users had only elementary controls over the data collected about them on the web. P3P challenged that paradigm by providing a way for web sites to express machine-readable privacy policies for browsers to vet and possibly override according to the user's preference. The P3P policy expression language was designed to allow sites to make complex assertions about how they intended to make use of data related to users.
P3Pの場合、規制上の圧力が存在しないことが明らかになりました。P3Pの最初のバージョンは、合法的なプライバシーポリシーが標準であり、ユーザーがWeb上で収集されたデータに対する基本的なコントロールのみを持っていた2000年代初頭に標準化されました。P3Pは、Webサイトがブラウザーが視聴し、ユーザーの好みに応じてオーバーライドするために機械読み取り可能なプライバシーポリシーを表現する方法を提供することにより、そのパラダイムに挑戦しました。P3Pポリシー表現言語は、ユーザーに関連するデータをどのように使用するつもりなのかについて、サイトが複雑なアサーションを作成できるように設計されています。
The designers of Internet Explorer 6 made a crucial decision to only allow sites to use third-party cookies if they had installed adequate P3P policies. To avoid having their cookies blocked, most commercial sites adopted some P3P policy, although many sites merely cut and pasted from the example policies provided by the W3C. Today, large numbers of sites are misrepresenting their privacy practices in their P3P policies, but little has been done in response [Policies], and browser support for P3P outside of IE is limited.
Internet Explorer 6の設計者は、適切なP3Pポリシーをインストールした場合にのみサイトがサードパーティCookieを使用できるようにすることを重要な決定を下しました。Cookieをブロックすることを避けるために、ほとんどの商用サイトはP3Pポリシーを採用しましたが、多くのサイトはW3Cが提供するポリシーの例から切り取って貼り付けただけです。今日、多数のサイトがP3Pポリシーでプライバシー慣行を誤って伝えていますが、それに応じて[ポリシー]にはほとんど行われておらず、IE以外のP3Pのブラウザーサポートは限られています。
While theories abound to explain the current status of P3P implementations, there is no doubt that the relationship between regulatory and commercial incentives played a significant role. The P3P policy expression language provided support for companies to be able to express in granular detail how they handle user data, but the companies had little reason to do so, preferring to protect themselves from the liability associated with revealing potentially unsavory practices. In theory, the threat of regulatory backlash could have served as an incentive to publish accurate P3P policies, but at the time of P3P's release, there was little regulatory interest in moving beyond long, legalistic privacy policies. Even today, regulators are reluctant to bring enforcement actions against companies with misleading policies, perhaps because their own incentive structure compels them to focus on other, more prominent matters.
P3P実装の現在の状況を説明する理論はたくさんありますが、規制と商業のインセンティブの関係が重要な役割を果たしたことは間違いありません。P3Pポリシー表現言語は、企業がユーザーデータをどのように処理するかを詳細に表現できるようにサポートを提供しましたが、企業はそうする理由がほとんどありませんでした。理論的には、規制の反発の脅威は、正確なP3Pポリシーを公開するインセンティブとして役立った可能性がありますが、P3Pのリリース時には、長い合法的なプライバシーポリシーを超えて移動することに対する規制上の関心はほとんどありませんでした。今日でも、規制当局は、誤解を招く政策を備えた企業に対して執行措置を導入することに消極的です。おそらく、彼ら自身のインセンティブ構造により、他の、より顕著な問題に焦点を当てることを強いられているからでしょう。
The P3P experience is instructive in general for attempts at crafting privacy features that require the active participation of both ends of a communication. Actors that are meant to articulate their own privacy preferences, whether they be companies or individuals, require incentives to do so, as do those that are meant to process and react to such preferences. For example, the IETF's GEOPRIV architecture allows for expression of user preferences about location information [RFC4119]. While users may have more incentive to disclose their privacy preferences than companies did in the P3P case, successful use of the GEOPRIV model will require endpoints that
P3Pエクスペリエンスは、一般的に、コミュニケーションの両端の積極的な参加を必要とするプライバシー機能を作成しようとする試みに有益です。企業であろうと個人であろうと、自分のプライバシーの好みを明確にすることを目的としたアクターは、そのような好みに合わせて対応することを意図したものと同様に、そうするためのインセンティブを必要とします。たとえば、IETFのGEOPRIVアーキテクチャにより、位置情報に関するユーザー設定を表現できます[RFC4119]。ユーザーは、P3Pの場合に企業が行ったよりもプライバシーの好みを開示するインセンティブを持っているかもしれませんが、GEOPRIVモデルの使用が成功するにはエンドポイントが必要です。
consume location information to abide by those preferences, and in certain contexts -- commercial or employment-related, for example -- they may be unwilling, or regulatory pressure may be required to spur a change in practice.
これらの好みを順守するために位置情報を消費し、特定のコンテキストでは、たとえば商業的または雇用関連など、不本意な場合、または実際の変化を促進するために規制上の圧力が必要になる場合があります。
It is clearly not the prerogative of Internet protocol developers to seek to change existing incentive structures. But acknowledging what motivates businesses, individuals, and regulators is crucial to determining whether new privacy technologies will succeed or fail.
明らかに、既存のインセンティブ構造を変更しようとすることは、インターネットプロトコル開発者の特権ではありません。しかし、ビジネス、個人、規制当局の動機付けを認めることは、新しいプライバシーテクノロジーが成功するか失敗するかを判断するために重要です。
The workshop demonstrated that the understanding of how to address privacy within the Internet standards community is nascent. The IETF faces particular challenges, because IETF protocols generally do not mandate implementation styles or pre-conceive particular deployment contexts, making the space of potential privacy threats attributable to any single protocol difficult to foresee at protocol design time.
ワークショップは、インターネット標準コミュニティ内のプライバシーに対処する方法の理解が初期段階であることを実証しました。IETFは、IETFプロトコルは一般に実装スタイルを義務付けたり、特定の展開コンテキストを事前に確認したりしないため、特定の課題に直面しているため、プロトコルの設計時に予測が困難な単一のプロトコルに起因する潜在的なプライバシーの脅威のスペースになります。
Workshop participants nonetheless outlined a number of potential next steps. Work has already begun to attempt to provide guidance to protocol designers about the privacy impact of their specifications [PrivCons]. In refining this guidance, many of the questions raised at the workshop will need to be confronted, including those about how to properly model privacy threats against generic protocols, how to anticipate privacy risks that have been exposed in the previous design efforts, and how to document risks that are more difficult to foresee and mitigate. Workshop participants acknowledged that developing such guidance is likely necessary if document authors are expected to incorporate "Privacy Considerations" sections in their documents, but even with guidance, this is likely to be an uphill battle for many authors for some time to come.
それにもかかわらず、ワークショップの参加者は、多くの潜在的な次のステップについて概説しました。作業はすでに、仕様のプライバシーへの影響についてプロトコル設計者にガイダンスを提供しようとしています[Privcons]。このガイダンスを改善する際、ワークショップで提起された質問の多くは、一般的なプロトコルに対するプライバシーの脅威を適切にモデル化する方法、以前の設計の取り組みで公開されたプライバシーリスクを予測する方法、そしてどのようにするかを含め、直面する必要があります。予見して軽減するのがより困難なリスクを文書化します。ワークショップの参加者は、文書著者が文書に「プライバシーに関する考慮事項」セクションを組み込むことが期待される場合、そのようなガイダンスの開発が必要である可能性が高いことを認めましたが、ガイダンスがあっても、これはしばらくの間、多くの著者にとって困難な戦いになる可能性があります。
As preliminary steps, those with privacy expertise may seek to apply the current guidance to existing IETF protocols. The security area directors have also created a privacy directorate where privacy reviews of documents coming before the IESG are being conducted.
予備的な手順として、プライバシーの専門知識を持つ人は、現在のガイダンスを既存のIETFプロトコルに適用しようとする場合があります。セキュリティエリアのディレクターは、IESGが実施される前に来るドキュメントのプライバシーレビューがプライバシー局長を作成しました。
Participants also expressed an interest in further pursuing a number of the technical topics discussed at the workshop, including lessons learned from the experience of Tor and the fingerprinting implications of HTTP, TCP, SIP, and other IETF protocols. These and other efforts may be explored within the Internet Research Task Force (IRTF) in addition to, or in lieu of, the IETF.
参加者はまた、TORの経験から学んだ教訓やHTTP、TCP、SIP、およびその他のIETFプロトコルのフィンガープリントの意味を含む、ワークショップで議論された多くの技術的トピックをさらに追求することに関心を表明しました。これらおよびその他の努力は、IETFに加えて、またはIETFに加えて、またはその代わりにインターネットリサーチタスクフォース（IRTF）内で調査される場合があります。
The W3C is likewise in a position of seeking a more comprehensive approach to privacy within the SDO. Because the work of the W3C operates within a more defined scope than that of the IETF -- namely, the web -- the questions before the W3C tend to lie more in the space of distinguishing between what can appropriately be accomplished within W3C specifications and what should be left to individual implementations, a theme that repeated itself again and again at the workshop.
同様に、W3Cは、SDO内のプライバシーに対するより包括的なアプローチを求める立場にあります。W3Cの作業は、IETFのそれよりも定義された範囲内で動作しているため、つまりWeb - W3Cの前の質問は、W3C仕様内で適切に達成できるものを区別する空間にある傾向があります。ワークショップで何度も何度も繰り返されるテーマである個々の実装に任されるべきです。
To further develop its approach to privacy, the W3C will investigate an interest group to discuss privacy topics. Some potential topics that emerged from the workshop include the fingerprinting impact of W3C protocols, data minimization in APIs, dealing with referrer header privacy leakage, developing privacy considerations for non-browser-based protocols, and developing usability considerations as part of specification design.
プライバシーへのアプローチをさらに開発するために、W3Cは利益団体を調査してプライバシーのトピックについて議論します。ワークショップから登場した潜在的なトピックには、W3Cプロトコルのフィンガープリントの影響、APIのデータの最小化、リファラーヘッダーのプライバシー漏れ、非ブラウザーベースのプロトコルのプライバシーに関する考慮事項の開発、仕様設計の一部としてのユーザビリティに関する考慮事項の開発が含まれます。
The workshop covered a number of topics that may deserve further exploration in the IETF, the W3C, and the privacy community at large. These include development of privacy terminology; articulation of privacy threat models; analysis and experimentation with "Do Not Track" mechanisms for the web; work on cross-site data sharing, correlation, and linkability in web and non-web contexts; and investigation of policy expression languages.
このワークショップでは、IETF、W3C、およびプライバシーコミュニティ全体でさらなる調査に値する可能性のある多くのトピックを取り上げました。これらには、プライバシー用語の開発が含まれます。プライバシー脅威モデルの明確化。Webの「追跡しない」メカニズムを使用した分析と実験。Webおよび非WEBコンテキストでのクロスサイトのデータ共有、相関、およびリンク性に取り組みます。および政策表現言語の調査。
Thanks to Bernard Aboba, Nick Doty, and Hannes Tschofenig for their early reviews.
初期のレビューをしてくれたバーナード・アボバ、ニック・ドティ、ハンヌ・ツェコフェニグに感謝します。
Workshop participants discussed security aspects related to privacy, acknowledging that while much of the standards community may have once viewed most relevant privacy concerns as being encompassed by security considerations, there is a growing realization of privacy threats that lie outside the security realm. These include concerns related to data minimization, identifiability, and secondary use. Earlier security work provided minimal provision for privacy protection (e.g., the definition of "privacy" in [RFC2828] and some guidance about private information in [RFC3552]).
ワークショップの参加者は、プライバシーに関連するセキュリティの側面について議論し、標準コミュニティの多くはかつて最も関連性の高いプライバシーの懸念をセキュリティ上の考慮事項に包括していると見なしていたかもしれないが、セキュリティの領域の外側にあるプライバシーの脅威の実現が高まっている。これらには、データの最小化、識別可能性、および二次使用に関連する懸念が含まれます。以前のセキュリティ作業は、プライバシー保護の最小限の規定を提供しました（例：[RFC2828]の「プライバシー」の定義と[RFC3552]の個人情報に関するいくつかのガイダンス）。
[ALTO] IETF, "Application-Layer Traffic Optimization (alto)", 2011, <http://datatracker.ietf.org/wg/alto/charter/>.
[alto] ietf、「アプリケーションレイヤートラフィック最適化（ALTO）」、2011、<http://datatracker.ietf.org/wg/alto/charter/>。
[Directive] European Parliament and Council of the European Union, "Directive 2009/136/EC of the European Parliament and of the Council", November 2009, <http://eur-lex.europa.eu/ LexUriServ/ LexUriServ.do?uri=OJ:L:2009:337:0011:01:EN:HTML>.
[指令]欧州議会および欧州連合評議会、「欧州議会および評議会の指令2009/136/EC」、2009年11月<http://eur-lex.europa.eu/ lexuriserv/lexuriserv.do？uri = oj：l：2009：337：0011：01：en：html>。
[FTC] Federal Trade Commission Staff, "A Preliminary FTC Staff Report on Protecting Consumer Privacy in an Era of Rapid Change: A Proposed Framework for Businesses and Policymakers", December 2010, <http://www.ftc.gov/opa/2010/12/privacyreport.shtm>.
[FTC]連邦取引委員会のスタッフ、「急速な変化の時代における消費者プライバシーの保護に関する予備FTCスタッフレポート：2010年12月<http://www.ftc.gov/opa/2010/12/privacyReport.shtm>。
[Geolocation] Popescu, A., Ed., "Geolocation API Specification", September 2010, <http://www.w3.org/TR/2010/CR-geolocation-API-20100907/>.
[Geolocation] Popescu、A.、ed。、「Geolocation API Specification」、2010年9月、<http://www.w3.org/tr/2010/cr-geolocation-api-20100907/>。
[IETF77] Krishnamurthy, B., "Privacy Leakage on the Internet", March 2010, <http://www.ietf.org/proceedings/77/slides/ plenaryt-5.pdf>.
[IETF77] Krishnamurthy、B。、「インターネット上のプライバシーリーク」、2010年3月、<http://www.ietf.org/proceedings/77/slides/ plenaryt-5.pdf>。
[OptOuts] Cooper, A. and H. Tschofenig, "Overview of Universal Opt-Out Mechanisms for Web Tracking", Work in Progress, March 2011.
[Optouts] Cooper、A。and H. Tschofenig、「Webトラッキングのためのユニバーサルオプトアウトメカニズムの概要」、2011年3月、Work in Progress。
[P3P] Wenning, R., Ed., and M. Schunter, Ed., "The Platform for Privacy Preferences 1.1 (P3P1.1) Specification", November 2006, <http://www.w3.org/TR/P3P11/>.
[P3P] Wenning、R.、ed。、およびM. Schunter、ed。、「プライバシー設定のプラットフォーム1.1（P3P1.1）仕様」、2006年11月、<http://www.w3.org/tr/p3p11/>。
[Panopticlick] Electronic Frontier Foundation, "Panopticlick", 2011, <http://panopticlick.eff.org/>.
[Panopticlick] Electronic Frontier Foundation、「Panopticlick」、2011、<http://panopticlick.eff.org/>。
[Policies] Leon, P., Cranor, L., McDonald, A., and R. McGuire, "Token Attempt: The Misrepresentation of Website Privacy Policies through the Misuse of P3P Compact Policy Tokens", September 2010, <http://www.cylab.cmu.edu/research/ techreports/2010/tr_cylab10014.html>.
[ポリシー] Leon、P.、Cranor、L.、McDonald、A。、およびR. McGuire、「トークンの試み：P3Pコンパクトポリシートークンの誤用によるウェブサイトプライバシーポリシーの不実表示」、2010年9月、<http：//www.cylab.cmu.edu/research/ techReports/2010/tr_cylab10014.html>。
[PrivCons] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., and J. Morris, "Privacy Considerations for Internet Protocols", Work in Progress, October 2011.
[Privcons] Cooper、A.、Tschofenig、H.、Aboba、B.、Peterson、J。、およびJ. Morris、「インターネットプロトコルのプライバシーに関する考慮事項」、2011年10月の作業。
[PrivDiffus] Krishnamurthy, B. and C. Wills, "Privacy Diffusion on the Web: A Longitudinal Perspective", Proceedings of the World Wide Web Conference, pages 541-550, Madrid, Spain, April 2009, <http://www.cs.wpi.edu/~cew/papers/www09.pdf>.
[Privdiffus] Krishnamurthy、B。and C. Wills、「Web上のプライバシー拡散：縦断的視点」、World Wide Web Conferenceの議事録、2009年4月、スペイン、マドリッド541-550ページ、<http：// wwwwww.cs.wpi.edu/〜cew/papers/www09.pdf>。
[PrivLoss] Krishnamurthy, B., Malandrino, D., and C. Wills, "Measuring Privacy Loss and the Impact of Privacy Protection in Web Browsing", Proceedings of the Symposium on Usable Privacy and Security, pages 52-63, Pittsburgh, PA USA, ACM International Conference Proceedings Series, July 2007, <http://www.cs.wpi.edu/~cew/papers/soups07.pdf>.
[Privloss] Krishnamurthy、B.、Malandrino、D。、およびC. Wills、「プライバシーの損失とWebブラウジングにおけるプライバシー保護の影響の測定」、使用可能なプライバシーとセキュリティに関するシンポジウムの議事録、52〜63ページ、ピッツバーグ、PA USA、ACM International Conference Proceedingsシリーズ、2007年7月、<http://www.cs.wpi.edu/~cew/papers/soups07.pdf>。
[RFC1543] Postel, J., "Instructions to RFC Authors", RFC 1543, October 1993.
[RFC1543] Postel、J。、「RFC著者への指示」、RFC 1543、1993年10月。
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2616] Fielding、R.、Gettys、J.、Mogul、J.、Frystyk、H.、Masinter、L.、Leach、P。、およびT. Berners-Lee、「HyperText Transfer Protocol-HTTP/1.1」、RFC 2616、1999年6月。
[RFC2778] Day, M., Rosenberg, J., and H. Sugano, "A Model for Presence and Instant Messaging", RFC 2778, February 2000.
[RFC2778] Day、M.、Rosenberg、J。、およびH. Sugano、「存在とインスタントメッセージングのモデル」、RFC 2778、2000年2月。
[RFC2828] Shirey, R., "Internet Security Glossary", RFC 2828, May 2000.
[RFC2828] Shirey、R。、「インターネットセキュリティ用語集」、RFC 2828、2000年5月。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[RFC3261] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：SESSION INTIANIATION Protocol」、RFC 3261、2002年6月。
[RFC3323] Peterson, J., "A Privacy Mechanism for the Session Initiation Protocol (SIP)", RFC 3323, November 2002.
[RFC3323]ピーターソン、J。、「セッション開始プロトコル（SIP）のプライバシーメカニズム」、RFC 3323、2002年11月。
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, July 2003.
[RFC3552] Rescorla、E。およびB. Korver、「セキュリティに関する考慮事項に関するRFCテキストを書くためのガイドライン」、BCP 72、RFC 3552、2003年7月。
[RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J. Polk, "Geopriv Requirements", RFC 3693, February 2004.
[RFC3693] Cuellar、J.、Morris、J.、Mulligan、D.、Peterson、J。、およびJ. Polk、「Geopriv Recomission」、RFC 3693、2004年2月。
[RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object Format", RFC 4119, December 2005.
[RFC4119] Peterson、J。、「存在ベースのGeoprivロケーションオブジェクト形式」、RFC 4119、2005年12月。
[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 4941, September 2007.
[RFC4941] Narten、T.、Draves、R。、およびS. Krishnan、「IPv6のステートレスアドレスAutoconfigurationのプライバシー拡張」、RFC 4941、2007年9月。
[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, April 2011.
[RFC6265] Barth、A。、「HTTP状態管理メカニズム」、RFC 6265、2011年4月。
[Tor] The Tor Project, Inc., "Tor", 2011, <https://www.torproject.org/>.
[Tor] Tor Project、Inc。、 "Tor"、2011、<https://www.torproject.org/>。
[Workshop] IAB, W3C, ISOC, MIT CSAIL, "Internet Privacy Workshop 2010", 2011, <http://www.iab.org/activities/workshops/ internet-privacy-workshop-2010/>.
[ワークショップ] IAB、W3C、ISOC、MIT CSAIL、「インターネットプライバシーワークショップ2010」、2011年、<http://www.iab.org/activities/workshops/ Internet-privacy-workshop-2010/>。
Main page: http://www.iab.org/activities/workshops/ internet-privacy-workshop-2010/
メインページ：http：//www.iab.org/activities/workshops/ Internet-privacy-workshop-2010/
Slides: http://www.iab.org/activities/workshops/ internet-privacy-workshop-2010/slides/
スライド：http：//www.iab.org/activities/workshops/ Internet-privacy-workshop-2010/slides/
Minutes: http://www.iab.org/activities/workshops/ internet-privacy-workshop-2010/minutes/
議事録：http：//www.iab.org/activities/workshops/ Internet-privacy-workshop-2010/minutes/
Position papers: http://www.iab.org/activities/workshops/ internet-privacy-workshop-2010/papers/
ポジションペーパー：http：//www.iab.org/activities/workshops/ Internet-privacy-workshop-2010/Papers/
o Fu-Ming Shih, MIT o Ian Jacobi, MIT o Steve Woodrow, MIT o Nick Mathewson, The Tor Project o Peter Eckersley, Electronic Frontier Foundation o John Klensin, IAB o Oliver Hanka, Technical University Munich o Alan Mislove, Northeastern University o Ashkan Soltani, FTC o Sam Hartman, Painless Security o Kevin Trilli, TRUSTe o Dorothy Gellert, InterDigital o Aaron Falk, Raytheon - BBN Technologies o Sean Turner, IECA o Wei-Yeh Lee, NAVTEQ o Chad McClung, The Boeing Company o Jan Seedorf, NEC o Dave Crocker, Brandenburg InternetWorking o Lorrie Cranor, Carnegie Mellon University o Noah Mendelsohn, W3C TAG Chair o Stefan Winter, RESTENA o Craig Wittenberg, Microsoft o Bernard Aboba, IAB/Microsoft o Heather West, Google o Blaine Cook, British Telecom o Kasey Chappelle, Vodafone Group o Russ Housley, IETF Chair/Vigil Security, LLC o Daniel Appelquist, Vodafone R&D o Olaf Kolkman, IAB Chair o Jon Peterson, IAB/NeuStar, Inc. o Balachander Krishnamurthy, AT&T Labs--Research o Marc Linsner, Cisco Systems
o Fu-Ming Shih、Mit O Ian Jacobi、Mit O Steve Woodrow、Mit O Nick Mathewson、Tor Project O Peter Eckersley、電子フロンティア財団O John Klensin、Iab O Oliver Hanka、工科大学ミュンヘンOアランミスローブ、北東大学Oshkan Soltani、FTC O Sam Hartman、痛みのないセキュリティO Kevin Trilli、Truste O Dorothy Gellert、Interdigital O Aaron Falk、Raytheon -BBN Technologies O Sean Turner、Ieca O Wei -Yeh Lee、Navteq O Chad McClung、Boeing Company O Jan Seadorf、 Nec O Dave Crocker、Brandenburg InternetWorking O Lorrie Cranor、Carnegie Mellon University O Noah Mendelsohn、W3C Tag Chair O Stefan Winter、Restena O Craig Wittenberg、Microsoft O Bernard Aboba、IAB/Microsoft O Heather West、Google Telecom O Blaine o Kasey Chappelle、Vodafone Group o Russ Housley、IETF議長/Vigil Security、LLC O Daniel Appelquist、Vodafone R＆D O Olaf Kolkman、IAB議長O Jon Peterson、IAB/Neustar、Inc。 、シスコシステム
o Jorge Cuellar, Siemens AG o Arvind Narayanan, Stanford University o Eric Rescorla, Skype o Cullen Jennings, Cisco o Christine Runnegar, Internet Society o Alissa Cooper, Center for Democracy & Technology o Jim Fenton, Cisco o Oshani Seneviratne, MIT o Lalana Kagal, MIT o Fred Carter, Information & Privacy Commissioner of Ontario, Canada o Frederick Hirsch, Nokia o Benjamin Heitmann, DERI, NUI Galway, Ireland o John Linn, RSA, The Security Division of EMC o Paul Trevithick, Azigo o Ari Schwartz, National Institute of Standards and Technology o David Evans, University of Cambridge o Nick Doty, UC Berkeley, School of Information o Sharon Paradesi, MIT o Jonathan Mayer, Stanford University o David Maher, Intertrust o Brett McDowell, PayPal o Leucio Antonio Cutillo, Eurecom o Susan Landau, Radcliffe Institute for Advanced Study, Harvard University o Christopher Soghoian, FTC In-house Technologist, Center for Applied Cybersecurity Research, Indiana University o Trent Adams, Internet Society o Thomas Roessler, W3C o Karen O'Donoghue, ISOC o Hannes Tschofenig, IAB/Nokia Siemens Networks o Lucy Elizabeth Lynch, Internet Society o Karen Sollins, MIT o Tim Berners-Lee, W3C
o ホルヘ・クエラー、シーメンス・アグ・オルビンド・ナラヤナン、スタンフォード大学オリック・レスコルラ、スカイプ・オ・カレン・ジェニングス、シスコ・オ・クリスティン・ランネガー、インターネット社会オリッサ・クーパー、民主主義＆技術センターoジム・フェントン、Cisco o Oshani heneviratne、mit o lalana kagal MIT O FRED CARTER、カナダ、オンタリオ州オンタリオ州の情報＆プライバシーコミッショナーO FREDERICK HIRSCH、NOKIA O BENJAMIN HEITMANN、DERI、NUI GALWAY、ARELAND O JOHN LINN、RSA、EMC O Paul Trevithick、Azigo O Ari Schwartz、国民研究所のセキュリティ部門標準と技術のDavid Evans、Cambridge University o Calc Berkeley、Nick Berkeley、School of Sharon Paradesi、Mit o Jonathan Mayer、Stanford University O David Maher、Intertrust O Brett McDowell、Paypal O Leucio Antonio Cutillo、Eurecom O Susananランドー、ラドクリフ高等研究所、ハーバード大学Oクリストファー・ソゴイアン、FTC社内技術者、応用サイバーセキュリティ研究センター、インディアナ大学Oトレント・アダムス、インターネット社会O Thomas Roessler、W3C O Karen O'Donoghue、Isoc O Hannes Tschofenig、Iab/Nokia Siemens Networks O Lucy Elizabeth Lynch、Internet Society O Karen Sollins、Mit O Tim Berners-Lee、W3C
1. "Addressing the privacy management crisis in online social networks" by Krishna Gummadi, Balachander Krishnamurthy, and Alan Mislove
1. Krishna Gummadi、Balachander Krishnamurthy、およびAlan Misloveによる「オンラインソーシャルネットワークのプライバシー管理危機への対処」
2. "Thoughts on Adding "Privacy Considerations" to Internet Drafts" by Alissa Cooper and John Morris
2. Alissa CooperとJohn Morrisによる「インターネットドラフトに「プライバシーに関する考慮事項」を追加することについての考え
3. "Toward Objective Global Privacy Standards" by Ari Schwartz
3. Ari Schwartzによる「客観的なグローバルプライバシー基準に向けて」
4. "SocialKeys: Transparent Cryptography via Key Distribution over Social Networks" by Arvind Narayanan
4. 「ソーシャルキー：ソーシャルネットワークを介したキーディストリビューションによる透明な暗号」Arvind Narayanan
5. "Web Crawlers and Privacy: The Need to Reboot Robots.txt" by Arvind Narayanan and Pete Warden
5. 「Webクローラーとプライバシー：Robots.txtの再起動の必要性」Arvind NarayananとPete Warden
6. "I Know What You Will Do Next Summer" by Balachander Krishnamurthy
6. 「来年の夏に何をするか知っている」バラチャンダー・クリシュナムルシー
7. "An architecture for privacy-enabled user profile portability on the Web of Data" by Benjamin Heitmann and Conor Hayes
7. Benjamin HeitmannとConor Hayesによる、データのWebでのプライバシー対応ユーザープロファイルの移植性のアーキテクチャ」
8. "Addressing Identity on the Web" by Blaine Cook
8. ブレインクックによる「ウェブ上のアイデンティティの対処」
9. "Protection-by-Design: Enhancing ecosystem capabilities to protect personal information" by Jonathan Fox and Brett McDowell
9. ジョナサン・フォックスとブレット・マクダウェルによる「保護による設計による保護：個人情報を保護するためのエコシステム機能の強化」
10. "Privacy-preserving identities for a safer, more trusted internet" by Christian Paquin
10. Christian Paquinによる「より安全で信頼できるインターネットのためのプライバシーを提供するアイデンティティ」
11. "Why Private Browsing Modes Do Not Deliver Real Privacy" by Christopher Soghoian
11. 「なぜプライベートブラウジングモードが本当のプライバシーを提供しないのか」クリストファー・ソゴアンによる
12. "Incentives for Privacy" by Cullen Jennings
12. カレン・ジェニングスによる「プライバシーのインセンティブ」
13. "Joint Privacy Workshop: Position Comments by D. Crocker" by Dave Crocker
13. 「共同プライバシーワークショップ：D。Crockerによるポジションコメント」DaveCrocker
14. "Using properties of physical phenomena and information flow control to manage privacy" by David Evans and David M. Eyers
14. David EvansとDavid M. Eyersによる「物理現象と情報フロー制御のプロパティの使用」プライバシーを管理する」
15. "Privacy Approaches for Internet Video Advertising" by Dave Maher
15. Dave Maherによる「インターネットビデオ広告のプライバシーアプローチ」
16. "Privacy on the Internet" by Dorothy Gellert
16. ドロシー・ゲラートによる「インターネット上のプライバシー」
17. "Can We Have a Usable Internet Without User Trackability?" by Eric Rescorla
17. 「ユーザーの追跡可能性なしで使用可能なインターネットを持つことができますか？」エリック・レスコルラ
18. "Privacy by Design: The 7 Foundational Principles -- Implementation and Mapping of Fair Information Practices" by Fred Carter and Ann Cavoukian
18. 「設計によるプライバシー：7つの基本原則 - 公正な情報慣行の実装とマッピング」Fred CarterとAnn Cavoukian
19. "Internet Privacy Workshop Position Paper: Privacy and Device APIs" by Frederick Hirsch
19. 「インターネットプライバシーワークショップポジションペーパー：プライバシーとデバイスAPI」by Frederick Hirsch
20. "Position Paper for Internet Privacy Workshop" by Heather West
20. ヘザーウェストによる「インターネットプライバシーワークショップのポジションペーパー」
21. "I 'like' you, but I hate your apps" by Ian Glazer
21. 「私はあなたが好きですが、私はあなたのアプリが嫌いです」Ian Glazer
22. "Privicons: A approach to communicating privacy preferences between Users" by E. Forrest and J. Schallabock
22. 「プライベート：ユーザー間でプライバシーの好みを伝えるためのアプローチ」E.フォレストとJ.シャラボック
23. "Privacy Preservation Techniques to establish Trustworthiness for Distributed, Inter-Provider Monitoring" by J. Seedorf, S. Niccolini, A. Sarma, B. Trammell, and G. Bianchi
23. J. Seedorf、S。Niccolini、A。Sarma、B。Trammell、およびG. Bianchiによる、「分散型、プロバイダー間監視の信頼性を確立するためのプライバシー保存技術」
24. "Trusted Intermediaries as Privacy Agents" by Jim Fenton
24. ジム・フェントンによる「プライバシーエージェントとしての信頼できる仲介者」
25. "Protocols are for sharing" by John Kemp
25. ジョン・ケンプによる「プロトコルは共有のためです」
26. "On Technology and Internet Privacy" by John Linn
26. ジョン・リンによる「テクノロジーとインターネットプライバシーについて」
27. "Do Not Track: Universal Web Tracking Opt-out" by Jonathan Mayer and Arvind Narayanan
27. 「追跡しない：ユニバーサルウェブトラッキングオプトアウト」ジョナサンメイヤーとアービンドナラヤナン
28. "Location Privacy Protection Through Obfuscation" by Jorge Cuellar
28. ホルヘ・クエラーによる「難読化による場所のプライバシー保護」
29. "Everything we thought we knew about privacy is wrong" by Kasey Chappelle and Dan Appelquist
29. 「プライバシーが間違っていると思っていたことはすべて」Kasey ChappelleとDan Appelquistによる
30. "TRUSTe Position Paper" by Kevin Trilli
30. Kevin Trilliによる「Truste Position Paper」
31. "Position Paper: Incentives for Adoption of Machine-Readable Privacy Notices" by Lorrie Cranor
31. 「ポジションペーパー：機械読み取り可能なプライバシー通知の採用のインセンティブ」Lorrie Cranor
32. "Facilitate, don't mandate" by Ari Rabkin, Nick Doty, and Deirdre K. Mulligan
32. アリ・ラブキン、ニック・ドーティ、ディアドル・K・マリガンによる「促進、義務を負わない」
33. "Location Privacy in Next Generation Internet Architectures" by Oliver Hanka
33. オリバー・ハンカによる「次世代のインターネットアーキテクチャの場所のプライバシー」
34. "HTTPa: Accountable HTTP" by Oshani Seneviratne and Lalana Kagal
34. 「HTTPA：説明責任のあるhttp」by Oshani SeneviratneとLalana Kagal
35. "Personal Data Service" by Paul Trevithick
35. Paul Trevithickによる「個人データサービス」
36. "Several Pressing Problems in Hypertext Privacy" by Peter Eckersley
36. Peter Eckersleyによる「ハイパーテキストプライバシーにおけるいくつかの差し迫った問題」
37. "Adding Privacy in Existing Security Systems" by Sam Hartman
37. Sam Hartmanによる「既存のセキュリティシステムにプライバシーを追加」
38. "Mobility and Privacy" by S. Brim, M. Linsner, B. McLaughlin, and K. Wierenga
38. S. Brim、M。Linsner、B。Mclaughlin、K。Wierengaによる「モビリティとプライバシー」
39. "Saveface: Save George's faces in Social Networks where Contexts Collapse" by Fuming Shih and Sharon Paradesi
39. 「Saveface：ShihとSharon Paradesiを発煙させることで、コンテキストが崩壊するソーシャルネットワークでジョージの顔を保存する
40. "eduroam -- a world-wide network access roaming consortium on the edge of preserving privacy vs. identifying users" by Stefan Winter
40. 「eduroam-プライバシーを維持する端にある世界的なネットワークアクセスローミングコンソーシアムとユーザーの識別」Stefan Winter
41. "Effective Device API Privacy: Protecting Everyone (Not Just the User)" by Susan Landau
41. 「効果的なデバイスAPIプライバシー：すべてのユーザーではなく保護する」スーザンランダウ
42. "Safebook: Privacy Preserving Online Social Network" by L. Antonio Cutillo, R. Molva, and M. Onen
42. 「SafeBook：プライバシーオンラインソーシャルネットワークの保存」L.アントニオ・カティロ、R。モルバ、およびM.オネン
Author's Address
著者の連絡先
Alissa Cooper CDT 1634 I Street NW, Suite 1100 Washington, DC 20006 USA
Alissa Cooper CDT 1634 I Street NW、Suite 1100 Washington、DC 20006 USA
EMail: acooper@cdt.org
URI: http://www.cdt.org/