Adjust the organization of BPs and split one into two.

[tomrittervg]

Presently we have

• Weighing increased fingerprinting surface
  • Avoid unnecessary or severe increases to fingerprinting surface, especially for passive fingerprinting.
  • Narrow the scope and availability of a feature with fingerprinting surface to what is functionally necessary.
  • Mark features that contribute to fingerprintability.
• Standardization
  • Specify orderings and non-functional differences.
• Detectability
  • Design APIs to access only the entropy necessary.
  • Require servers to advertise or opt in to access data.
  • Enable graceful degradation for privacy-conscious users or implementers.
• Clearing all local state
  • Avoid unnecessary new local state mechanisms.
  • Highlight any local state mechanisms to enable simultaneous clearing.
  • Limit permanent or persistent state.

I would propose:

• Weighing increased fingerprinting surface
  • Avoid unnecessary or severe increases to fingerprinting surface, especially for passive fingerprinting.
  • Narrow the scope and availability of a feature with fingerprinting surface to what is functionally necessary.
  • Mark features that contribute to fingerprintability.
• Standardization
  • Specify orderings and non-functional differences.
  • Limit the fingerprinting surface to only the entropy necessary
  • Enable graceful degradation for privacy-conscious users or implementers.
• Detectability
  • Design APIs to access only the entropy necessary
  • Require servers to advertise or opt in to access data.
• Clearing all local state
  • Avoid unnecessary new local state mechanisms.
  • Highlight any local state mechanisms to enable simultaneous clearing.
  • Limit permanent or persistent state.

Specifically:

• Move "Enable graceful degradation for privacy-conscious users or implementers." to "Standardization"
• Add "Limit the fingerprinting surface to only the entropy necessary"
• Edit "Design APIs to access only the entropy necessary"

Presently Design APIs to access only the entropy necessary says:

Following the basic principle of data minimization [RFC6973], design your APIs such that a site can access (and does access by default) only the entropy necessary for particular functionality.

Authors might design an API to allow for querying of a particular value, rather than returning an enumeration of all values. User agents and researchers can then more easily distinguish between sites that query for one or two particular values (gaining minimal entropy) and those that query for all values (more likely attempting to fingerprint the browser); or implementations can cap the number of different values. For example, Tor Browser limits the number of fonts that can be queried with a browser.display.max_font_attempts preference.

The granularity or precision of information returned can be minimized in order to reduce entropy. For example, implementations of the Battery Status API [BATTERY-STATUS] allowed for high precision (double-precision, or 15-17 significant digits) readings of the current battery level, which provided a short-term identifier that could be used to correlate traffic across origins or clearance of local state. Rounding off values to lower precision mitigates browser fingerprinting while maintaining functional use cases. Alternatively, providing Boolean or a small enumeration of values might provide functionality without revealing underlying details; for example, the Boolean near property in the Proximity Sensor API [PROXIMITY].

This is covering what, to me, is two very different topics. The first is "Make the API so the UA can tell when you're trying to get lots of data" and the second is "Don't expose a lot of data in your feature". I think each of these points is very important and deserve to have their own BP.

Limit the fingerprinting surface to only the entropy necessary is often the first thing we look at in a new API: "How much data does it provide, can it provide less?" I think it deserves to be broken out.

Design APIs to access only the entropy necessary gives a great explanation of making an API queryable. I would suggest we somehow add a second example to this BP and that is to make an API asyncronous when possible, as that provides User Agents the ability - but not the requirement - to inform the user and allow them to take action if desired. I've spent an incredible amount of time dealing with Tor Browser's canvas mitigations and it would have been orders of magnitude easier if the image extraction APIs were async. Hindsight is 50/50 but this same principal is applicable for all APIs that query hardware devices (e.g. Media Devices, Gamepads, Pointers).

I recognize this async API suggestion fits better under "Standardization" and doesn't mesh well with the original API design paragraph. I think it's a worthwhile thing to integrate somehow into the doc, I don't really think it deserves its own BP though. Very open to thoughts.