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: Vinay Goel <vigoel@adobe.com>
Date: Wed, 15 Oct 2014 12:57:35 +0000
To: Mike O'Neill <michael.oneill@baycloud.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: <D063E663.14CE4%vigoel@adobe.com>
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?


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.
>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]
> 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
>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
>> 2) Web-wide.  True, if all you load is a tracking pixel or other
>> 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,
>> 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
Received on Wednesday, 15 October 2014 12:58:06 UTC

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