RE: Issue 12: Javascript API to return promises instead of nothing.

I forgot to add:

 

All WG docs. are “open source”, how they are implemented is up to who uses them. 

 

From: Shane M Wiley [mailto:wileys@yahoo-inc.com] 
Sent: 02 February 2017 16:21
To: Mike O'Neill <michael.oneill@baycloud.com>; rob@blaeu.com
Cc: 'TOUBIANA Vincent' <vtoubiana@cnil.fr>; 'David Singer' <singer@mac.com>; 'Matthias Schunter (Intel Corporation)' <mts-std@schunter.org>; public-tracking@w3.org
Subject: Re: Issue 12: Javascript API to return promises instead of nothing.

 

Mike,

 

With respect to proposal #1 - I believe you could develop something on your own if you like (open source?) but I'm confident many publishers will NOT want to cede control of consent messaging to the browser and will want to maintain a direct dialogue with their users.

 

Proposal #2 - Again, it appears you're leaning towards a specific UX for implementation.  Same issues as above but more than supportive of you developing something (open source?) that publisher then could modify for their own purposes.

 

- Shane

 

Shane Wiley
VP, Privacy Policy
Yahoo

 

  _____  

From: Mike O'Neill <michael.oneill@baycloud.com <mailto:michael.oneill@baycloud.com> >
To: 'Shane M Wiley' <wileys@yahoo-inc.com <mailto:wileys@yahoo-inc.com> >; rob@blaeu.com <mailto:rob@blaeu.com>  
Cc: 'TOUBIANA Vincent' <vtoubiana@cnil.fr <mailto:vtoubiana@cnil.fr> >; 'David Singer' <singer@mac.com <mailto:singer@mac.com> >; 'Matthias Schunter (Intel Corporation)' <mts-std@schunter.org <mailto:mts-std@schunter.org> >; public-tracking@w3.org <mailto:public-tracking@w3.org> 
Sent: Wednesday, February 1, 2017 3:23 PM
Subject: RE: Issue 12: Javascript API to return promises instead of nothing.

 

Shane,

 

To be clear I have 2 proposals:

 

1.     For a mechanism to implement site-specific consent. We have an API for registering it, but not for implementing it in a clearly verifiable way that users will believe. I suggested that this may be useful for publishers as it helps them explain and obtain user consent.

2.     For a similar mechanism to both registering and implementing qualified web-wide consent. This would allow demand side advertisers to declare purpose and retention limits in order to obtain easily revocable user consent for a defined set of first-party/third-party combinations.

 

I produced a technical document for 1) https://w3c.github.io/dnt/sitespecificconsent.html , and have some ideas for 2) that I can post if there is interest in pursuing it.

 

Mike

 

From: Shane M Wiley [mailto:wileys@yahoo-inc.com] 
Sent: 01 February 2017 20:39
To: Mike O'Neill <michael.oneill@baycloud.com <mailto:michael.oneill@baycloud.com> >; rob@blaeu.com <mailto:rob@blaeu.com> 
Cc: 'TOUBIANA Vincent' <vtoubiana@cnil.fr <mailto:vtoubiana@cnil.fr> >; 'David Singer' <singer@mac.com <mailto:singer@mac.com> >; 'Matthias Schunter (Intel Corporation)' <mts-std@schunter.org <mailto:mts-std@schunter.org> >; public-tracking@w3.org <mailto:public-tracking@w3.org> 
Subject: Re: Issue 12: Javascript API to return promises instead of nothing.

 

Mike,

 

I'm comfortable with both Site and Web Wide exceptions as they currently stand for a number of reasons:

 

1) They are useful globally (we're not building DNT only for the EU)

2) They are other mechanisms to provide coverage for the web-wide situation that you call out and without real research I'm not going to take any one person's perspective on what users will or won't accept.  Reality has taught me that most research in this area is typically unable to map "survey results" to "real world results" as they often lack the quid-pro-quo elements of "free content/experiences" that motivate users to "do" something different than they said they would do in a survey.

 

That said, we could offer a "limited" Web Wide exceptions as a 3rd option (or a variation of the same option) with more narrowly defined scope if we feel there is a real need from publishers.

 

- Shane

 

Shane Wiley
VP, Privacy Policy
Yahoo

 

  _____  

From: Mike O'Neill <michael.oneill@baycloud.com <mailto:michael.oneill@baycloud.com> >
To: 'Shane M Wiley' <wileys@yahoo-inc.com <mailto:wileys@yahoo-inc.com> >; rob@blaeu.com <mailto:rob@blaeu.com>  
Cc: 'TOUBIANA Vincent' <vtoubiana@cnil.fr <mailto:vtoubiana@cnil.fr> >; 'David Singer' <singer@mac.com <mailto:singer@mac.com> >; 'Matthias Schunter (Intel Corporation)' <mts-std@schunter.org <mailto:mts-std@schunter.org> >; public-tracking@w3.org <mailto:public-tracking@w3.org> 
Sent: Tuesday, January 31, 2017 5:07 AM
Subject: RE: Issue 12: Javascript API to return promises instead of nothing.

 

Hi Shane,

 

Consent for a third-party needs to be explained freely obtained now, and will be especially pertinent after May 2018. Also, the EPR proposal introduces the idea, which the Parliament will probably build on,  that user agents should actively block non-consented data exchange.

 

Currently we have described an API for registering site-specific and web-wide consent.

 

Site-specific consent maps onto the publisher model quite well, helping the publisher minimise “ID leakage” by restricting data exchange to a first-party site. Users are more likely to agree to this also, though it would be a good idea to make this more verifiable and less reliant on “operational & administrative procedures”, which is why I started issue #14 https://github.com/w3c/dnt/issues/14. 

 

Web-wide consent as we have described it is easier to implement with HTTP cookies, but again, users are unlikely to agree to it, especially to a third-party which may be present on any site without warning across the web. 

 

IMO we should refine web-wide consent. If it could be shown that data sharing was restricted to specified contexts, say only to third-parties/first-party combinations that contracted to specified purpose and retention limits then users would be more likely to agree. 

 

If there is interest in exploring this I will start a new issue, and suggest some initial text.

 

Mike

 

 

 

 

From: Shane M Wiley [mailto:wileys@yahoo-inc.com] 
Sent: 26 January 2017 19:59
To: rob@blaeu.com <mailto:rob@blaeu.com> 
Cc: TOUBIANA Vincent <vtoubiana@cnil.fr <mailto:vtoubiana@cnil.fr> >; Mike O'Neill <michael.oneill@baycloud.com <mailto:michael.oneill@baycloud.com> >; 'David Singer' <singer@mac.com <mailto:singer@mac.com> >; 'Matthias Schunter (Intel Corporation)' <mts-std@schunter.org <mailto:mts-std@schunter.org> >; public-tracking@w3.org <mailto:public-tracking@w3.org> 
Subject: Re: Issue 12: Javascript API to return promises instead of nothing.

 

Rob,

 

Exchanges do add a real complication here - one we discussed at length while working on the TCS.  

 

If a 1st party is able to secure a "site-wide exception" from the user this solves for the exchange model from the end-user DNT perspective for that site.  This does NOT not solve for processor/controller contractual obligations though - if you see the independent 3rd party as something other than a co-controller.  (Note - I don't believe DNT can solve this particular aspect of the situation).  

 

Alternatively, as 3rd parties are exposed to users in real-time as part of the ad delivery they could be shown a pop-up dialogue (with the 1st parties permission) in an attempt to secure a "web-wide exception" for that specific domain.  

 

This still doesn't solve for the trading of user IDs during the bidding process that comes a step prior to ad delivery - I believe is where you're focusing your attention, correct?  When we look at cookie mapping I've been assuming that sites have gained consent for themselves and their third party partners to allow for both tracking cookies and the mapping between them.  Do you see this initial cookie consent step as changing under GDPR or the ePR Draft?

 

- Shane

 

Shane Wiley
VP, Privacy Policy
Yahoo

 

  _____  

From: Rob van Eijk < <mailto:rob@blaeu.com> rob@blaeu.com>
To: Shane M Wiley < <mailto:wileys@yahoo-inc.com> wileys@yahoo-inc.com> 
Cc: TOUBIANA Vincent < <mailto:vtoubiana@cnil.fr> vtoubiana@cnil.fr>; Mike O'Neill < <mailto:michael.oneill@baycloud.com> michael.oneill@baycloud.com>; 'David Singer' < <mailto:singer@mac.com> singer@mac.com>; 'Matthias Schunter (Intel Corporation)' < <mailto:mts-std@schunter.org> mts-std@schunter.org>;  <mailto:public-tracking@w3.org> public-tracking@w3.org
Sent: Thursday, January 26, 2017 11:38 AM
Subject: Re: Issue 12: Javascript API to return promises instead of nothing.



Shane,

A third party data controller within a firt party context may rely on a 
first party to gain valid consent. However, as we are seeing in the EU, 
may sites are struggling with real time bidding. The first party is in 
some cases not in the best position to inform adequately about all the 
purposes of the data processing of every third parties showing up within 
the first party context. As a result unknown parties are processing 
personal data for unknown purposes. Not an optimal situation, in 
addition to the third party acting outside of the control of the first 
party. In the EU a third party without a data processor agreement will 
have to gain consent somehow before dropping/deriving/collecting a uid.

Mike raises an important issue which we should think through. Working 
with a JavaScript promises may lead to a better/uninterrupted user 
experience and possibly help them comply with local law. IMHO, important 
enough to take it seriously and not be too dogmatic about the outcome of 
previous discussions.

Rob

Shane M Wiley schreef op 2017-01-26 18:59:
> Vincent,
> 
> We discussed this at length in the Working Group and agreed the 3rd
> party would need to coordinate their consent request with their 1st
> party partners.  They could of course leverage a pop-up dialogue as
> part of their ad/widget/content but they would likely upset their 1st
> party partner if this was done with no coordination and with no
> expectation from the 1st party partner that a user experience was
> going to change outside of their control.
> 
> - Shane
> 
> Shane Wiley
> VP, Privacy Policy
> Yahoo
> 
> -------------------------
>  FROM: TOUBIANA Vincent <vtoubiana@cnil.fr <mailto:vtoubiana@cnil.fr> >
> TO: Mike O'Neill <michael.oneill@baycloud.com <mailto:michael.oneill@baycloud.com> >; 'David Singer'
> <singer@mac.com <mailto:singer@mac.com> >
> CC: 'Matthias Schunter (Intel Corporation)' <mts-std@schunter.org <mailto:mts-std@schunter.org> >;
> "public-tracking@w3.org <mailto:public-tracking@w3.org> " <public-tracking@w3.org <mailto:public-tracking@w3.org> >
> SENT: Thursday, January 26, 2017 12:53 AM
> SUBJECT: RE: Issue 12: Javascript API to return promises instead of


> nothing.
> 
> Hi David and Mike,
> 
> I agree with Mike, the Exception API is AFAIU necessary to obtain
> consent through DNT. One of the question related to the new ePrivacy
> regulation is how third parties can obtain consent, it was apparently
> raised during a Q&A session and the answer provided was "Defer to the
> market" [1]. It would be useful to have a DNT implementation
> addressing this.
> 
> The regulation is also pushing from some changes in the browsers,
> especially to provide information and obtain consent when user first
> install or update a browser (see article 10 of the current draft:
> http://ec.europa.eu/newsroom/dae/document.cfm?doc_id=41241). This push
> for a significant update may solve the "After you" problem.
> 
> Regards,
> 
> Vincent
> 
> [1] The only source is a tweet, the stream is no longer available
> https://twitter.com/Andreea_L2/status/821328127653711872
> 
> -----Message d'origine-----
> De : Mike O'Neill [mailto:michael.oneill@baycloud.com <mailto:michael.oneill@baycloud.com> ]
> Envoyé : mercredi 25 janvier 2017 22:59
> À : 'David Singer' <singer@mac.com <mailto:singer@mac.com> >
> Cc : 'Matthias Schunter (Intel Corporation)' <mts-std@schunter.org <mailto:mts-std@schunter.org> >;
> public-tracking@w3.org <mailto:public-tracking@w3.org> 
> Objet : RE: Issue 12: Javascript API to return promises instead of
> nothing.
> 
> Hi David,
> 
> If you mean  the JS API, the relevant EU legal requirement is for
> "freely given, informed, *specific*, unambiguous" consent (in ePrivacy
> via "terminal settings"), which the API provides.
> Without it DNT has very little point IMO.
> Moreover we already have 2 independent interoperable implementations.
> 
> Anyway the point about promises is to make the API more usable for the
> modern web platform, as I have already written about ad nauseam. I
> only raised it again because you mentioned as something we could do as
> a quick win. The API still works without it, even if it irritates the
> developers who will have to add the asynchronous capability themselves
> (with unnecessary extra latency)
> 
> -----Original Message-----
> From: David Singer [mailto:singer@mac.com <mailto:singer@mac.com> ]
> Sent: Wednesday, January 25, 2017 9:15 AM
> To: Mike O'Neill <michael.oneill@baycloud.com <mailto:michael.oneill@baycloud.com> >
> Cc: Matthias Schunter (Intel Corporation) <mts-std@schunter.org <mailto:mts-std@schunter.org> >;
> public-tracking@w3.org <mailto:public-tracking@w3.org> 
> Subject: Re: Issue 12: Javascript API to return promises instead of
> nothing.
> 
> Hi Mike
> 
> I guess I am finding it hard to get enthusiastic about fixing a
> feature that’s very likely to be marked as “at risk of removal”
> in the CR and removed through lack of interoperable support in the PR.
> 
>> On Jan 25, 2017, at 9:03 , Mike O'Neill
> <michael.oneill@baycloud.com <mailto:michael.oneill@baycloud.com> >
>> wrote:
>> 
>> I don't think changing the API to return a promise changes much, it
>> only affects the IE implementation which already does not comply
> with
>> the rec anyway (does not support navigator.doNotTrack for a start).
>> Bouncer will be fixed to comply with whatever we agree in a jiffy.
>> 
>> But we may want other changes anyway so why don't we schedule a drop
> 
>> dead date for all the TPE changes we agree on,  say june/july,
> giving
>> us a couple months or so  for the transition request.
>> 
>> -----Original Message-----
>> From: Matthias Schunter (Intel Corporation)
>> [mailto:mts-std@schunter.org <mailto:mts-std@schunter.org> ]
>> Sent: Tuesday, January 24, 2017 8:31 PM
>> To: public-tracking@w3.org <mailto:public-tracking@w3.org> 
>> Subject: Re: Issue 12: Javascript API to return promises instead of
>> nothing.
>> 
>> Hi TPWW,
>> 
>> 
>> BERT: this is very useful information.
>> 
>> Here are two process suggestions.
>> 
>> -------------
>> ANOTHER TRANSITION?
>> 
>> We should try to balance efficiency/speed and a useful outcome.
>> For me, being required to issue another transition request would not
> 
>> be a show-stopper.
>> I guess it also would not cause huge delay (say more than 1 month),
>> won't it?
>> 
>> What we could do is triage changes according to two criteria:
>> 
>> (a) Are they essential to reach our goal or nice to have?
>> (b) Are they substantial or editorial?
>> 
>> If we do not have essential changes that are substantial, we will
> not
>> need to take the burden of another transition.
>> We we do, there is no way around it.
>> 
>> -----
>> IMPLEMENTATION/INTEROP
>> 
>> We should soon document our implementation / interop test plans and
>> discuss them in the group and then with the director.
>> Once we all have a joint understanding of the plans and informal OK
>> that the plans are likely to meet the W3C requirements, then we are
>> good to go.,
>> 
>> 
>> What do you think? Any other feedback?
>> 
>> 
>> Regards,
>> 
>> matthias
>> 
>> 
>> 
>> On 24.01.2017 14:45, Bert Bos wrote:
>>> On Tuesday, January 24, 2017 8:45:56 AM CET Schunter, Matthias
> wrote:
>>>> Hi Roy,
>>>> 
>>>> PS: As far as I know, W3C now allows to change the spec while
>>>> iterating in the candidate recommendation state. I.e. no need to
> go
>>>> back to WD even if we introduce changes to the API.
>>> Yes, but the exact process depends on the kind of changes:
>>> 
>>> Republishing a CR with only editorial changes simply requires a WG
>>> decision and can be done as often as the WG wishes. It needs the
>>> Webmaster's help, so only on Tuesdays and Thursdays, but otherwise
> no
>>> need to talk to anybody.
>>> 
>>> The same holds for republishing a CR after removing features that
>>> were already marked explicitly as "at risk".
>>> 
>>> The WG can also decide at any time to republish the CR as a WD.
>>> 
>>> But republishing a CR with "substantive changes" requires writing a
> 
>>> new Transition Request (with all the usual things that go into such
> a
>>> request) and waiting for Director's approval. If the changes are
>>> small, such approval is likely to be quick, though.
>>> 
>>> "Substantive changes" are changes that affect conformance or add
> new
>>> features: i.e., any changes that can make an implementation that
> used
>>> to
>> 
>>> be conforming now non-conforming, or vice-versa.
>>> 
>>> 
>>> I haven't looked at the change itself, but based on Roy's e-mail
>>> below, it seems to be a change that affects conformance. And so it
>>> requires writing a new Transition Request if we want the updated
> spec
>>> to
>> be a CR.
>>> 
>>> I can help writing such a Transition Request, but I can't do it on
> my
>>> own. I don't know enough about the history of the spec and its
>>> implementations yet.
>>> 
>>>> -----Original Message-----
>>>> From: Roy T. Fielding [mailto:fielding@gbiv.com <mailto:fielding@gbiv.com> ]
>>>> Sent: Tuesday, January 24, 2017 9:15 AM
>>>> To: Matthias Schunter (Intel Corporation) <mts-std@schunter.org <mailto:mts-std@schunter.org> >
>>>> Cc: public-tracking@w3.org <mailto:public-tracking@w3.org>  (public-tracking@w3.org <mailto:public-tracking@w3.org> )
>>>> <public-tracking@w3.org <mailto:public-tracking@w3.org> > Subject: Re: Issue 12: Javascript API to
>>>> return promises instead of nothing.
>>>> 
>>>> Umm, the downside is that it is a normative change to the API,
> which
>>>> means we go back to WD status and have zero implementations.
>>>> 
>>>> I want commitments from browsers to implement this change before
> we
>>>> make it. Right now we should assume the entire API will be
> removed.
>>>> 
>>>> ....Roy
>>>> 
>>>>> On Jan 24, 2017, at 3:20 AM, Matthias Schunter (Intel
> Corporation)
>>>>> <mts-std@schunter.org <mailto:mts-std@schunter.org> > wrote:
>>>>> 
>>>>> Hi Folks,
>>>>> 
>>>>> 
>>>>> Sites can use our javascript API to register site-wide and
> web-wide
>>>>> exceptions. Currently the corresponding calls do not return any
>>>>> results.
>>>>> 
>>>>> Mike proposed to return promises. These would allow the engine to
> 
>>>>> call-back to a site once it has processed a javascript request.
>>>>> This renders our API more asynchronous.
>>>>> 
>>>>> IMHO there does not be a downside to this proposal. Mike posted
> the
>>>>> changed javascript API here: https://github.com/w3c/dnt/issues/12
>>>>> 
>>>>> 
>>>>> Unless somebody objects before our next call, I suggest to
>>>>> introduce this change to our API.
>>>>> 
>>>>> 
>>>>> Regards,
>>>>> 
>>>>> matthias
>>>> Intel Deutschland GmbH
>>>> Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany
>>>> Tel: +49 89 99 8853-0, www.intel.de <http://www.intel.de/> 
>>>> Managing Directors: Christin Eisenschmid, Christian Lamprechter
>>>> Chairperson of the Supervisory Board: Nicole Lau Registered
> Office:
>>>> Munich Commercial Register: Amtsgericht Muenchen HRB 186928
>>> 
>>> 
>>> Bert
>> 
>> 
>> 
>> 
> 
> Dave Singer
> 
> singer@mac.com <mailto:singer@mac.com>