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


ad hoc advertisement auctions would be impossible under the rules 
you describe here. This means the DPAs consider a multi-billion 
dollar industry illegal. This is exactly the kind of gap between the 
real world and the data protection system that makes things so 

To remedy the situation, I suggested to have transitive permissions. 
The price to pay is that the first data controller using the 
transitive permission to hand data to sub-data controllers would be 
liable for his/her choice. 

To complete ACTION-174, I would like you to also inquire about the 
possibility that such a system of transitive permissions is 
acceptable. Can you ask back inside the DPA system?


On Wednesday 06 June 2012 15:20:45 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).
> 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
> The discussion thread on "explicit-explicit exception pairs"
> tml
> ISSUE-129: User-granted Exceptions a) Site-wide Exceptions
> (mysite, any-third party)
> ISSUE-147: Transporting Consent via the Exception / DNT mechanisms
> Ninja

Received on Wednesday, 6 June 2012 15:07:05 UTC