mitigating browser fingerprinting: identifying sources and severity

Hi all,

In trying to make the guidance for mitigating browser fingerprinting in web specifications more actionable (see https://github.com/w3c/fingerprinting-guidance/issues/13), I've sketched a list of sources of fingerprinting surface and factors for severity of fingerprintability.

I would benefit from review on two particular points:
* are these the right list of factors of severity? are there other factors you would consider? or factors in this list you find irrelevant?
* do these sources of fingerprinting and these factors of severity make it easier for the spec designer to mitigate fingerprinting?

Thanks,
Nick

Particular section is included inline below, or see the full updated version here:
https://w3c.github.io/fingerprinting-guidance/

> Second, for each identified feature, consider the severity for the privacy impacts described above (1.2 Privacy impacts and threat models <file:///Users/nick/writing/fingerprinting-guidance/index.html#privacy_threat_models>) based on the following factors:
> 
> entropy
> How distinguishing is this new surface? Consider both the possible variations and the likely distribution of values. Adding 1-bit of entropy is typically of less concern; 30-some bits of entropy would be enough to uniquely identify every individual person.
> detectability
> Will use of this feature for browser fingerprinting be observable to the user agent or likely to be discoverable by researchers? Because detectability is an important — and perhaps the most feasible — mitigation, increases to the surface for passive fingerprinting <file:///Users/nick/writing/fingerprinting-guidance/index.html#dfn-passive-fingerprinting> are of particular concern and should be avoided.
> persistence
> How long will the characteristics of this fingerprinting surface stay unchanged? Can users control or re-set these values to prevent long-lived identification? While short-lived characteristics may still enable unexpected correlation of activity (for example, between two browser profiles on the same device), persistent or permanent identifiers are particularly concerning for the lack of user control.
> availability
> Will this surface be accessible to the "drive-by Web" or only in certain contexts where a user has granted a particular sensor permission or directly authenticated? While browser fingerprinting is still something to mitigate in the permissioned context, the concern that a feature will end up used primarily for fingerprinting is reduced.
> scope
> Is this surface consistent across origins or only within a single origin? In general, characteristics or identifiers that are tied to a particular origin are of less concern and can be handled with the same tools as HTTP cookies.
> While we do not recommend specific trade-offs, these factors can be used to weigh increases to that surface (6.1 Weighing increased fingerprinting surface <file:///Users/nick/writing/fingerprinting-guidance/index.html#weighing_increased_fingerprinting_surface>) and suggest appropriate mitigations. Although each factor may suggest specific mitigations, in weighing whether to add fingerprinting surface <file:///Users/nick/writing/fingerprinting-guidance/index.html#dfn-fingerprinting-surface> they should be considered in concert. For example, access to a new set of characteristics about the user may be high entropy, but be of less concern because it has limited availability and is easily detectable. A cross-origin, drive-by-accessible, permanent, passive unique identifier is incompatible with our expectations for privacy on the Web.
>