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

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.