- From: David Singer <singer@apple.com>
- Date: Thu, 12 Oct 2017 10:27:21 +0200
- To: Mike O'Neill <michael.oneill@baycloud.com>
- Cc: Shane M Wiley <wileys@oath.com>, "Matthias Schunter (Intel Corporation)" <mts-std@schunter.org>, public-tracking@w3.org, Shane Wiley <wileys@yahoo-inc.com>
> On Oct 12, 2017, at 10:15 , Mike O'Neill <michael.oneill@baycloud.com> wrote: > > Hi David, > >> One obvious way to do this would be to allow the server to register a DNT-extension string when asking for the exception. >> We add to the bag an optional parameter, DNT-extension-string; and when the exception applies, >> and the UA sends a DNT:0 to the servers, it appends “;” and the DNT-extension-string registered in the exception. > > 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. > >> However, for site-wide exceptions, especially ones that are not limited to an enumerated list of domains, >> this exception causes DNT:0 to be sent to all embedded sites. I have some anxiety that not all of them will understand. >> On the other hand, why is the site registering for the exception asking for site-wide exceptions if it’s not confident of >> the way that all embedded sites will handle ‘permission to track’ i.e. the consequent DNT:0? On the third hand, >> the UA is allowed to take an site-specific exception request that HAS got a list of domains that, when embedded on this site, >> get DNT:0, and IGNORE that list and ‘broaden’ the request to a general site-wide request. > > The same DNT header does not have to be sent to every site-specific UGE target. Bouncer, for example, calculates the header for each request, using data from the requested origin as well as the current parent. The purpose string would be similarly calculated after examining that subresource's TSR. The user-agent can’t possibly do a fetch of a TSR in order to work out what header to send in fetch requests…I must misunderstand what you say here. It’s both circular and an overhead. > > >> On Oct 12, 2017, at 4:37 , Shane M Wiley <wileys@oath.com> wrote: >> >> Mike, >> >> Custom vs. Standard List of Purposes: I believe the list will have to be somewhat custom (defined by the domain) as different companies may refer to the purposes and their definition of the scope of those purposes in different ways to align with their privacy practices. For example, a 1st party obtaining consent for a specific communications purpose will likely not map to a 3rd party purpose specific to profiling or mapping identities. >> >> I'm not sure I understand this question "The complicated one is selecting an arbitrary domain for DNT:0 based on purpose, but maybe this is not required - Shane?" Could you please explain what you mean by "selecting an arbitrary domain for DNT:0"? >> >> - Shane >> >> On Wed, Oct 11, 2017 at 10:33 AM, Mike O'Neill <michael.oneill@baycloud.com> wrote: >> We should differentiate between conveying a set of agreed purposes to a server, and selecting what DNT is for a particular domain which declares a set of purposes. >> >> >> >> The former is relatively easy to fix. We just use the DNT header extension, and limit the entropy as Shane suggests. The DNT header would only allow the extension if the TSV was 0. >> >> >> >> So: >> >> DNT:0;p=2A >> >> “;” to separate the extension components (we may have others in future), p= introduces the array of purposes which is hex encoded bit pattern with a max length of (say) 10 and a purpose is either selected (1) or not (0). The above bit pattern 2A means 00101010 i.e. purposes 3,5 and 7. >> >> 10 bits can at most select 1024 individuals, so limited use for fingerprinting. >> >> >> >> A user agent would never send a DNT:1 header with any extensions. i.e. just DNT:1, and the purposes array would be constrained to be as above. >> >> >> >> We would have to come up with an agreed set of purposes, but that should not be too difficult. Maybe that could be left to the EDPB? >> >> >> >> The complicated one is selecting an arbitrary domain for DNT:0 based on purpose, but maybe this is not required - Shane? >> >> >> >> >> >> Mike >> >> >> >> >> >> From: Shane M Wiley [mailto:wileys@oath.com] >> Sent: 11 October 2017 17:41 >> To: Matthias Schunter (Intel Corporation) <mts-std@schunter.org> >> Cc: Mike O'Neill <michael.oneill@baycloud.com>; public-tracking@w3.org; Shane Wiley <wileys@yahoo-inc.com> >> Subject: Re: Next 2 calls canceled (Oct 09 and Oct 16) >> >> >> >> Matthias, >> >> >> >> On option #1 - legal minds are stating this will not be possible. While the concepts of "all-or-nothing" and "tracking-walls" are still heavily debated, I believe we'll need to develop a solution that supports a data subject's ability to selective consent to some of the requested purposes (versus all or none of them). >> >> >> >> On option #2 - if we are required to use cookies to facilitate the consent process then there is little to no utility in DNT. Industry can just use cookies for the entire process. The motivation for leveraging DNT over cookies is that these are held out under separate controls from cookies - and hopefully avoid proactive blocking activities such as 3rd party cookie blocking and Apple's ITP. We're trying to do the right thing here so let's not punish good actors in the fear of bad actors. >> >> >> >> The discussion on fingerprinting in this context is a bit of a red herring IMHO. The number of legitimate purposes should be small (6 or less). In all cases there is a full record of the UGE registration so those misusing this feature for illegitimate means can be quickly tracked (back to the specific domain) and dealt with -- versus other forms of fingerprinting which are often invisible to the browser. >> >> >> >> - Shane >> >> >> >> On Wed, Oct 11, 2017 at 6:29 AM, Matthias Schunter (Intel Corporation) <mts-std@schunter.org> wrote: >> >> Hi Shane, >> >> thanks a lot for documenting this important usage. >> >> If I understood correctly, your goal is to bind consent to a set of >> purposes. I.e. the goal is that a party can obtain information on "yes, >> I obtained consent for purpose2, 8, and 15 from the user browsing the page. >> >> While including purpose into UGE is a viable option, it may not be the >> best way to achieve your goal. If a site can learn (per user) what >> purposes have been enabled, then fingerprinting risks may be high. It >> may be hard for us to define the right set of purposes. Finally, I >> expect that we are not allowed to extend beyond year end unless new >> members join our WG - A delay may be deadly in this case. >> >> I see two potential ways to implement what you need and would like to >> discuss different implementation options (not sure whether mine work >> indeed better): >> >> 1. STATIC PURPOSES PER SITE >> - A site documents a set of purposes SP in its privacy policy (and >> potentially (extension) in the TSR >> - A site explains the purposes to the user >> - A user grants consent >> - The site registers an UGE >> - Next time, the site obtains a DNT;0 >> - The site knows that it now has consent for the purposes in SP >> >> 2. DYNAMIC PURPOSES PER SITE >> - A site documents a set of purposes SP in its privacy policy (and >> potentially (extension) in the TSR >> - A site explains the purposes to the user >> - Each user grants consent _TO A SUBSET OF THE PURPOSES_ >> - One of these purpose must be setting a cookie for keeping preferences >> - The site registers an UGE (this at least allows setting a cookie) >> - The site stores a cookie that contains or links to the >> consented purposes >> - Next time, the site obtains a DNT;0 >> - The site retrieves the cookie >> - The site knows that it now has consent for the purposes referenced by >> the cookie >> >> I suggest whether we find a viable way to implement your usage. If you >> have additional implementors, I would like to invite them to the group >> (as visitors) to explain their requirements in order to understand the >> constraints further. >> >> Regards, >> matthias >> >> >> >> On 10.10.2017 03:26, Shane M Wiley wrote: >>> Submitted: https://github.com/w3c/dnt/issues/60 >>> >>> - Shane >>> >>> On Mon, Oct 9, 2017 at 9:09 AM, Shane M Wiley <wileys@oath.com >>> <mailto:wileys@oath.com>> wrote: >>> >>> Working on it now - will have it out by days end (apologies - >>> attending a wedding across the coast last week so I'm a bit behind). >>> >>> - Shane >>> >>> On Sun, Oct 8, 2017 at 10:23 AM, Mike O'Neill >>> <michael.oneill@baycloud.com <mailto:michael.oneill@baycloud.com>> >>> wrote: >>> >>> Is this an issue posted recently? I see nothing on the list. >>> >>> >>> >>> -----Original Message----- >>> From: Matthias Schunter (Intel Corporation) >>> [mailto:mts-std@schunter.org <mailto:mts-std@schunter.org>] >>> Sent: 08 October 2017 16:25 >>> To: public-tracking@w3.org <mailto:public-tracking@w3.org> >>> (public-tracking@w3.org <mailto:public-tracking@w3.org>) >>> <public-tracking@w3.org <mailto:public-tracking@w3.org>> >>> Subject: Next 2 calls canceled (Oct 09 and Oct 16) >>> >>> Hi Folks, >>> >>> I will be travelling for 2 weeks. I suggest to cancel the call >>> tomorrow >>> (Oct 08) and the week afterwards (Oct 16). >>> Sorry for the short notice. >>> >>> In the subsequent call, I would like to discuss the issue Shane >>> raised. >>> Shane: Could you outline your usage/requirements/issue in the github >>> issue tracker? >>> >>> >>> Regards, >>> matthias >>> >>> >>> >>> >>> >>> -- >>> - 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 >> >> >> >> >> -- >> - Shane >> >> Shane Wiley >> VP, Privacy >> Oath: A Verizon Company > > Dave Singer > > singer@mac.com > > > David Singer Manager, Software Standards, Apple Inc.
Received on Thursday, 12 October 2017 08:28:02 UTC