- From: Peter Cranstone <peter.cranstone@3phealth.com>
- Date: Tue, 24 Oct 2017 17:24:43 +0000
- To: "Roy T. Fielding" <fielding@gbiv.com>
- CC: public-tracking-comments w3.org <public-tracking-comments@w3.org>
- Message-ID: <8C729CBD-C4CB-40C1-90D8-15F7D8D4C030@3phealth.com>
Roy, After thinking about your email some more I find myself in agreement with you - something that rarely happens. So in the context of public comments on the specification in the CR as it relates to the question posed by Robin I would now change my answer. His two questions are: 1. Is the intent of the Tracking Preference Expression that `DNT:0` would convey consent in the sense of GDPR Article 4, definition 11, and Article 7? 2. Is the intent of the TPE that `DNT:1` would convey a user's objection to processing in the sense of GDPR Article 21, specifically paragraph 5 concerning the "right to object by automated means using technical specifications". Based on the CR I would change my previous answers from NO to YES. The protocol is designed to communicate a signal, either a 0 or a 1 that indicates an intent by the user. So that signal COULD be used in support of both of your questions. And there I have to end the conversation (as Roy correctly points out). Anything about the HOW is out of scope for the protocol. You COULD use the other part of the CR to ask for a User Generated Exception (UGE: this idea came about based on first and third parties) which adds more ‘extensibility’ to the protocol to help you solve your problem. Again how you do that is again out of scope for the protocol. With regard to the UGE database - this is also out of scope for the protocol. The CR mentions WHY in this section: https://w3c.github.io/dnt/drafts/CRc-tracking-dnt.html#security Use of client-side storage is always a security concern. Although the information being stored for each user-granted exception is limited and cannot be directly accessed by scripts, storing too many exceptions might exceed available storage or indicate an attempt to exploit other vulnerabilities. There are also security concerns regarding the ability of scripts to store exceptions beyond the scope of their effective script origin. So in summary - I would say that apart from a few engineering nits the CR is final. It does exactly what it was designed to do - send a privacy signal with the MINIMUM of INFORMATION and give the server a way to negotiate for a different setting from the user. Can you use the current DNT protocol for GDPR - Maybe? Only you have to decide if it meets your business requirements. Cheers, Peter Peter Cranstone CEO, 3PHealth COMS: 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. On Oct 23, 2017, at 11:04 AM, Roy T. Fielding <fielding@gbiv.com<mailto:fielding@gbiv.com>> wrote: Everyone, The purpose of this list (public-tracking-comments) is to receive public comments on the specification in CR. It is not for discussing WG business or making proposals for WG consideration. It is certainly not for discussing regional laws: do that on the privacy interest group lists. Cheers, Roy T. Fielding <http://roy.gbiv.com/> Senior Principal Scientist, Adobe <https://www.adobe.com/>
Received on Tuesday, 24 October 2017 17:25:10 UTC