Re: PING call - Thursday 10 January 2019 at UTC 17 - agenda

On Jan 7, 2019, at 4:56 PM, Christine Runnegar <runnegar@isoc.org> wrote:
> 
> Also on the agenda:
> 
> - private browsing modes (continuing the discussion)
> - update re mitigating fingerprinting guidance

On our last call I noted that I needed to address the last batch of issues and then we could publish another Note snapshot. I’ve made a small group of changes over the last two weeks, described below. I’d be happy for us to publish a Note of this version now; we can and should continue to make changes in the future, but this would be a fairly good stopping point and the last published Note is over 3 years old.

I would benefit from feedback:
1. I’ve marked all the issues I think are addressed with “pending-review” in the Github issues list: https://github.com/w3c/fingerprinting-guidance/issues <https://github.com/w3c/fingerprinting-guidance/issues>
If someone is willing to check my work, we can close those issues. (I could just close them as the editor if the Interest Group would prefer to work that way.)
2. If you opened an issue, could you check and see if it’s been satisfactorily resolved?
3. I’ve split up / added to the best practices, to note narrowing scope and limiting availability (like permission prompts) as mitigations, and to note the experimental use of server opt in as a mitigation for otherwise passive fingerprinting.
Does this list of 10 look reasonable?

 • Best Practice 1: Avoid unnecessary or severe increases to fingerprinting surface, especially for passive fingerprinting.
 • Best Practice 2: Narrow the scope and availability of a feature with fingerprinting surface to what is functionally necessary.
 • Best Practice 3: Mark features that contribute to fingerprintability.
 • Best Practice 4: Specify orderings and non-functional differences.
 • Best Practice 5: Design APIs to access only the entropy necessary.
 • Best Practice 6: Require servers to advertise or opt in to access data.
 • Best Practice 7: Enable graceful degradation for privacy-conscious users or implementers.
 • Best Practice 8: Avoid unnecessary new local state mechanisms.
 • Best Practice 9: Highlight any local state mechanisms to enable simultaneous clearing.
 • Best Practice 10: Limit permanent or persistent state.

Thanks,
Nick

And here’s the longer list of changes:

* moved Tor/cross-layer discussion to "What can we do about it?", as suggested in #17
* fixed internal section references by putting ids on sections rather than headings
* noted anonymity set as a reason for standardization over randomization, as suggested in #23
* noted implementation-specific surface mitigations, like font whitelists, #24
* noted different distributions of values (hardware vs user configurations, say), as per #26
* noted timing channels and inferences generally in data sources, #27

* added new research references
* updated feasibility section, with examples from research
* lots more references, and better organization of research section

* split up limit-severity best practice to emphasize 1) limit new passive fingerprinting surface and 2) narrow scope and availability, including with permission prompts
* add example of Media Capture permissions for media device labels
* add a separate best practice for server-side opt-in on HTTP requests, as a kind of experimental option, with Client Hints design as the example
* make a clearer, numbered action list (removed issue box #1)
* removed a note/question box in privacy impacts