RE: confirm and fingerprinting issues

Hi Matthias,

That is not quite what I meant. The fingerprinting I identified would allow
the subresource to assign a random number (up to 32 bits long in my
example), because there are 32 sub-subresources (lets call them
grandchildren of the first-party site):

b0.images.schunter.org
b1.images.schunter.org
b2.images.schunter.org
                  .
                  .
                  .
B31.images.schunter.org

Each grandchild represents one bit in the 32 bit string.

If an exception exists for a particular grandchild, that represents a 0 at
that particular bit position
Otherwise the value of the bit is 1.

The value of each grandchild "bit" is communicated back to
images.schunter.org by each grandchild detecting its DNT header (say by
reading navigator.doNotTrack), then sending the 1 bit value in a message
using the postMessage API.

Then images.schunter.org receives all these messages and assembles the
original 32 bit string from them.

Note, this does not need the confirm call, though it could. Restricting the
confirm call does not fix the risk because the same information can be
obtained via postMessage.

This is complicated, but it is just javascript. Once it is done it will be
easy to reproduce. It gives subresources the ability to generate UIDs even
when they are blocked from using cookies e.g. on Safari. There are already
other more complicated methods for doing this in the wild, one of the
reasons for Apple's ITB in OS11.



Mike






-----Original Message-----
From: Matthias Schunter (Intel Corporation) [mailto:mts-std@schunter.org] 
Sent: 22 August 2017 07:44
To: Michael O'Neill <michael.oneill@btinternet.com>; public-tracking@w3.org
Cc: 'Roy T. Fielding' <fielding@gbiv.com>
Subject: Re: confirm and fingerprinting issues

Hi Mike,


thanks a lot for the analysis of fingerprinting.

If I understand correctly, a sub-resource (say images.schunter.org) can
obtain an exception for its "tracker7289437923.images.schunter.org"
where tracker7289437923 is unique to a user for this subdomain. Since
tracker7289437923 is unique, your concern is that by learning that there
is a UGE for tracker7289437923, the site knows what user is visiting.

I believe that this is not a severe fingerprinting risk for the
following reason:

Assume that the web-site has registered a table of UGEs
  TRACKERID		NAME
  tracker7289437923 	Joe
  tracker728laksdjh	Jim
  trackerk823982089	Helen
  ....

In theory, obtaining a line from this table allows fingerprinting.
However, our "confirm" API only allows to verify whether a single line
exists. I.e. I could indeed confirm whether I am talking to a given user:
- if confirm("tracker7289437923.images.schunter.org") is true, then I am
talking to Joe.

However, using the scheme to fingerprint larger numbers of users seems
not really feasible: One needs to call the confirm() API once for each
subdomain that corresponds to each potential user:
  tracker7289437923 	
  tracker728laksdjh	
  trackerk823982089	
  ....

Ensuring this was the rationale (AFAIR) that David Signer insisted that
confirm must be called with the exact parameters of the store() call.

What do you think? If we agree that there is still a larger risk, we
should investigate your potential resolution (which I have not checked
in detail yet; since I am not 100% sure I see the risk).

Any feedback is welcome!

matthias




On 21.08.2017 21:19, Michael O'Neill wrote:
> I think the web-wide issue is fine with Roy's sentence:
> 
> For each of the targets in a web-wide exception, a user agent must not
store
> the duplets and must reject the promise with a DOMException named
> "SecurityError" unless the target domain matches both the
document.domain of
> the script's responsible document and the document.domain of the
top-level
> browsing context's active document [HTML5]. This effectively limits the
API
> for web-wide exceptions to the single target domain of the caller.
> 
> This limits web-wide consent to the top-level browsing context which was
how
> it always was supposed to be.
> 
> But as the text is now, a subresource browsing context (aka an iframe)
can
> still specify a site-specific exception for itself and its own set of
> targets. This could be a danger because it allows a third-party
subresource
> to invisibly create arbitrary exceptions for itself, which it can then
use
> to fingerprint the user agent. It would do this by creating  a set of
> subresource iframes and establishing a UGEs for a random set of them.
> 
> For example, subresorce.com loads 32 child  iframes b0.subresource.com,
> b1.subresource.com, ..., b31.subresource.com. 
> 
> When it exists as a subresource on top-level site example.com for user
Alice
> it creates a UGE for targets bX.subresource.com, bY.subresource.com,
...,
> bZ.subresource.com . i.e. a random 32 bit pattern unique to Alice.
> 
> When Alice later revisits example.com DNT:0 will be sent in requests for
the
> subset of targets specified in the UGE. These subresources can then
> communicate back to the parent subresource the value of DNT they have
> received, using the postMessage API. Thus subresource.com can recognise
> Alice without having to place a third-party cookie. It cannot do this
for
> sites other than example.com, but it is still a privacy risk.
> 
> We do not have a use case for a subresource initiated site-specific UGE,
so
> why do we need it? the easiest way to fix this is simply to adopt Roy's
> wording for all UGEs, not just web-wide ones.
> 
> For the other issue, making the confirm call (now called
> Navigator.trackingExceptionExists) capable of confirming exceptions for
> cookie rule subdomains as Navigator.storeTrackingException does, I
suggest
> the following derived from Roy's definition of "site" for
> storeTrackingException, with a lone "*" illegal:
> 
> site
> The referring domain scope where an exception should be confirmed:
> If site is undefined, null, or the empty string, the referring domain
scope
> defaults to the [site domain].
> Otherwise, the referring domain scope is defined by a domain found in
site
> that is treated in the same way as the domain parameter to cookies
> [RFC6265], allowing subdomains to be included with the prefix "*.". The
> value can be set to a fully-qualified right-hand segment of the document
> host name, up to one level below TLD. If such a domain scope cannot be
> parsed then the user agent must reject the promise with the DOMException
> named "SecurityError"
> 
> Comments?
> 
> Mike
> 
> 
> 
>

Received on Tuesday, 22 August 2017 08:23:33 UTC