- From: Roy T. Fielding <fielding@gbiv.com>
- Date: Sat, 9 Jun 2012 16:31:59 -0700
- To: Ninja Marnau <nmarnau@datenschutzzentrum.de>
- Cc: "<public-tracking@w3.org> (public-tracking@w3.org)" <public-tracking@w3.org>
On Jun 6, 2012, at 6:20 AM, Ninja Marnau wrote: > There has been a long discussion on the explicit/explicit exception pairs. It kind of bogged down some weeks ago. > > I want to further motivate that we keep at least the option of a non-"*" exception in the spec. I will list the reasons that I already mentioned in DC but did not write down. Some of these arguments were already made in the related discussions referred below. > > 1) Liability: > A site-wide exception requested by the provider can be translated to (I am quoting Ian here): "I ask you to trust me to pick reputable third parties." > The issue here is that this blanket exception request creates under several legislations an (additional) unintentional liability of the first party for its third parties. Although under the EU Directive 95/46 the first party (data controller) already is responsible for its data processors' behaviour, it is generally not responsible for third parties who are data controllers themselves. Outside the EU there may be no liability for third parties without site-wide exceptions in the beginning. But this changes when the first party steps up and asks the user to trust its choice of third parties without giving further information on who will be responsible. If a (to the user unknown) third party misuses the data, the user may sue the first party (if she can track the misuse back to a specific first party), which then may have to prove to chose and control its third parties with special diligence ("reputable" for sure is not sufficient in Germany at least). I don't think that changes the situation we already have. Yes, there is some liability that goes along with any decision to use a third party, but it is usually mitigated by contract and selection. For example, an ad auction chain requires at least some basic agreement in order to participate in the auction, and I would assume the site owner would have vetted that agreement as part of its own decision to send traffic via the auction. DNT would not change that. > 2)Informed consent: > Consent may be site wide, but to be considered "informed", the user must be able to gain knowledge about the third parties that are considered data controllers (collect and process data on their own behalf). These data controllers are legally responsible in the EU. Therefore, the user needs to be able to determine who they are (even outside the EU this is of importance for reasons of litigation, objection, etc.) I don't see the problem. The browser is sending requests directly to the third party. In fact, the only software that knows for sure which party is being accessed, and when, is the browser. Hence, the user is able to determine who they are by making a request on "http://third-party.example.com/.well-known/dnt", exactly as already specified. > If we want the exceptions to at least partly work as an opt-in according to the ePrivacy Directive (only for third parties) transparency is necessary, granularity in choice would be the most convinient way to implement this in the DNT recommendation imho. As I mentioned to Rob, the directive requires explicit, informed, and specific prior consent for each purpose to which the data collected will be used. Since DNT does not itself communicate a purpose, the exception framework does not satisfy the ePrivacy Directive (by my reading, at least) regardless of how we tie down specific third parties. For DNT to have any value in Europe, specific purposes would have to be communicated by the DNT:0 signal or significant changes would be required to that directive. I doubt we have sufficient consensus to do the former, and I am not willing to specify a protocol based on speculation of future changes to the EU laws. I'd much rather ditch the exceptions entirely, send one DNT signal to all parties, and define an opt-in mechanism via cookies that can communicate and record prior consent for exactly the set of purposes requested by each party. Because it would be opt-in (when sent with DNT:1), it would not suffer from the problems associated with the opt-out proposals, can support existing browsers in the EU that don't need to send DNT:1, and can be implemented by sites the day it is specified. ....Roy
Received on Saturday, 9 June 2012 23:32:26 UTC