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

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

I just found out there already is a bigdata.com . My use case was obviously not related to them, so just read all the domain references as otherbigdataco.com (or whatever).

Mike

> -----Original Message-----
> From: Mike O'Neill [mailto:michael.oneill@baycloud.com]
> Sent: 10 October 2014 13:05
> 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> ***
> 
> 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

iQEcBAEBAgAGBQJUN99IAAoJEHMxUy4uXm2JJdQH/0SQRLBjChzOUaBLuEDap2W1
7ryQ2ku7xYZ++0kYA69Wuz08q7u0HPK9w9dyR2lCEJtJbOABrVCZlYaNypPs1MaC
lXOiMG9OseTBzM4wcN+B93X22uwJjCKlRrq7DPrKCv+9s8tuHJAGAj3o+krycHKb
liKDSE1p3NAK1xuAScdYM/C/rXSqxR4cj3DMLDr7CYPWLcR8x4ob8eIrml+YZmjk
7A8Z7O40h7KHUJ5bqA88JJ1N2lAJyctb+xjtnr248wrpKpf0WSI25+H3t2vu61Zd
aMbqRkUZ5BXCKJ6REkMeJY5lIqQMBv6DyJUw4TSmf0sIgRvKMNpFIDeKB+QX4IM=
=nd6b
-----END PGP SIGNATURE-----

Received on Friday, 10 October 2014 13:30:34 UTC