Hi,
mikeperry@torproject.org:
Yan was kind enough to send this to me as a heads up. We both agreed that the Security & Privacy questionnaire needs a Threat Model for Third Party Tracking, so that it is easier to build a single option for controlling third party tracking identifiers, like we did with our 'privacy.thirdparty.isolate' option.
She suggested that we should create an issue for this at https://github.com/mikewest/spec-questionnaire/issues, describing how Tor Browser deals with this threat model, and what we would like to see in terms of how API designers should address it.
Are there any other issues or suggestions we should make there, in either that document, or the fingerprinting guidance draft?
Below I have added some points after reading the draft closely and thinking a bit about it. The issue you raised wrt to the questionnaire is a good one and I don't have to add here anything, I think. ,
----- Forwarded message from Yan Zhu yzhu@yahoo-inc.com -----
Date: Thu, 19 Mar 2015 16:06:27 +0000 (UTC) From: Yan Zhu yzhu@yahoo-inc.com Subject: privacy/security guidance docs for W3C groups
Hi technologist-ish people, The W3C has been working on some privacy and security guides for working groups to consider when writing new specs. As you probably know, it has historically been easy for new specifications to accidentally (or intentionally) introduce web tracking methods and increase browser security surface. We are trying to take steps towards preventing this by encouraging/forcing working groups to do a security/privacy self-review of specs in the future. I'd be curious to hear your feedback on the following two guides if you have any:
general collection of security/privacy questions that groups should ask about new specs
- https://w3c.github.io/fingerprinting-guidance/ - a guide to mitigating
fingerprinting. I'm thinking the "Best Practices Section" could get merged into the questionnaire above.
Comments on the draft:
A)
I think the section 4 is good and the differentiation between active and passive fingerprinting might be helpful as an analytical distinction and providing us some knobs to make better recommendations e.g. for spec writers.
That said, I think the draft conflates fingerprinting and linkability a distinction we should keep as it helps us structuring the tracking landscape in a meaningful way. This can be seen in 3.3 and 5.4 which is actually the thing we describe as linkability. If that is in the scope of the draft, too, maybe it should be "Tracking Guidance" and not "Fingerprinting Guidance". The difference between linkability and fingerprinting can sometimes even be found in the text itself:
"Fingerprinting also allows for tracking across origins: different sites may be able to combine information about a single user even where a cookie policy would block accessing of the cookies between origins, because the fingerprinting is relatively unique and the same for all origins."
But then on the other hand there are things like
"Passive fingerprinting would trivially include cookies."
Another thing I was wondering was the mentioning of "entropy" as kind of a metric for fingerprintability. What does the draft mean with it? Is it the right concept for the issue at hand at all? I think an own section talking at least a bit about measuring/quantification of fingerprinting surface might not be bad and would aid in understanding the guidance.
B)
Apart from these larger issues there are some smaller ones:
The draft asks "What is fingerprinting?" but then answers what browser fingerprinting is while the reader is expecting to get to know what is meant by "fingerprinting" generally.
"but still face the danger of browser fingerprinting to correlate their Web-based activity." in 2.1.1 does belong into 2.1.2.
C)
I think we can say something about the points in 5.2 when we fill in the Tor Browser specific parts after the design documentation update!? Especially the standardized profile and randomization things seem be worth talking about.
Georg