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

Mike,

Fair - the bank account use case was a bit extreme.  My goal was to setup the difference in nature between a typical ePrivacy Directive compliance approach and a UGE one where more direct (active) consent from the user will expected.  I feel we have other technical options to facilitate the expiration possible need (as we watch how these concepts evolve in the Data Protection Regulation).

- Shane

-----Original Message-----
From: Mike O'Neill [mailto:michael.oneill@baycloud.com] 
Sent: Wednesday, October 15, 2014 7:44 AM
To: Shane M Wiley; 'Vinay Goel'; '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]

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

Shane, bank accounts are a not even close use case. A lot more than explicit consent has to be exchanged i.e. proof of identity, honesty, money etc. Anyway the expiry can happen anyway via JavaScript execution, just not transparently or reliably.

WP29 holds the legal foundation to be constitutional, i.e. fundamental rights based as well as legal. But IANAL.

My point is companies subject to EU law will have to comply, so we should not ignore that. 


Mike



> -----Original Message-----
> From: Shane M Wiley [mailto:wileys@yahoo-inc.com]
> Sent: 15 October 2014 15:16
> To: Mike O'Neill; 'Vinay Goel'; '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]
> 
> Mike,
> 
> Expiry is implied as a companion to the "implied consent" structures 
> that have emerged as part of ePrivacy Directive compliance.  In 
> scenarios where a user provides direct and explicit consent expiry is not required but is still encouraged.
> For example, if you setup a bank account, does it automatically expire 
> at some point in time unless you reauthorize your consent?  No 
> (outside of a possible inactivity element but even then likely not).  
> Similarly, in situations where a user provides express, direct, and 
> explicit consent to granting UGEs, those implementing DNT have the 
> option of setting an expiration on their own backend and on their next 
> engagement with the user (re)prompt the user for consent again.  We do 
> not need to build this into the standard to effectuate the same outcome.
> 
> - Shane
> 
> -----Original Message-----
> From: Mike O'Neill [mailto:michael.oneill@baycloud.com]
> Sent: Wednesday, October 15, 2014 6:22 AM
> To: 'Vinay Goel'; '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]
> 
> -----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+siQHH2U
> 6
> pwitj9NC+g/DIQTnK8wvkccWqQp9J0QwvNWjF6dqoENpqIG9cIJpcbq5ckyUrveA
> Voj8utqXzpaM7YzNHAmzJAWa/F8UvqrTbnv1NDMYPr9SSgTysn6dxUjeZyTzTGiT
> NwlqC/4ByWiUZZ9MI9+o4nLXCWOKG9c2VicGEhvbHR1jJIOD8ezpGi/VraBjKPhF
> PCJvY8HgoNqeCE0Y9U5PZbZqX8WmnKaoq9/I3soUD7DqmAFyTcAuu0UL0aOaKY
> Ot
> U1a4sbuE9AQ665W2dE+ianUwLGVKrWjY3Q8gCXMLMjbrpE3z8EBwZ6/9ui7l1X0=
> =qGEa
> -----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

iQEcBAEBAgAGBQJUPogkAAoJEHMxUy4uXm2J3zYIAOUEVZvKnTWuS+xmOQlFvCsp
UOf4z7fgYw+trndurm5Mq+U4B3UQ0WTMnogAgMap9kX5bfkSACqGuc9ZAkwQLiKZ
ltZjVuwwqxsTP3d4vAjgmi5pU5+1t3HHs+l9Di4wDy03e9zcX2JkGMlBqCAE9qfr
BlMy5VLkSNPDdIKDc4JCz7hTcY1pXYIHVYinhSmzm8P6Kf1Fjx6q2n0TZB7YH/CJ
8pEAW7SP01udu+FW9quOq1IX/N+PjR18xGxkDkEiEtK5IVDERuRFwENShp0LNJ46
rNeS0FG3De2tNMZH8IY8J8goF/SdckoPclDq2myZERwEQk9W8U6JWlcGuVBBhQE=
=LJFs
-----END PGP SIGNATURE-----

Received on Wednesday, 15 October 2014 15:39:46 UTC