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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

David, 

To make my point clearer here is a use case, which I think will be quite common.

Company BigDataCo with domain bigdata.com has resource “trackergif” that returns an image. It is accessed when the image tag <img src=’//bigdata.com/trackergif?=uid=copyof firstpartcookievalue’/>  is rendered on multiple pages on different first-party sites. 

When the bigdata.com server receives a GET for trackergif it records the Referer header plus the encoded first-party cookie value etc. and inserts them into a web history data base.

BigDataCo now decides to honour DNT requests and offer a web-wide exception for DNT:1 users (or DNT:0 consent for any user in the EU) .

Sites render an anchor tag which links to a ‘getconsent’ resource on the bigdata.com origin. This returns html explain the purpose of web history collection and a form the user can submit giving their consent. The form action resource (say ‘getconsentaction’) returns html with embedded JavaScript that executes  storeWebWideTrackingException. This results in all subsequent GETS to trackergif from this user having DNT:0.

The only way now to implement a sunset (remember trackergif cannot return executable JavaScript) is for the getconsentaction resource to return a cookie either encoding the date-time in the value or with an expiry set to the sunset period. Let us assume the latter method  and a 3 month sunset so getconsentaction returns the header Set-Cookie: sunset=1;Expires=Sat, 10 Jan 2014 00:00:00 GMT or the JS writes this value to document.cookie .

The trackergif resource would now detect DNT:0 but would also have to act on the other out-of-band signal i.e. the absence of the sunset cookie. It could only insert records into the web history data base if the Sunset cookie was absent. There is no longer any point in even checking for DNT:0, even though it might have resulted from a general preference being set (it could have been from the member of a consenting audience measurement panel).

The same scenario applies whenever tracking is implemented in a resource that does cause JavaScript to be executed in the target origin. For example resources might return CSS files or act as a CDN for open source JavaScript libraries into other origins. BigDataCo could require first-party sites to embed an iframe tag pointing to trackergif (so executable JavaScript can always be returned), and monitor the sunset cookie in that, but this would require a big change to their implementation on a large number of sites and often may not even be possible within their modus operandi.

Unless the user returned to the getconsent resource or other html returning resource the UGE would remain and the DNT:0 would continue to be sent after 3 months. It would appear to the UA (or its extension subcomponents)  that the user’s consent was still active (they know nothing about the sunset cookie). 

There are a number of problems with this status-quo if the answer to WP29 is that there is already an adequate sunset mechanism:

1) The DNT:0 signal becomes irrelevant. Detecting web-wide consent now becomes a matter of monitoring the existence of a sunset cookie. There is no recommendation in the TPE for the name or how it is encoded, so the signal is no longer transparent. In fact there is no point third-party tracking sites  even bothering with the web-wide API.
2) The Tracking Status Value after the 3 month sunset is undefined. We have a Tk: C value for out-of-band consent but no TSV for out-of-band revoked consent.
3) There will be many browser extensions that will monitor DNT:0 as a consent signal. Privacy extensions will work better if they can detect consent and DNT:0 is the only standard way to do it. Not having built-in expiry diminishes DNT as a consent indication.
4) UAs may have a UI that show existing UGEs. It will show UGEs that are not acted upon because they have expired because of the invisible sunset mechanism, and the user may accuse BigDataCo of dishonesty.
5) The user might delete their cookies but not their UGEs. With no sunset cookie DNT:0 becomes ambiguous. Adco might lose their carefully arranged consent early, while other implementations could wrongly restore consent after the sunset.
6) BigDataCo could be in a jurisdiction that does not require a sunset and they decide not to support one. The first-party sites must now decide whether the regulatory risk is worth embedding trackergif image tags at all. This would not be a problem if the API had built in expiry and BigData just respected DNT:0.
7) This is a lot more complex and harder to implement than it looks. There could be a regulatory risk in not getting it right, and the burden would be placed needlessly on thousands of companies.


If Adco relied on site-specific exceptions set by the first-party sites they would have to base the sunset on a first-party cookie and rely on the first-party site to handle it correctly by  supplying a library that did that. DNT:0 as a consent signal becomes almost irrelevant because the supplied library could just arrange for the trackergif tag not to be rendered, based on the existence of a first-party cookie. Granted, the first-party site could insert its own sunset cookie and call removeSiteSpecificTrackingException after the sunset but this is again complex, does not handle the case when a user disables JavaScript execution before the sunset (admittedly an edge case but one that does not arise at all with built in expiry), and suffers from the same transparency issues mentioned above.

An important aspect of DNT is Europe is the UGE API because there is already a legal requirement for an opt-in (for PII processing unless the data controller can claim legitimate interest). Not having a built-in expiry mechanism makes the consent API much less useful, because it will have to supplemented by other more complex and less transparent techniques.

This could all be fixed by UAs implementing expiry in the grants record, and to do that would be very easy for them.

Mike

> -----Original Message-----
> From: David (Standards) Singer [mailto:singer@apple.com]
> Sent: 09 October 2014 23:35
> To: Mike O'Neill
> Cc: Nicholas Doty; Tracking Protection Working Group
> Subject: Re: tracking-ISSUE-266: automatic expiration of a tracking preference
> exception via API parameter [TPE Last Call]
> 
> 
> On Oct 9, 2014, at 14:13 , David (Standards) Singer <singer@apple.com> wrote:
> 
> > If the site can ask for the exception in the first place, it can ask for a re-
> confirmation. I guess it may be that you visit e.g. FootScroll and get a webwide
> exception, and then their ‘lake’ button on other sites get DNT:0.  But again, they
> also get (or not) the cookie, and know whether to take DNT:0 seriously.  If the
> user never visits footscroll again, sure, the exception can’t be reconfirmed, but if
> the user never visits you, why care?
> 
> this is wrong. apologies. the cookie only goes back to the requester.
> 
> David Singer
> Manager, Software Standards, Apple Inc.
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (MingW32)
Comment: Using gpg4o v3.3.26.5094 - http://www.gpg4o.com/
Charset: utf-8

iQEcBAEBAgAGBQJUN8QEAAoJEHMxUy4uXm2JkDcIAIKgAznHzXLc+EyRT41ncZEk
ztHg10oyDg32F6UlN8Cb4KOz5f/9kx7u3VROH5z4ApLz0dPDDgwQDqG4rdctYtki
o/eA+YY+lUrOzb3BEfFSBjqqc6dHxCCBHKnfkqZWM4r/ivxMzaGjiRwqvaX/o43r
1SyeDfzaN4T2sxuBcLUARvI8FWBRIyzcXCzAhbzZ490fxD8008yhHh4cIfx8r6Z/
UQb+uDqEwW4MlGm2hg8FPQuyt01yjmJwB1iNdyzZehvDum/wIt7cQ6edm7NLejiz
AgEAw3UiWLWQqT2n9m9P6v+vjk34yMbbL1qwWtLDFWvBh53x3CgfSS61WS1cETc=
=FV1C
-----END PGP SIGNATURE-----

Received on Friday, 10 October 2014 11:33:57 UTC