- From: David (Standards) Singer <singer@apple.com>
- Date: Thu, 09 Oct 2014 14:13:35 -0700
- To: Mike O'Neill <michael.oneill@baycloud.com>
- Cc: Nicholas Doty <npdoty@w3.org>, Tracking Protection Working Group <public-tracking@w3.org>
On Oct 9, 2014, at 2:29 , Mike O'Neill <michael.oneill@baycloud.com> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Some of the operation might depend on it, the user can be given a choice, and it would be natural to offer a sunset. The user-agent is quite a liberty to offer that. > In Europe there is a regulatory requirement for data controllers to offer a choice with a sunset. > > If there is no automatic expiry there would have to be a way to record the time the UGE was granted and communicate it back to the site, i.e. a persistent cookie that encodes the date-time or one which expires after the sunset. In either case the meaning of DNT:0 would be conditional on the absence of (or parsing the value of) a cookie, making it non-transparent. No, the existence of the exception is irrelevant if you don’t go back to the site. If you do, then the site also sees the absence of the cookie (it’s expired) and knows it needs to re-acquire the exception. > To make it transparent we could specify the name and encoding of the cookie in the TPE, but this is more complicated to explain and implement than simply associating an expiry with the grant. No, the site can do this easily all by itself. There’s no interop question here. > The only way for a site to clear a UGE is by returning HTML with executable script. If the tracking resource does not do that (it could be anything else e.g. an image) then the DNT:0 would persist forever along with its obscure sidekick cookie signalling the opposite. If the site can ask for the exception in the first place, it can ask for a re-confirmation. I guess it may be that you visit e.g. FootScroll and get a webwide exception, and then their ‘lake’ button on other sites get DNT:0. But again, they also get (or not) the cookie, and know whether to take DNT:0 seriously. If the user never visits footscroll again, sure, the exception can’t be reconfirmed, but if the user never visits you, why care? > DNT:0 may be taken into account by UAs or extensions so the meaning of it should be clear. Sorry, DNT is a signal to the site. I don’t know what you mean here. > If it is to be qualified by an out-of-band signal with the reciprocal meaning to the one we talk about in the TPE, so we would have to expand on that i.e. we would need yet another TSV, so even more complexity. None of this needs standardizing IMHO; there are plenty of tools to handle this already. > > The overhead on UAs implementing it is low. They already have the code to expire cookies, and they have to keep track of grants. Getting code bug free in UAs once is better than thousands of buggy implementations in servers. If data controllers across Europe (at least) would have to implement complicated, error-prone and non-transparent expiry mechanisms with cookies we will not be popular. I don’t think we can or should adjust the standard in order to make it easier to implement every regulation. Possible to comply, sure, we should look at it. But not easier. > > > > >> -----Original Message----- >> From: David (Standards) Singer [mailto:singer@apple.com] >> Sent: 09 October 2014 01:22 >> To: Mike O'Neill >> Cc: Nicholas Doty; Tracking Protection Working Group >> Subject: Re: tracking-ISSUE-266: automatic expiration of a tracking preference >> exception via API parameter [TPE Last Call] >> >> I am still unclear as to why a *site* would think an exception needs to expire. >> >> I understand why cookies can expire; they can be used to record information >> that is intended to be transient (e.g. a login state, the content of a shopping >> basket). >> >> But sites ask for exceptions when their operation depends on it. >> >> If they *need* to do an expiry, or re-confirmation periodically, I think it would >> be easier for them to set a cookie and then effectively get an active reminder (if >> the exception exists and the cookie does not). >> >> I do not think that exceptions are cookie-like enough to justify the complexity, >> myself. >> >> On Sep 28, 2014, at 4:54 , Mike O'Neill <michael.oneill@baycloud.com> wrote: >> >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA1 >>> >>> As promised, here is the WebIDL for automatic expiry in a ReSpec file, to >> replace the section “7.4.1 API to Request a Site-specific Exception”. >>> The web-wide API uses the same property bag so does not need changing. >>> I mirrored both the Max-Age and Expires attributes with Max-Age taking >> precedence as it does in RFC6265. >>> It is pretty self-evident but if people think it is necessary I can also write a >> descriptive paragraph to go into the Exception model section. >>> Mike >>>> -----Original Message----- >>>> From: Nicholas Doty [mailto:npdoty@w3.org] >>>> Sent: 25 September 2014 01:24 >>>> To: Tracking Protection Working Group >>>> Subject: Re: tracking-ISSUE-266: automatic expiration of a tracking >> preference >>>> exception via API parameter [TPE Last Call] >>>> >>>> *** gpg4o | Unknown Signature from 40203EE90BBAB306 1 2 01 >> 1411604644 9 >>>> *** >>>> >>>> This is the more specific issue we decided to open in discussing issue-258 >>>> regarding automatic expiration in general. Mike O'Neill has voluntereed to >> write >>>> up a text proposal for it this weekend. >>>> >>>> Thanks, >>>> Nick >>>> >>>> On September 24, 2014, at 5:16 PM, Tracking Protection Working Group >> Issue >>>> Tracker <sysbot+tracker@w3.org> wrote: >>>> >>>>> tracking-ISSUE-266: automatic expiration of a tracking preference >> exception >>>> via API parameter [TPE Last Call] >>>>> >>>>> http://www.w3.org/2011/tracking-protection/track/issues/266 >>>>> >>>>> Raised by: Rob van Eijk >>>>> On product: TPE Last Call >>>>> >>>>> In discussing the automatic expiration Last Call comment, we decided to >> open >>>> a separate issue for any proposals for an API parameter for storing user- >> granted >>>> exceptions to tracking preferences. >>> -----BEGIN PGP SIGNATURE----- >>> Version: GnuPG v1.4.13 (MingW32) >>> Comment: Using gpg4o v3.3.26.5094 - http://www.gpg4o.com/ >>> Charset: utf-8 >>> >>> >> iQEcBAEBAgAGBQJUJ/bdAAoJEHMxUy4uXm2JjRkIAMDOGlMeF+d2bTD7kcA0Ev >> m3 >>> >> YCYZr6/J9xRDCo/cJUcDSeDb3Ogd8Lk+rqwmq0WuO4+vaGC/BlV1sU2D0jMIETPv >>> 3WBj2susnaziPevvxivo6StcVu9Fs+7NZsYdfRYmMX+ms9mscFw18g8li+u0jkfL >>> >> 1KYoyTqs0Yu8m0kk7lqVyj8PPWTeMFsOe1MwSlY7J9XBKZu/80amQ+U58GSS/Nyi >>> >> EuRVUPDltXBgBYFOqUSY/1t6FSJVwAG4qQzW3+lMTt/SrGvRoSrh1Iv7H7b5RGP5 >>> >> VrMuu+6gUMsbcthdrryUs/LO4OD6IwkdrzS6T1DnSPmYYQPC49BCLWIILMze9NE >> = >>> =ta2F >>> -----END PGP SIGNATURE----- >>> <PGPexch.htm><tpe_expiry.html><PGPexch.htm.sig><tpe_expiry.html.sig> >> >> David Singer >> Manager, Software Standards, Apple Inc. > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.13 (MingW32) > Comment: Using gpg4o v3.3.26.5094 - http://www.gpg4o.com/ > Charset: utf-8 > > iQEcBAEBAgAGBQJUNlWIAAoJEHMxUy4uXm2JQMsH/it+W3Fx9ysgrW+meiC3nQAG > sStT/XlCP6Vjn174Q0wBTpc166jnfjHPAjE4Ee1c8aC2OFhknB+RKbNY9T8xczEu > 9ncL0sxp0r4lIQvjyUOFd4RhdoooL+8uYZMLETPVSBF7vydAfT9aExAhJylM2dZg > MlXGJUPhunV1z6HoKS8jtMvfeL/1Ytya3bV3yEKIDWbGOWS4BanBvF1NxhUu28qh > VBvXA2iniEML4xhqW0y+xQGaMWDcCFeCygOL/1lx5Bl7ql2NREqewPOiUw8Falav > Ge+lURcsR3bhdoyIujTCuaCdDycHPgK4mlPXSJ4jTDLGUZi06sFEPk/NWM2ZpJA= > =PfPn > -----END PGP SIGNATURE----- > David Singer Manager, Software Standards, Apple Inc.
Received on Thursday, 9 October 2014 21:14:12 UTC