Role of prompting as mitigation #21
Comments
|
Re: #20 and #21: "availability", listed as one of the severity factors in evaluating fingerprinting surface, notes that characteristics available only after a permission prompt are less severe than those available to the drive-by Web. I think it's better to have it as a severity/mitigation rather than part of the definition itself, as it still might be part of browser fingerprinting, it's just less likely to be a severe problem. In terms of mitigation, I plan to add an example to BP 1 on limiting severity of new fingerprinting surface to discuss permission prompts as one possibility (though probably more of a last resort), or making that part of splitting up that best practice into a few distinct suggestions. |
…sive fingerprinting surface and 2) narrow scope and availability, including with permission prompts * note permission prompts as mitigation #21 * add example of Media Capture permissions for media device labels * add a separate best practice for server-side opt-in on HTTP requests, as a kind of experimental option, with Client Hints design as the example * make a clearer, numbered action list (removed issue box #13) * removed a note/question box in privacy impacts
|
See http://w3c.github.io/fingerprinting-guidance/#narrow-scope-availability for a best practice noting permission gating as one mitigation, with example |
In the vein of #20, it seems worthwhile to add a suggestion to consider adding prompting as a mitigation if no other fingerprinting mitigation can be implemented.
The text was updated successfully, but these errors were encountered: