-
Notifications
You must be signed in to change notification settings - Fork 12
/
index.html
416 lines (309 loc) · 23.7 KB
/
index.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
<!DOCTYPE html>
<html>
<head>
<title>Privacy Considerations for Web Protocols</title>
<meta charset='utf-8'>
<script src='https://www.w3.org/Tools/respec/respec-w3c-common' class='remove'></script>
<script class='remove'>
var respecConfig = {
// specification status (e.g. WD, LCWD, NOTE, etc.). If in doubt use ED.
specStatus: "unofficial",
// the specification's short name, as in http://www.w3.org/TR/short-name/
shortName: "web-privacy-guideline",
// if your specification has a subtitle that goes below the main
// formal title, define it here
// subtitle : "an excellent document",
// if you wish the publication date to be other than today, set this
// publishDate: "2009-08-06",
// if the specification's copyright date is a range of years, specify
// the start date here:
// copyrightStart: "2005"
// if there is a previously published draft, uncomment this and set its YYYY-MM-DD date
// and its maturity status
// previousPublishDate: "1977-03-15",
// previousMaturity: "WD",
// if there a publicly available Editor's Draft, this is the link
//edDraftURI: "http://dev.w3.org/2009/dap/ReSpec.js/documentation.html",
// if this is a LCWD, uncomment and set the end of its review period
// lcEnd: "2009-08-05",
// editors, add as many as you like
// only "name" is required
editors: [
{ name: "Hannes Tschofenig", url: "http://www.tschofenig.priv.at/",
company: "", companyURL: "" },
{ name: "Nick Doty", url: "http://npdoty.name/",
company: "W3C", companyURL: "http://w3.org/" },
],
// authors, add as many as you like.
// This is optional, uncomment if you have authors as well as editors.
// only "name" is required. Same format as editors.
//authors: [
// { name: "Your Name", url: "http://example.org/",
// company: "Your Company", companyURL: "http://example.com/" },
//],
// name of the WG
wg: "Privacy Interest Group",
// URI of the public WG page
wgURI: "http://w3.org/Privacy/",
// name (without the @w3c.org) of the public mailing to which comments are due
wgPublicList: "public-privacy",
// URI of the patent status for this WG, for Rec-track documents
// !!!! IMPORTANT !!!!
// This is important for Rec-track documents, do not copy a patent URI from a random
// document unless you know what you're doing. If in doubt ask your friendly neighbourhood
// Team Contact.
wgPatentURI: "",
localBiblio: {
"EFF": {
"author": "Peter Eckersley",
"href": "https://panopticlick.eff.org/browser-uniqueness.pdf",
"title": "How unique is your web browser?",
"publisher": "Privacy Enhancing Technologies. Springer Berlin Heidelberg",
"date": "2010"
}
}
};
</script>
</head>
<body>
<section id='abstract'>
This document offers guidance for writing privacy considerations test
in W3C specifications. It aims to make designers,
implementers, and those who deploy W3C specifications aware of privacy-
related design choices.
</section>
<section>
<h2>Introduction</h2>
<p>
As the Web continues its evolution into a powerful application platform, an increasing number of its additional abilities risk compromising user privacy unless they are specifically created to promote it. Privacy has to become a core feature of the Web.
<p>
Privacy is present in all aspects of the Web platform, it is particularly salient when it comes to Javascript APIs since they comprise one of the most frequent and natural extensibility point for powerful features that can be misused, and that are hard to mitigate against. This leads to a strong requirement on these APIs to take user privacy into account from the earliest steps in their conception. This, in turn, imposes design constraints that are different from those found in more traditional applications programming, which entails that experience with APIs designed for the latter seldom applies in full and needs to be revisited.
<p>
This document is focused on those who develop specifications. Their design will be read by others who implement and deploy. As such, this document aims to provide them enough guidance so that they consider privacy during the design and convey powerful messages to those who implement and deploy. </p>
<p>
This document does not attempt to define what privacy is (in a Web context). Instead privacy is the sum of what is contained in this document. While this may not be exactly what most readers would typically assume but privacy is a complicated concept with a rich history that spans many disciplines and there remains confusion over the meaning.</p>
<p>
Whether any individual document warrants a specific privacy considerations section will depend on the document's content. In some cases privacy may be part of the security considerations or may not be relevant to certain specifications at all. In some other cases a fruitful discussion about privacy properties of a system requires several specifications to be evaluated in concert to offer meaningful guidance. </p>
<p>
Note that this document does not try to attempt to define the term 'privacy' itself. Instead privacy is the sum of what is contained in this document. We therefore follow the approach taken by [[RFC3552]] as well as [[RFC6973]]. </p>
</section>
<section>
<h2>Terminology</h2>
<p>This section defines basic terms used in this document, with references to pre-existing definitions as appropriate.</p>
<section>
<h3>Entities</h3>
<ul>
<li>Attacker: An entity that intentionally works against some privacy
protection goal. Unlike observers, attackers' behavior is
unauthorized.</li>
<li>Eavesdropper: A type of attacker that passively observes an
initiator's communications without the initiator's knowledge or
authorization. See [[RFC4949]].</li>
<li>Enabler: A protocol entity that facilitates communication between
an initiator and a recipient without being directly in the
communications path.</li>
<li>Individual: A human being.</li>
<li>Initiator: A protocol entity that initiates communications with a
recipient.</li>
<li>Intermediary: A protocol entity that sits between the initiator
and the recipient and is necessary for the initiator and recipient
to communicate. Unlike an eavesdropper, an intermediary is an
entity that is part of the communication architecture, and
therefore at least tacitly authorized. For example, an HTTP proxy
is such an intermediary.</li>
<li>Observer: An entity that is able to observe and collect
information from communications, potentially posing privacy
threats depending on the context. As defined in this document,
initiators, recipients, intermediaries, and enablers can all be
observers. Observers are distinguished from eavesdroppers by
being at least tacitly authorized.</li>
<li>Recipient: A protocol entity that receives communications from an
initiator.</li>
</ul>
</section>
<section>
<h3>Data and Analysis</h3>
<ul>
<li>Attack: An intentional act by which an entity attempts to violate
an individual's privacy. See [[RFC4949]].</li>
<li>Correlation: The combination of various pieces of information
relating to an individual.</li>
<li>Fingerprint: A set of information elements that identifies a
device or application instance.</li>
<li>Fingerprinting: The process of an observer or attacker uniquely
identifying (with a sufficiently high probability) a device or
application instance based on multiple information elements
communicated to the observer or attacker. See [[EFF]].</li>
<li>Item of Interest (IOI): Any data item that an observer or
attacker might be interested in. This includes attributes,
identifiers, identities, communications content, and the fact that
a communication interaction has taken place.</li>
<li>Personal Data: Any information relating to an individual who can
be identified, directly or indirectly.</li>
<li>(Protocol) Interaction: A unit of communication within a
particular protocol. A single interaction may be comprised of a
single message between an initiator and recipient or multiple
messages, depending on the protocol.</li>
<li>Traffic Analysis: The inference of information from observation
of traffic flows (presence, absence, amount, direction, timing,
packet size, packet composition, and/or frequency), even if flows
are encrypted. See [[RFC4949]].</li>
<li>Undetectability: The inability of an observer or attacker to
sufficiently distinguish whether an item of interest exists or
not.</li>
<li>Unlinkability: Within a particular set of information, the
inability of an observer or attacker to distinguish whether two
items of interest are related or not (with a high enough degree of
probability to be useful to the observer or attacker).</li>
</ul>
</section>
<section>
<h3>Identifiability</h3>
<ul>
<li>Anonymity: The state of being anonymous.</li>
<li>Anonymity Set: A set of individuals that have the same
attributes, making them indistinguishable from each other from the
perspective of a particular attacker or observer.</li>
<li>Anonymous: A state of an individual in which an observer or
attacker cannot identify the individual within a set of other
individuals (the anonymity set).</li>
<li>Attribute: A property of an individual.</li>
<li>Identifiable: A property in which an individual's identity is
capable of being known to an observer or attacker.</li>
<li>Identifiability: The extent to which an individual is
identifiable.</li>
<li>Identified: A state in which an individual's identity is known.</li>
<li>Identifier: A data object uniquely referring to a specific
identity of a protocol entity or individual in some context. See
[[RFC4949]]. Identifiers can be based upon natural names --
official names, personal names, and/or nicknames -- or can be
artificial (for example, x9z32vb). However, identifiers are by
definition unique within their context of use, while natural names
are often not unique.</li>
<li>Identification: The linking of information to a particular
individual to infer the individual's identity or to allow the
inference of the individual's identity in some context.</li>
<li>Identity: Any subset of an individual's attributes, including
names, that identifies the individual within a given context.
Individuals usually have multiple identities for use in different
contexts.</li>
<li>Identity Confidentiality: A property of an individual wherein any
party other than the recipient cannot sufficiently identify the
individual within a set of other individuals (the anonymity set).
This is a desirable property of authentication protocols.</li>
<li>Identity Provider: An entity (usually an organization) that is
responsible for establishing, maintaining, securing, and vouching
for the identity associated with individuals.</li>
<li>Official Name: A personal name for an individual which is
registered in some official context. For example, the name on an
individual's birth certificate.</li>
<li>Personal Name: A natural name for an individual. Personal names
are often not unique, and often comprise given names in
combination with a family name. An individual may have multiple
personal names at any time and over a lifetime, including official
names. From a technological perspective, it cannot always be
determined whether a given reference to an individual is, or is
based upon, the individual's personal name(s) (see Pseudonym).</li>
<li>Pseudonym: A name assumed by an individual in some context,
unrelated to the individual's personal names known by others in
that context, with an intent of not revealing the individual's
identities associated with her other names.</li>
<li>Pseudonymity: The state of being pseudonymous.</li>
<li>Pseudonymous: A property of an individual in which the individual
is identified by a pseudonym.</li>
<li>Real name: See personal name and official name.</li>
<li>Relying party: An entity that relies on assertions of
individuals' identities from identity providers in order to
provide services to individuals. In effect, the relying party
delegates aspects of identity management to the identity
provider(s). Such delegation requires protocol exchanges, trust,
and a common understanding of semantics of information exchanged
between the relying party and the identity provider.</li>
</ul>
</section>
</section>
<section>
<h2>Privacy Threats</h2>
<p>There are a wide range of privacy concerns and on a high level they fall into the following categories.</p>
<ul>
<li>Surveillance: Surveillance is the observation or monitoring of an individual's
communications or activities.</li>
<li>Stored Data Compromise: End systems that do not take adequate measures to secure stored data
from unauthorized or inappropriate access.</li>
<li>Intrusion: Intrusion consists of invasive acts that disturb or interrupt one's
life or activities.</li>
<li>Misattribution: Misattribution occurs when data or communications related to one
individual are attributed to another.</li>
<li>Correlation: Correlation is the combination of various pieces of information
related to an individual or that obtain that characteristic when
combined. [Editor's Note: Maybe a reference to the DNT work would be appropriate.]
</li>
<li>Identification: Identification is the linking of information to a particular
individual to infer an individual's identity or to allow the
inference of an individual's identity.</li>
<li>Secondary Use: Secondary use is the use of collected information about an individual
without the individual's consent for a purpose different from that
for which the information was collected. </li>
<li>Disclosure: Disclosure is the revelation of information about an individual that
affects the way others judge the individual.</li>
<li>Exclusion: Exclusion is the failure to allow individuals to know about the data
that others have about them and to participate in its handling and
use.</li>
</ul>
<p>To mitigate various privacy threats presented above techniques like
data minimisation, anonymity and pseudonymity techniques, identity confidentiality,
user participation, and security protection can be applied. </p>
</section>
<section>
<h2>Guidelines</h2>
<p>The starting point for addressing privacy in the design of a protocol, in its implementation and the deployment is to acknowledge that there are potential privacy concerns. Documenting these concerns is an important step to develop a shared understanding is the prerequisite for deciding whether there are ways to mitigate these concerns, either with an alternative protocol design, guidance for implementers, or with recommendations for those who deploy the technology.</p>
<p>Changing the underlying security and privacy baseline typically leads to modifications of the entire architecture. Consequently, it is wise to consider security as well as privacy early in the design process. Often, specifications are extensions to an already defined communication architecture whereby many underlying design decisions have been made years ago already. In such a case it is highly valuable for non-protocol experts to have access to a high-level summary of the communication architecture the extension builds on. This simplifies a privacy assessment and to spot potential deviation from previously made assumptions. [[RFC4101]] offers suggerstions for writing such a protocol model.</p>
<p>Since privacy builds on top of security proper security protection is assumed. In addition to the guidance for protocol designers provided in [[RFC3552]] for writing security consideration text the following questions are relevant.</p>
<ul>
<li>How do the protocol's security considerations prevent surveillance, including eavesdropping and traffic analysis?</li>
<li>How do the protocol's security considerations prevent or mitigate stored data compromise?</li>
<li>How do the protocol's security considerations prevent or mitigate intrusion, including denial-of-service attacks and unsolicited communications more generally?</li>
<li>How do the protocol's mechanisms for identifying and/or authenticating individuals prevent misattribution?</li>
</ul>
<p>The guidance given below is not a hard rule but instead aims to make you think about your design. Not all items are equally applicable to all specifications and stakeholders involved in the implementation and deployment. For example, notice and consent is often best accomplished by parties that implement and deploy software rather than by those who write specifications since many deployments use non-standardized functionality for informing their user base about the privacy properties of their service and for obtaining the users consent before they are able to use the service. In other cases again, users are given the opportunity to convey their privacy preferences via protocol mechanisms or make consent decisions in real-time before data sharing takes place. This would clearly fall into the scope of technical specifications.</p>
<section>
<h3>Data Minimisation</h3>
<p>Minimisation is a strategy that involves exposing as little information to other communication partners as is required for a given operation to complete. More specifically, it requires not providing access to more information than was apparent in the user-mediated access or allowing the user some control over which information exactly is provided.</p>
<p>For example, if the user has provided access to a given file, the object representing that should not make it possible to obtain information about that file's parent directory and its contents as that is clearly not what is expected.</p>
<p>Basic fingerprinting guidance can be found <a href="https://github.com/w3c/fingerprinting-guidance">here</a>.</p>
<p>In context of data minimisation it is natural to ask what data is passed around between the different parties, how persistent the data items and identifiers are, and whether there are correlation possibilities between different protocol runs.</p>
<p>For example, the W3C Device APIs Working Group has defined the following requirements in their Device API Privacy Requirements document.</p>
<ul>
<li>APIs must make it easy to request as little information as required for the intended usage. For instance, an API call should require specific parameters to be set to obtain more information, and should default to little or no information.</li>
<li>APIs should make it possible for user agents to convey the breadth of information that the requester is asking for. For instance, if a developer only needs to access a specific field of a user address book, it should be possible to explicitly mark that field in the API call so that the user agent can inform the user that this single field of data will be shared.</li>
<li>
APIs should make it possible for user agents to let the user select, filter, and transform information before it is shared with the requester. The user agent can then act as a broker for trusted data, and will only transmit data to the requester that the user has explicitly allowed.
</li>
</ul>
<p>Data minimisation is applicable to specification authors, implementers as well as to those deploying the final service.</p>
<p>As an example, consider mouse events. When a page is loaded, the application has no way of knowing whether a mouse is attached, what type of mouse it is (e.g., make and model), what kind of capabilities it exposes, how many are attached, and so on. Only when the user decides to use the mouse — presumably because it is required for interaction — does some of this information become available. And even then, only a minimum of information is exposed: you could not know whether it is a trackpad for instance, and the fact that it may have a right button is only exposed if it is used. For instance, the Gamepad API makes use of this data minisation capability. It is impossible for a Web game to know if the user agent has access to gamepads, how many there are, what their capabilities are, etc. It is simply assumed that if the user wishes to interact with the game through the gamepad then she will know when to action it — and actioning it will provide the application with all the information that it needs to operate (but no more than that).</p>
<p>The way in which the functionality is supported for the mouse is simply by only providing information on the mouse's behaviour when certain events take place. The approach is therefore to expose event handling (e.g., triggering on click, move, button press) as the sole interface to the device.</p>
</section>
<section>
<h3>Trade-offs</h3>
<p>Designing privacy features into a protocol or architecture often requires tradeoffs to be made. As a designer we often make these decisions without spending too much thoughts about them. For others, this decision making process is, however, important to judge the value of certain design decisions. </p>
<p>Does the protocol make trade-offs between privacy and usability, privacy and efficiency, privacy and implementability, privacy and security, or privacy and other design goals? Capture these trade-offs and the rationale for the design chosen.</p>
</section>
<section>
<h3>Defaults</h3>
<p>Protocol often come with flexible options so that it can be tailored to specific environments. Does the default mode minimize the amount, identifiability, and persistence of the data and identifiers exposed by the protocol? Does the default mode or option maximize the opportunity for user participation? Does it provide the strictest security features of all the modes/options?</p>
<p>If any of these answers are no, explain why less protective defaults were chosen.</p>
</section>
<section>
<h3>User Participation</h3>
<p>Many Web protocols allow data to be made available through APIs and other protocol mechanisms. It is important for users to be able to control access to their data. What controls or consent mechanisms does the protocol define or require before personal data or identifiers are shared or exposed via the protocol/API? </p>
<p>Does the user have control over their data after it has been shared with other parties, for example regarding secondary use? Are users able to determine what information was shared with other parties? </p>
<p>What recommendations can be given to implementers and the deployment community regarding privacy-friendly sharing of information?</p>
</section>
</section>
<section class='appendix'>
<h2>Acknowledgements</h2>
<p>Add your name here.</p>
</section>
</body>
</html>