RE: Next 2 calls canceled (Oct 09 and Oct 16)

David,

Presumably part of the rationale for ITP was to stop entities executing code to avoid the default third-party cookie blocking in Safari. If the store API can specify arbitrary extension strings, then the DNT header becomes identical to a perpetual cookie which can be used even if third-party cookies are blocked, in one line of javascript from any sub resource iframe. It does not even need any collaboration via first-party script (which was needed to avoid the original cookie blocking).

I get your point about the site-wide site-specific but that would not apply if the user has giving specific consent for particular purposes. The site-wide could not be used in that case.

Mike



-----Original Message-----
From: singer@apple.com [mailto:singer@apple.com] 
Sent: 12 October 2017 11:40
To: Mike O'Neill <michael.oneill@baycloud.com>
Cc: public-tracking@w3.org (public-tracking@w3.org) <public-tracking@w3.org>
Subject: Re: Next 2 calls canceled (Oct 09 and Oct 16)



> On Oct 12, 2017, at 11:49 , Mike O'Neill <michael.oneill@baycloud.com> wrote:
> 
>>> This lets a bad actor misuse the API for fingerprinting. Specify an
> arbitrary string then always get the same string back
>>> in other requests.
> 
>> Um, Mike, it’s only going to servers that the user has agreed may track.
> I’m not terribly fussed about improve the
>> fingerprintability of users who already agree to being tracked.
> 
> The bad actor won't care if the user has agreed or not, they will just use
> the API (from a subresource). It gets round any third-party cookie blocking,
> so it will happen.
> 
> 

Mike, if a bad actor (a) can set an exception that claims to have the user’s consent but does not or (b) leverages an exception that has been granted based on another’s request (e.g. a site-wide), to do evil, the presence of a slightly larger fingerprint is a minor concern.

> On Oct 12, 2017, at 11:49 , Mike O'Neill <michael.oneill@baycloud.com> wrote:
> 
> When the store API is called it would fetch the TSRs for each of the
> Targets, we already say they may do that. The TSRs are then put into domain
> specific store (maybe just the purpose array ). When requests get sent the
> domain store is examined (it must anyway, if only to get cookies) and the
> DNT extension is calculated. Pretty efficient.

The UA can only fetch the TSR for named targets, not for a site-wide (target=“*”) exception. And if the array of targets in the exception request is large, this could be very tedious.

David Singer
Manager, Software Standards, Apple Inc.

Received on Thursday, 12 October 2017 11:31:21 UTC