RE: Issues for Monday Call

Shane,

 

One big advantage of machine-readable data is that it can be presented to the user by parties who are better able to do that. An embedded sub-resource may not be in control of any “real estate” on a page, and can only rely on the containing site, a third-party script library on that site, or the user agent to present it to the user. If the information is in a standardised machine readable form then companies can compete to present it in ways that the user can understand.

 

Otherwise information would have to be buried in a legalistic privacy policy which we know nobody bothers to read anyway.

 

If the issue is that the third-party needs to supply its own presentation then that could be conveyed through properties in the TSR also, we could discuss that.

 

On the legal point, and as you say IANAL, the proposed ePrivacy Regulation covers more than just Processors and Controllers, e.g. see Recital 8 in the ePR. Companies that provide software, e.g. O/S or browsers, are also drawn in (in A.10 as I already said).

 

“This Regulation should apply to providers of electronic communications services, to providers of publicly available directories, and to software providers permitting electronic communications, including the retrieval and presentation of information on the internet. This Regulation should also apply to natural and legal persons who use electronic communications services to send direct marketing commercial communications or collect information related to or stored in end-users’ terminal equipment.”

 

Mike

 

 

From: Shane M Wiley [mailto:wileys@yahoo-inc.com] 
Sent: 02 April 2017 12:31
To: rob@blaeu.com; Matthias Schunter (Intel Corporation) <mts-std@schunter.org>
Cc: public-tracking@w3.org
Subject: Re: Issues for Monday Call

 

Unfortunately I won't be able to join on Monday but I think it's important to gain two key perspectives here:  browsers and publishers.

 

Any concepts of pre-flighting or automated processing place legal liability on the web browser as a processor in some part and if they are processing this outside of a contract with the publisher/3rd party one could argue they are acting as a controller in this regard (independent access and control).  Based on our initial discussions with browser vendors this was not something they were interested in but it would be helpful to hear from those that Rob's solution places the greatest burden upon.

 

I'm trying to understand how placing more in the TSO changes the dialogue with the user.  In either case a consent conversation must occur and any party can raise this through a UGE request which then points to their WKL which in turn carries all the information being discussed and likely more.

 

Attempting to add more structure feels like there is a goal of automation such that browsers take on considerably more liability and data controllers (publishers/3rd parties) are further removed from direct conversations with their users.  Those don't feel like appropriate goals for the working group.

 

- Shane

 

Sent from mobile phone so please excuse brevity and typos. 

 

On Sun, Apr 2, 2017 at 7:14 AM, Rob van Eijk

<rob@blaeu.com <mailto:rob@blaeu.com> > wrote:



To simplyfy the discussion, there are at least three scenario's:

A: pre-flight checking
B: consent by data controller for itself, its processors (same party) 
and any third parties that the controller can identify (webResources)
C: consent by 3rd parties that cannot rely on OOBC or the consent by the 
data controller.

The TSR has different functions, or no fuction at all in these 3 
scenario's. I think collating these scenario's confuses our discussion. 
If I have understood the discussion so far, Roy's comments see to 
scenario B and possibly scenario C. Shané comments see mainly to 
scenario B.

My assumption is that the more real-time the consent becomes, i.e., 
scenario C, the more information needs to be readily available and 
presented to the user such that he/she can grant an exception. The TSR 
may be a good building block to use in real-time situations like 
scenario C for third parties that cannot rely on G as a TSV. It can be 
parsed by browsers when the third party asks for an exception based on 
the information presented. Machine readable metadata in the TSR means 
that browsersetting can be rule based, which could be a huge benefit for 
both the third-party and the user.

Talk to you all on Monday,

Best regards,
Rob


Matthias Schunter (Intel Corporation) schreef op 2017-04-01 17:09:
> Hi Mike,
> 
> 
> thanks a lot for this detailed inputs.
> 
> It helps to clarify what fields are actually suggested and what their
> content should be.
> 
> I tend to agree that this data is useful (or even required) for GPDR
> compliance.
> 
> However, in the spirit of "minimal changes" I tend to suggest to keep
> all data under the URL in a human-readable form.
> 
> What we need to clarify further is:
> - Why is the data required to be machine readable?
> - What actions will the browser take once it has read and parsed this 
> data?
> - What bad things would happen if the data continues to be available in
> human-readable form only?
> - Why couldnt the fields be defined in a "EU compliance" note (since
> they seem to be specific to the EU)?
> 
> If the browser will only store this data, then a consent-metadata blob
> (JSON or so) would be sufficient. Further notes and best practices can
> then structure this object further.
> 
> Just my 2cents. Let us discuss this further on monday.
> 
> 
> Regards,
> matthais
> 
> 
> 
> 
> On 31.03.2017 19:36, Mike O'Neill wrote:
>> 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 <mailto:mts-std@schunter.org> ]
>>> Sent: 30 March 2017 08:11
>>> To: public-tracking@w3.org <mailto:public-tracking@w3.org>  (public-tracking@w3.org <mailto:public-tracking@w3.org> ) <public-
>>> tracking@w3.org <mailto: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
>> 
>> 
>>