Fingerprinting Guidance: feasibility; icon/marker

Hi public-privacy,

I've made a couple updates [0] to the unofficial Fingerprinting Guidance draft, for which I'd love your expert review:

1) As the question has often come up explicitly, I've tried to reorganize the document and add a specific section on the question of feasibility/lost cause. The new text is:

> Given the advances in techniques for browser fingerprinting (see the Research section below), particularly in active fingerprinting, many have asked whether browser fingerprinting is a "lost cause" and mitigations therefore not worth pursuing during the design process. This document works under the expectation that mitigations with different levels of success are feasible under different circumstances, for different threat models and against different types of fingerprinting. In general, active fingerprinting may be made detectable; we can minimize increases to the surface of passive fingerprinting; and cookie-like fingerprinting can be documented to enable clearing local state.
> 
> However, the mitigations recommended here are simply mitigations, not solutions. Research in browser fingerprinting continues and even with the mitigations described here, users should not rely on sites being completely unable to recognize or correlate traffic, most especially when executing client-side code. A fingerprinting surface extends across all implemented Web features for a particular user agent, and even to other layers of the stack. In order to mitigate the risk as a whole, fingerprinting must be considered during the design and development of all specifications.
> 
> Some implementers and some users may be willing to accept reduced functionality or decreased performance in order to minimize browser fingerprinting. Documenting which features have fingerprinting risk eases the work of implementers building modes for these at-risk users; minimizing fingerprinting even in cases where common implementations will have easy active fingerprintability allows such users to reduce the functionality trade-offs necessary. 

Comments of any constructive kind are welcome; perhaps you have additions or replacements for my attempt.

2) I've noticed that the HTML WG is using a fingerprint icon to mark sections of the HTML spec that have a fingerprinting impact, which makes it easier for a UA implementer to consider those issues (and might also make privacy reviews easier!). While I'd love to hear any feedback on those who have used that, the idea of marking relevant sections seems valuable. New text:

> Where a feature does contribute to the fingerprinting surface, authors SHOULD indicate that impact, by explaining the effect (and any known implementer mitigations) and marking the relevant section with a fingerprinting icon, as this paragraph is.


As usual, you can read the nicely formatted version here:
	http://w3c.github.io/fingerprinting-guidance/
And the "source" is here:
	https://github.com/w3c/fingerprinting-guidance

Thanks,
Nick

[0] https://github.com/w3c/fingerprinting-guidance/commit/594ee71c655eed473791a45aec80e405d839faa5