W3C home > Mailing lists > Public > public-tracking@w3.org > October 2014

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

From: Mike O'Neill <michael.oneill@baycloud.com>
Date: Tue, 14 Oct 2014 20:59:48 +0100
To: "'David Singer'" <singer@apple.com>
Cc: "'Roy T. Fielding'" <fielding@gbiv.com>, "'Nicholas Doty'" <npdoty@w3.org>, "'Tracking Protection Working Group'" <public-tracking@w3.org>
Message-ID: <01ed01cfe7e9$6a14ad90$3e3e08b0$@baycloud.com>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



> -----Original Message-----
> From: David Singer [mailto:singer@apple.com]
> Sent: 14 October 2014 18:58
> To: Mike O'Neill
> Cc: Roy T. Fielding; Nicholas Doty; Tracking Protection Working Group
> Subject: Re: tracking-ISSUE-266: automatic expiration of a tracking preference
> exception via API parameter [TPE Last Call]
> 
> 
> On Oct 11, 2014, at 5:46 , Mike O'Neill <michael.oneill@baycloud.com> wrote:
> 
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> >
> >> True, but the question of “how do I expire a UGE?” came up, and *one* way
> to
> >> do it is to use a cookie.  I think it may work acceptably well for some or
> many.
> >
> > Hardly anyone will do that, it is too complicated.
> >
> >>
> >> Somehow we’ve got from “can I use a cookie as the timer to help me expire
> a
> >> UGE?” to “can I rely on a cookie to record a UGE?”. The answer to the first is
> >> yes, if you like.  But it doesn’t give you the right to ignore the DNT header and
> >> treat the cookie as definitive.
> >>
> >> If the DNT header comes as zero, and the cookie doesn’t arrive, then you
> >> eyebrows go up and you probably re-confirm the exception and re-set the
> >> cookie.
> >
> > You cannot re-confirm unless the resource returns  html, and sometimes not
> even then.
> 
> But Mike, think of the two cases.
> 
> 1) Site-wide.  The first party that requested it *is* the site the user visited.  No
> problem here.

There is still the transparency problem I mentioned. The UA has no way to tell users about the expiry of UGEs, while it is normal to report it for cookies.

UAs should be able to help users understand when and to whom they gave consent (and see if it was forced on them without their knowledge).
If no explanationString  and siteName there is less for UAs to report on about the actual API event (they could show info from WHOIS lookups or X.509 certs instead). Any time to expiry of the UGE would help keep the user informed.

> 
> 2) Web-wide.  True, if all you load is a tracking pixel or other non-scripted
> resource, you cannot confirm the exception. But if the user never visits your
> main site, *should* you be maintaining or reconfirming the exception?
> 
> > In my use case re-conformation is impossible. DNT will always be zero
> (because it will not be cancelled) , and the cookie is not there either a) it has
> expired or b) it was purged or c) it was never placed (the DNT:0 signalled a
> general preference).
> 
> OK, so it’s true that if you use cookies to expire, and a DNT:0 is received without
> the cookie, you cannot tell if that’s because the cookie has expired (so DNT:0 is
> now questionable) or because the user has set a DNT:0 general preference.  And
> setting another cookie that has a different expiry doesn’t solve it, either,
> because if the user deletes cookies, you’ll lose that as well.
> 
> This *is* a problem.
> 
> > This is why it is hard to get software that relies on non-atomic states to work,
> and hardly anybody will try.
> 
> So the question is whether the exception-expiry is a necessary part of the API.  I
> guess we need WG consensus.
> 
> 
> 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

iQEcBAEBAgAGBQJUPYCzAAoJEHMxUy4uXm2JUfIH/2IdK4MiqBGNIwKfAjl96jWU
vbtPZh3cY4YSegJvu76jz23j5bKDB0rdPPZXimSfm6ifpOQAEVwG9lIWPLC7+uOc
S45ogMcKS2SjLLY7HOGNyL5Q+Ly6GABBjG9N88WbRb079N9E3pX9ZuPPy+tmch6X
zje0bYTq3Cjiyc6L4yWgp/y5Y9lsYvJ01MYiP0+xfvzhg3x3ZbgGtqpXF/vg3Jgv
GzvBrx0w+0YFW7hHGAZv4TYvzqYioPltweB3Da89EM3jOQK0CDimYKQIxwBnQPhr
p7bwwPntp4yYzIoJF8Mozf3FZAD5MD2VSI2YQJ0A/zEPWOq1SehxwGAvDEQ3Nc4=
=k21O
-----END PGP SIGNATURE-----
Received on Tuesday, 14 October 2014 20:01:10 UTC

This archive was generated by hypermail 2.3.1 : Friday, 3 November 2017 21:45:24 UTC