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.