Re: Issues for Monday Call

Thanks Shane,

You reply surely opens up our discussion in a positive way.

However, I do not think that there is any legal liability on the web 
browser as a processor in some part. If the browser collects telemetry 
for its own purposes or on behalf of another data controller, that is a 
scenario that I would love to keep out of the DNT debate. To keep things 
simple: the browser is not a legal entity but a means used by the 
consumer to visit a website or use a web service. Leaving the browser 
out of the picture, we can zoom in on the (real-time) transactional 
steps between the consumer and data controller towards consent.

Regards,
Rob



Shane M Wiley schreef op 2017-04-02 13:31:
> 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> 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]
>>>>> 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 Sunday, 2 April 2017 11:46:12 UTC