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 06:44:47 UTC