W3C home > Mailing lists > Public > public-tracking@w3.org > June 2012

ACTION-174: Write up implication of origin/* exceptions in EU context

From: Ninja Marnau <nmarnau@datenschutzzentrum.de>
Date: Wed, 06 Jun 2012 15:20:45 +0200
Message-ID: <4FCF592D.5020506@datenschutzzentrum.de>
To: "<public-tracking@w3.org> (public-tracking@w3.org)" <public-tracking@w3.org>
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).

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


I went through all of these related threads. I apologise if I missed 
some arguments.

Action 172: Write up more detailed list of use cases for origin/origin 
exceptions
http://www.w3.org/2011/tracking-protection/track/actions/172

The discussion thread on "explicit-explicit exception pairs"
http://lists.w3.org/Archives/Public/public-tracking/2012Apr/0196.html

ISSUE-129: User-granted Exceptions a) Site-wide Exceptions (mysite, 
any-third party)
http://www.w3.org/2011/tracking-protection/track/issues/129

ISSUE-147: Transporting Consent via the Exception / DNT mechanisms
http://www.w3.org/2011/tracking-protection/track/issues/147

Ninja

-- 

Ninja Marnau
mail: NMarnau@datenschutzzentrum.de - http://www.datenschutzzentrum.de
Telefon: +49 431/988-1285, Fax +49 431/988-1223
Unabhaengiges Landeszentrum fuer Datenschutz Schleswig-Holstein
Independent Centre for Privacy Protection Schleswig-Holstein
Received on Wednesday, 6 June 2012 13:19:34 UTC

This archive was generated by hypermail 2.3.1 : Friday, 21 June 2013 10:11:30 UTC