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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Vinay,

Expiry is implied in the Directives (not just e-privacy) and specifically called for by WP29 Opinions. At least one major DPA requires it I know of.

The e-privacy Directive is technology agnostic, not just http cookies but any kind of storage use.

I did ask for symmetric API to be considered, but did not get any support. Maybe we can get into that if we ever have DNT2.0

Mike


> -----Original Message-----
> From: Vinay Goel [mailto:vigoel@adobe.com]
> Sent: 15 October 2014 13:58
> To: Mike O'Neill; 'Nicholas Doty'
> Cc: 'David Singer'; 'Roy T. Fielding'; 'Tracking Protection Working Group'
> Subject: Re: tracking-ISSUE-266: automatic expiration of a tracking preference
> exception via API parameter [TPE Last Call]
> 
> Hi Mike,
> 
> I believe only one country has explicitly included expiry requirements in
> its regulatory guidance.  That is far from the norm across the world; and
> that consent is limited to cookies and not to uses of personal
> information.  Besides, exploring a UGC for only UGCs seems one-sided to
> me.  There are other preferences (like the user¹s DNT preference).  Should
> that too be confirmed every so often or it expires?
> 
> -Vinay
> 
> On 10/15/14, 5:36 AM, "Mike O'Neill" <michael.oneill@baycloud.com> wrote:
> 
> >-----BEGIN PGP SIGNED MESSAGE-----
> >Hash: SHA1
> >
> >Nick, the web-wide use case refers to the usual way tracking is
> >implemented, using 1x1 gif images, JS library & CSS loading, object tag
> >rendering etc. The case where tracking is done using an iframe is
> >relatively rare.
> >
> >In the EU there is legislative backing and regulatory requirement for
> >expiry and therefore the use case will represent the norm.
> >
> >On the site-wide case, as I said to David, the transparency issue arises.
> >
> >There is no point in de-coupling them because UA implementation is easier
> >if it is done for both, and we would not have to derive another property
> >bag for the web-wide case. Even if you are not swayed by  the
> >transparency argument it does not harm to have site-specific expiry if we
> >are already doing it for web-wide.
> >
> >Mike
> >
> >
> >From: Nicholas Doty [mailto:npdoty@w3.org]
> >Sent: 15 October 2014 03:22
> >To: Mike O'Neill
> >Cc: David Singer; Roy T. Fielding; 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 1413339731 9
> >
> > On October 14, 2014, at 12:59 PM, Mike O'Neill
> ><michael.oneill@baycloud.com> wrote:
> >
> >Signed PGP part
> >> 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.
> >
> >I tend to agree with David that the site-wide doesn't seem like a
> >problem. The storeSiteSpecificTrackingException is designed for the use
> >case where the *site* takes the burden of explaining the conditions of
> >the exception request and then only stores the exception in the UA. The
> >UA will never be able to give full details on the consent -- that's up to
> >the site. When the site assumes the consent will expire seems like an
> >example of a detail of consent that we don't expect the UA to manage.
> >
> >And because the site also typically has JavaScript access, it can remove
> >the exception when an expiration has taken place, or when some change in
> >the user's logged-in account happens, or on any other condition they
> >choose.
> >
> >> 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.
> >
> >I can see the potential problem for Web-wide exceptions, for parties that
> >want automatic expiration, and do their tracking through non-JavaScript
> >means and either want the exception to persist beyond clearing of cookies
> >or want to distinguish between general DNT:0 and specific-but-expired
> >Web-wide exceptions.
> >
> >We could implement expiration parameters to cover this use case, but this
> >is also a very specific set of conditions and I'm not aware of any
> >implementers in that situation.
> >-----BEGIN PGP SIGNATURE-----
> >Version: GnuPG v1.4.13 (MingW32)
> >Comment: Using gpg4o v3.3.26.5094 - http://www.gpg4o.com/
> >Charset: utf-8
> >
> >iQEcBAEBAgAGBQJUPkAhAAoJEHMxUy4uXm2JAfIH/1+laR+3cMkJGu3f6WvHsc
> 08
> >z8vqQl5zkpX/qMnKgQgXKF4d3GMLpe5XtNQx2YvXF3lv/eudOrN29qNV+iz0GLb3
> >p0OsVsXz2TcV4Z/DGm4xvoV3EoPj/4UkGysBvAhmuwv2An0/hEuNE0Stj1HfTT2
> w
> >e1BNbwD4J629byaoeL0MvHDL6vOufuzy3ULdSBGdtLbvE4rnDYBhjaMaXFiRIK+5
> >6qbh0VY+ODKromf4yVouggqIGwKvR8x6CpvE/yGzfhKSX+3KvQ2JHCjola302kvn
> >QviDUrlNFvHvAzY2bpLaeK7/cdd206Fhg+IJ5DfEvVVNC354BZOPKgQciSjJcBA=
> >=iA1n
> >-----END PGP SIGNATURE-----
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (MingW32)
Comment: Using gpg4o v3.3.26.5094 - http://www.gpg4o.com/
Charset: utf-8

iQEcBAEBAgAGBQJUPnUOAAoJEHMxUy4uXm2JFcUH/jSnZQsiu+wXpL1+siQHH2U6
pwitj9NC+g/DIQTnK8wvkccWqQp9J0QwvNWjF6dqoENpqIG9cIJpcbq5ckyUrveA
Voj8utqXzpaM7YzNHAmzJAWa/F8UvqrTbnv1NDMYPr9SSgTysn6dxUjeZyTzTGiT
NwlqC/4ByWiUZZ9MI9+o4nLXCWOKG9c2VicGEhvbHR1jJIOD8ezpGi/VraBjKPhF
PCJvY8HgoNqeCE0Y9U5PZbZqX8WmnKaoq9/I3soUD7DqmAFyTcAuu0UL0aOaKYOt
U1a4sbuE9AQ665W2dE+ianUwLGVKrWjY3Q8gCXMLMjbrpE3z8EBwZ6/9ui7l1X0=
=qGEa
-----END PGP SIGNATURE-----

Received on Wednesday, 15 October 2014 13:23:26 UTC