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

On Oct 10, 2014, at 4:33 , Mike O'Neill <michael.oneill@baycloud.com> wrote:

> -----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.

if it’s also PRESENT. I.e. the cookie has not yet expired.

> 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).

yes, we pointed out that web-wide exceptions were replicating cookie behavior, but people still wanted them, partly because they were less likely to be deleted en masse, I think.

> 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.

If you want to expire, you need to look at BOTH the DNT header and the cookie.  Loss of either means you need to re-ask, yes.  If the site explains that the exception will expire automatically in N months (they don’t have to say how), and also if either the cookie is deleted, or the exception canceled, I don’t see a problem. 

> 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.

I don’t see why we need it.

> 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.

From the user’s point of view, they gave consent. Sites don’t have to act on it.

> 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.

and then it will be explained.

> 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.

They can only restore the cookie if they can work out when it should expire, which is unlikely.

> 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.

Sorry, I don’t get it.  If BigData decides not to support expiry, they wouldn’t set a hypothetical expiry parameter either.

> 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-----
> 

David Singer
Manager, Software Standards, Apple Inc.

Received on Friday, 10 October 2014 16:45:22 UTC