Discussed in NYC; @mnot to start.

Discussed in SF; scheduled for 5-20

Discussed 5-20 we may run a special session in Berlin on this.

Discussed in Boston.

@mnot is happy with the revised version. @slightlyoff needs to feed back as well.

I have some concerns:

• the recent TAG Finding on Unsactioned Tracking appears to be more actionable regarding how we might guide spec/feature designers in specific areas like storage mechanisms
• Best Practice #1 in this document seems to guide in an ambiguous way. What's "unnecessary"? Who decides?
• Best Practice #3 and #6 seems like the strongest, most actionable advice.
• Reducing available entropy and storage (BP's 4, 5, 7) seem as though they're either deeply confused or are unsupportable as general principles. We discussed this in the Unsanctioned Tracking finding and these points appear to be incompatible with that finding.
• Perhaps BP #8 might have some relationship to @mikewest's new work on Clear Site Data?: https://w3c.github.io/webappsec/specs/clear-site-data/

In general, I'm not sure that there's much in here the TAG would be able to use in a spec review to help guide a designer to build a more functional, privacy-respecting design. Side-channels exist and as we covered in the Finding, it seems useful to guide developers towards actionable tradeoffs. Else we need to come to a new understanding of the overall (non privacy/incognito-mode) thread model.

IG note published in November: https://www.w3.org/TR/2015/NOTE-fingerprinting-guidance-20151124/

This feedback doesn't appear to have been addressed.

/cc @npdoty (esp. regarding previous comment)

Hey all (/me waves at @npdoty):

It looks like the Draft NOTE doesn't include changes based on the comments we left in Sept. Eager to have a conversation about those and come to some consensus.

Perhaps we can schedule some time on an upcoming call to discuss?

/cc @torgo and @plinss re: scheduling

@torgo to contact @npdoty to schedule a call

Have done & will schedule for a future call.

Thanks for the note. I tried to do a pass to address TAG feedback earlier, but I think I was responding to a different list than what is described by @slightlyoff above. (Also, I may have been guilty of focusing on addressing the issues I best knew how to address.) Happy to talk more, and thanks @torgo for scheduling.

Hi @npdoty – have put this on our agenda for next week (2-feb).

Taken up on call in Feb 2016 minutes

https://github.com/w3c/fingerprinting-guidance/issues/5 not yet resolved... @npdoty can you update on the status?

Edits made this month attempt to address the naming issue (w3c/fingerprinting-guidance#5) and add several examples, which I noted during our February call might address concerns or at least elucidate where we disagree. @slightlyoff, you might look at those now and see if that helps, or at least, I'm at the point where I'll need more info from you to understand your concerns. (The minutes from the February call might also explain my position and what I don't understand.)

On the challenge of explaining how specifications should handle the trade-off, would it help to combine Best Practices 1 and 2 and note that, when trying to balance functionality with additional fingerprinting surface, a key consideration is especially to avoid increases in the passive surface?

We are reviewing today in the TAG f2f.

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

One other thought about the active / passive / cookie-like split in section 3. It seems that perhaps being cookie-like is orthogonal to active vs. passive (e.g., cookies are cookie-like and passive, while indexed db is cookie-like and active). If that's the intent, maybe it should be clearer that cookie-like isn't mutually exclusive with active and passive.

I also wonder two other things: whether cookie-like features actually should be considered part of "fingerprinting" (as stated in section 1), and whether supercookies that aren't clearable should be part of the cookie-like category or should instead just be considered bugs (in spec or implementation) of a more severe category.

Discussed at the TAG f2f in Boston. https://pad.w3ctag.org/p/2017-02-08-minutes.md

@wseltzer said: This is sitting with PiNG. Nick is deep in his PhD, so this is unlikely to have changed since your last review. I will make sure PiNG pings TAG when it's ready for another review.