Provide guidelines or heuristics to prevent fingerprinting in case permission is denied

[youennf]

https://w3c.github.io/permissions/#privacy-considerations discusses privacy concerns.

One case that is of concern is if the user is not trusting the website and is permanently denying the permission.
This could be used as a permanent fingerprint that is more difficult to clean up than other website data like cookies.

One potential countermeasure is that Permissions API would only expose the denied state after the web site actually tries to call the API requesting access.

For instance, a web page is loaded on a site where camera is denied permanently:

• page calls Permissions API and 'prompt' is returned instead of the actual 'denied' state.
• page calls getUserMedia, no prompt is shown, NotAllowedError is returned.
• page calls Permissions API and now understands that permission is permanently denied. Page provide guidelines to user in case user wants to change the persistent setting.

Thoughts?

[jyasskin]

How do you envision this set of denied permissions being used to discover that 2 visits on different top-level sites come from the same person?

[KOLANICH]

I think denied state should always ge exposed by default.

[youennf]

How do you envision this set of denied permissions being used to discover that 2 visits on different top-level sites come from the same person?

One possibility is for the two web sites to go to the same origin C and then navigate to the actual page (say when both pages are in the background).
While clearing C cookies/website data regularly is usually good enough, permissions are more difficult to clear (they are more visible to users) and tend to be more persistent as well.

I think denied state should always ge exposed by default.

Can you detail potential downsides?
For instance, can you describe how the above heuristic would break well-behaving applications?