[tbb-dev] FWD: privacy/security guidance docs for W3C groups

[Georg Koppen]

Hi,

mikeperry at 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 at yahoo-inc.com> -----
> 
> Date: Thu, 19 Mar 2015 16:06:27 +0000 (UTC)
> From: Yan Zhu <yzhu at 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:
> 
> * https://mikewest.github.io/spec-questionnaire/security-privacy/ - a
> 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tbb-dev/attachments/20150424/e9eff139/attachment.sig>