W3C home > Mailing lists > Public > public-tracking-comments@w3.org > October 2017

Re: Mapping DNT to GDPR

From: Peter Cranstone <peter.cranstone@3phealth.com>
Date: Sat, 14 Oct 2017 18:41:08 +0000
To: Robin Berjon <robin.berjon@nytimes.com>
CC: public-tracking-comments w3.org <public-tracking-comments@w3.org>
Message-ID: <D4321A14-443E-4904-919D-F7E445F0D634@3phealth.com>
Hi Robin,

I thought I would follow up with some additional comments to your two questions. My two reference documents for this response are:

  1.  The very latest Candidate Release of the Do Not Track protocol - link<http://https://w3c.github.io/dnt/drafts/CRc-tracking-dnt.html> (Dated October 17th 2017)
  2.  The current GDPR regulation - link<http://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32016R0679&from=en>

DNT is a web wide setting - only through the use of exceptions can you change it’s intent to one of the following three items - link<http://https://w3c.github.io/dnt/drafts/CRc-tracking-dnt.html#exception-scope>

As I’ve said before, any initial web wide DNT setting is irrelevant in the EU. GDPR is based on real time PHYSICAL location for Privacy decisions. So site/domain exceptions are required ALL the time.

Now let’s put GDPR and Do Not Track to a real world test with a use case:

  *   I fly in to Zurich with a current US regionalized browser and access a French web site which offers advertising from four different vendors - I’ll call them A, B, C and D.

As my PHYSICAL location is in the EU then GDPR applies - so you MUST obtain consent on a site by site basis, my web wide Do Not Track setting is irrelevant.

Now we must refer section 6.1 of the CR version of DNT User Granted Exceptions Overview - link<http://https://w3c.github.io/dnt/drafts/CRc-tracking-dnt.html#exception-overview> So now you would need to check to see if the browser(s) that the data subject is currently using supports the JavaScript API (Navigator.storeTrackingException) and also the (Navigator.revokeTrackingException)  - link<http://https://www.w3.org/wiki/Privacy/TPWG/TPE_Implementation_Report>  As you can see from the table there are no current browsers except one that support it.

At this point we stop - execution in the real world is currently impossible.

Continuing on…

Let’s say tomorrow that every browser fully supports the CURRENT CR Do Not Track protocol AND that EVERYONE in the world updates to the new browser(s). All the APIs are there along with a STANDARD storage/exception database that can be used by everyone.

Could you use a web wide signal of DNT:0 to convey consent?

  *   The answer is NO - why? Only by reading the exception database can you determine what the INDIVIDUAL user has consented to e.g A and B but no to C and D
  *   Currently no browser supports the setting of DNT:0 see this link<http://https://w3c.github.io/dnt/drafts/CRc-tracking-dnt.html#determining>

Could you use a web wide signal of DNT:1 to revoke consent?

  *   The answer is NO - why? Only by examining the exception database can you determine what the INDIVIDUAL user has revoked e.g the user revokes consent to B, keeps A and adds C and D.
  *   Each individual is within their rights to change their consent at any time, and may choose whatever they wish to consent to

Could you use web wide DNT:1xyz extensions?

  *   No - as they have not yet been defined

Conclusion… executing on the Do Not Track protocol for compliance with the GDPR and other Privacy regulations in the real world:

  *   In the EU consent servers are appearing - which will mean they avoid using the proposed DNT API Navigator calls - Do Not Track was never designed with multiple storage mechanisms in mind
  *   The use of multiple devices by a consumer i.e desktop browser, smartphone web browser, tablet web browser will cause immense user experience issues
  *   At a minimum all browsers must be updated to fully support the current Do Not Track Candidate Release version for GDPR to be even tested
  *   Without a standard exception database which can be accessed by the consumer no consent record can currently be stored or reviewed
  *   GDPR compliance will also encounter issues in the form of HTTP 2.0 which supports cross device tracking at the protocol level
  *   VPN’s and mobile devices (carrier networks) will cause issues when it comes to determining real time PHYSICAL location
  *   Browsers must be installed on every device prior to May 25, 2018 to to support GDPR compliance
  *   If the exception database is wiped out - everything starts over again

As I come to the conclusion of this post, the core problem with Do Not Track starts to emerge - I have often wondered about this statement in section 6.1:

  *   However, we only define the API (below); the choice of storage mechanism is left to each implementation

Why would you leave it to each implementation?

  1.  It will require a user interface - which each browser OEM will design differently for different devices - which is ‘out of scope’ for this protocol
  2.  It will need the ability to store different types of individual contextual consent which will affect value to the advertisers

It is the second item that is the problem - and it can be illustrated with a simple example tied into our Zurich use case - In the case of advertisers A, B, C and D I offer consent for the next 10 minutes ONLY - after that consent is withdrawn.

I’ve highlighted the words I offer consent for the next 10 minutes ONLY for a reason. Under GDPR the consumer has much more negotiating power. I call this ‘Negotiated Digital Commerce’. If I trust you, I will share my data, but if you abuse that trust I’ll simply opt out of everything.

Time and Value now become negotiated in real time which leads to the next level of sustainable commerce on the Internet. If I opt out (no consent) the value of ‘Me’ plummets to an advertiser. If I opt in and offer more meaningful data the value of ‘Me’ increases. What goes in and out of this database will be the key to revenue in the future. Advertisers NEED consent and if possible EVEN more data to individualize. There’s only one way to get this - negotiate in real time and the 'exception database' is the key.

In closing…

GDPR is a personalized contract with each individual consumer and their choices must be respected to ensure compliance. No web wide signal can achieve that. The exception (consent) database is the beginning of the next business model on the Internet - Negotiated Digital Commerce.

Why? Because MY terms are inside that database and GDPR states that you have to respect them.



Peter Cranstone
CEO, 3PHealth

Mobile/Signal: +1 - <tel:303-246-9954> 303-809-7342<tel:303-246-9954> UTC -6hrs
Skype: cranstone
Website | www.3phealth.com<http://www.3phealth.com>  (Healthcare Patient Engagement and Data Interoperability)
Website | www.3pmobile.com<http://www.3pmobile.com> (Privacy by Design Platform for GDPR and ePrivacy reg.)

CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files or previous e-mail messages attached to it may contain information that is confidential or legally privileged. Any unauthorized review, use, disclosure or distribution of such information is prohibited. If you are not the intended recipient, please notify the sender by telephone or return e-mail and delete the original transmission and its attachments and destroy any copies thereof. Thank you.

Received on Saturday, 14 October 2017 18:41:33 UTC

This archive was generated by hypermail 2.3.1 : Saturday, 14 October 2017 18:41:34 UTC