idnits 2.17.1
draft-iab-privacy-workshop-00.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
No issues found here.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
-- The document date (June 30, 2011) is 4656 days in the past. Is this
intentional?
Checking references for intended status: Informational
----------------------------------------------------------------------------
-- Obsolete informational reference (is this intentional?): RFC 1543
(Obsoleted by RFC 2223)
-- Obsolete informational reference (is this intentional?): RFC 2616
(Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235)
-- Obsolete informational reference (is this intentional?): RFC 2828
(Obsoleted by RFC 4949)
-- Obsolete informational reference (is this intentional?): RFC 4941
(Obsoleted by RFC 8981)
Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 5 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 Network Working Group A. Cooper
3 Internet-Draft CDT
4 Intended status: Informational June 30, 2011
5 Expires: January 1, 2012
7 Report from the Internet Privacy Workshop
8 draft-iab-privacy-workshop-00
10 Abstract
12 On December 8-9, 2010, the IAB co-hosted an Internet privacy workshop
13 with the W3C, ISOC, and MIT's Computer Science and Artificial
14 Intelligence Laboratory. The workshop revealed some of the
15 fundamental challenges in designing, deploying, and analyzing
16 privacy-protective Internet protocols and systems. Although workshop
17 participants and the community as a whole are still far from
18 understanding how best to systematically address privacy within
19 Internet standards development, workshop participants identified a
20 number of potential next steps. For the IETF, these included the
21 creation of a privacy directorate to review Internet drafts, further
22 work on documenting privacy considerations for protocol developers,
23 and a number of exploratory efforts concerning fingerprinting and
24 anonymized routing. Potential action items for the W3C included
25 investigating the formation of a privacy interest group and
26 formulating guidance about fingerprinting, referrer headers, data
27 minimization in APIs, usability, and general considerations for non-
28 browser-based protocols.
30 Note that this document is a report on the proceedings of the
31 workshop. The views and positions documented in this report are
32 those of the workshop participants and do not necessarily reflect IAB
33 views and positions.
35 Status of this Memo
37 This Internet-Draft is submitted in full conformance with the
38 provisions of BCP 78 and BCP 79.
40 Internet-Drafts are working documents of the Internet Engineering
41 Task Force (IETF). Note that other groups may also distribute
42 working documents as Internet-Drafts. The list of current Internet-
43 Drafts is at http://datatracker.ietf.org/drafts/current/.
45 Internet-Drafts are draft documents valid for a maximum of six months
46 and may be updated, replaced, or obsoleted by other documents at any
47 time. It is inappropriate to use Internet-Drafts as reference
48 material or to cite them other than as "work in progress."
49 This Internet-Draft will expire on January 1, 2012.
51 Copyright Notice
53 Copyright (c) 2011 IETF Trust and the persons identified as the
54 document authors. All rights reserved.
56 This document is subject to BCP 78 and the IETF Trust's Legal
57 Provisions Relating to IETF Documents
58 (http://trustee.ietf.org/license-info) in effect on the date of
59 publication of this document. Please review these documents
60 carefully, as they describe your rights and restrictions with respect
61 to this document. Code Components extracted from this document must
62 include Simplified BSD License text as described in Section 4.e of
63 the Trust Legal Provisions and are provided without warranty as
64 described in the Simplified BSD License.
66 Table of Contents
68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
69 2. Workshop Overview . . . . . . . . . . . . . . . . . . . . . . 4
70 2.1. Technical Discussion . . . . . . . . . . . . . . . . . . . 5
71 2.2. SDO Discussion . . . . . . . . . . . . . . . . . . . . . . 6
72 3. Design Challenges . . . . . . . . . . . . . . . . . . . . . . 7
73 3.1. Ease of Fingerprinting . . . . . . . . . . . . . . . . . . 7
74 3.2. Information Leakage . . . . . . . . . . . . . . . . . . . 8
75 3.3. Differentiating Between First and Third Parties . . . . . 8
76 3.4. System Dependencies . . . . . . . . . . . . . . . . . . . 9
77 3.5. Lack of User Understanding . . . . . . . . . . . . . . . . 10
78 4. Deployment and Analysis Challenges . . . . . . . . . . . . . . 10
79 4.1. Generative Protocols vs. Contextual Threats . . . . . . . 11
80 4.2. Tension Between Privacy Protection and Usability . . . . . 12
81 4.3. Interaction Between Business, Legal and Technical
82 Incentives . . . . . . . . . . . . . . . . . . . . . . . . 13
83 4.3.1. Role of Regulation . . . . . . . . . . . . . . . . . . 13
84 4.3.2. P3P: A Case Study . . . . . . . . . . . . . . . . . . 14
85 5. Conclusions and Next Steps . . . . . . . . . . . . . . . . . . 15
86 5.1. IETF Outlook . . . . . . . . . . . . . . . . . . . . . . . 15
87 5.2. W3C Outlook . . . . . . . . . . . . . . . . . . . . . . . 16
88 5.3. Other Future Work . . . . . . . . . . . . . . . . . . . . 16
89 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
90 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
91 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17
92 9. Informative References . . . . . . . . . . . . . . . . . . . . 17
93 Appendix A. Workshop Materials . . . . . . . . . . . . . . . . . 19
94 Appendix B. Workshop Participants . . . . . . . . . . . . . . . . 19
95 Appendix C. Accepted Position Papers . . . . . . . . . . . . . . 22
96 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 25
98 1. Introduction
100 On December 8-9, 2010, the IAB co-hosted a workshop with the W3C,
101 ISOC, and MIT's Computer Science and Artificial Intelligence
102 Laboratory (CSAIL) about Internet privacy [Workshop]. The workshop
103 was organized to help the Internet community gain some understanding
104 of what it means for Internet-based systems to respect privacy, how
105 such systems have been or could be designed, how the relationship
106 between the web and the broader Internet impacts privacy, and what
107 specific work the IETF and/or the W3C might pursue to address
108 Internet privacy. An overview of topics discussed at the workshop is
109 provided in Section 2.
111 The workshop discussions revealed the complexity and broad-based
112 nature of privacy on the Internet. Across numerous different
113 applications, a number of fundamental design challenges appear again
114 and again, the increasing ease of user/device/application
115 fingerprinting, unforeseen information leakage, difficulties in
116 distinguishing first parties from third parties, complications
117 arising from system dependencies, and the lack of user understanding
118 of privacy risks and tradeoffs (see Section 3). Workshop
119 participants also identified a number of barriers to successful
120 deployment and analysis of privacy-minded protocols and systems,
121 including the difficulty of using generative protocols and tools to
122 defend against context-specific threats, the tension between privacy
123 protection and usability, and the difficulty of navigating between
124 business, legal and individual incentives (see Section 4).
126 Privacy challenges far outnumber solutions, but the workshop
127 identified a number of concrete preliminary steps that standards
128 organizations can take to help ensure respect for user privacy in the
129 design of future standards and systems. For the IETF, these included
130 the creation of a privacy directorate to review Internet drafts,
131 further work on documenting privacy considerations for protocol
132 developers, and a number of exploratory efforts concerning
133 fingerprinting and anonymized routing. Potential action items for
134 the W3C included investigating the formation of a privacy interest
135 group and formulating guidance about fingerprinting, referrer
136 headers, data minimization in APIs, usability, and general
137 considerations for non-browser-based protocols. These next steps and
138 workshop outcomes are discussed in Section 5.
140 2. Workshop Overview
142 The workshop explored both current technical challenges to protecting
143 privacy and the ways in which standards organizations can help to
144 address those challenges. Links to workshop materials are listed in
145 Appendix A.
147 2.1. Technical Discussion
149 The workshop explored privacy challenges in three different technical
150 domains: at the network level, at the browser level, and with respect
151 to cross-site data exchanges. Example technologies were highlighted
152 in each area to motivate the discussion.
154 At the network level, participants discussed IP address hiding in
155 mobility protocols, privacy extensions for IPv6 addressing [RFC4941],
156 and onion routing. Discussion about the Tor project [Tor] was
157 particularly insightful. Tor is a circuit-based, low-latency
158 communication service designed to anonymize protocols that run over
159 TCP. End hosts participating in a Tor exchange choose a path through
160 the network and build a circuit in which each "onion router" in the
161 path knows its predecessor and successor, but no other nodes in the
162 circuit. Each onion router in the path unwraps and decrypts received
163 information before relaying it downstream.
165 For Tor to provide anonymity guarantees, Tor nodes need to be able to
166 strip out information elements that can be used to re-identify users
167 over time. For example, web technologies such as cookies, large
168 portions of JavaScript, and almost all browser plug-ins (including
169 Flash) need to be disabled in order to maintain Tor's privacy
170 properties during web use, significantly hampering usability.
172 At the browser level, the discussion focused first on experiences
173 with "private browsing" modes. Private browsing puts a browser into
174 a temporary session where no information about the user's browsing
175 session is stored locally after the session ends. The goal is to
176 protect the user's browsing behavior from others who may make use of
177 the same browser on the same machine. Private browsing is not
178 designed to protect the user from being tracked by remote servers,
179 employers, or governments, but there is some evidence that users fail
180 to understand the distinction between protection from local snooping
181 and these other forms of tracking. The specific protections offered
182 by private browsing modes also vary from browser to browser, creating
183 privacy loopholes in some cases.
185 The browser discussion also addressed proposals for "Do Not Track"
186 (DNT) technologies to be built into browsers to provide users with a
187 simple way to opt out of web tracking. At the time of the workshop,
188 various different technical proposals had been designed to offer
189 users the ability to indicate their preference to opt out or to block
190 communication to certain web sites altogether. The discussions at
191 the workshop illustrated a lack of agreement about what type of
192 tracking is acceptable, which technical mechanisms would be best
193 suited for different scenarios, and how the mechanisms would interact
194 with other aspects of privacy protection (such as notices to users).
196 The cross-site data-sharing discussion focused on current uses of
197 OAuth (with Facebook Connect, for example). While improvements have
198 been made in obtaining user consent to sharing data between sites,
199 challenges remain with regard to data minimization, ease-of-use,
200 hidden sharing of data, and centralization of identity information.
202 2.2. SDO Discussion
204 Participants discussed past experiences in approaching privacy within
205 the IETF and the W3C. Individual protocol efforts within the IETF
206 have sought to address certain privacy threats over the years.
207 Protocol designers have taken steps to reduce the potential for
208 identifiability associated with protocol usage, such as in the IPv6
209 privacy extensions case [RFC4941]. Protocols architected to rely on
210 intermediaries have sought to minimize the user data exposed in
211 transit, most notably in SIP [RFC3323]. Protocol architectures used
212 in inter-personal exchange have sought to give users granular control
213 over their information, including presence [RFC2778] and geolocation
214 information [RFC3693]. Efforts to square privacy with usability are
215 ongoing; the ALTO working group [ALTO], for example, is working out
216 how to balance the needs of users and network operators to share data
217 with each other about content preferences and network topologies
218 against legitimate concerns about revealing too much of either kind
219 of information.
221 The IETF also has experience to draw on in building a culture of
222 security awareness. Beginning with [RFC1543], all RFCs were required
223 to contain a security considerations section. But that simple
224 mandate did not immediately translate into the extensive security
225 consciousness that permeates the IETF today. Over many years and
226 with much effort invested, a more systematic approach to security has
227 evolved that makes use of a variety of tools and resources: the
228 security area itself, guidelines to RFC authors about security
229 considerations [RFC3552], the security directorate, security advisors
230 assigned to individual working groups, security tutorials at IETF
231 meetings, and so on.
233 The W3C likewise has a number of past efforts to draw on. One of the
234 earliest large-scale standards efforts aimed at improving web privacy
235 was the Platform for Privacy Preferences [P3P]. The idea behind P3P
236 was to have web sites provide machine-readable privacy policies that
237 browsers could vet and possibly override according to the user's
238 preference. The P3P policy expression language was robust enough to
239 allow sites to make complex assertions about how they intended to
240 make use of data related to users, but market developments have
241 created a number of challenges with deployed policies.
243 More recent work at the W3C centered around the appropriateness of
244 various privacy features to be included in the Geolocation API
245 [Geolocation], which gives web sites a way to access the user's
246 precise location. The API requires that implementations obtain user
247 consent before accessing location information and allow users to
248 revoke that consent, but decisions about retention, secondary use,
249 and data minimization are left up to individual web sites and
250 applications. The geolocation effort and the P3P experience both
251 raise questions about how to navigate usability, regulation, business
252 incentives, and other aspects that normally lie outside the scope of
253 SDO work.
255 3. Design Challenges
257 Workshop discussions surfaced a number of key issues that can make
258 designing privacy-sensitive protocols and systems difficult: the
259 increasing ease of user/device/application fingerprinting, unforeseen
260 information leakage, difficulties in distinguishing first parties
261 from third parties, complications arising from system dependencies,
262 and the lack of user understanding of privacy risks and tradeoffs.
264 3.1. Ease of Fingerprinting
266 Internet applications and protocols now share so many unique
267 identifiers and other bits of information as part of their ordinary
268 operation that it is becoming increasingly easy for remote nodes to
269 create unique device or application fingerprints and re-identify the
270 same devices or applications over time [Panopticlick]. Hardware
271 identifiers, IP addresses, transport protocol parameters, cookies,
272 other forms of web storage, and a vast array of browser-based
273 information may be routinely shared as users browse the web. The
274 ease of fingerprinting presents a significant challenge for any
275 application that seeks to guarantee anonymity or unlinkability (such
276 as [Tor], which uses onion routing to strip out data that identifies
277 communications endpoints).
279 In many cases the information that can be used to fingerprint a
280 device was not originally shared for that purpose; identifiers and
281 other information are provided to support some other functionality
282 (like IP addresses being shared in order to route packets), and may
283 incidentally be used to fingerprint. This complicates the task of
284 preventing fingerprinting because each application or protocol likely
285 needs its own identifiers and information to function. Furthermore,
286 some services are increasingly coming to rely on fingerprinting in
287 order to detect fraud or provide customized content, for example.
289 Finding privacy-friendly substitutes for fingerprinting will only
290 become more difficult as these services become more entrenched (see
291 Section 4.3).
293 The space of fingerprinting mitigations requires further exploration.
294 For example, workshop participants discussed the use of Javascript
295 queries to obtain a browser's (often highly unique) font list, and
296 the tradeoffs associated with browsers instead (or additionally)
297 supporting some small subset of fonts in order to reduce browser
298 identifiability. As with many other privacy features, such a
299 restriction presents a tradeoff between privacy and usability, and in
300 the case of fingerprinting writ large, it may be difficult to find
301 consensus about which mitigations appropriately balance both values.
302 As a first step, the IETF may consider documenting the fingerprinting
303 implications for widely used IETF protocols (TCP, HTTP, SIP, etc.).
305 3.2. Information Leakage
307 Internet protocols and services tend to leak information in ways that
308 were not foreseen at design time [Krishnamurthy07][Krishnamurthy09].
309 For example, the HTTP referrer header [RFC2616] provides a way for a
310 web site to obtain the URI of the resource that referred the user to
311 the site. Referrer headers provide valuable insights to web sites
312 about where their users come from, but they can also leak sensitive
313 information (search terms or user IDs, for example) because URI
314 strings on the web often contain this information. The
315 infrastructure of an individual web site is often designed solely
316 with a view to making the site itself function properly, and
317 embedding search terms or other user-specific information in URIs may
318 serve that goal, but when those URIs leak out to other sites via a
319 referrer header, it creates the potential for third parties to use
320 and abuse the data contained therein.
322 The use of URIs for authentication of identity or capabilities can be
323 susceptible to the same kinds of problems. Relying on a "possession
324 model" where any user in possession of an authentication or
325 capability URI can gain access to a resource is only suitable in
326 situations with some means of control over URI distribution, and can
327 lead to wide leakage when used on the open web.
329 3.3. Differentiating Between First and Third Parties
331 Distinguishing between "first-party" interactions and "third-party"
332 interactions is important for understanding the implications of data
333 collection, sharing and use that take place during the normal course
334 of web use. Unfortunately, the traditional meanings of these
335 concepts do not always clearly match up with user expectations or
336 evolving web technologies. Traditionally, the term "first party" has
337 been used to refer to the domain of a web site to which a user agent
338 directs an explicit request on behalf of a user. The term "third
339 party" has been used to refer to the domain of a web resource that a
340 user agent requests as a result of a first-party request, with the
341 third-party resource hosted at a different domain from the first-
342 party domain.
344 This distinction between first-party and third-party domains is in
345 part a result of long-standing user agent practices for handling HTTP
346 cookies. Typically, HTTP cookies are returned only to the origin
347 server that set them [RFC6265]. Cookies set from first-party domains
348 may not be read by third-party domains and vice versa. In some
349 cases, cookies set from first-party domains that contain subdomains
350 are accessible by all subdomains of the first-party domain. The
351 distinction between first-party domains and third-party domains is
352 reflected in browser-based cookie controls: major web browsers all
353 offer distinct first-party cookie settings and third-party cookie
354 settings.
356 However, a user's perception or expectation of the difference between
357 a "first party" and a "third party" may not fall neatly within these
358 distinctions. Users may expect that content hosted on a first-party
359 subdomain, but provided or used by a third party, would be treated as
360 third-party content, but browsers often treat it as first-party
361 content. Conversely, when third-party content appears from a source
362 with which the user has an established relationship -- such as the
363 Facebook "Like" button or other social widgets -- users may consider
364 their interaction with that content to be a desirable first-party
365 interaction, even though the content is hosted on a third-party
366 domain.
368 Handling these expectations programmatically is difficult since the
369 same identifier structures (domains, subdomains) can correlate to
370 different user expectations in different contexts. On the other
371 hand, prompting users to express a preference about what kinds of
372 data collection and use should be allowable by each party encountered
373 on the web is not practical. Web and browser developers are actively
374 seeking novel ways to address this challenge, but there are few
375 clear-cut solutions.
377 3.4. System Dependencies
379 [Maybe say something about the issues encountered with Tor (e.g. need
380 to disable Java, Javascript, etc.)? I'm not really sure what else to
381 say here that isn't already in Section 4.2.]
383 3.5. Lack of User Understanding
385 There is no question that users lack a full understanding of how
386 their information is being used and what the tradeoffs are between
387 having their data collected and accessing services at little or no
388 cost. Much of the tracking that takes place on the web is passive
389 and invisible to users. Most companies disclose their data usage
390 practices in written privacy policies, but these policies are rarely
391 read, difficult to understand, and often fail to disclose salient
392 details (such as data retention lifetimes). Even when web tracking
393 is associated with some visual indication -- a highly targeted Gmail
394 ad or the Facebook "Like" button, for example -- users often do not
395 realize that it is occurring.
397 Efforts abound to attempt to present information about data
398 collection and usage in a more digestible way. P3P was one early
399 effort, but because it sought to support the expression of the vast
400 expanse of potential policies that companies may have, it developed
401 more complexity than the average user (or user interface) could
402 sustain. More recent efforts have focused on using a limited set of
403 icons to represent policies or provide an indication that tracking is
404 taking place.
406 Part of the challenge is the level of nuance involved in making
407 decisions about privacy -- how can users be made to understand the
408 privacy tradeoffs of blocking HTTP referrer headers, for example,
409 when the effects of doing so will vary from site to site? Even
410 seemingly simple privacy controls like private browsing are not well
411 understood.
413 There is little about user understanding of privacy that is directly
414 actionable by standards organizations. But to the extent that
415 particular use cases for a new protocol or API rely on certain
416 conceptions of what users understand, standards developers should be
417 aware that users' understanding of the privacy implications of their
418 activities is likely be low.
420 4. Deployment and Analysis Challenges
422 Workshop paricipants identified a number of barriers to both
423 deployment of privact-protecting technologies and the analysis of the
424 privacy properties of technological systems. These included the
425 difficulty of using generative protocols and tools to defend against
426 context-specific threats, the tension between privacy protection and
427 usability, and the difficulty of navigating between business, legal
428 and individual incentives.
430 4.1. Generative Protocols vs. Contextual Threats
432 Privacy is not a binary state. Rather than operating either entirely
433 in private or entirely in public, individuals experience privacy
434 contextually, resulting in differing requirements for privacy
435 protection depending on the circumstance and the individual. On the
436 Internet, the contextual nature of privacy means that threats against
437 it can vary depending on the deployment scenario, the usage scenario,
438 the capabilities of different attackers, and the level of concern
439 that different kinds of attackers generate among different users.
441 Addressing the full waterfront of privacy threats within generative
442 protocols and tools is largely intractable. As a result, existing
443 privacy features developed at the network and application layers have
444 taken more targeted approaches. For example, privacy extensions for
445 stateless address autoconfiguration in IPv6 [RFC4941] support
446 addresses constructed dynamically rather than generating addresses
447 based on interface MAC addresses, which for most users are persistent
448 and unchangeable unique identifiers that could be used for long-term
449 tracking. While IPv6 privacy extensions provide important protection
450 against tracking and re-identification by remote endpoints, they do
451 not prevent -- and were not meant to prevent -- all parties from
452 being able to associate an IP address with a particular user. ISPs
453 and governments still have means to make such associations, and
454 remote endpoints have many other mechanisms at their disposal to
455 attempt to identify users persistently, albeit without using IPv6
456 addresses.
458 This kind of experience with developing privacy tools shows that
459 designing privacy features into systems and protocols requires a
460 clear understanding of the scope of the threats they are designed to
461 address. This scope is currently being debated in discussion about
462 developing "do not track" (DNT) mechanisms for the web and other
463 online contexts. A number of different approaches have been
464 proposed, including browser functionality to retain opt-out cookies,
465 an HTTP header that expresses the user's preference not to be
466 tracked, and a browser-based block list mechanism that prevents the
467 browser from communicating with tracking sites (for an overview, see
468 [I-D.cooper-web-tracking-opt-outs]). Regardless of the approach,
469 these mechanisms function based on some understanding of which
470 "tracking" users should be able to control, which in turn is based on
471 some notion of the threats presented by different kinds of tracking
472 conducted by different kinds of entities on the web. Should DNT
473 mechanisms apply to sites with which the user already has an
474 established relationship? Or sites that use only aggregate, non-
475 individualized data? Does tracking for fraud prevention or
476 customization present different threats than tracking for advertising
477 or marketing purposes? The answers to these questions will dictate
478 DNT design choices.
480 The space of privacy threats on the Internet may appear particularly
481 broad from a protocol design perspective because many of the
482 protocols in widest use are designed generically to support a variety
483 of applications and functionality. HTTP, for example, is used for a
484 wider variety of purposes than its original designers likely
485 anticipated; it is unsurprising that some of these purposes include
486 obtaining and using data about web users in ways that may be privacy-
487 infringing. It is unreasonable to ask protocol designers to mitigate
488 the potential privacy risks of every possible deployment that may
489 result from a particular protocol design; the key questions are about
490 how the responsibility for protecting against privacy intrusion
491 should be split between protocols, APIs, applications, and services
492 and which kinds of privacy features can best be implemented in each
493 place.
495 4.2. Tension Between Privacy Protection and Usability
497 The workshop discussions highlighted the tension between providing
498 privacy protections and maintaining usability. Tor [Tor] provides
499 some salient examples of this tradeoff. Tor seeks to provide
500 protection against network surveillance, but by lengthening the
501 routing path it may significantly increase round-trip time. Tor
502 obscures endpoint IP addresses, thus it also interferes with IP-based
503 geolocation. Web browsing using Tor is particularly challenging, as
504 much of Javascript, most browser plug-ins, and a number of other
505 browser-based features need to be blocked or overriden in order to
506 meet Tor's anonymity requirements. With Tor, privacy clearly comes
507 at a price.
509 Even less aggressive privacy features may come with usability
510 tradeoffs. One example is the blocking of HTTP referrer headers for
511 privacy protection reasons. Some sites provide a customized
512 experience to users based on the referring page, which means that
513 disabling referrer headers, as some browsers allow users to do, may
514 sacrifice user experience features on certain sites. (Whether users
515 understand this tradeoff is a separate question, see Section 3.5.)
517 The feature set that implementors choose to make available is often
518 reflective of the tension between usability and privacy. For
519 example, SIP supports S/MIME [RFC3261] to secure SIP request bodies,
520 but given its user experience impact, few implementations include
521 S/MIME support. Although usability challenges are generally thought
522 of as user-level issues that are out of scope for the IETF, to the
523 extent that they trickle down into implementation decisions, they are
524 highly relevant.
526 Although workshop participants reached few firm conclusions about how
527 to tackle usability issues arising from privacy features, the group
528 agreed that it may be beneficial for the W3C to do some more thinking
529 in this area, possibly toward the end of including usability
530 considerations in individual specifications. The challenge with such
531 an effort will be to provide useful guidance without being overly
532 prescriptive about how implementations should be designed.
534 4.3. Interaction Between Business, Legal and Technical Incentives
536 4.3.1. Role of Regulation
538 The Internet has sustained commercial content for decades. Many
539 services are offered at little or no cost in exchange for being able
540 to sell advertising or collect user data (or both). As the
541 commercial value of the web in particular has exploded in recent
542 years, the paradigm for regulating privacy has also begun to change,
543 albeit more slowly.
545 At the dawn of the commercial Internet, few web sites had written
546 privacy policies that explained what they did with user data. Under
547 regulatory pressure, sites began to document their data collection
548 and usage practices in publicly posted policies. These policies
549 quickly became lengthy legal documents that commercial sites could
550 use to limit their liability, often by disclosing every possible
551 practice that the site might engage in, rather than informing users
552 about the salient practices of relevance to them.
554 Because so many businesses are fueled by user data, any move to give
555 users greater control over their data -- whether by better informing
556 them about its use or providing tools and settings -- often requires
557 the force of regulatory influence to succeed. In recent years,
558 regulatory authorities have put pressure on companies to improve
559 their privacy disclosures by making them simpler, more concise, more
560 prominent, and more accessible (see the 2010 Federal Trade Commission
561 privacy report [FTC]). Certain companies and industry sectors have
562 responded by developing privacy icons, using short notices in
563 addition to privacy policies, and making the language they use to
564 describe privacy practices more accessible and easier to understand.
566 Regulators play an important role in shaping incentive structures.
567 Companies often seek a balance between acting to limit their
568 liability and pushing the envelope with respect to uses of consumer
569 data. If regulators take a strong stand against certain practices --
570 as, for example, European legislators have against cookies being set
571 without user consent [Directive] -- legitimate businesses will feel
572 compelled to comply. But where there is regulatory uncertainty,
573 business responses may differ according to different market
574 strategies. The variety of potential responses to the emerging
575 discussion about mechanisms to control web tracking demonstrate this
576 variation: some businesses will embrace support for enhanced user
577 control, others may restrict their offerings or charge fees if they
578 are unable to track users, and still others may elect to circumvent
579 any new mechanisms put in place. The abscence of regulatory pressure
580 tends to make the line between "good" and "bad" actors less evident.
582 4.3.2. P3P: A Case Study
584 That abscence of regulatory pressure revealed itself in the case of
585 P3P. The first version of P3P was standardized in the early 2000's,
586 when legalistic privacy policies were the norm and users had only
587 elementary controls over the data collected about them on the web.
588 P3P challenged that paradigm by providing a way for web sites to
589 express machine-readable privacy policies for browsers to vet and
590 possibly override according to the user's preference. The P3P policy
591 expression language was designed to allow sites to make complex
592 assertions about how they intended to make use of data related to
593 users.
595 The designers of Internet Explorer 6 made a crucial decision to only
596 allow sites to use third-party cookies if they had installed adequate
597 P3P policies. To avoid having their cookies blocked, most commercial
598 sites adopted some P3P policy, although many sites merely cut and
599 pasted from the example policies provided by the W3C. Today, large
600 numbers of sites are misrepresenting their privacy practices in their
601 P3P policies, but little has been done in response [Policies], and
602 browser support for P3P outside of IE is limited.
604 While theories abound to explain the current status of P3P
605 implementations, there is no doubt that the relationship between
606 regulatory and commercial incentives played a significant role. The
607 P3P policy expression language provided support for companies to be
608 able to express in granular detail how they handle user data, but the
609 companies had little reason to do so, preferring to protect
610 themselves from the liability associated with revealing potentially
611 unsavory practices. In theory the threat of regulatory backlash
612 could have served as an incentive to publish accurate P3P policies,
613 but at the time of P3P's release, there was little regulatory
614 interest in moving beyond long, legalistic privacy policies. Even
615 today, regulators are reluctant to bring enforcement actions against
616 companies with misleading policies, perhaps because their own
617 incentive structure compells them to focus on other, more prominent
618 matters.
620 The P3P experience is instructive in general for attempts at crafting
621 privacy features that require the active participation of both ends
622 of a communication. Actors that are meant to articulate their own
623 privacy preferences, whether they be companies or individuals,
624 require incentives to do so, as do those that are meant to process
625 and react to such preferences. For example, the IETF's GEOPRIV
626 architecture allows for expression of user preferences about location
627 information [RFC4119]. While users may have more incentive to
628 disclose their privacy preferences than companies did in the P3P
629 case, successful use of the GEOPRIV model will require endpoints that
630 consume location information to abide by those preferences, and in
631 certain contexts -- commerical or employment-related, for example --
632 they may be unwilling, or regulatory pressure may be required to spur
633 a change in practice.
635 It is clearly not the perogative of Internet protocol developers to
636 seek to change existing incentive structures. But acknowledging what
637 motivates businesses, individuals, and regulators is crucial to
638 determining whether new privacy technologies will succeed or fail.
640 5. Conclusions and Next Steps
642 5.1. IETF Outlook
644 The workshop demonstrated that the understanding of how to address
645 privacy within the Interent standards community is nascent. The IETF
646 faces particular challenges because IETF protocols generally do not
647 mandate implementation styles or pre-conceive particular deployment
648 contexts, making the space of potential privacy threats attributable
649 to any single protocol difficult to foresee at protocol design time.
651 Workshop participants nonetheless outlined a number of potential next
652 steps. Work has already begun to attempt to provide guidance to
653 protocol designers about the privacy impact of their specifications
654 [I-D.morris-privacy-considerations]. In refining this guidance, many
655 of the questions raised at the workshop will need to be confronted,
656 including those about how to properly model privacy threats against
657 generative protocols, how to anticipate privacy risks that have been
658 exposed in the previous design efforts, and how to document risks
659 that are more difficult to foresee and mitigate. Workshop
660 participants acknowledged that developing such guidance is likely
661 necessary if document authors are expected to incorporate "Privacy
662 Considerations" sections in their documents, but even with guidance
663 this is likely to be an uphill battle for many authors for some time
664 to come.
666 As preliminary steps, those with privacy expertise may seek to apply
667 the current guidance to existing IETF protocols. The security area
668 directors have also created a privacy directorate where privacy
669 reviews of documents coming before the IESG are being conducted.
671 Participants also expressed an interest in further pursuing a number
672 of the technical topics discussed at the workshop, including lessons
673 learned from the experience of Tor and the fingerprinting
674 implications of HTTP, TCP, SIP, and other IETF protocols. These and
675 other efforts may be explored within the IRTF in addition to or in
676 lieu of the IETF.
678 5.2. W3C Outlook
680 The W3C is likewise in a position of seeking a more comprehensive
681 approach to privacy within the SDO. Because the work of the W3C
682 operates within a more defined scope than that of the IETF -- namely,
683 the web -- the questions before the W3C tend to lie more in the space
684 of distinguishing between what can appropriately be accomplished
685 within W3C specifications and what should be left to individual
686 implementations, a theme that repeated itself again and again at the
687 workshop.
689 To further develop its approach to privacy, the W3C will investigate
690 an interest group to discuss privacy topics. Some potential topics
691 that emerged from the workshop include the fingerprinting impact of
692 W3C protocols, data minimization in APIs, dealing with referrer
693 header privacy leakage, developing privacy considerations for non-
694 browser-based protocols, and developing usability considerations as
695 part of specification design.
697 5.3. Other Future Work
699 The workshop covered a number of topics that may deserve further
700 exploration in the IETF, the W3C, and the privacy community at large.
701 These include development of privacy terminology; articulation of
702 privacy threat models; analysis and experimentation with "do not
703 track" mechanisms for the web; work on cross-site data sharing,
704 correlation, and linkability in web and non-web contexts; and
705 investigation of policy expression languages.
707 6. Acknowledgements
709 Thanks to Bernard Aboba, Nick Doty and Hannes Tschofenig for their
710 early reviews.
712 7. IANA Considerations
714 This memo includes no requests of IANA.
716 8. Security Considerations
718 Workshop participants discussed security aspects related to privacy,
719 acknowledging that while much of the standards community may have
720 once viewed most relevant privacy concerns as being encompassed by
721 security considerations, there is a growing realization of privacy
722 threats that lie outside the security realm. These include concerns
723 related to data minimization, identifiability, and secondary use.
724 Earlier security work provided minimal provision for privacy
725 protection (e.g., the definition of "privacy" in [RFC2828] and some
726 guidance about private information in [RFC3552]).
728 9. Informative References
730 [ALTO] IETF, "Application-Layer Traffic Optimization",
731 http://datatracker.ietf.org/wg/alto/charter/, 2011.
733 [Directive]
734 European Parliament and Council of the European Union,
735 "Directive 2009/136/EC of the European Parliament and of
736 the Council", http://eur-lex.europa.eu/LexUriServ/
737 LexUriServ.do?uri=OJ:L:2009:337:0011:01:EN:HTML,
738 September 2010.
740 [FTC] Federal Trade Commission Staff, "A Preliminary FTC Staff
741 Report on Protecting Consumer Privacy in an Era of Rapid
742 Change: A Proposed Framework for Businesses and
743 Policymakers",
744 http://www.ftc.gov/opa/2010/12/privacyreport.shtm,
745 December 2010.
747 [Geolocation]
748 Popescu, A., Ed., "Geolocation API Specification",
749 http://www.w3.org/TR/2010/CR-geolocation-API-20100907/,
750 September 2010.
752 [I-D.cooper-web-tracking-opt-outs]
753 Cooper, A. and H. Tschofenig, "Overview of Universal Opt-
754 Out Mechanisms for Web Tracking",
755 draft-cooper-web-tracking-opt-outs-00 (work in progress),
756 March 2011.
758 [I-D.morris-privacy-considerations]
759 Aboba, B., Morris, J., Peterson, J., and H. Tschofenig,
760 "Privacy Considerations for Internet Protocols",
761 draft-morris-privacy-considerations-03 (work in progress),
762 March 2011.
764 [Krishnamurthy07]
765 Krishnamurthy, B., Malandrino, D., and C. Wills,
766 "Measuring privacy loss and the impact of privacy
767 protection in web browsing. In Proceedings of the
768 Symposium on Usable Privacy and Security, pages 52-63,
769 Pittsburgh, PA USA, July 2007. ACM International
770 Conference Proceedings Series.",
771 http://www.cs.wpi.edu/~cew/papers/soups07.pdf, July 2007.
773 [Krishnamurthy09]
774 Krishnamurthy, B. and C. Wills, "Privacy diffusion on the
775 web: A longitudinal perspective. In Proceedings of the
776 World Wide Web Conference, pages 541-550, Madrid, Spain,
777 April 2009", http://www.cs.wpi.edu/~cew/papers/www09.pdf,
778 April 2009.
780 [P3P] Wenning, R., Ed. and M. Schunter, Ed., "The Platform for
781 Privacy Preferences 1.1 (P3P1.1) Specification",
782 http://www.w3.org/TR/P3P11/, November 2006.
784 [Panopticlick]
785 Electronic Frontier Foundation, "Panopticlick", 2011,
786 .
788 [Policies]
789 Leon, P., Cranor, L., McDonald, A., and R. McGuire, "Token
790 Attempt: The Misrepresentation of Website Privacy Policies
791 through the Misuse of P3P Compact Policy Tokens", http://
792 www.cylab.cmu.edu/research/techreports/2010/
793 tr_cylab10014.html, September 2010.
795 [RFC1543] Postel, J., "Instructions to RFC Authors", RFC 1543,
796 October 1993.
798 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
799 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
800 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
802 [RFC2778] Day, M., Rosenberg, J., and H. Sugano, "A Model for
803 Presence and Instant Messaging", RFC 2778, February 2000.
805 [RFC2828] Shirey, R., "Internet Security Glossary", RFC 2828,
806 May 2000.
808 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
809 A., Peterson, J., Sparks, R., Handley, M., and E.
810 Schooler, "SIP: Session Initiation Protocol", RFC 3261,
811 June 2002.
813 [RFC3323] Peterson, J., "A Privacy Mechanism for the Session
814 Initiation Protocol (SIP)", RFC 3323, November 2002.
816 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
817 Text on Security Considerations", BCP 72, RFC 3552,
818 July 2003.
820 [RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and
821 J. Polk, "Geopriv Requirements", RFC 3693, February 2004.
823 [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object
824 Format", RFC 4119, December 2005.
826 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy
827 Extensions for Stateless Address Autoconfiguration in
828 IPv6", RFC 4941, September 2007.
830 [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265,
831 April 2011.
833 [Tor] The Tor Project, Inc., "Tor", 2011,
834 .
836 [Workshop]
837 IAB, W3C, ISOC, MIT CSAIL, "Internet Privacy Workshop
838 2010", 2011, .
841 Appendix A. Workshop Materials
843 Main page: http://www.iab.org/activities/workshops/
844 internet-privacy-workshop-2010/
846 Slides: http://www.iab.org/activities/workshops/
847 internet-privacy-workshop-2010/slides/
849 Minutes: http://www.iab.org/activities/workshops/
850 internet-privacy-workshop-2010/minutes/
852 Position papers: http://www.iab.org/activities/workshops/
853 internet-privacy-workshop-2010/papers/
855 Appendix B. Workshop Participants
856 Fu-Ming Shih, MIT
858 Ian Jacobi, MIT
860 Steve Woodrow, MIT
862 Nick Mathewson, The Tor Project
864 Peter Eckersley, Electronic Frontier Foundation
866 John Klensin, IAB
868 Oliver Hanka, Technical University Munich
870 Alan Mislove, Northeastern University
872 Ashkan Soltani, FTC
874 Sam Hartman, Painless Security
876 Kevin Trilli, TRUSTe
878 Dorothy Gellert, InterDigital
880 Aaron Falk, Raytheon - BBN Technologies
882 Sean Turner, IECA
884 Wei-Yeh Lee, NAVTEQ
886 Chad McClung, The Boeing Company
888 Jan Seedorf, NEC
890 Dave Crocker, Brandenburg InternetWorking
892 Lorrie Cranor, Carnegie Mellon University
894 Noah Mendelsohn, W3C TAG Chair
896 Stefan Winter, RESTENA
898 Craig Wittenberg, Microsoft
900 Bernard Aboba, IAB/Microsoft
902 Heather West, Google
903 Blaine Cook, British Telecom
905 Kasey Chappelle, Vodafone Group
907 Russ Housley, IETF Chair/Vigil Security, LLC
909 Daniel Appelquist, Vodafone R&D
911 Olaf Kolkman, IAB Chair
913 Jon Peterson, IAB/NeuStar, Inc.
915 Balachander Krishnamurthy, AT&T Labs--Research
917 Marc Linsner, Cisco Systems
919 Jorge Cuellar, Siemens AG
921 Arvind Narayanan, Stanford University
923 Eric Rescorla, Skype
925 Cullen Jennings, Cisco
927 Christine Runnegar, Internet Society
929 Alissa Cooper, Center for Democracy & Technology
931 Jim Fenton, Cisco
933 Oshani Seneviratne, MIT
935 Lalana Kagal, MIT
937 Fred Carter, Information & Privacy Commissioner of Ontario, Canada
939 Frederick Hirsch, Nokia
941 Benjamin Heitmann, DERI, NUI Galway, Ireland
943 John Linn, RSA, The Security Division of EMC
945 Paul Trevithick, Azigo
947 Ari Schwartz, National Institute of Standards and Technology
949 David Evans, University of Cambridge
950 Nick Doty, UC Berkeley, School of Information
952 Sharon Paradesi, MIT
954 Jonathan Mayer, Stanford University
956 David Maher, Intertrust
958 Brett McDowell, PayPal
960 Leucio Antonio Cutillo, Eurecom
962 Susan Landau, Radcliffe Institute for Advanced Study, Harvard
963 University
965 Dave Crocker, Brandenburg InternetWorking
967 Christopher Soghoian, FTC In-house Technologist, Center for
968 Applied Cybersecurity Research, Indiana University
970 Trent Adams, Internet Society
972 Thomas Roessler, W3C
974 Karen O'Donoghue, ISOC
976 Hannes Tschofenig, IAB/Nokia Siemens Networks
978 Lucy Elizabeth Lynch, Internet Society
980 Karen Sollins, MIT
982 Tim Berners-Lee, W3C
984 Appendix C. Accepted Position Papers
986 1. Addressing the privacy management crisis in online social
987 networks by Krishna Gummadi, Balachander Krishnamurthy, and Alan
988 Mislove
990 2. Thoughts on Adding "Privacy Considerations" to Internet Drafts
991 by Alissa Cooper, and John Morris
993 3. Toward Objective Global Privacy Standards by Ari Schwartz
995 4. SocialKeys: Transparent Cryptography via Key Distribution over
996 Social Networks by Arvind Narayanan
998 5. Web Crawlers and Privacy: The Need to Reboot Robots.txt by
999 Arvind Narayanan and Pete Warden
1001 6. I Know What You Will Do Next Summer by Balachander Krishnamurthy
1003 7. An architecture for privacy-enabled user profile portability on
1004 the Web of Data by Benjamin Heitmann and Conor Hayes
1006 8. Addressing Identity on the Web by Blaine Cook
1008 9. Protection-by-Design: Enhancing ecosystem capabilities to
1009 protect personal information by Jonathan Fox and Brett McDowell
1011 10. Privacy-preserving identities for a safer, more trusted internet
1012 by Christian Paquin
1014 11. Why Private Browsing Modes Do Not Deliver Real Privacy by
1015 Christopher Soghoian
1017 12. Incentives for Privacy by Cullen Jennings
1019 13. Joint Privacy Workshop: Position Comments by D. Crocker by Dave
1020 Crocker
1022 14. Using properties of physical phenomena and information flow
1023 control to manage privacy by David Evans and David M. Eyers
1025 15. Privacy Approaches for Internet Video Advertising by Dave Maher
1027 16. Privacy on the Internet by Dorothy Gellert
1029 17. Can We Have a Usable Internet Without User Trackability? by Eric
1030 Rescorla
1032 18. Privacy by Design: The 7 Foundational Principles --
1033 Implementation and Mapping of Fair Information Practices by Fred
1034 Carter and Ann Cavoukian
1036 19. Internet Privacy Workshop Position Paper: Privacy and Device
1037 APIs by Frederick Hirsch
1039 20. Position Paper for Internet Privacy Workshop by Heather West
1041 21. I 'like' you, but I hate your apps by Ian Glazer
1043 22. Privicons: A approach to communicating privacy preferences
1044 between Users by E. Forrest and J. SchallabAP.ck
1046 23. Privacy Preservation Techniques to establish Trustworthiness for
1047 Distributed, Inter-Provider Monitoring by J. Seedorf, S.
1048 Niccolini, A. Sarma, B. Trammell, and G. Bianchi
1050 24. Trusted Intermediaries as Privacy Agents by Jim Fenton
1052 25. Protocols are for sharing by John Kemp
1054 26. On Technology and Internet Privacy by John Linn
1056 27. Do Not Track: Universal Web Tracking Opt-out by Jonathan Mayer
1057 and Arvind Narayanan
1059 28. Location Privacy Protection Through Obfuscation by Jorge Cuellar
1061 29. Everything we thought we knew about privacy is wrong by Kasey
1062 Chappelle and Dan Appelquist
1064 30. TRUSTe Position Paper by Kevin Trilli
1066 31. Position Paper: Incentives for Adoption of Machine-Readable
1067 Privacy Notices by Lorrie Cranor
1069 32. Facilitate, don't mandate by Ari Rabkin, Nick Doty and Deirdre
1070 K. Mulligan
1072 33. Location Privacy in Next Generation Internet Architectures by
1073 Oliver Hanka
1075 34. HTTPa: Accountable HTTP by Oshani Seneviratne and Lalana Kagal
1077 35. Personal Data Service by Paul Trevithick
1079 36. Several Pressing Problems in Hypertext Privacy by Peter
1080 Eckersley
1082 37. Adding Privacy in Existing Security Systems by Sam Hartman
1084 38. Mobility and Privacy by S. Brim, M. Linsner, B. McLaughlin, and
1085 K. Wierenga
1087 39. Saveface: Save George's faces in Social Networks where Contexts
1088 Collapse by Fuming Shih and Sharon Paradesi
1090 40. eduroam -- a world-wide network access roaming consortium on the
1091 edge of preserving privacy vs. identifying users by Stefan
1092 Winter
1094 41. Effective Device API Privacy: Protecting Everyone (Not Just the
1095 User) by Susan Landau
1097 42. Safebook: Privacy Preserving Online Social Network by L. Antonio
1098 Cutillo, R. Molva, and M. Onen
1100 Author's Address
1102 Alissa Cooper
1103 CDT
1105 Email: acooper@cdt.org