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

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

Sorry, a half completed revision. For Adco read BigDataCo

Mike

> -----Original Message-----
> From: Mike O'Neill [mailto:michael.oneill@baycloud.com]
> Sent: 10 October 2014 12:33
> To: 'David (Standards) Singer'
> Cc: 'Nicholas Doty'; 'Tracking Protection Working Group'; rob@blaeu.com
> Subject: RE: tracking-ISSUE-266: automatic expiration of a tracking preference
> exception via API parameter [TPE Last Call]
> 
> *** gpg4o | Valid Signature from 7331532E2E5E6D89 Mike O'Neill
> <michael.oneill@btinternet.com> ***
> 
> 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

iQEcBAEBAgAGBQJUN8t0AAoJEHMxUy4uXm2J0gAH/2uSSJDBTZ+e49CJII2nPisT
XIIcLSfUj5UzG+jSLGpT8XWQn6vOHC34HFGBg/FsnvqBOu858R/eUahOa+xES6xN
7UtO1QOhv4KaYoGFNdUjor9cFIMJMjssgHKegj1IBVGi2uA/SWaJZWdKYBjUbL6V
TERtdPWo29w+SP61lxzogotXVybFSIHTGrFvaU4kunBOP+kpYWDIDDFBs1T6jFZK
iRRKT/G5a5sjS/HVFJviW6PxRyKiQ6ATd7yRtjApwwMOoKFeAE+91oY5/vLGvNFK
/KP2O6+9GiiwuTPUu2yKp5UMP6dB87co17+AKqIo2BByqbtb/ruk/T86NYh4VTc=
=FF0x
-----END PGP SIGNATURE-----

Received on Friday, 10 October 2014 12:05:42 UTC