From 643fa2cc7ee14d060a0b198a060854a3ffffa8b3 Mon Sep 17 00:00:00 2001
From: Jason Novak <1934060+jasonanovak@users.noreply.github.com>
Date: Sun, 14 Oct 2018 11:27:11 -0500
Subject: [PATCH 01/46] make mitigations section have 80 character line breaks
---
index.src.html | 37 +++++++++++++++++++++++--------------
1 file changed, 23 insertions(+), 14 deletions(-)
diff --git a/index.src.html b/index.src.html
index 92404f8..01c4faa 100644
--- a/index.src.html
+++ b/index.src.html
@@ -639,15 +639,17 @@
Drop the feature
- The simplest way to mitigate potential negative security or privacy impacts of a feature,
- and even discussing the possibility, is to drop the feature.
- Every feature in a spec should be considered guilty (of harming security and/or privacy) until proven otherwise.
+ The simplest way to mitigate potential negative security or privacy impacts
+ of a feature, and even discussing the possibility, is to drop the feature.
+ Every feature in a spec should be considered guilty (of harming security
+ and/or privacy) until proven otherwise.
- Every specification should seek to be as small as possible, even if only for the reasons of reducing
- and minimizing security/privacy attack surface(s).
+ Every specification should seek to be as small as possible, even if only
+ for the reasons of reducing and minimizing security/privacy attack surface(s).
- By doing so we can reduce the overall security (and privacy) attack surface of not only a particular feature,
- but of a module (related set of features), a specification, and the overall web platform.
+ By doing so we can reduce the overall security (and privacy) attack surface
+ of not only a particular feature, but of a module (related set of
+ features), a specification, and the overall web platform.
Examples
@@ -658,8 +660,13 @@
Sanitize the data handled in the feature
- It is always a good strategy to consider the kinds of data a new feature is processing. For example, new features allowing the readout of data may want to adopt specific privacy strategies such as minimizing the quality of datas (quantization) or reducing the frequency, in line with standard privacy engineering practices. Examples
- * [BATTERY-STATUS-API] “The user agent should not expose high precision readouts”
+ It is always a good strategy to consider the kinds of data a new feature
+ is processing. For example, new features allowing the readout of data may
+ want to adopt specific privacy strategies such as minimizing the quality
+ of datas (quantization) or reducing the frequency, in line with standard
+ privacy engineering practices. Examples
+ * [BATTERY-STATUS-API] “The user agent should not expose high
+ precision readouts”
* [SENSORS-API] “Limit maximum sampling frequency”, “Reduce accuracy”
@@ -667,12 +674,14 @@
Making a privacy impact assessment
- Some features are potentially supplying very sensitive data, and it is the end-developer,
- system owners, or managers responsibility to realize this and act accordingly in the design of his/her
- system. Some use may warrant conducting as privacy impact assessment, especially when data relating to
- individuals may be processed. Examples.
+ Some features are potentially supplying very sensitive data, and it is
+ the end-developer, system owners, or managers responsibility to realize
+ this and act accordingly in the design of his/her system. Some use may
+ warrant conducting as privacy impact assessment, especially when data
+ relating to individuals may be processed. Examples.
- * [GENERIC-SENSORS] advices to consider performing of a privacy impact assessment
+ * [GENERIC-SENSORS] advices to consider performing of a privacy impact
+ assessment
From 6b621a3fa63c7538eebdc6e5486d2678c9eebb9a Mon Sep 17 00:00:00 2001
From: Jason Novak <1934060+jasonanovak@users.noreply.github.com>
Date: Sun, 14 Oct 2018 11:27:45 -0500
Subject: [PATCH 02/46] remove the duplicative how to use section at the end of
the document
---
index.src.html | 19 +------------------
1 file changed, 1 insertion(+), 18 deletions(-)
diff --git a/index.src.html b/index.src.html
index 01c4faa..32b9c26 100644
--- a/index.src.html
+++ b/index.src.html
@@ -98,7 +98,7 @@
Introduction
* External audience (developers, designers, etc.) wanting to understand the
possible security and privacy implications.
-
How To Use The Questionnaire
+
How To Use The Questionnaire
Thinking about security and privacy risks and mitigations early in a project
is the best approach as it helps ensure the privacy of your feature at an
@@ -686,23 +686,6 @@
-
-
How to Use the questionnaire
-
- To ensure good designs, security and privacy should be considered as early as possible.
- This questionnaire facilitates this and the questions should be considered early in the specification development
- process, kept in mind as it matures, with the answers being updated along the specification evolution.
- This questionnaire should not be used as a “check box" excercise before requesting final publication - acting in
- this manner does not help improve privacy or security on the Web. Each question needs to be considered and that
- any privacy or security concerns are described, along with a possible mitigation strategy.
- It is not a good approach to provide a one-word answer (“yes” / “no”). Rather, it is expected to include an
- explanatory description. The questions in the questionnaire are more about “why” and “how”, rather than “if”.
-
- It is expected that a questionnaire must be filled in prior to obtaining a W3C Working Draft status, and prior to requiring a review, along the Privacy by Design principles.
- The questionnaire and its answers should not be included in the specification itself. It is preferable to keep it in a standard and easily available place, with a link available in the TAG repository.
-
-
-
+ To mitigate the security and privacy risks you’ve identified in your
+ specification as you’ve filled out the questionnaire and consulted with PING,
+ you may want to apply one or more of the mitigations described below to your
+ feature.
+
Secure Contexts
From db552fca9e5d030ee40a540d4392d18c5f27ccbe Mon Sep 17 00:00:00 2001
From: Jason Novak <1934060+jasonanovak@users.noreply.github.com>
Date: Sun, 14 Oct 2018 11:33:44 -0500
Subject: [PATCH 04/46] reorder mitigations and add placeholders for new
mitigations
---
index.src.html | 77 +++++++++++++++++++++++++++++++-------------------
1 file changed, 48 insertions(+), 29 deletions(-)
diff --git a/index.src.html b/index.src.html
index 7a76c5b..2f2fc49 100644
--- a/index.src.html
+++ b/index.src.html
@@ -615,15 +615,17 @@
you may want to apply one or more of the mitigations described below to your
feature.
-
- Secure Contexts
+
+ Data Minimization
- In the presence of an active network attacker, offering a feature to
- an insecure origin is the same as offering that feature to every origin (as
- the attacker can inject frames and code at will). Requiring an encrypted and
- authenticated connection in order to use a feature can mitigate this kind of
- risk.
+ TODO
+
+
+ Privacy Friendly Defaults
+
+
+ TODO
Explicit user mediation
@@ -640,6 +642,35 @@
ISSUE: Bring in some of felt@'s ideas here.
+
+ Sanitize the data handled in the feature
+
+
+ It is always a good strategy to consider the kinds of data a new feature
+ is processing. For example, new features allowing the readout of data may
+ want to adopt specific privacy strategies such as minimizing the quality
+ of datas (quantization) or reducing the frequency, in line with standard
+ privacy engineering practices. Examples
+ * [BATTERY-STATUS-API] “The user agent should not expose high
+ precision readouts”
+ * [SENSORS-API] “Limit maximum sampling frequency”, “Reduce accuracy”
+
+
+ Explicitly restrict the feature to first party origins
+
+
+ TODO
+
+
+ Secure Contexts
+
+
+ In the presence of an active network attacker, offering a feature to
+ an insecure origin is the same as offering that feature to every origin (as
+ the attacker can inject frames and code at will). Requiring an encrypted and
+ authenticated connection in order to use a feature can mitigate this kind of
+ risk.
+
- In the presence of an active network attacker, offering a feature to
- an insecure origin is the same as offering that feature to every origin (as
- the attacker can inject frames and code at will). Requiring an encrypted and
+ If the primary risk that you’ve identified in your specification is the
+ threat posed by active network attacker, offering a feature to an
+ insecure origin is the same as offering that feature to every origin because
+ the attacker can inject frames and code at will. Requiring an encrypted and
authenticated connection in order to use a feature can mitigate this kind of
risk.
+ However, requiring a secure context is not sufficient to mitigate many
+ privacy risks or even security risks from other threat actors than active
+ network attackers.
+
the end-developer, system owners, or managers responsibility to realize
this and act accordingly in the design of his/her system. Some use may
warrant conducting as privacy impact assessment, especially when data
- relating to individuals may be processed. Examples.
+ relating to individuals may be processed.
+ Specifications that expose such sensitive data should include a
+ recommendation that websites and applications adopting the API — but not
+ necessarily the implementing user agent — conduct a privacy impact assessment
+ of the data that they collect.
+
+ A features that recommends such is:
* [GENERIC-SENSORS] advices to consider performing of a privacy impact
assessment
From 444a3f0d59aa62a9c942bb1d7c4ee0f21a2015cd Mon Sep 17 00:00:00 2001
From: "Jason A. Novak"
Date: Thu, 18 Oct 2018 10:52:51 -0500
Subject: [PATCH 15/46] Address @eseltzer comments
---
index.src.html | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/index.src.html b/index.src.html
index cc1ed9f..e16286d 100644
--- a/index.src.html
+++ b/index.src.html
@@ -654,7 +654,7 @@
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.
- Data minimization is applicable to specification authors, implementers as
+ Data minimization is applicable to specification authors and implementers, as
well as to those deploying the final service.
As an example, consider mouse events. When a page is loaded, the application
@@ -780,9 +780,9 @@
Some features are potentially supplying very sensitive data, and it is
- the end-developer, system owners, or managers responsibility to realize
+ the responsibility of the end-developer, system owner, or manager to realize
this and act accordingly in the design of his/her system. Some use may
- warrant conducting as privacy impact assessment, especially when data
+ warrant conducting a privacy impact assessment, especially when data
relating to individuals may be processed.
Specifications that expose such sensitive data should include a
From cb291f87923278f1eaa10bbf9fe761984d2f90d7 Mon Sep 17 00:00:00 2001
From: "Jason A. Novak" <1934060+jasonanovak@users.noreply.github.com>
Date: Mon, 22 Oct 2018 11:13:39 -0500
Subject: [PATCH 16/46] address Nick's feedback
---
index.src.html | 73 +++++++++++++++++++++++++++++++++++++++-----------
1 file changed, 58 insertions(+), 15 deletions(-)
diff --git a/index.src.html b/index.src.html
index e16286d..9f6f142 100644
--- a/index.src.html
+++ b/index.src.html
@@ -630,7 +630,7 @@
that file's parent directory and its contents as that is clearly not what is
expected.
- Basic fingerprinting guidance can be found here.
+ Basic fingerprinting guidance can be found in [DOTY-FINGERPRINTING].
In context of data minimization it is natural to ask what data is passed
around between the different parties, how persistent the data items and
@@ -705,18 +705,33 @@
implement more privacy-preserving version.
It is possible that the risk of a feature cannot be mitigated because the
- risk is endemic to the feature itself. For instance, [[ GEOLOCATION-API ]]
+ risk is endemic to the feature itself. For instance, [GEOLOCATION-API]
reveals a user’s location, and wouldn’t be particularly useful if it didn’t;
user agents generally gate access to the feature on a permission prompt which
the user may choose to accept. This risk is also present and should be
accounted for in features that expose personal data or identifiers.
Designing such prompts is difficult as is determining the duration and timing
- that the permission should provide. Generally speaking, the duration and
- timing of the prompt should be inversely proportional to the risk posed by
- the data exposed. Often, the best prompt is one that is clearly tied to a
- user action, like the file picker. And, walls of text may not be read by
- users or understood by all.
+ that the permission should provide.
+
+ Often, the best prompt is one that is clearly tied to a user action, like the
+ file picker, where in response to a user action, the file picker is brought
+ up and a user gives access to a specific file to an individual site.
+
+ Generally speaking, the duration and timing of the prompt should be inversely
+ proportional to the risk posed by the data exposed. In addition, the prompt
+ should consider issues such as:
+ * How should permission requests be scoped? Especially when requested by an
+ embedded third party iframe?
+ * Should persistence be based on the pair of top-level/embedded origins or a
+ different scope?
+ * How is it certain that the prompt is occuring in context of requiring the
+ data and at a time that it is clear to the user why the prompt is occuring.
+ * Explaining the implications of permission before prompting the user, in a
+ way that is accessible and localized -- _who_ is asking, _what_ are they
+ asking for, _why_ do they need it?
+ * What happens if the user rejects the request at the time of the prompt or
+ if the user later changes their mind and revokes access.
These prompts should also include considerations for what, if any, control a
user has over their data after it has been shared with other parties. For
@@ -727,13 +742,22 @@
Explicitly restrict the feature to first party origins
- As described in the "Third-Party Tracking" section, the power of the web is
- the mixing of first and third party content in a single page, but, this
- introduces risk where the third party content can use the same set of web
- features as the first party content. One way to mitigate this risk is for
- the specification to restrict access to the feature to the first party
- origin only and make third party’s access to the feature an optional
- implementation for conformance.
+ As described in the "Third-Party Tracking" section, a significant feature of
+ the web is the mixing of first and third party content in a single page, but,
+ this introduces risk where the third party content can use the same set of web
+ features as the first party content.
+
+ Authors should explicit specify the feature's scope of availability:
+ * When a feature should be made available to embedded third parties -- and
+ often first parties should be able to explicitly control that (using
+ iframe attributes or feature policy)
+ * Whether a feature should be available in the background or only in the
+ top-most, visible tab.
+ * Whether a feature should be available to offline service workers.
+ * Whether events will be fired simultaneously
+
+ Third party’s access to a feature should be an optional implementation for
+ conformance.
Secure Contexts
@@ -746,6 +770,12 @@
authenticated connection in order to use a feature can mitigate this kind of
risk.
+ Secure contexts also protect against passive network atackers. For
+ example, if a page uses the Geolocation API and sends the sensor-provided
+ latitude and longitude back to the server over an insecure connection, then
+ any passive network attacker can learn the user's location, without any
+ feasible path to detection by the user or others.
+
However, requiring a secure context is not sufficient to mitigate many
privacy risks or even security risks from other threat actors than active
network attackers.
@@ -792,8 +822,14 @@
A features that recommends such is:
* [GENERIC-SENSORS] advices to consider performing of a privacy impact
- assessment
+ assessment
+ Documenting these impacts is important for organizations although it should
+ be noted that there are limitations to putting this onus on organizations.
+ Research has shown that sites often do not comply with security/privacy
+ requirements in specifications. For example, in [[DOTY-GEOLOCATION]], it was
+ found that none of the studied websites informed users of their privacy
+ practices before the site prompted for location.
@@ -908,5 +944,12 @@
"title": "Chrome Lets Hackers Phish Even 'Unphishable' YubiKey Users",
"authors": [ "Andy Greenberg" ],
"publisher": "Wired"
+ },
+ "DOTY-GEOLOCATION": {
+ "href": "https://escholarship.org/uc/item/0rp834wf",
+ "title": "Privacy Issues of the W3C Geolocation API",
+ "authors": [ "Nick Doty, Deirdre K. Mulligan, Erik Wilde" ],
+ "publisher": "UC Berkeley School of Information"
+ }
}
From 540e58501881d4ca9a616a55a1122b1bcb91f86c Mon Sep 17 00:00:00 2001
From: "Jason A. Novak" <1934060+jasonanovak@users.noreply.github.com>
Date: Fri, 9 Nov 2018 08:45:21 -0600
Subject: [PATCH 17/46] bikeshed w3ctag variant through PR41 including edits so
links work; update editors
---
index.html | 591 ++++++++++++++++++++++++++++++++-----------------
index.src.html | 23 +-
2 files changed, 401 insertions(+), 213 deletions(-)
diff --git a/index.html b/index.html
index bfec5a6..acaf2fb 100644
--- a/index.html
+++ b/index.html
@@ -1214,7 +1214,7 @@
-
+
-
+