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

Hi Nick, comments in line.

Mike

> -----Original Message-----
> From: Nick Doty [mailto:npdoty@ischool.berkeley.edu]
> Sent: 13 February 2017 00:53
> To: Mike O'Neill <michael.oneill@baycloud.com>
> Cc: David Singer <singer@mac.com>; TOUBIANA Vincent <vtoubiana@cnil.fr>;
> Matthias Schunter (Intel Corporation) <mts-std@schunter.org>; public-
> tracking@w3.org
> Subject: Re: Issue 12: Javascript API to return promises instead of nothing.
> 
> (Apologies, I got behind on this discussion and got confused about the call
> schedule but we'll be joining tomorrow so I'm trying to catch up.)
> 
> Do we have the sites using the Exception API listed in our implementation
> report? That seems like very valuable information, and not something I was
> aware of.
Good point. The API already had a column in the server-side table, but mentioned only the Baycloud sites. I have added 2 entries as representative examples of the several thousand sites using the service for ePrivacy compliance. 
> 
> I can understand why there would be hesitation about making a breaking change
> to the API (to return promises rather than being void/synchronous), but I don't
> see what new functionality we would get from making it asynchronous that
> would provide any compliance advantage in the EU. We all considered making it
> asynchronous and using browser interface to get confirmation of consent (that
> was the initial design in early drafts that I contributed to); the group ultimately
> decided that it was easier for site owners to get consent in their web content
> and then just register it with a synchronous API, no Promises needed. I
> understand that EU sites have an interest in getting informed consent; but that
> can be done by site owners in their own content, rather than needing it to be an
> interactive process with the browser (which would benefit from an
> asynchronous API).
> 
> We also considered Promises in response to Last Call comments, and noted in
> our response that we had intentionally chosen not to make it asynchronous
> specifically because the purpose of the API was not to gain user consent, but to
> register consent that had already been received.


Returning a Promise is not about EU compliance or client-side confirmation of Exceptions.

Asynchronous responses are necessary to implement working web applications in Javascript. If the API does not return a Promise then the asynchronous capability has to be added by the developer, as I have explained. 

Web applications are increasingly client based with the logic implemented in JavaScript, which necessitates asynchronous working. 
In our case one example of this is that calling confirmSiteSpecific synchronously after a call to storeSiteSpecific will always fail (always return false even if the Exception was granted). In order for the logic to work a setTimeout call has to be made with an arbitrary time interval, which is infuriating for developers. This is what Promises are for, and why they were suggested in the last call comments.

In fact Promises would not be suitable for detecting user revocation or client grant confirms, you would probably use an Event for this.



> 
> Apologies for my confusion and being late to this discussion; I'd appreciate any
> explanations others can provide.
> Cheers,
> Nick
> 
> > On Feb 1, 2017, at 6:09 AM, Mike O'Neill <michael.oneill@baycloud.com>
> wrote:
> >
> > Hi David,
> >
> > We can change both sides if need be, our site plugin CookieQ has been on
> these sites since 2013, making calls to the API if the browser supported it. It has
> worked with Internet Explorer since then, in Edge since it started appearing in
> 2014 (until the API was disabled in it in May 2016) and with Bouncer since Aug
> 2015. In total these sites receive more than 1M pageviews per day, from which
> we have been collecting statistics on aggregated DNT usage since Jan 2013. For
> example here is a chart showing the proportion of requests sent with DNT
> headers (0 or 1) broken down by browser company
> https://baycloud.com/chart/dnt
> >
> > CookieQ deletes tracking cookies (actually any storage that has not been
> declared to be "strictly necessary to fulfil a service requested by the user") unless
> consent has been given and after it has been revoked, and uses the JS DNT API
> to send DMT:0 to embedded third-party when explicit consent has been given. It
> can also inhibit the loading of embedded third-parties when DNT is 1. I can give
> anyone a demo of this whenever they want.
> >
> > The API is used on well over 4,000 active production consumer facing sites in
> almost all EU Member States, as well as other countries including some in North
> America.
> >
> > In any case the proposed changes to the API do not affect the current
> implementation, because the return value is ignored (for the store and remove
> calls it was a void). The confirm call is also used and that does need a slight
> change (the changed confirm call would return a Promise resolving to a
> DOMString instead of immediately returning a DOMString), but as I have said this
> will simplify the code which currently has to simulate an asynchronous return.
> Anyone else using the API they would have expressed irritation at the same
> problem.
> >
> > Mike
> >
> >
> > -----Original Message-----
> > From: David Singer [mailto:singer@mac.com]
> > Sent: 01 February 2017 08:57
> > To: Mike O'Neill <michael.oneill@baycloud.com>
> > Cc: TOUBIANA Vincent <vtoubiana@cnil.fr>; Matthias Schunter (Intel
> Corporation) <mts-std@schunter.org>; public-tracking@w3.org
> > Subject: Re: Issue 12: Javascript API to return promises instead of nothing.
> >
> >
> >> On Jan 31, 2017, at 11:40 , Mike O'Neill <michael.oneill@baycloud.com>
> wrote:
> >>
> >> Hi David,
> >>
> >> The API has been in use since 2013 implementing ePrivacy compliance server-
> side on thousands of sites (including Unilever & GSK consumer brand sites)
> >
> > thousands of sites use the JS exception API and will change if we change the
> definition?  That surprises me
> >
> >> and client-side on IE, Edge (from 2014 till May 2016), and Chrome (with
> Bouncer).
> >
> > and we expect more than one of these to change if we change the API (I know
> you’ll change bouncer)
> >>
> >> Mike
> >>
> >>
> >> -----Original Message-----
> >> From: David Singer [mailto:singer@mac.com]
> >> Sent: 27 January 2017 06:12
> >> To: TOUBIANA Vincent <vtoubiana@cnil.fr>
> >> Cc: Mike O'Neill <michael.oneill@baycloud.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.
> >>
> >>
> >>> On Jan 26, 2017, at 10:53 , TOUBIANA Vincent <vtoubiana@cnil.fr> wrote:
> >>>
> >>> Hi David and Mike,
> >>>
> >>> I agree with Mike, the Exception API is AFAIU necessary to obtain consent
> through DNT.
> >>
> >> We’re at cross purposes.  I didn’t question whether the API is needed; I
> questioned whether it is implemented/used on either end, and hence if it’s likely
> to get removed on the way to Rec.
> >>
> >>> 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]
> >>> Envoyé : mercredi 25 janvier 2017 22:59
> >>> À : 'David Singer' <singer@mac.com>
> >>> Cc : 'Matthias Schunter (Intel Corporation)' <mts-std@schunter.org>; 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]
> >>> Sent: Wednesday, January 25, 2017 9:15 AM
> >>> To: Mike O'Neill <michael.oneill@baycloud.com>
> >>> Cc: Matthias Schunter (Intel Corporation) <mts-std@schunter.org>; 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>
> >>>> 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]
> >>>> Sent: Tuesday, January 24, 2017 8:31 PM
> >>>> To: 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]
> >>>>>> Sent: Tuesday, January 24, 2017 9:15 AM
> >>>>>> To: Matthias Schunter (Intel Corporation) <mts-std@schunter.org>
> >>>>>> Cc: public-tracking@w3.org (public-tracking@w3.org)
> >>>>>> <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> 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
> >>>>>> 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
> >>>
> >>>
> >>>
> >>
> >> Dave Singer
> >>
> >> singer@mac.com
> >>
> >>
> >>
> >>
> >
> > Dave Singer
> >
> > singer@mac.com
> >
> >
> >
> >

Received on Monday, 13 February 2017 09:38:14 UTC