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

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

David, 

comments to your comments, inline.




> -----Original Message-----
> From: David Singer [mailto:singer@apple.com]
> Sent: 10 October 2014 17:44
> To: Mike O'Neill
> 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]
> 
> 
> 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.

Yes, OK I meant that. It doesn't change my point though, the server only has to see if the cookie exists, it can ignore DNT:0


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

But also because DNT is more transparent (look at AdChoices with the myriad of opt-out cookie names and ways of acting on them) . 

If UGEs are less likely to be cleared than cookies this makes the signal ambiguity I mentioned more likely.

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

You only need to check the cookie. If it is there you must have executed the UGE because you placed the cookie at the same time. So you do not need to bother with the UGE (unless you want the UA to display it, but the UA cannot know about the sunset so there is no point).

> Loss of either means you need to re-ask, yes.  If the site explains that the

Whatever way they detect it BigDataCo has no way to ask again because the trackergif resource does not return html. BigDataCo will have to wait till the user decides to visit the consent resource again. The user has no way of telling whether their consent has been revoked or not. BigDataCo find itself in a worse situation if cookies are deleted.

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

The problem is that the DNT signal is unnecessary and third-party companies have a good reason to ignore it because there is no API to register a sunset. The UA is unable to show all the grants. We lose transparency for users and regulators. 

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


Because, how would an extension qualify the DNT:0 to know it is lapsed consent?  If it quacks and you can't see it, it has to be a duck.

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

Privacy extensions might for example clear cookies for sites that are sent DNT:1, or are not sent DNT:0. They need to do this because blanket blocking does not work, it reduces web experience by blocking resources users have consented to and curated blocking lists are hard to update fast enough to be adequate. DNT:0  can become a universally recognised consent signal used by privacy UAs to enforce user preference. This is better for advertisers and users.

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

But other users continue to be confused. Transparency again.

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

That is my point. If the cookie is lost half the signalling is gone. DNT:0 with no cookie could be taken as consent having been revoked when it had not. After the sunset, depending how the sunset cookie is implemented, consent may be assumed when it should have been revoked. The result is ambiguity. If the UA supports UGE expiry the signalling is atomic so no problem.


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

I meant the (probably common) case where BigDataCo does not implement expiry but the first-party is in a jurisdiction that requires it (or they want to offer it to their users). In this circumstance the first-party's only recourse is not to use BigDataCo at all, use the site-specific API and use its own first-party cookie to decide when to call removeSiteSpecificTrackingException, or to control whether the tag gets rendered on a per user basis. These can all be done but they are complicated (and site-specific consent still has the transparency problem). The DNT API offers the possibility for regulated sites to continue to use third-parties without complex site re-engineering. They just need third-parties to honour DNT, maybe with a contractual commitment. If UAs do not support expiry this advantage is lost, or at least greatly reduced.

This proposal replaces a lot of grief by thousands of companies (probably leading to a failure to use DNT:0, less transparency and further loss of trust in online commerce) by a small amount of implementation work by UA companies.

> 
> > 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/wIt7cQ6edm7NLeji
> z
> >
> AgEAw3UiWLWQqT2n9m9P6v+vjk34yMbbL1qwWtLDFWvBh53x3CgfSS61WS1cE
> Tc=
> > =FV1C
> > -----END PGP SIGNATURE-----
> >
> 
> 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

iQEcBAEBAgAGBQJUOCpJAAoJEHMxUy4uXm2JfcAH/1c0vgvllkE4OCNxrhnw5juI
dRedqpBm9l0eLiqpbBysMTa/nE50WdZP5C1LEP9vE2YAiToFE09+DS3Is7nsQZsk
ME/cSzLV5Dksg5pdN/jbOGq9E/Q2tMoXfhSWexsCczrP/yQqtgNc/3w2CuGBbCFG
ZpaAAWoBdUIqBHEl7nS+t8UQDOSrq1q/Sj6pgLm5s597imlePsqPayHcSjlK/vam
knTiHCqqbQ0Hb0O5SKwMYtdARoaLA14Q94bJK59bPgb2N5vd9abuiRaze6MEiwbx
p8Vqqi9PVlkCBLj2NbsgJ74H3fPWej0lUgZQYjx95x2QrHsqROBonr4uIB8GOp0=
=+KgQ
-----END PGP SIGNATURE-----

Received on Friday, 10 October 2014 18:50:22 UTC