RE: tracking-ISSUE-266: automatic expiration of a tracking preference exception via API parameter [TPE Last Call]

-----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. 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. 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.

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.

DNT:0 may be taken into account by UAs or extensions so the meaning of it should be clear. 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.

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.




> -----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-----

Received on Thursday, 9 October 2014 09:30:47 UTC