Re: [w3ctag/spec-reviews] Browser Fingerprinting Document (#38)

Hey Nick,

Thanks for bringing this up.

We're happy to see the name change. Thanks for doing that!

Regarding the definitions of fingerprinting types ("Passive", "Active", and "Cookie-like"): the name "Cookie-like" is a bit tough. The second sentence in "Passive" seems to imply that cookie storage is handled by "Passive". Is "Cookie-like" a superset of "Passive"? If not, should "Cookie-like" be called "Supercookie"?

At a higher level, I'm struggling with how to consider using this document with engineers on my team who want to do the right thing. I.e., if someone came to me and asked me to review a spec, I'm not sure that handing them this document would clarify anything for them about how to design their feature.

This might be because the document lacks examples? For instance, in "Best Practice 1" it'd be great to understand how a specific design(s) might be changed to be better. What's the razor for "unnecessary"? What sort of changes shouldn't be undertaken because they would be too costly or defeat a feature?

Consider the hypothetical conversation with an engineer who wants review:

 - Their API includes some method which stores some data in a persistent way
 - In a review, I'd ask them something along the lines of "so, what control does the user have over setting and clearing this?". Normally that implies integration with cache/data clearing UI. If something is settable but not clearable (by design), I'd flag it for the privacy team to review (this is your "Cookie-like" bucket). That higher level of invasiveness is something we don't want in the platform and the TAG finding on unsanctioned tracking is now the "Big Stick" that I (and others) can use to prevent such features from being added.
 - Assuming a feature can be reworked to put things under positive user control, I'm not sure where I'd apply Best Practices 7 and 8 in the review. Lets say the question is "access to local fonts". This is a capability that would be behind a permission prompt. What's the actionable guidance from this document for a designer of such a feature? Would it be to not add it? Language to possibly include in the prompt? Guidance on ambient usage indicators to let users know when these sorts of features are being accessed? Discussion of how to enable/disable them from iframes and sub-documents (vs. top-level documents)? Re-designing the feature to consult a service with a list of known fonts? Some way to remove uncommon fonts (again, perhaps via bloom filter from a service) to reduce the capacity for fingerprinting? Or is the permission prompt "enough"?

Cataloging those sorts of mitigations and the decision tree (with examples) might be a good way to help make this document more actionable.

In general the TAG is supportive of this work and we'd like to see a version of this valuable effort move forward. Thanks again for persisting through our sporadic feedback.

Regards

---
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/spec-reviews/issues/38#issuecomment-236352266