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: Shane M Wiley <wileys@yahoo-inc.com>
Date: Wed, 15 Oct 2014 14:16:06 +0000
To: Mike O'Neill <michael.oneill@baycloud.com>, 'Vinay Goel' <vigoel@adobe.com>, 'Nicholas Doty' <npdoty@w3.org>
CC: 'David Singer' <singer@apple.com>, "'Roy T. Fielding'" <fielding@gbiv.com>, 'Tracking Protection Working Group' <public-tracking@w3.org>
Message-ID: <DCCF036E573F0142BD90964789F720E324FA30E8@GQ1-AM-M03-03.y.corp.yahoo.com>

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]

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


> -----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:
> >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.
> >Version: GnuPG v1.4.13 (MingW32)
> >Comment: Using gpg4o v3.3.26.5094 - http://www.gpg4o.com/

> >Charset: utf-8
> >
> 08
> >z8vqQl5zkpX/qMnKgQgXKF4d3GMLpe5XtNQx2YvXF3lv/eudOrN29qNV+iz0GLb3
> >p0OsVsXz2TcV4Z/DGm4xvoV3EoPj/4UkGysBvAhmuwv2An0/hEuNE0Stj1HfTT2
> w
> >e1BNbwD4J629byaoeL0MvHDL6vOufuzy3ULdSBGdtLbvE4rnDYBhjaMaXFiRIK+5
> >6qbh0VY+ODKromf4yVouggqIGwKvR8x6CpvE/yGzfhKSX+3KvQ2JHCjola302kvn
> >QviDUrlNFvHvAzY2bpLaeK7/cdd206Fhg+IJ5DfEvVVNC354BZOPKgQciSjJcBA=
> >=iA1n
> >-----END PGP SIGNATURE-----

Version: GnuPG v1.4.13 (MingW32)
Comment: Using gpg4o v3.3.26.5094 - http://www.gpg4o.com/

Charset: utf-8


Received on Wednesday, 15 October 2014 14:17:54 UTC

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