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.
12月8-9、2010年、IAB World Wide Webコンソーシアム（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.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報が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.
著作権（C）2012 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
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トラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。
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.
12月8-9、2010年、IABインターネットのプライバシー[ワークショップ]についてW3C、ISOC、およびMITのコンピュータ科学人工知能研究所（CSAIL）とのワークショップを共催。ワークショップは、インターネットコミュニティは、それがプライバシーを尊重するために、インターネットベースのシステムのために何を意味するのか、いくつかの理解を得るのを助けるために組織された、どのようなシステムは、または、設計することができるされていますどのようにウェブとより広範なインターネットの影響のプライバシー、と何の関係特定の作業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.
ネットワークレベルでは、参加者は、モビリティプロトコル、[RFC4941]をIPv6アドレスのプライバシーの拡張機能、およびオニオンルーティングに隠れIPアドレスを議論しました。 Torのプロジェクト[トア]についての議論は、特に洞察に満ちました。 Torのは、TCP上で実行するプロトコルを匿名化するために設計された回路に基づく、低遅延通信サービスです。 Torの交換に参加するエンドホストは、ネットワークを介してパスを選択し、パス内の各「オニオンルータは」前任者と後継者を知っていませんが、回路内の他のノードた回路を構築します。パス内の各オニオンルータは、下流の中継前に受信した情報をアンラップして復号化します。
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のノードは、時間をかけてユーザーを再識別するために使用することができる情報要素を取り除くことができるようにする必要があります。たとえば、クッキーは、JavaScriptの大部分、および（フラッシュを含む）ほぼすべてのブラウザプラグインなどの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 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).
ブラウザの議論はまた、ウェブトラッキングをオプトアウトするための簡単な方法をユーザーに提供するために、ブラウザに組み込まれたことを「追跡しない」（DNT）技術のための提案を取り上げました。ワークショップの時には、様々な異なる技術提案は、ユーザーがオプトアウトするか、完全に特定のWebサイトへの通信を遮断するために自分の好みを示す能力を提供するように設計されていました。ワークショップでの議論は、追跡の種類についての合意の欠如を示す技術的なメカニズムは異なるシナリオに最適だろう、とどのようにメカニズムが（例えばユーザーへの通知など）プライバシー保護の他の側面との対話と思われる、許容可能です。
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.
（例えば、Facebookの接続で）オープン認証（OAuthの）の現在の用途に焦点を当てた、クロスサイトデータ共有議論。改善がサイト間でデータを共有するユーザーの同意を得てなされているが、課題はデータの最小化、使いやすさ、データの隠し共有、およびアイデンティティ情報の一元化に関して残ります。
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がSecurity Considerations部を含んでする必要がありました。しかし、そのシンプルな任務はすぐに今日IETFに浸透広範なセキュリティ意識に変換しませんでした。長年にわたり投下多くの努力で、セキュリティに対するより体系的なアプローチは、ツールとリソースのさまざまな使用すること進化しました：セキュリティエリア自体が、セキュリティ上の考慮事項[RFC3552]、セキュリティ総局、セキュリティアドバイザーについてRFCの作者にガイドラインをその上で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 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.
W3Cは同様に描画するための過去の努力の数を持っています。ウェブのプライバシーを向上させることを目的とした最古の大規模な標準化の取り組みの一つは、プライバシー設定[P3P]のためのプラットフォームでした。 P3Pの背後にある考え方は、Webサイトがブラウザはおそらく獣医とは、ユーザの好みに応じてオーバーライドすることができ、機械可読プライバシーポリシーを提供持っていました。 P3Pポリシー表現言語は、サイトは、彼らがユーザーに関連するデータを利用することを意図した方法についての複雑なアサーションを行うことができるように十分に堅調に推移しましたが、市場の動向は、展開方針に多くの課題を作成しました。
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のより最近の研究は、ウェブサイトにユーザーの正確な位置にアクセスする方法を提供するジオロケーションAPI [ジオロケーション]に含まれます。 APIは、実装は、位置情報にアクセスする前にユーザーの同意を得て、ユーザーがその同意を取り消すことができますが、保持、二次利用、およびデータの最小化についての決定は、個々のウェブサイトやアプリケーションに任されている必要があります。ジオロケーションの努力と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アドレス、トランスポートプロトコルパラメータ、クッキー、ウェブ・ストレージの他の形態、およびブラウザベースの情報の広大な配列は、日常的に共有されてもよいです。フィンガープリントの容易さは、匿名またはリンク不能（たとえば通信エンドポイントを識別するデータを取り除くためにオニオン・ルーティングを使用して[トール]、のように）を保証しようとするアプリケーションのための重要な課題を提示します。
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を取得するためにウェブサイトの方法を提供します。ウェブ上のURI文字列は、多くの場合、この情報が含まれているため、リファラーヘッダーには、そのユーザーはどこから来に関するウェブサイトに貴重な洞察を提供し、彼らはまた、（例えば、検索語またはユーザーID）機密情報を漏洩することができます。個々のWebサイトのインフラストラクチャは、多くの場合、それ自体が正常に機能サイトを作って、その目標を果たすことができる検索語またはURIの中の他のユーザー固有の情報を埋め込むことを視野にのみ設計されていますが、時にそれらの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分布を制御するいくつかの手段を持つ状況でのみ適している「所有モデル」に頼って、オープンウェブ上で使用する場合、広い漏れにつながることができます。
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テクノロジと一致しません。伝統的に、用語「最初のパーティは、」ユーザーエージェントがユーザーに代わって明示的な要求を指示するウェブサイトのドメインを参照するために使用されてきました。用語「第三者」とは、第1パーティのドメインから別のドメインでホストされているサードパーティのリソースで、ユーザーエージェントは、ファーストパーティの要求の結果として要求した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クッキーを処理するための長年のユーザエージェントの実践の結果です。通常、HTTPクッキーは、それらだけを設定オリジンサーバ[RFC6265]に戻ります。ファーストパーティドメインから設定クッキーは、サードパーティのドメインとその逆によって読み取らなくてもよいです。いくつかのケースでは、サブドメインが含まれているファーストパーティのドメインから設定されたクッキーは、ファーストパーティのドメインのすべてのサブドメインでアクセスできます。ファーストパーティのドメインとサードパーティのドメイン間の区別は、ブラウザベースのクッキーのコントロールに反映されます。主要な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およびブラウザの開発者が積極的にこの課題に対処するための新しい方法を模索しているが、いくつかの明確なソリューションがあります。
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.
ユーザーが自分の情報が使用されているとどのようなトレードオフが自分のデータを収集したとほとんど、あるいはまったくコストでのサービスへのアクセスの間にあるかを十分に理解が不足していることに疑いはありません。ウェブ上で行われ、追跡の多くは受動的なユーザーには見えません。ほとんどの企業が書かれたプライバシーポリシーにそのデータ利用プラクティスを開示するが、これらの政策はほとんど読まれていない、理解しにくい、と多くの場合（たとえば、データ保持寿命など）顕著な詳細を開示していません。ウェブトラッキングは、いくつかの視覚的な表示に関連している場合でも - ターゲットを絞ったGmailの広告またはFacebookの「Like」ボタン、例えば - ユーザーは、しばしば、それが発生していることに気付いていません。
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]のサポートアドレスでステートレスアドレス自動設定のプライバシーの拡張機能ではなく、ほとんどのユーザーのために長期に使用することができ、永続的かつ不変のユニークな識別子であるインタフェースのメディアアクセス制御（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.
プライバシーツールを開発した経験のこの種のシステムとプロトコルにプライバシー機能を設計することは、彼らが対処するように設計されている脅威の範囲を明確に理解が必要であることを示しています。この範囲は、現在「追跡しない」ウェブや他のオンラインの状況について（DNT）のメカニズムの開発についての議論に議論されています。異なるアプローチの数は（オプトアウトクッキー、追跡されるべきではなく、ユーザの嗜好を表現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 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.
最も広く使用されているプロトコルの多くはアプリケーションや機能の多様性をサポートするために一般的に設計されているため、インターネット上のプライバシーの脅威のスペースは、プロトコル設計の観点から、特に幅広い表示されることがあります。 HTTPは、例えば、元の設計者はおそらく予想よりも目的の多種多様のために使用されます。これらの目的のいくつかは、取得やプライバシー侵害かもしれ方法でウェブユーザーに関するデータを使用して含まれていることを驚くべきことではありません。特定のプロトコルの設計に起因するすべての可能な展開の潜在的なプライバシーのリスクを軽減するためのプロトコル設計を依頼するのは無理です。重要な質問は、プライバシーの侵入から保護するための責任は、プライバシー機能の種類は、最高のそれぞれの場所で実現することができるプロトコル、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ブラウジングは、ほとんどのブラウザプラグインは、JavaScriptの限り、特に困難であり、他のブラウザベースの機能の数は、Torの匿名性の要件を満たすためにブロックされたり上書きする必要があります。 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]はSIP要求の本体を確保する多目的インターネットメール拡張（S / MIME）/セキュアサポートし、そのユーザーエクスペリエンスへの影響を与え、いくつかの実装では、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.
インターネットは、何十年もの間、商用コンテンツを支えてきました。多くのサービスは、広告を販売するか（あるいは両方）のユーザデータを収集することができることと引き換えに、ほとんど、あるいは無償で提供されています。特にウェブの商業的価値は近年爆発したように、プライバシーを調整するためのパラダイムは、よりゆっくりとはいえ、変わり始めました。
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.
商用インターネットの夜明けに、いくつかのウェブサイトは、彼らがユーザーデータでやったことを説明し、プライバシーポリシーを書いていました。規制の圧力の下で、サイトが公に掲載ポリシーで自分のデータ収集およびデータの利用慣行を文書化し始めました。これらのポリシーは、すぐに商用サイトではなく、それらとの関連性の顕著な慣行についてユーザーに通知するよりも、多くの場合、サイトはに従事かもしれないすべての可能な練習を開示することにより、自分の責任を制限するために使用することができ、長い法的文書となりました。
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.
規制当局は、インセンティブ構造を形成する上で重要な役割を果たしています。企業は多くの場合、彼らの責任を制限するように作用すると、消費者データの使用に関して封筒をプッシュするとの間のバランスを追求します。規制当局は、一定の実務に強い立場を取る場合 - 例えば、ヨーロッパの議員は、ユーザーの同意なしに設定されているクッキーに対して持っている、と[指令] - 合法的な企業が遵守することを強要感じるだろう。規制の不確実性がある場合でも、ビジネスの応答が異なる市場戦略に応じて異なる場合があります。ウェブトラッキングを制御するメカニズムについて新たな議論への潜在的な応答の様々なこの変化を示しています。一部の企業は、彼らがユーザーを追跡することができない場合は他の人が自社製品やチャージ料が制限される可能性があり、拡張ユーザーコントロールのサポートを受け入れるだろう、と、まだ他の人が選ぶことができます場所に置かれた任意の新しいメカニズムを回避します。規制圧力の不在が「良い」と「悪い」の俳優の間の線はあまり明らかにする傾向があります。
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の最初のバージョンは、律法主義のプライバシーポリシーが当たり前だったし、ユーザーがウェブ上でそれらについて収集したデータの上にのみ基本のコントロールを持っていたとき、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を使用できるようにする重要な決定をしました。多くのサイトは、単にW3Cによって提供される例の方針から切り取り、貼り付けたものの、そのクッキーがブロックされないようにするには、ほとんどの商用サイトは、いくつかのP3Pポリシーを採用しました。今日では、サイトの多くは、彼らの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 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.
P3Pの経験は通信の両端の積極的な参加を必要とするプライバシー機能を作り上げるの試みのために一般に有益です。処理して、このような好みに反応するように意図されているものがそうであるように、そうするインセンティブが必要で、彼らは企業や個人を問わず、自分のプライバシー設定を明確にすることを意図している俳優。例えば、IETFのGEOPRIVアーキテクチャは、位置情報[RFC4119]についてのユーザの好みの発現を可能にします。ユーザーは、企業がP3Pケースで行ったよりも、GEOPRIVモデルの使用の成功は、これらの好みに従うことに、位置情報を消費するエンドポイントが必要になりますし、特定のコンテキストで自分のプライバシー設定を開示する多くのインセンティブを持っているかもしれないが - 、商業や雇用関連、例えば - 彼らは不本意であってもよいし、あるいは規制の圧力は、実際の変化に拍車をかけるために必要な場合があります。
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の代わりにインターネットResearch Task Force（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のそれより定義されたスコープ内で動作するので - すなわち、ウェブ - 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は、プライバシーのトピックを議論するために金利グループを調査します。ワークショップから生まれたいくつかの潜在的なトピックは、参照元のヘッダープライバシー漏洩を扱う非ブラウザベースのプロトコルのためのプライバシーの配慮を開発し、仕様設計の一部として、ユーザビリティの配慮を開発し、APIの中にW3Cのプロトコルのフィンガープリントへの影響、データの最小化が含まれます。
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コンテキストにおけるクロスサイトデータ共有、相関、およびリンク可能性に取り組みます。そして、ポリシー表現言語の調査。
Thanks to Bernard Aboba, Nick Doty, and Hannes Tschofenig for their early reviews.
彼らの初期のレビューのためのバーナードAboba、ニック・ドーティ、およびハンネスTschofenigに感謝します。
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、 "アプリケーションレイヤトラフィックの最適化（アルト）"、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/ 12分の2010 / privacyreport.shtm>。
[Geolocation] Popescu, A., Ed., "Geolocation API Specification", September 2010, <http://www.w3.org/TR/2010/CR-geolocation-API-20100907/>.
[ジオロケーション]ポペスク、A.編、 "ジオロケーションAPI仕様"、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]クーパー、A.およびH. Tschofenig、「ウェブトラッキングのためのユニバーサルオプトアウトメカニズムの概要」、進歩、2011年3月に作業。
[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]ヴェニング、R.、エド。、およびM. Schunter、エド。、 "プライバシー設定1.1（P3P1.1）仕様のためのプラットフォーム"、2006年11月、<http://www.w3.org/TR/ P3P11 />。
[Panopticlick] Electronic Frontier Foundation, "Panopticlick", 2011, <http://panopticlick.eff.org/>.
[Panopticlick]電子フロンティア財団、 "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>.
[ポリシー]レオン、P.、Cranor、L.、マクドナルド、A.、およびR.マクガイア、 "トークンの試み：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]クーパー、A.、Tschofenig、H.、Aboba、B.、ピーターソン、J.、およびJ.モリス、 "インターネットプロトコルのための個人情報保護に関する注意事項"、進歩、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.およびC.ウィルズ、 "Web上のプライバシー拡散：縦視点"、ワールド・ワイド・ウェブ会議の議事録、ページ541から550、マドリード、スペイン、2009年4月、<のhttp：// WWW .cs.wpi.edu /〜CEW /論文/ 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.、マランドリーノ、D.、およびC.ウィルズ、「プライバシー損失やWebブラウジングにおけるプライバシー保護の影響の測定」、シンポジウム使用可能なプライバシーとセキュリティ上、ページ52-63、ピッツバーグ、 PA USA、ACM国際会議議事録シリーズ、2007年7月、<http://www.cs.wpi.edu/~cew/papers/soups07.pdf>。
[RFC1543] Postel, J., "Instructions to RFC Authors", RFC 1543, October 1993.
[RFC1543]ポステル、J.、RFC 1543、1993年10月 "RFC作者への指示"。
[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]フィールディング、R.、ゲティス、J.、モーグル、J.、Frystyk、H.、Masinter、L.、リーチ、P.、およびT.バーナーズ - リー、 "ハイパーテキスト転送プロトコル - 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]日、M.、ローゼンバーグ、J.、およびH.菅野、 "プレゼンスとインスタントメッセージングのためのモデル"、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]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル" 、RFC 3261、2002年6月。
[RFC3323] Peterson, J., "A Privacy Mechanism for the Session Initiation Protocol (SIP)", RFC 3323, November 2002.
[RFC3323]ピーターソン、J.、RFC 3323、2002年11月 "セッション開始プロトコル（SIP）のためのプライバシーメカニズム"。
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, July 2003.
[RFC3552]レスコラ、E.とB.コーバー、BCP 72、RFC 3552、2003年7月、 "セキュリティ上の考慮事項の書き方RFCテキストのためのガイドライン"。
[RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J. Polk, "Geopriv Requirements", RFC 3693, February 2004.
[RFC3693]クエリャル、J.、モリス、J.、マリガン、D.、ピーターソン、J.、およびJ.ポーク、 "Geopriv要件"、RFC 3693、2004年2月。
[RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object Format", RFC 4119, December 2005.
[RFC4119]ピーターソン、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.クリシュナン、 "IPv6におけるステートレスアドレス自動設定のための個人情報保護の拡張"、RFC 4941、2007年9月。
[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, April 2011.
[RFC6265]バース、A.、 "HTTP状態管理機構"、RFC 6265、2011年4月。
[Tor] The Tor Project, Inc., "Tor", 2011, <https://www.torproject.org/>.
[Torの]のTorプロジェクト、株式会社、 "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/インターネット・プライバシー・ワークショップ-2010 />。
Appendix A. Workshop Materials
付録A.ワークショップ資料
Main page: 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/インターネットプライバシーワークショップ-2010 /スライド/
Minutes: http://www.iab.org/activities/workshops/ internet-privacy-workshop-2010/minutes/
分：http://www.iab.org/activities/workshops/インターネットプライバシーワークショップ-2010 /分/
Position papers: http://www.iab.org/activities/workshops/ internet-privacy-workshop-2010/papers/
ポジション・ペーパー：http://www.iab.org/activities/workshops/インターネットプライバシーワークショップ-2010 /論文/
Appendix B. Workshop Participants
付録B.ワークショップ参加者
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 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ニック・マシューソン、ピーター・エッカースリーOのTorプロジェクト、ジョン・クレンシンO電子フロンティア財団（EFF）、IAB Oフー明シーズー、イアン・ヤコビO MIT、スティーブ・ウッドローO MIT、MIT、アランMislove Oミュンヘン工科大学、ノースイースタン大学Oアッシュカーン・ソルタニ、アーロンフォーク、レイセオンOサム・ハートマン、ケビンTrilli O無痛セキュリティ、ドロシーゲッレールトO TRUSTe認証、インターデジタルO FTC - チャドマックラング、ジャン・セードルフOボーイング社Oショーン・ターナーO BBNテクノロジーズ、魏・葉・リーO IECA、NAVTEQノアメンデルゾーン、ブレイン・クック、ブリティッシュテレコムOヘザー・ウェスト、GoogleのOバーナードAboba、IAB /マイクロソフトOクレイグ・ヴィッテンベルク、マイクロソフトOステファン・ウィンター、RESTENA O W3Cタグ議長Oロリー・クラナー、カーネギーメロン大学Oデイブ・クロッカー、ブランデンブルクインターネットワーキングO、NEC Oケイシーシャペル、ラスHousley、IETF議長Balachander Krishnamurthy、AT＆T LabsのOダニエルAppelquist O /ビジルセキュリティ、LLC、ジョン・ピーターソンOオラフKolkman、IAB議長OボーダフォンR＆D、IAB / NeuStar、Inc.のOボーダフォン・グループ - マルク・O・リサーチLinsner、CISCアリッサ・クーパー、Oshani Seneviratne、MIT〇〇ジム・フェントン、シスコO民主主義＆テクノロジーセンターOクリスティンRunnegar、インターネット協会Oカレン・ジェニングス、シスコOエリックレスコラ、スカイプOアービンド・ナラヤナン、スタンフォード大学Oホルヘクエリャル、シーメンスAG O Oシステムジョン・リン、RSA、ポール・トレビシック、アリ・シュワルツO Azigo O EMCのセキュリティ部門であるOベンジャミンHeitmann、DERI、NUIゴールウェイ、アイルランドOフレデリック・ハーシュ、ノキアOフレッド・カーター、情報・オンタリオ州、カナダのプライバシーコミッショナーO Lalana Kagal、MIT 、レウチョアントニオCutillo Oデイビッド・エヴァンス、ニック・ドーティOケンブリッジ大学Oアメリカ国立標準技術研究所、ジョナサン・メイヤーO UCシャロンParadesi Oバークレー、情報のスクール、MIT、デビッド・マヘル・Oスタンフォード大学、インタートラストブレット・マクダウェルO、ペイパル、 Eurecomスーザン・ランドー、クリストファー・ソグホアン、FTC社内のテクノロジストO先端研究のためラドクリフ研究所、ハーバード大学、応用サイバーセキュリティ研究センター、トレント・アダムス、インターOインディアナ大学Oトーマスレスラー、ティム・バーナーズ=リー、W3C OカレンSollins、MIT Oルーシー・エリザベス・リンチ、インターネット協会OカレンO'Donoghue、ハンネスTschofenig O ISOC、IAB /ノキアシーメンスネットワークスO W3C Oネット社会
Appendix C. Accepted Position Papers
付録C.受け入れられたポジションペーパー
1. "Addressing the privacy management crisis in online social networks" by Krishna Gummadi, Balachander Krishnamurthy, and Alan Mislove
1.クリシュナGummadi、Balachander Krishnamurthy、そしてアランMisloveで「オンラインソーシャルネットワークにおけるプライバシー管理の危機への対処」
2. "Thoughts on Adding "Privacy Considerations" to Internet Drafts" by Alissa Cooper and John Morris
アリッサ・クーパーとジョン・モリスによる「インターネットドラフトに 『プライバシーの考慮事項2』の追加に関する考察」
4. "SocialKeys: Transparent Cryptography via Key Distribution over Social Networks" by Arvind Narayanan
4.「SocialKeys：ソーシャルネットワークの上にキー配布を経由して透明暗号化」アービンド・ナラヤナンによって
5. "Web Crawlers and Privacy: The Need to Reboot Robots.txt" by Arvind Narayanan and Pete Warden
5.「ウェブクローラとプライバシー：robots.txtのを再起動する必要があります」アービンド・ナラヤナンとピート・ウォーデンで
6. "I Know What You Will Do Next Summer" by Balachander Krishnamurthy
6. Balachander Krishnamurthyで「私はあなたが来年の夏に何をするか知っています」
7. "An architecture for privacy-enabled user profile portability on the Web of Data" by Benjamin Heitmann and Conor Hayes
7.ベンジャミンHeitmannとコナー・ヘイズによる「データのWeb上のプライバシーが有効なユーザープロファイルの移植のためのアーキテクチャ」
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.「より安全、より信頼性の高いインターネットのためのプライバシ保護アイデンティティ」
11. "Why Private Browsing Modes Do Not Deliver Real Privacy" by Christopher Soghoian
クリストファー・ソグホアンで「プライベートブラウジングモードでは、Realプライバシーが届かないのはなぜ」11
13. "Joint Privacy Workshop: Position Comments by D. Crocker" by Dave Crocker
13.「共同プライバシーワークショップ：D.クロッカーによる位置のコメント」デイブクロッカーによって
14. "Using properties of physical phenomena and information flow control to manage privacy" by David Evans and David M. Eyers
デイビッド・エヴァンスとDavid M. Eyersで「プライバシーを管理するための物理現象や情報フロー制御のプロパティを使用する」14
15. "Privacy Approaches for Internet Video Advertising" by Dave Maher
15.デイブマーで「プライバシーはインターネットビデオ広告のためのアプローチ」
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基本原則 - 公正な情報プラクティスの実装とマッピング」フレッド・カーターとアン・カブーキアンによって
19. "Internet Privacy Workshop Position Paper: Privacy and Device APIs" by Frederick Hirsch
19.「インターネットプライバシーワークショップポジションペーパー：プライバシーとデバイスAPIの」フレデリックHirschの
22. "Privicons: A approach to communicating privacy preferences between Users" by E. Forrest and J. Schallabock
22.「Privicons：ユーザ間のプライバシー設定を通信するためのアプローチ」E.フォレスト及びJ. Schallabockによって
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.セードルフ、S.ニッコリーニ、A.サルマ、B.トラメル、およびG.ビアンキにより「個人情報保存技術は、分散、インタープロバイダのモニタリングのための信頼性を確立するために」
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.ケイシーチャペルとダンAppelquistで「私たちはプライバシーを知っていたと思ったすべてが間違っています」
31. "Position Paper: Incentives for Adoption of Machine-Readable Privacy Notices" by Lorrie Cranor
31：ロリー・クラナーによる「ポジションペーパーは、機械読み取り可能なプライバシー通知の採用のためのインセンティブ」
32. "Facilitate, don't mandate" by Ari Rabkin, Nick Doty, and Deirdre K. Mulligan
32.アリRabkin、ニック・ドーティ、およびディアドラK.マリガンで「は必須ではありません、促進します」
33. "Location Privacy in Next Generation Internet Architectures" by Oliver Hanka
オリバー・ハンカ33.「次世代インターネットアーキテクチャにおける場所プライバシー」
36. "Several Pressing Problems in Hypertext Privacy" by Peter Eckersley
ピーター・エッカースリーによって36.「ハイパーテキスト個人情報保護のいくつかの差し迫った問題」
38. "Mobility and Privacy" by S. Brim, M. Linsner, B. McLaughlin, and K. Wierenga
38. S.ブリム、M. Linsner、B.マクローリン、及びK. Wierengaによって "モビリティとプライバシー"
39. "Saveface: Save George's faces in Social Networks where Contexts Collapse" by Fuming Shih and Sharon Paradesi
39.「Saveface：コンテキストは折りたたむソーシャルネットワークでジョージの顔を保存」発煙シーズーとシャロンParadesiで
40. "eduroam -- a world-wide network access roaming consortium on the edge of preserving privacy vs. identifying users" by Stefan Winter
40.「eduroam - ユーザを識別対プライバシーを保護するエッジ上の世界的なネットワークアクセスローミングコンソーシアム」ステファン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.アントニオCutillo、R. Molva、およびM. Onenで
Author's Address
著者のアドレス
Alissa Cooper CDT 1634 I Street NW, Suite 1100 Washington, DC 20006 USA
アリッサ・クーパーCDT 1634 IストリートNW、スイート1100ワシントンD.C. 20006 USA
EMail: acooper@cdt.org URI: http://www.cdt.org/
電子メール：acooper@cdt.org URI：http://www.cdt.org/