Re: Issues for Monday Call

Thanks for this, Mike,

I think this document serves as a good basis for the discussion.

As I recalled before, for consent to be valid in the EU, providing 
information is key (fairness and transparency principle). Under the 
draft) ePrivacy Regulation (EU) 2017/0003 (hereinafter: ePR) proposal, 
consent may be expressed by using the appropriate technical settings of 
a software application enabling access to the internet. Furthermore, 
users shall be given the possibility to withdraw their consent at any 
time.

The information properties the TSR should express are IMHO (a) who 
collects (b) what UID (c) for which purpose and (d) shares it with whom. 
These follow directly from the GDPR and the ePR proposal. Having the 
option for data controllers to express the information in the TSR will 
help them to become compliant with the law and will reduce the amount of 
pop-ups users are confronted with. I am aiming for the normative 
requirement of 'the TRS SHOULD contain property xyz'. But we should 
discuss whether a MAY could work as well.

Have a nice weekend,
Regards,
Rob

Mike O'Neill schreef op 2017-03-31 19:36:
> European Data Protection law has definite requirements for the
> information made available to users. In my opinion the TSR is the best
> place for these elements because a) they are not only required when
> consent is given, or when it is the legal basis for processing, and b)
> the TSR is more accessible to privacy researchers, regulators and
> browser extensions (if it was only available to the API we would need
> to add another API to report them).
> 
> They need not be mandatory in the TPE (though the simple string name
> property for controllers should be in my opinion), so why not put them
> in as a non-normative Addendum describing them as examples of TSR
> extensibility.
> 
> I have assembled my suggestions in a document (in the repo drafts 
> folder):
> 
> https://w3c.github.io/dnt/drafts/Transparency.html
> 
>> -----Original Message-----
>> From: Matthias Schunter (Intel Corporation) 
>> [mailto:mts-std@schunter.org]
>> Sent: 30 March 2017 08:11
>> To: public-tracking@w3.org (public-tracking@w3.org) <public-
>> tracking@w3.org>
>> Subject: Issues for Monday Call
>> 
>> Hi Folks,
>> 
>> based on the discussion last week. Below I codified an alternative
>> approach to resolving the TSR issues (based on the emails on the list
>> and input from last week).
>> 
>> Our list of issues is at:
>>   https://github.com/w3c/dnt/issues/23
>> Note that issues that are not resolved by end of April will be
>> auto-pushed out to potential future releases.
>> 
>> 
>> Regards,
>> matthias
>> 
>> -----
>> DISCUSSIONS FOR MONDAY
>> 
>> 1. Issue triage: Are there issues that are high priority and must be
>> resolved in April? If not, we can process without change.
>> 
>> 2. What additional fields are desired for simplifying compliance in 
>> the EU?
>> 
>> Note: So far I have not seen any submitted proposals for an additional
>> concrete field on the list. If I receive none, IMHO we can close this
>> discussion on monday.
>> 
>> 2. Best way to communicate "consent context".
>> Our current approach was that the TSR serves two roles:
>> 	A. Discovery (before visiting site) of essential tracking
>> 		information
>> 	B. Sufficient context to give clear meaning to
>> 		user-granted exception. This role triggered that we
>> 		plan to require TSR if the exception API is used.
>> 		It also fuels our discussion "what extra fields are
>> 		needed"
>> Roy suggested that TSR may be the best place for (B). Let us see 
>> whether
>> we find a better place for the consent-context information.
>> One suggestion was that it should be part of the API call.
>> 
>> 3. Asyncronous API / Update Events (Continued)
>> https://github.com/w3c/dnt/issues/13
>> 
>> 4. Anything else we want to discuss

Received on Saturday, 1 April 2017 08:32:54 UTC