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+3cMkJGu3f6WvHsc08
>z8vqQl5zkpX/qMnKgQgXKF4d3GMLpe5XtNQx2YvXF3lv/eudOrN29qNV+iz0GLb3
>p0OsVsXz2TcV4Z/DGm4xvoV3EoPj/4UkGysBvAhmuwv2An0/hEuNE0Stj1HfTT2w
>e1BNbwD4J629byaoeL0MvHDL6vOufuzy3ULdSBGdtLbvE4rnDYBhjaMaXFiRIK+5
>6qbh0VY+ODKromf4yVouggqIGwKvR8x6CpvE/yGzfhKSX+3KvQ2JHCjola302kvn
>QviDUrlNFvHvAzY2bpLaeK7/cdd206Fhg+IJ5DfEvVVNC354BZOPKgQciSjJcBA=
>=iA1n
>-----END PGP SIGNATURE-----

Received on Wednesday, 15 October 2014 12:58:06 UTC