- From: David Singer <singer@mac.com>
- Date: Mon, 28 Aug 2017 08:04:22 -0700
- To: "Matthias Schunter (Intel Corporation)" <mts-std@schunter.org>
- Cc: public-tracking@w3.org
I don’t know why we are changing design in these (subtle?) ways at this point. Can you remind me what we were trying to fix?
> On Aug 25, 2017, at 2:49 , Matthias Schunter (Intel Corporation) <mts-std@schunter.org> wrote:
>
> Hi Folks,
>
> my goal would be to satisfy the requirements of the industry in this
> group ;-)
>
> UNDERSTANDING THE PROBLEM
>
> I would like to enhance our understanding before converging on a design.
>
> I understand the fingerprinting risks of UGE for sub-domains
> (b1.site.com, bit2.site.com, ...). Mitigating the risks would be desirable.
>
> I do not understand why this same risk is not there for the main site.
>
> I also do not understand why site-wide exceptions should not be allowed
> (I do not see their fingerprinting risk) and I agree that allowing
> google to, e.g., ask for a "youtube.com" UGE in an iframe is a desirable
> use case.
>
> ENUMERATING POTENTIAL SOLUTIONS
>
> [1. Keep the old design] - allow UGE also for sub-contexts. This is the
> default unless we reach consensus to change something.
>
> This would allow web-wide and site-specific.
>
> One way to mitigate the fingerprinting risk of specific sub-domains in
> this scenario would be to limit the number of patterns that can be
> registered (e.g. 5 patterns should constitute at most 5 bits). This can
> be done as an implementation recommendation.
>
> [2. Disallow UGE for sub-contexts] This would IMHO break the google
> usecase above, would mitigate the fingerprinting risk for sub-contexts,
> would still allow sites to use this bit-wise mechanism for fingerprinting.
>
> [3. Only allow web-wide UGE for sub-contexts] This would mitigate
> fingerprinting for site-specific UGE. Since I did not understand why we
> wanted to disallow web-wide exceptions, I do not see a downside.
>
>
> DISCUSSION
> - I would appreciate if we continue populating the "understanding" and
> "potential solution" perspectives before picking a given solution.
>
> By default (unless we reach a new consensus), we will stick to the old
> consensus and will not change the spec fundamentally. If we see a risk,
> I would add a note and see what feedback we receive.
>
>
> Any suggestions/input/feedback/solutions?
>
>
> Regards,
> matthias
>
>
>
>
> On 25.08.2017 10:03, Mike O'Neill wrote:
>> Hi Shane,
>>
>>
>>
>> Only some industry.
>>
>>
>>
>> The trend is for subresources to not be able to set a cookies, i.e.
>> Safari, especially the new ITB which effectively creates separate silos
>> for subresource cookies, i.e. they are not web-wide. If we allow
>> web-wide consent from iframes with no check I doubt most browsers will
>> implement it.
>>
>>
>>
>> It also fails the “specific” test for lawful consent under EU DP/privacy
>> law.
>>
>>
>>
>>
>>
>> Mike
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> *From:*Shane M Wiley [mailto:wileys@oath.com]
>> *Sent:* 25 August 2017 04:45
>> *To:* Mike O'Neill <michael.oneill@baycloud.com>
>> *Cc:* Matthias Schunter (Intel Corporation) <mts-std@schunter.org>;
>> public-tracking@w3.org; Roy T. Fielding <fielding@gbiv.com>
>> *Subject:* Re: confirm and fingerprinting issues
>>
>>
>>
>> Working Group,
>>
>>
>>
>> This will likely be a non-starter for industry then. We specifically
>> reviewed this concept when the UGE API was first written and everyone
>> was supportive at that time ("NAI Opt-Out Model in reverse"). I'm
>> struggling to understand why a domain can set a cookie in an iFrame but
>> we're going to restrict setting an exception...?
>>
>>
>>
>> - Shane
>>
>>
>>
>> On Thu, Aug 24, 2017 at 2:18 PM, Mike O'Neill
>> <michael.oneill@baycloud.com <mailto:michael.oneill@baycloud.com>> wrote:
>>
>> Shane.
>>
>>
>>
>> Nope, web-wide was specifically ruled out see:
>> https://w3c.github.io/dnt/drafts/tracking-dnt.html#exception-javascript-api-store
>> 6th para before end of section
>>
>>
>>
>> “This effectively limits the API for web-wide exceptions to the
>> single target domain of the caller”
>>
>>
>>
>> What we said Monday was the site-specific in a an iframe was
>> possible, but probably pointless.
>>
>>
>>
>> Mike
>>
>>
>>
>>
>>
>> *From:*Shane M Wiley [mailto:wileys@oath.com <mailto:wileys@oath.com>]
>> *Sent:* 24 August 2017 20:49
>> *To:* Mike O'Neill <michael.oneill@baycloud.com
>> <mailto:michael.oneill@baycloud.com>>
>> *Cc:* Matthias Schunter (Intel Corporation) <mts-std@schunter.org
>> <mailto:mts-std@schunter.org>>; public-tracking@w3.org
>> <mailto:public-tracking@w3.org>; Roy T. Fielding <fielding@gbiv.com
>> <mailto:fielding@gbiv.com>>
>> *Subject:* Re: confirm and fingerprinting issues
>>
>>
>>
>> Mike,
>>
>>
>> Agreed on web-wide for those scenarios but I thought we confirmed on
>> Monday that those would work in an iFramed approach?
>>
>>
>>
>> - Shane
>>
>>
>>
>> On Thu, Aug 24, 2017 at 12:39 PM, Mike O'Neill
>> <michael.oneill@baycloud.com <mailto:michael.oneill@baycloud.com>>
>> wrote:
>>
>> Shane,
>>
>>
>>
>> I think you need the web-wide exceptions for that and they are
>> already disallowed for iframes (unless they are for cookie rule
>> subdomains of the top-level domain). The site-specific exception
>> is pointless for other-origin iframes, other than to specify
>> same-party exceptions. It just lets you set a site-specific
>> exception for the iframe domain when it is later visited as a
>> first party.
>>
>>
>>
>> This way means you do not even have to use the iframes, it is
>> much faster.
>>
>>
>>
>> Mike
>>
>>
>>
>> *From:*Shane M Wiley [mailto:wileys@oath.com
>> <mailto:wileys@oath.com>]
>> *Sent:* 24 August 2017 19:35
>> *To:* Mike O'Neill <michael.oneill@baycloud.com
>> <mailto:michael.oneill@baycloud.com>>
>> *Cc:* Matthias Schunter (Intel Corporation)
>> <mts-std@schunter.org <mailto:mts-std@schunter.org>>;
>> public-tracking@w3.org <mailto:public-tracking@w3.org>; Roy T.
>> Fielding <fielding@gbiv.com <mailto:fielding@gbiv.com>>
>> *Subject:* Re: confirm and fingerprinting issues
>>
>>
>>
>> Mike,
>>
>>
>>
>> But wouldn't this break the industry "opt-in" page concept
>> though (similar to the current "opt-out" iFrame model)?
>>
>>
>>
>> - Shane
>>
>>
>>
>> On Thu, Aug 24, 2017 at 11:05 AM, Mike O'Neill
>> <michael.oneill@baycloud.com
>> <mailto:michael.oneill@baycloud.com>> wrote:
>>
>> While restricting the API to top-level context stops it
>> being used by bad
>> actors (to invisibly fingerprint), it also stops the
>> use-case Shane has
>> identified of being able to assign consent to multiple
>> domains. No longer
>> will it be possible to call the API from an iframe, so top
>> level script will
>> not be able to dynamically create browsing contexts that do
>> that.
>>
>> I think the only way to fix the security weakness is to stop
>> sub-resources
>> using the API, but it is very desirable to still allow the
>> registering of
>> exceptions for other-origin (though same-party) domains.
>> This will be useful
>> not just to larger sites.
>>
>> I think both can be done as long as a check is made that the
>> script-origin
>> controls the other domains. The security and privacy benefit
>> of disallowing
>> subresources using the API far outweighs any threat from
>> first-parties
>> getting it wrong.
>>
>> I spent today amending the API to show how this could be
>> specified using the
>> same-party array:
>>
>> https://w3c.github.io/dnt/drafts/samepartyawareapi.html#exceptions
>>
>> See Section 6. It is in a new file to be web readable. It
>> would be easy to
>> create a PR for it against the master branch.
>>
>> Another possible way to check that script origins control
>> other origins is
>> to use CORS (or fetch) , but this adds round-trips and
>> therefore would be
>> slow. The same-party way will be a lot more efficient. We
>> could add
>> CORS/fetch as belt and braces if people thought it necessary.
>>
>> Please take the time to consider this before Monday's call.
>>
>>
>> Mike
>>
>>
>> -----Original Message-----
>> From: Matthias Schunter (Intel Corporation)
>> [mailto:mts-std@schunter.org <mailto:mts-std@schunter.org>]
>> Sent: 22 August 2017 11:59
>> To: public-tracking@w3.org <mailto:public-tracking@w3.org>
>> Subject: Re: confirm and fingerprinting issues
>>
>> Hi Mike,
>>
>>
>> thanks for the clarification.
>>
>> I believe your resolution should substantially reduce the
>> fingerprinting
>> isk.
>>
>> Any other concerns/objections?
>>
>>
>> Regards,
>> matthias
>>
>>
>>
>> On 22.08.2017 11 <tel:22.08.2017%2011>:31, Mike O'Neill wrote:
>>> Matthias, subresources are already denied making web-wide
>> extensions (by
>>> Roy's last change). My suggestion is to generalise his
>> sentence to cover
>>> site-specific also.
>>>
>>> Mike
>>>
>>> -----Original Message-----
>>> From: Matthias Schunter (Intel Corporation)
>> [mailto:mts-std@schunter.org <mailto:mts-std@schunter.org>]
>>> Sent: 22 August 2017 09:39
>>> To: public-tracking@w3.org <mailto:public-tracking@w3.org>
>>> Subject: Re: confirm and fingerprinting issues
>>>
>>> Hi Mike,
>>>
>>> thanks for the clarification.
>>>
>>> I now (hopefully) understand: Instead of pushing an
>> identifier as a
>>> whole (9437489), you push individual bits (bit1-0, bit2-1,
>> bit3-1, ...).
>>> Then querying them gets efficient; only say 32 queries
>> (one per bit)
>>> needed ;-(
>>>
>>> Thos the "you can only query what you store" approach does
>> not mitigate
>>> this fingerprinting risk (it is efficient to query 32 bits).
>>>
>>> Your suggested mitigation is to disallow subresources from
>> requesting
>>> user-granted _site-specific_ exceptions (only the main
>> site is allowed
>>> to do so). They would still be allowed to request web-wide
>> exceptions
>>> (where this risk does not seem to exist).
>>>
>>> This seems to be a workable and efficient solution.
>>>
>>> Any thoughts?
>>>
>>>
>>> Regards,
>>> matthias
>>>
>>> PS: Am I right that the main site could still use
>> site-specific UGE
>>> approach for fingerprinting? Anything we can mitigate for
>> them?
>>>
>>>
>>>
>>> On 22.08.2017 10 <tel:22.08.2017%2010>:22, Mike O'Neill wrote:
>>>> 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 <http://b0.images.schunter.org>
>>>> b1.images.schunter.org <http://b1.images.schunter.org>
>>>> b2.images.schunter.org <http://b2.images.schunter.org>
>>>> .
>>>> .
>>>> .
>>>> B31.images.schunter.org <http://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 <http://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 <http://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 <mailto:mts-std@schunter.org>]
>>
>>>> Sent: 22 August 2017 07:44
>>>> To: Michael O'Neill <michael.oneill@btinternet.com
>> <mailto:michael.oneill@btinternet.com>>;
>>> public-tracking@w3.org <mailto:public-tracking@w3.org>
>>>> Cc: 'Roy T. Fielding' <fielding@gbiv.com
>> <mailto: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 <http://images.schunter.org>) can
>>>> obtain an exception for its
>> "tracker7289437923.images.schunter.org
>> <http://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
>> <http://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 <tel:21.08.2017%2021>: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 <http://subresorce.com>
>> loads 32 child iframes b0.subresource.com
>> <http://b0.subresource.com>,
>>>>> b1.subresource.com <http://b1.subresource.com>, ...,
>> b31.subresource.com <http://b31.subresource.com>.
>>>>>
>>>>> When it exists as a subresource on top-level site
>> example.com <http://example.com> for user
>>>> Alice
>>>>> it creates a UGE for targets bX.subresource.com
>> <http://bX.subresource.com>, bY.subresource.com
>> <http://bY.subresource.com>,
>>>> ...,
>>>>> bZ.subresource.com <http://bZ.subresource.com> . i.e. a
>> random 32 bit pattern unique to Alice.
>>>>>
>>>>> When Alice later revisits example.com
>> <http://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 <http://subresource.com> can recognise
>>>>> Alice without having to place a third-party cookie. It
>> cannot do this
>>>> for
>>>>> sites other than example.com <http://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
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>>
>>
>>
>> --
>>
>> - Shane
>>
>>
>>
>> Shane Wiley
>>
>> VP, Privacy
>>
>> Oath: A Verizon Company
>>
>>
>>
>>
>>
>> --
>>
>> - Shane
>>
>>
>>
>> Shane Wiley
>>
>> VP, Privacy
>>
>> Oath: A Verizon Company
>>
>>
>>
>>
>>
>> --
>>
>> - Shane
>>
>>
>>
>> Shane Wiley
>>
>> VP, Privacy
>>
>> Oath: A Verizon Company
Dave Singer
singer@mac.com
Received on Monday, 28 August 2017 15:05:02 UTC