Re: ACTION-172: Write up more detailed list of use cases for origin/origin exceptions

Explicit/explicit gives Controllers the opportunity to signal which 3rd parties are processors. Because the controller determines the purpose and means, controller is responsible for valid consent in the EU.

So my use case [A] would be: a DNT:0 signal sent to the limited and known list of processors, who are bound by a legal contract, i.e. the processor agreement. In my opinion, this is not the use case to use the '*' parameter, i.e. MUST NOT be used. In this case the list [Inc_A,Inc_B,...,Inc_Z] SHOULD/MUST be used.

Use case [B]: a DNT:0 signal to service providers, not being processors, but as a result controllers themselves or in some cases joint controller. It could be useful, but I haven't given it a lot of thought. My assumption for DNT:0 to be useful in this scenario is that the browser reflects user consent. This implies that the user has made an informed choice, preferably in the install/update flow of the browser to use DNT technology as a granular consent expression mechanism.

Rob


On 2-5-2012 9:54, Nicholas Doty wrote:
>>> * Separate data controllers in EU jurisdictions
>>> >>  A DNT:0 signal sent to a third-party service in the EU might usefully be interpreted as consent for independent use by that thid-party (that the service would itself be a data controller, not just a processor). EU regulations, however, may require that this consent be specific to the party rather than site-wide. (Suggested by Ninja, who may be able to add more detail.)
>> >  
>> >  Importance: Medium
>> >  
>> >  Design Notes:
>> >  I agree that being able to provide consent via DNT is useful. I cannot
>> >  judge what extent explicit/explicit is needed or whether a site-wide
>> >  exception would also be considered consent. An important question in
>> >  this use case is what responsibilities (under EU law) are implied from
>> >  the corresponding "Trust myself and my third parties" statement.
> I also welcome input from Ninja, Rob and others on this issue.
>

Received on Thursday, 3 May 2012 22:06:07 UTC