confirm and fingerprinting issues

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 Monday, 21 August 2017 19:19:39 UTC