- From: David Singer <singer@apple.com>
- Date: Wed, 22 Oct 2014 09:37:03 +0200
- To: Justin Brookman <jbrookman@cdt.org>
- Cc: Shane M Wiley <wileys@yahoo-inc.com>, Tracking Protection Working Group <public-tracking@w3.org>
Seems reasonable. *If* we add an expiration parameter, I suggest it be on both calls to record an exception. We don’t need the calls differing needlessly. Does someone know current best practice for how to express an expiration time in a ‘set’ call like this? On Oct 21, 2014, at 23:31 , Justin Brookman <jbrookman@cdt.org> wrote: > David had been the leading opponent of including an expiry parameter for exception-setting APIs; it sounds like he may be willing to support so long as we’re retaining the mechanism for granting web-wide exceptions. Do others object to Mike’s proposed language (or want to tweak it to address their concerns)? > > On Oct 15, 2014, at 3:52 PM, David Singer <singer@apple.com> wrote: > >> >> On Oct 15, 2014, at 12:19 , Shane M Wiley <wileys@yahoo-inc.com> wrote: >> >>> David, >>> >>> I believe terseness is warranted in this case. >> >> Thanks, what you say below explains what I needed, so that was less terse. >> >>> The core difference between UGE and Cookies is that UGE survives cookie removal exercises much like a DNT setting does. Web-wide exceptions are for a singular domain to be provided an exception in any 3rd party scenario that domain is encountered - something 3rd parties will be motivated to obtain if they ever support DNT - all types of 3rd parties not only large social networks. This will be the only option for ad networks, trading desks, agencies, etc. to obtain a consent to apply to their business across the Internet. >> >> So, agreed, the difference is the expiry/deletion model; we hope that UGEs won’t get wholesale cleared quite as often as cookies >> >>> >>> - Shane >>> >>> -----Original Message----- >>> From: David Singer [mailto:singer@apple.com] >>> Sent: Wednesday, October 15, 2014 12:08 PM >>> To: Shane M Wiley >>> Cc: Tracking Protection Working Group >>> Subject: Re: tracking-ISSUE-266: automatic expiration of a tracking preference exception via API parameter [TPE Last Call] >>> >>> >>> On Oct 15, 2014, at 10:48 , Shane M Wiley <wileys@yahoo-inc.com> wrote: >>> >>>> Removing the option for web-wide exceptions is a non-starter as that's the only tool expected to be used by 3rd parties that are most impacted by this standard. >>> >>> Can you be a little less terse? My impression is that web-wide is >>> a) most useful for sites that have a presence over multiple other sites, and for which the user would perceive an advantage to being tracked ('track my reading', facebook, etc.) I don't see advertisers falling into this category very much >>> b) the only difference between a UGE Webwide and a cookie is maybe the expiry/deletion model. >>> >>> >>>> >>>> - Shane >>>> >>>> -----Original Message----- >>>> From: David Singer [mailto:singer@apple.com] >>>> Sent: Wednesday, October 15, 2014 10:09 AM >>>> To: Tracking Protection Working Group >>>> Subject: Re: tracking-ISSUE-266: automatic expiration of a tracking preference exception via API parameter [TPE Last Call] >>>> >>>> I think that this is a problem most conspicuously for web-wide exceptions, and they effectively emulate the behavior of cookies but in another way. (Site-wide exceptions and cookies are not similar.) >>>> >>>> The really broken scenario is where the site has a web-wide exception that needs to expire for some reason, and the exceptions API doesn't support expiry. To remember the expiry, the site sets an expiring cookie, and questions or disregards the exception if either it or the cookie is missing. If the site's web-wide resource is non-scripted it is in no position to do anything about confirmation, re-requesting, checking etc. unless the user visits the site itself again. >>>> >>>> Issues: >>>> * why not use just the cookie? >>>> * if the cookie is missing but the exception is present, which of the following occurred? >>>> a) the user deleted cookies but the expiry time is not yet reached >>>> b) the cookie expired >>>> c) the user set their general preference to DNT:0 I don't think the site can tell. >>>> >>>> >>>> I therefore think that we should either >>>> >>>> 1] add an expiry parameter to both exception-setting APIs (for regularity, though only the web-wide one is problematic) OR 2] delete web-wide exceptions, since they are simply replicating cookies >>>> >>>> >>>> Which do people prefer? >>>> >>>> >>>> David Singer >>>> Manager, Software Standards, Apple Inc. >>>> >>>> >>> >>> David Singer >>> Manager, Software Standards, Apple Inc. >>> >> >> David Singer >> Manager, Software Standards, Apple Inc. >> >> > > David Singer Manager, Software Standards, Apple Inc.
Received on Wednesday, 22 October 2014 07:37:36 UTC