RFC 6462

Report from the Internet Privacy Workshop

📅 published January 2012, from ietf

Report from the Internet Privacy Workshop 🎀

Okay bestie, so this is RFC 6462 📜, and it's the IAB's report on the Internet Privacy Workshop. The author is A. Cooper, it's an Informational doc (so not a standard, just a record 💅), and it came out in January 2012. The ISSN is 2070-1721. There's no Obsoletes or Updates line in the title block, so nothing gets replaced or changed by it. Let's go! 🦋

Abstract 💖

So 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 showed some of the big, fundamental challenges in designing, deploying, and analysing privacy-protective Internet protocols and systems 🔍. The community is still pretty far from figuring out how to systematically handle privacy in Internet standards work, but the participants came up with a bunch of possible next steps ✨.

For the IETF, the ideas were: create a privacy directorate to review Internet-Drafts, keep working on documenting privacy considerations for protocol developers, and start some exploratory efforts on fingerprinting and anonymized routing 🧚. For the W3C, the possible action items were investigating a privacy interest group and writing guidance about fingerprinting, referrer headers, data minimisation in APIs, usability, and general considerations for non-browser-based protocols 💜.

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 🙈.

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 💅.

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 ✨.

Copyright Notice ©️

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 🫶.

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

1. Introduction ✨

So 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) all about Internet privacy [Workshop] 🎀. The whole point was to help the Internet community get a handle on what it actually means for Internet-based systems to respect privacy 🔍. They wanted to know how these systems have been designed (or could be), how the web's relationship with the broader Internet affects privacy, and what specific work the IETF and/or the W3C might take on to tackle Internet privacy 💅. If you want the rundown of topics, that's in Section 2 💖.

The discussions were honestly so complex, like, the privacy problem is broad and touches everything 😭. Across tons of different applications, the same fundamental design challenges kept popping up: fingerprinting is getting easier for users, devices, and applications; information leaks in ways nobody planned for; it's hard to tell first parties from third parties; system dependencies create complications; and people just aren't very aware of privacy risks and tradeoffs 👀 (see Section 3). Participants also spotted barriers to actually deploying and analysing privacy-minded protocols and systems 🚧. Those were: using generic protocols and tools to defend against context-specific threats is hard, privacy protection and usability are in tension, and it's tricky to navigate business, legal, and individual incentives all at once 🌀 (see Section 4).

Privacy challenges totally outnumber solutions, but the workshop found a few concrete preliminary steps that standards organisations can take to help protect user privacy in future standards and systems 👑. For the IETF, those included creating a privacy directorate to review Internet-Drafts, doing more work on documenting privacy considerations for protocol developers, and starting a number of exploratory efforts on fingerprinting and anonymized routing 🧚. Potential action items for the W3C were investigating the formation of a privacy interest group and formulating guidance about fingerprinting, referrer headers, data minimisation in APIs, usability, and general considerations for non-browser-based protocols 💜. The next steps and workshop outcomes are covered in Section 5 🦋.

2. Workshop Overview 🧚

The workshop looked at both the current technical challenges to protecting privacy and the ways standards organisations can help address those challenges 🌸. Links to the workshop materials are listed in Appendix A 📎.

2.1. Technical Discussion 🌈

The workshop dug into privacy challenges across three technical domains: the network level, the browser level, and cross-site data exchanges 🔥. Example technologies were highlighted in each area to get the conversation going ✨.

At the network level, people talked about IP address hiding in mobility protocols, privacy extensions for IPv6 addressing [RFC4941], and onion routing 🧅. The discussion about the Tor project [Tor] was particularly insightful 🙌. So Tor is a circuit-based, low-latency communication service designed to anonymise protocols that run over TCP 🛡️. End hosts in a Tor exchange choose a path through the network and build a circuit, where each "onion router" in the path only knows its predecessor and successor, and no other nodes in the circuit 🫣. Each onion router in the path unwraps and decrypts received information before relaying it downstream 🔐.

For Tor to give anonymity guarantees, Tor nodes need to be able to strip out information elements that could be used to re-identify users over time 🕵️. For example, web technologies like cookies, large portions of JavaScript, and almost all browser plug-ins (including Flash) need to be disabled to keep Tor's privacy properties during web use. The catch is that this really hampers usability 😩.

At the browser level, the discussion started with 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 behaviour from others who use 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 🚫. There's some evidence, though, that users don't really understand the difference between protection from snooping among people who share a device and these other forms of tracking 🤷‍♀️. The specific protections private browsing modes offer also vary from browser to browser, which creates privacy loopholes in some cases 🕳️.

The browser discussion also covered proposals for "Do Not Track" (DNT) technologies built into browsers, to give users a simple way to opt out of web tracking 🙅‍♀️. At the time of the workshop, various technical proposals had been designed to let users indicate their preference to opt out, or to block communication with certain web sites altogether 🧱. The discussions showed a real lack of agreement about what type of tracking is acceptable, which technical mechanisms would work best for different scenarios, and how those mechanisms would interact with other parts of privacy protection (such as notices to users) 😬.

The cross-site data-sharing discussion focused on current uses of Open Authorization (OAuth) (with Facebook Connect, for example) 🔑. Improvements have been made in getting user consent for sharing data between sites, but challenges remain around data minimisation, ease of use, hidden sharing of data, and centralisation of identity information 💀.

2.2. SDO Discussion 🎀

okay so the group talked about how the IETF and the W3C have each tried to handle privacy over the years 💅 Individual IETF protocol efforts have gone after certain privacy threats. Protocol designers have taken steps to cut down how identifiable someone can get from using a protocol, like the IPv6 privacy extensions case [RFC4941]. Protocols built to rely on intermediaries have tried to limit the user data exposed in transit, most notably in SIP [RFC3323]. Protocol architectures used for interpersonal exchange have aimed to give users granular control over their info, including presence [RFC2778] and geolocation information [RFC3693]. Squaring privacy with usability is still a work in progress 🫶 The ALTO working group [ALTO], for example, is figuring out how to balance what users and network operators need in order to share data with each other about content preferences and network topologies, against real worries about revealing too much of either kind of info.

The IETF also has experience building a culture of security awareness 🔥 Starting with [RFC1543], RFCs were required to contain a Security Considerations section. But that simple rule didn't instantly turn into the super intense security consciousness the IETF has now 😭 It took years and a LOT of effort to get here. Now there's a more systematic approach that uses a bunch 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.

The W3C has a bunch of past efforts to draw on too 🌈 One of the earliest large-scale standards efforts aimed at better web privacy was the Platform for Privacy Preferences [P3P]. The idea behind P3P was that web sites would 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 for sites to make complex assertions about how they meant to use data related to users, but market developments have created a number of challenges with the policies that got deployed.

More recent W3C work centered on which privacy features were appropriate to include 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 lets users revoke that consent. But decisions about retention, secondary use, and data minimization are left up to individual web sites and apps. The geolocation effort and the P3P experience both raise questions about how to navigate usability, regulation, business incentives, and other stuff that normally sits outside the scope of standards development organization (SDO) work 💀

3. Design Challenges ✨

Workshop discussions surfaced a bunch of key issues that make designing privacy-sensitive protocols and systems hard: the increasing ease of user/device/application fingerprinting, unforeseen information leakage, difficulty telling first parties apart from third parties, complications from system dependencies, and the lack of transparency and user awareness of privacy risks and tradeoffs.

3.1. Ease of Fingerprinting 🕵️

Internet apps and protocols now share so many unique identifiers and other bits of info during normal operation that it's getting easier and easier for remote nodes to create unique device or application fingerprints and re-identify the same devices or apps over time [Panopticlick]. Hardware identifiers, IP addresses, transport protocol parameters, cookies, other forms of web storage, and a vast array of browser-based info may be routinely shared as users browse the web. The ease of fingerprinting is a big challenge for any app that wants to guarantee anonymity or unlinkability (like [Tor], which uses onion routing to strip out data that identifies communications endpoints).

In lots of cases, the info that can fingerprint a device wasn't originally shared for that purpose. Identifiers and other info get provided to support some other functionality (like IP addresses being shared so packets can be routed), and may incidentally be used to fingerprint. That makes preventing fingerprinting tricky, because each app or protocol likely needs its own identifiers and info to function.

Also, some services are increasingly relying on fingerprinting to detect fraud or provide customized content, for example. Finding privacy-friendly substitutes for fingerprinting will only get harder as these services become more entrenched (see Section 4.3).

The space of fingerprinting mitigations still needs more exploring 🔍 For example, workshop participants talked about using JavaScript queries to get a browser's (often super unique) font list, and about the tradeoffs of browsers instead (or additionally) supporting a small subset of fonts to reduce browser identifiability. As with lots of other privacy features, a restriction like that is a privacy-versus-usability tradeoff, and for fingerprinting writ large it may be hard to reach consensus on which mitigations balance both values well. As a first step, the IETF may consider documenting the fingerprinting implications for widely used IETF protocols (TCP, HTTP, SIP, etc.).

3.2. Information Leakage 🫣

Internet protocols and services tend to leak info in ways nobody foresaw 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 as Referer in the original specification) lets a web site find out the URI of the resource that referred the user to it. Referrer headers give sites valuable insight into where their users come from, but they can also leak sensitive info (search terms or user IDs, for example), because URI strings on the web often contain that info. The infrastructure of an individual site is often designed only to make the site itself work, and embedding search terms or other user-specific info 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 inside.

Using URIs for authentication of identity or capabilities can run into the same kinds of problems. A "possession model," where any user holding an authentication or capability URI can get access to a resource, is only suitable in situations with some means of controlling URI distribution, and it can lead to wide leakage when used on the open web 💀

3.3. Differentiating between First and Third Parties 🍓

Distinguishing "first-party" interactions from "third-party" ones is important for understanding the implications of data collection, sharing, and use that happen during normal web use. Unfortunately, the traditional meanings of these concepts don't always match up with user expectations or evolving web tech. Traditionally, "first party" has referred to the domain of a web site to which a user agent directs an explicit request on behalf of a user. "Third party" has referred to the domain of a web resource that a user agent requests as a result of a first-party request, where the third-party resource is hosted at a different domain from the first-party domain.

This first/third divide is partly a result of long-standing user agent practices for handling HTTP cookies. Typically, HTTP cookies are only returned 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 first-party versus third-party split also shows up in browser cookie controls: major web browsers all offer distinct first-party cookie settings and third-party cookie settings.

But a user's perception or expectation of the difference between a "first party" and a "third party" may not fit neatly into these distinctions. Users may expect content hosted on a first-party subdomain, but provided or used by a third party, to be treated as third-party content, but browsers often treat it as first-party content. Flip it around: when third-party content comes from a source the user has an established relationship with -- like the Facebook "Like" button or other social widgets -- users may consider their interaction with it a desirable first-party interaction, even though the content is hosted on a third-party domain.

Handling these expectations programmatically is hard, since the same identifier structures (domains, subdomains) can map 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 allowed by each party they run into on the web isn't practical. Web and browser developers are actively looking for novel ways to tackle this challenge, but there are few clear-cut solutions.

3.4. Lack of Transparency and User Awareness 👀

There's no question that users don't fully understand how their info is used, or what the tradeoffs are between having their data collected and accessing services at little or no cost. Much of the tracking 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 (like data retention lifetimes). Even when web tracking comes with some visual indication -- a highly targeted Gmail ad or the Facebook "Like" button, for example -- users often don't realize it's happening.

Efforts abound to present info about data collection and usage in a more digestible way. P3P was one early effort, but because it sought to support the vast expanse of potential policies companies may have, it got more complex 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 to indicate that tracking is taking place ✨🦋✨

4. Deployment and Analysis Challenges ✨

okay so bestie, the workshop folks spotted a bunch of roadblocks 🚧 that keep privacy tech from actually getting deployed, and also make it hard to check whether a system is actually private. the big ones were: using generic protocols and tools to fight context-specific threats (super hard 😩), the tension between privacy and usability, and trying to juggle business, legal, and individual incentives all at once. it's giving complicated, but we're going to unpack it 💅

4.1. Generative Protocols vs. Contextual Threats 🦋

privacy is not a light switch, babe. it's not all-private or all-public. people experience privacy in context, so what they need depends on the situation and on the person 🌸 on the internet, that means the threats can look totally different depending on the deployment, how it's actually used, what different attackers can do, and how worried different users are about different kinds of attackers 💜

covering every privacy threat with generic protocols and tools is basically impossible 💀 so the features we already have at the network and application layers have gone for more targeted fixes. like, privacy extensions for stateless address autoconfiguration in IPv6 [RFC4941] build addresses dynamically instead of making them from interface Media Access Control (MAC) addresses. for most users, those MAC addresses are persistent, unchangeable unique identifiers that could be used for long-term tracking 😭 the IPv6 privacy extensions are a big deal for stopping tracking and re-identification by remote endpoints, but they do NOT stop all parties from linking an IP address to a particular user (and they were never supposed to) 🙈 ISPs and governments still have ways to make that link, and remote endpoints have plenty of other ways to identify users over time, just without using IPv6 addresses.

this whole experience teaches us that if you want privacy features built into systems and protocols, you need a super clear idea of which threats they're meant to handle 🎯 that scope is literally being argued about right now in the "Do Not Track" (DNT) conversation for the web and other online stuff 🍓 people have proposed a bunch of approaches: browsers keeping opt-out cookies, an HTTP header that says "don't track me" as a user preference, and a browser-based block list that stops the browser from talking to tracking sites (see [OptOuts] for an overview). no matter which one you pick, they all rely on some idea of which "tracking" users should be able to control. and that idea depends on what threats different kinds of tracking, run by different kinds of entities, actually pose on the web 🧐

the questions are kind of spicy: should DNT apply to sites where the user already has an established relationship? what about sites that only use aggregate, non-individualized data? does tracking for fraud prevention or customization hit differently than tracking for advertising or marketing? the answers to all of this are going to decide the DNT design choices ✨

the privacy threat space can look especially huge from a protocol design point of view, because a lot of the most-used protocols are built generically to support all kinds of apps and features 🧚 HTTP is a great example. it gets used for way more things than its original designers probably expected, so of course some of those uses involve getting and using data about web users in ways that invade privacy 😬 it's just not fair to expect protocol designers to fix the privacy risk of every possible deployment that could come out of a protocol design 🙅‍♀️ the real questions are how the job of protecting privacy should be split up between protocols, APIs, applications, and services, and which kinds of privacy features work best in each spot 👑

4.2. Tension between Privacy Protection and Usability 🎀

the workshop talks kept coming back to the tug-of-war between privacy protections and usability 🫶 Tor [Tor] is the queen of showing this tradeoff. it's designed to protect against network surveillance, but by making the routing path longer, it can seriously increase round-trip time 🐢 Tor also hides endpoint IP addresses, which means it gets in the way of IP-based geolocation. browsing the web over Tor is especially hard, because most browser plug-ins, a lot of JavaScript, and a bunch of other browser features have to be blocked or overridden to meet Tor's anonymity requirements 😩 with Tor, privacy clearly comes at a price 💸

even less aggressive privacy features come with usability tradeoffs. blocking HTTP referrer headers for privacy reasons is one example 🙈 some sites give users a customized experience based on the page they came from, so turning off referrer headers (which some browsers let users do) might cost certain sites their user experience features. the tricky part is that privacy decisions are super nuanced. how do you make users understand the privacy tradeoffs of blocking HTTP referrer headers when the effects change from site to site, or when there's barely any UI space to explain it? even seemingly simple controls, like private browsing, aren't well understood 🤷‍♀️

the features implementors choose to offer often show this same tension between usability and privacy 💅 for example, SIP [RFC3261] supports Secure/Multipurpose Internet Mail Extensions (S/MIME) to secure SIP request bodies, but because of how much it hurts the user experience, very few implementations include S/MIME support 😭 usability challenges are usually treated as user-level issues that are out of scope for the IETF, but when they trickle down into implementation decisions, they are super relevant 🔥

the workshop didn't reach many firm conclusions on how to tackle usability issues that come with privacy features 🥺 still, the group agreed it might be worth the W3C doing more thinking here, possibly with the goal of including usability considerations in individual specifications 🌈 the catch is giving useful guidance without being overly prescriptive about how implementations should be designed 🧁

4.3. Interaction between Business, Legal, and Technical Incentives 💜

4.3.1. Role of Regulation 👑

the Internet has been running on commercial content for decades 💰 a lot of services are free or nearly free because they can sell ads or collect user data (or both) 🛍️ as the commercial value of the web has exploded in recent years, the way we regulate privacy has started to shift too, just more slowly 🐌

at the start of the commercial Internet, hardly any websites had written privacy policies explaining what they did with user data 📜 under regulatory pressure, sites started publishing their data collection and usage practices. those policies quickly turned into long legal documents that companies used to limit their liability, often by listing every possible practice the site might do, instead of telling users about the practices that actually matter to them 🙃

because so many businesses run on user data, any move to give users more control over their data (whether by informing them better about its use or by offering tools and settings) usually needs regulatory force to succeed ⚖️ in recent years, regulators have pushed companies to improve privacy disclosures by making them simpler, more concise, more prominent, and more accessible (see the 2010 Federal Trade Commission privacy report [FTC]) 📣 some companies and industries have responded with privacy icons, short notices alongside privacy policies, and clearer language for describing their privacy practices ✨

regulators are a huge part of shaping incentive structures 🧠 companies often try to balance limiting their liability with pushing the envelope on how they use consumer data 🎢 when regulators take a strong stand against certain practices, legitimate businesses feel compelled to comply. for example, European legislators took a strong stand against cookies being set without user consent [Directive] 🍪 but where regulatory uncertainty exists, businesses respond in different ways depending on their market strategies 🤔 the range of responses to the emerging discussion about mechanisms for controlling web tracking shows this variation: some businesses will embrace better user control, some may restrict what they offer or charge fees if they can't track users, and others may choose to get around any new mechanisms that get put in place 🙄 without regulatory pressure, the line between "good" and "bad" actors tends to get blurry 🌫️

4.3.2. P3P: A Case Study of the Importance of Incentives 🍓

okay so this is the tea ☕ the lack of regulatory pressure literally showed up in the case of P3P 💀. P3P was standardized in the early 2000s, back when legalistic privacy policies were the norm and users had only basic controls over the data collected about them on the web. P3P was giving main character energy ✨ because it let websites express machine-readable privacy policies that browsers could check and possibly override based on the user's preference 🫶. The P3P policy expression language was built so sites could make complex claims about how they planned to use data related to users 🧚.

Internet Explorer 6's designers made a crucial call 👑: they only allowed sites to use third-party cookies if the sites had installed adequate P3P policies. So to avoid getting their cookies blocked, most commercial sites adopted some P3P policy 😭. Lowkey though, many of them just cut and pasted from the example policies the W3C provided 🙈. Today, a lot of sites are misrepresenting their privacy practices in their P3P policies, and little has been done about it [Policies]. Browser support for P3P outside of IE is also limited 🥀.

There are a bunch of theories about why P3P ended up like this, but it's giving that the relationship between regulatory and commercial incentives played a big role 💅. The P3P language let companies explain in granular detail how they handle user data, but they had little reason to do it. They were more into protecting themselves from liability for revealing potentially unsavory practices 💀. In theory, the threat of regulatory backlash could have pushed companies to publish accurate P3P policies, but when P3P came out, regulators weren't really interested in moving past long, legalistic privacy policies 📜. Even now, regulators are reluctant to bring enforcement actions against companies with misleading policies. Maybe that's because their own incentive structure pushes them to focus on other, more prominent matters 🫠.

The P3P experience is a super useful lesson for any privacy feature that needs both ends of a communication to actively take part 🎀. Actors who are supposed to state their own privacy preferences need incentives to do it, whether they're companies or individuals. The same goes for the actors who are supposed to process and react to those preferences 🧚. For example, the IETF's GEOPRIV architecture lets people express preferences about location information [RFC4119] 📍. Users may be more motivated to share their privacy preferences than companies were in the P3P case 🌸. But for GEOPRIV to work, endpoints that consume location information have to abide by those preferences. In certain contexts, like commercial or employment-related ones, they might be unwilling to do so, or regulatory pressure might be needed to spark a change in practice 😤.

It's clearly not the job of Internet protocol developers to try to change existing incentive structures 🙅‍♀️. But understanding what motivates businesses, individuals, and regulators is crucial for figuring out whether new privacy technologies will succeed or flop 🦋.

5. Conclusions and Next Steps 🌈

5.1. IETF Outlook 🔭

okay real talk: the workshop showed that the standards community's understanding of how to handle privacy is still in its baby era 🍼. The IETF has particular challenges here. IETF protocols generally don't mandate implementation styles or come with pre-conceived deployment contexts, so it's really hard to foresee which privacy threats could be attributed to any single protocol at design time 🥺.

Workshop participants still came up with a bunch of potential next steps 🪄. Work has already started on guidance for protocol designers about the privacy impact of their specifications [PrivCons] 💖. As that guidance gets refined, a lot of the questions raised at the workshop will need answers 🙋‍♀️. These include how to properly model privacy threats against generic protocols, how to anticipate privacy risks that were exposed in earlier design efforts, and how to document risks that are harder to foresee and mitigate 🔍. Participants also agreed that developing this guidance is likely necessary if document authors are expected to include "Privacy Considerations" sections in their documents. Even with guidance, though, it's going to be an uphill battle for many authors for quite a while 😩.

As preliminary steps, people with privacy expertise may try applying 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 📋.

Participants were also into digging deeper into a bunch of the technical topics from the workshop 🤓. That includes 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 instead of the IETF 🌸.

5.2. W3C Outlook 🕸️

the W3C is also on a quest for a more comprehensive approach to privacy within its SDO 💜. The W3C's work operates within a more defined scope than the IETF's, namely the web. So the questions in front of the W3C tend to be more about figuring out what can appropriately be accomplished within W3C specifications, and what should be left to individual implementations. That theme kept coming up again and again at the workshop 🔁.

To keep developing its approach to privacy, the W3C will look into forming an interest group to discuss privacy topics 🫧. Some potential topics that came out of 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 🎀.

5.3. Other Future Work 🔮

The workshop covered a bunch of topics that might deserve further exploration in the IETF, the W3C, and the privacy community at large 💅. These include developing privacy terminology, articulating privacy threat models, analyzing and experimenting with "Do Not Track" mechanisms for the web, and working on cross-site data sharing, correlation, and linkability in web and non-web contexts. Investigating policy expression languages is on the list too 🧩.

6. Acknowledgements 🫶

Huge thanks to Bernard Aboba, Nick Doty, and Hannes Tschofenig for their early reviews 💖✨.

7. Security Considerations 🔐

okay this part is SO important 😱 Workshop participants discussed security aspects related to privacy. While much of the standards community may once have viewed most relevant privacy concerns as being covered by security considerations, there's a growing realization that privacy threats exist outside the security realm 🚨. These include concerns related to data minimization, identifiability, and secondary use 👀. Earlier security work gave minimal provision for privacy protection. For example, there's the definition of "privacy" in [RFC2828], and some guidance about private information in [RFC3552] 📚.

8. Informative References ✨

okay bestie, this is the reading list 📚 every single source the doc leans on, so I'm keeping all the details exact 🫶

[ALTO] IETF, "Application-Layer Traffic Optimization (alto)", 2011, <http://datatracker.ietf.org/wg/alto/charter/>.
[Directive] European Parliament and Council of the European Union, "Directive 2009/136/EC of the European Parliament and of the Council", November 2009, <http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=OJ:L:2009:337:0011:01:EN:HTML>.
[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>.
[Geolocation] Popescu, A., Ed., "Geolocation API Specification", September 2010, <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>.
[OptOuts] Cooper, A. and H. Tschofenig, "Overview of Universal Opt-Out Mechanisms for Web Tracking", Work in Progress, March 2011.
[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/>.
[Panopticlick] Electronic Frontier Foundation, "Panopticlick", 2011, <http://panopticlick.eff.org/>.
[Policies] Leon, P., Cranor, L., McDonald, A., and R. McGuire, "Token Attempt: The Misrepresentation of Website Privacy Policies through the Misuse of P3P Compact Policy Tokens", September 2010, <http://www.cylab.cmu.edu/research/techreports/2010/tr_cylab10014.html>.
[PrivCons] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., and J. Morris, "Privacy Considerations for Internet Protocols", Work in Progress, October 2011.
[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>.
[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>.
[RFC1543] Postel, J., "Instructions to RFC Authors", RFC 1543, October 1993.
[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.
[RFC2778] Day, M., Rosenberg, J., and H. Sugano, "A Model for Presence and Instant Messaging", RFC 2778, February 2000.
[RFC2828] Shirey, R., "Internet Security Glossary", RFC 2828, May 2000.
[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.
[RFC3323] Peterson, J., "A Privacy Mechanism for the Session Initiation Protocol (SIP)", RFC 3323, November 2002.
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, July 2003.
[RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J. Polk, "Geopriv Requirements", RFC 3693, February 2004.
[RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object Format", RFC 4119, December 2005.
[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 4941, September 2007.
[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, April 2011.
[Tor] The Tor Project, Inc., "Tor", 2011, <https://www.torproject.org/>.
[Workshop] IAB, W3C, ISOC, MIT CSAIL, "Internet Privacy Workshop 2010", 2011, <http://www.iab.org/activities/workshops/internet-privacy-workshop-2010/>.

Appendix A. Workshop Materials 🎀

the workshop receipts, all the links you could want 🦋

Appendix B. Workshop Participants 🌸

the squad that showed up 🫶

Fu-Ming Shih, MIT
Ian Jacobi, MIT
Steve Woodrow, MIT
Nick Mathewson, The Tor Project
Peter Eckersley, Electronic Frontier Foundation
John Klensin, IAB
Oliver Hanka, Technical University Munich
Alan Mislove, Northeastern University
Ashkan Soltani, FTC
Sam Hartman, Painless Security
Kevin Trilli, TRUSTe
Dorothy Gellert, InterDigital
Aaron Falk, Raytheon - BBN Technologies
Sean Turner, IECA
Wei-Yeh Lee, NAVTEQ
Chad McClung, The Boeing Company
Jan Seedorf, NEC
Dave Crocker, Brandenburg InternetWorking
Lorrie Cranor, Carnegie Mellon University
Noah Mendelsohn, W3C TAG Chair
Stefan Winter, RESTENA
Craig Wittenberg, Microsoft
Bernard Aboba, IAB/Microsoft
Heather West, Google
Blaine Cook, British Telecom
Kasey Chappelle, Vodafone Group
Russ Housley, IETF Chair/Vigil Security, LLC
Daniel Appelquist, Vodafone R&D
Olaf Kolkman, IAB Chair
Jon Peterson, IAB/NeuStar, Inc.
Balachander Krishnamurthy, AT&T Labs--Research
Marc Linsner, Cisco Systems
Jorge Cuellar, Siemens AG
Arvind Narayanan, Stanford University
Eric Rescorla, Skype
Cullen Jennings, Cisco
Christine Runnegar, Internet Society
Alissa Cooper, Center for Democracy & Technology
Jim Fenton, Cisco
Oshani Seneviratne, MIT
Lalana Kagal, MIT
Fred Carter, Information & Privacy Commissioner of Ontario, Canada
Frederick Hirsch, Nokia
Benjamin Heitmann, DERI, NUI Galway, Ireland
John Linn, RSA, The Security Division of EMC
Paul Trevithick, Azigo
Ari Schwartz, National Institute of Standards and Technology
David Evans, University of Cambridge
Nick Doty, UC Berkeley, School of Information
Sharon Paradesi, MIT
Jonathan Mayer, Stanford University
David Maher, Intertrust
Brett McDowell, PayPal
Leucio Antonio Cutillo, Eurecom
Susan Landau, Radcliffe Institute for Advanced Study, Harvard University
Christopher Soghoian, FTC In-house Technologist, Center for Applied Cybersecurity Research, Indiana University
Trent Adams, Internet Society
Thomas Roessler, W3C
Karen O'Donoghue, ISOC
Hannes Tschofenig, IAB/Nokia Siemens Networks
Lucy Elizabeth Lynch, Internet Society
Karen Sollins, MIT
Tim Berners-Lee, W3C

Appendix C. Accepted Position Papers 💜

every paper that got the green light, no cap ✨

"Addressing the privacy management crisis in online social networks" by Krishna Gummadi, Balachander Krishnamurthy, and Alan Mislove
"Thoughts on Adding "Privacy Considerations" to Internet Drafts" by Alissa Cooper and John Morris
"Toward Objective Global Privacy Standards" by Ari Schwartz
"SocialKeys: Transparent Cryptography via Key Distribution over Social Networks" by Arvind Narayanan
"Web Crawlers and Privacy: The Need to Reboot Robots.txt" by Arvind Narayanan and Pete Warden
"I Know What You Will Do Next Summer" by Balachander Krishnamurthy
"An architecture for privacy-enabled user profile portability on the Web of Data" by Benjamin Heitmann and Conor Hayes
"Addressing Identity on the Web" by Blaine Cook
"Protection-by-Design: Enhancing ecosystem capabilities to protect personal information" by Jonathan Fox and Brett McDowell
"Privacy-preserving identities for a safer, more trusted internet" by Christian Paquin
"Why Private Browsing Modes Do Not Deliver Real Privacy" by Christopher Soghoian
"Incentives for Privacy" by Cullen Jennings
"Joint Privacy Workshop: Position Comments by D. Crocker" by Dave Crocker
"Using properties of physical phenomena and information flow control to manage privacy" by David Evans and David M. Eyers
"Privacy Approaches for Internet Video Advertising" by Dave Maher
"Privacy on the Internet" by Dorothy Gellert
"Can We Have a Usable Internet Without User Trackability?" by Eric Rescorla
"Privacy by Design: The 7 Foundational Principles -- Implementation and Mapping of Fair Information Practices" by Fred Carter and Ann Cavoukian
"Internet Privacy Workshop Position Paper: Privacy and Device APIs" by Frederick Hirsch
"Position Paper for Internet Privacy Workshop" by Heather West
"I 'like' you, but I hate your apps" by Ian Glazer
"Privicons: A approach to communicating privacy preferences between Users" by E. Forrest and J. Schallabock
"Privacy Preservation Techniques to establish Trustworthiness for Distributed, Inter-Provider Monitoring" by J. Seedorf, S. Niccolini, A. Sarma, B. Trammell, and G. Bianchi
"Trusted Intermediaries as Privacy Agents" by Jim Fenton
"Protocols are for sharing" by John Kemp
"On Technology and Internet Privacy" by John Linn
"Do Not Track: Universal Web Tracking Opt-out" by Jonathan Mayer and Arvind Narayanan
"Location Privacy Protection Through Obfuscation" by Jorge Cuellar
"Everything we thought we knew about privacy is wrong" by Kasey Chappelle and Dan Appelquist
"TRUSTe Position Paper" by Kevin Trilli
"Position Paper: Incentives for Adoption of Machine-Readable Privacy Notices" by Lorrie Cranor
"Facilitate, don't mandate" by Ari Rabkin, Nick Doty, and Deirdre K. Mulligan
"Location Privacy in Next Generation Internet Architectures" by Oliver Hanka
"HTTPa: Accountable HTTP" by Oshani Seneviratne and Lalana Kagal
"Personal Data Service" by Paul Trevithick
"Several Pressing Problems in Hypertext Privacy" by Peter Eckersley
"Adding Privacy in Existing Security Systems" by Sam Hartman
"Mobility and Privacy" by S. Brim, M. Linsner, B. McLaughlin, and K. Wierenga
"Saveface: Save George's faces in Social Networks where Contexts Collapse" by Fuming Shih and Sharon Paradesi
"eduroam -- a world-wide network access roaming consortium on the edge of preserving privacy vs. identifying users" by Stefan Winter
"Effective Device API Privacy: Protecting Everyone (Not Just the User)" by Susan Landau
"Safebook: Privacy Preserving Online Social Network" by L. Antonio Cutillo, R. Molva, and M. Onen

Author's Address ✨

okay bestie, this is the last stop 🧚 the author's contact info! Alissa Cooper, who wrote this whole thing, is at CDT, and you can find her here 💌

Alissa Cooper
CDT
1634 I Street NW, Suite 1100
Washington, DC  20006
USA

EMail: acooper@cdt.org
URI:   http://www.cdt.org/

that's the whole doc, babe! 🎀 you made it through all six parts 😭👑

📦 where this page comes from

ietf: rfc6462 2012-01
💖 girlified by claude-haiku-5-5 on 2026-10-17: a language model's rewrite of the original, under its terms