actionability through a decision tree or other

[npdoty]

w3ctag/design-reviews#38 (comment)

Expanding on the request for actionability, one suggestion is to make an explicit decision tree or more direct list of mitigations, so that a team using this document would know the kind of changes necessary to follow these best practices.

We might also try this out with a WG, or on our own with a couple of specs, and see what the direct changes would be.

[npdoty]

Attempting to address this through:
https://lists.w3.org/Archives/Public/public-privacy/2017AprJun/0021.html
12a3c83

[pes10k]

I vote strongly for more actionable guidance too.

Guidelines / "rules" like:

• APIs that reveal information about the environment outside the browser (e.g. fonts, display color depth, resolution, etc) should be gated behind permission prompts
• APIs that reveal information about previous browsing sessions (e.g. cookies, local storage, page history) should have access partitioned by same-origin, state flushed in private browsing modes, etc
  …etc

would be very useful, both hopefully in future standards, but also to browser vendors in deciding whether to implement

[npdoty]

I've tried to make the steps to follow in identifying surface, evaluating severity and applying mitigations more concrete.

@snyderp I think rules of that form could definitely be useful, but I'm not aware of any agreement on them. I don't know of any browsers that are gating CSS media queries or fonts behind user permission prompts and I'm not aware of a good UI for permissions that would explain that; this doc does note permissions as a possible mitigation. Noting local state and clearing it all at once is described in this document, and you can let me know if there's a way to make it clearer.

[pes10k]

@npdoty I appreciate your comments above, but they leave me unsure what the goals of this document are. If the goal is to highlight concerns, then issues about UI and what browsers are currently doing seem unrelated. If the goal is to prescribe certain actions, then it seems the whole thing should should be more direct and forceful.

In general, maybe it would be better to fold this effort into the PING privacy questionaire?

[npdoty]

@snyderp the goals of this document are to provide authors of specifications, designers of new web features and people reviewing those specs and features, guidance on how to identify and mitigate privacy risks that arise through browser fingerprinting.

In order to provide best practices, it's useful to be able to provide guidance and techniques that are used in the wild or that we can confidently recommend, which is why I think adoption and UI concerns are relevant. I would welcome any suggested changes to make this document more forceful about design decisions that are recommended.

We've definitely talked in the past about folding this into the privacy/security questionnaire and I've been open to that possibility. As both this document and the questionnaire have gotten longer and more involved, I'm not sure combining them is as promising now.

[npdoty]

Will open separate issue regarding providing a reference to current privacy/security questionnaire which also provides actionable guidance.