RE: Promises

Thanks David.

UAs will probably never register fast enough because of the single-threaded nature of JavaScript. Not returning a Promise or using a callback is tantamount to forcing a storeException ( or confirmException) implementation to be synchronous, which is a very bad idea.

Relying on servers "knowing" what was intended means using UIDs (connecting one browser context origin to another) which is also not good given the context.

Mike



-----Original Message-----
From: singer@apple.com [mailto:singer@apple.com] 
Sent: 07 October 2015 18:51
To: Mike O'Neill <michael.oneill@baycloud.com>
Cc: Roy T. Fielding <fielding@gbiv.com>; public-tracking@w3.org; Adrian Bateman <adrianba@microsoft.com>; Mounir Lamouri <mounir@lamouri.fr>; Mike West <mkwst@google.com>
Subject: Re: Promises

OK

I think we are converging.

I *think* the group felt that either
1. The UA would register the exception sufficiently fast that few, possibly no, HTTP requests would contain the ‘old’ value
or
2. The server would be able to proceed knowing it had the user’s consent, and instructing all its ad servers to know that too (and if needed ignore the ‘old’ DNT header).

I think you are saying that experience with the only implementation is that (1) is not true. I am aware that servers regularly communicate lots of info about me through the URLs they launch, so that’s at least one way to achieve (2). Are you saying that it’s not actually practical?

Thanks for digging down on this; it’s good to be clear.

> On Oct 1, 2015, at 11:41 , Mike O'Neill <michael.oneill@baycloud.com> wrote:
> 
> You could be sending the XHR (or image get, whatever) to a true third-party, , i.e. after a storeSiteSpecific, say an ad exchange sending to potential bidders, or for something else yet to be dreamed up. The cross-origin signalling capability is important and will become more so.
> 
> The fact that it cannot work without a setTimeout is annoying, and developers will complain.
> 
> 
> -----Original Message-----
> From: singer@apple.com [mailto:singer@apple.com] 
> Sent: 01 October 2015 18:27
> To: Mike O'Neill <michael.oneill@baycloud.com>
> Cc: Roy T. Fielding <fielding@gbiv.com>; public-tracking@w3.org; Adrian Bateman <adrianba@microsoft.com>; Mounir Lamouri <mounir@lamouri.fr>; Mike West <mkwst@google.com>
> Subject: Re: Promises
> 
> 
>> On Oct 1, 2015, at 10:18 , Mike O'Neill <michael.oneill@baycloud.com> wrote:
>> 
>> David,
>> 
>> If you execute the following code:
>> 
>> storeSiteSpecificTrackingException( { properties... } );
>> .
>> .
>> // as much synchronous code as you like
>> .
>> .
>> $.getJSON("http://domain1.cookieq.eu/API/ThirdParty/", null, function(json, textStatus) { 
>>           console.log("server received DNT value: "+ json.DNT);
>>       });
>> //
>> // using jQuery
>> //
>> // domain1.cookieq.eu/API/ThirdParty returns JSON with a DNT property set to the received DNT header value.
>> //
>> 
>> In a UA implementing the API the header the server receives is always wrong.
> 
> I can believe that. But, do you need the header? That’s what I am wondering.  You know you have consent — is it a practical problem to know that across the service, and ignore the header?
> 
>> (I have tried this on IE, Edge and my own extension). But if you do:
>> 
>> storeSiteSpecificTrackingException( { properties... } );
>> .
>> .
>> .
>> setTimeout(function() {
>>  $.getJSON("http://cookieq.eu/API/ThirdParty/", null, function(json, textStatus) { 
>>            console.log("server received DNT value: "+ json.DNT);
>>        });
>> },300);
>> 
>> it usually works (300ms might not be enough sometimes).
>> 
>> On IE and Edge there is no revoke so you have to clear tracking exceptions manually each time (this is easier to do in IE but not by much)
>> 
>> That is the kernel of it. Of course you can get it to work but you have to use setTimeout, restructure the code and insert an arbitrary delay. With a Promise you still have to restructure but you get rid of the arbitrary delay. If the UA supports double-checking the API will support it.
>> 
>> On IE/Edge the confirm after a store is correct but that is probably because it is returning a local static bool set by the last call to storeException (there is no arrayOfDomainStrings support or ability to revoke using the API). The doNotTrack property is (differently) wrong in IE and Edge.
>> 
>> All we have to do is return a Promise instead of void, or have an extra parameter declaring a callback function. I can write it up.
>> 
>> 
>> Mike
>> 
>> -----Original Message-----
>> From: singer@apple.com [mailto:singer@apple.com] 
>> Sent: 30 September 2015 19:55
>> To: Mike O'Neill <michael.oneill@baycloud.com>
>> Cc: Roy T. Fielding <fielding@gbiv.com>; public-tracking@w3.org; Adrian Bateman <adrianba@microsoft.com>; Mounir Lamouri <mounir@lamouri.fr>; Mike West <mkwst@google.com>
>> Subject: Re: Promises
>> 
>> 
>>> On Sep 30, 2015, at 1:23 , Mike O'Neill <michael.oneill@baycloud.com> wrote:
>>> 
>>> It is not a misapprehension, its comprehension based on experience.
>> 
>> ah!  Can you explain what about the current model — the site registers that it has the exception as a result of the user’s informed consent, and proceeds on that basis —is not working? If you could outline what the practical issue is, then we may have a reason to re-open.  
>> 
>>> I had to use setTimeout for the IE implementation as well as my own (following a store with a cross-origin XHR). The whole idea of this is to get comments gleaned from practical implementation experience and here it is. 
>> 
>> well, we need to know what the problem is.
>> 
>>> It would be interesting to hear what other implementers have to say about it, and also their experience of the performance impact on per-request DNT header determination when the "cookie origin" domain parameter applies.
>> 
>> sure
>> 
>>> 
>>> Mike
>>> 
>>> -----Original Message-----
>>> From: singer@apple.com [mailto:singer@apple.com] 
>>> Sent: 30 September 2015 00:33
>>> To: Mike O'Neill <michael.oneill@baycloud.com>
>>> Cc: Roy T. Fielding <fielding@gbiv.com>; public-tracking@w3.org; Adrian Bateman <adrianba@microsoft.com>; Mounir Lamouri <mounir@lamouri.fr>; Mike West <mkwst@google.com>
>>> Subject: Re: Promises
>>> 
>>> 
>>>> On Sep 29, 2015, at 15:50 , Mike O'Neill <michael.oneill@baycloud.com> wrote:
>>>> 
>>>> It is not counterproductive to have the option to double-check the site. The site can arrange for call to store without the users knowledge. This will be increasingly common because UAs and extensions will use the DNT signal to activate things such as blocking. You might not like it but it is bound to happen.
>>>> 
>>>> But my point is more the technical one of only having a synchronous API in an environment which is highly asynchronous. Even the simple code needed to exercise the API had to use setTimeout.
>>> 
>>> Mike, it really doesn’t.  I think this is a continuing misapprehension on your part.
>>> 
>>>> If you call store then trigger an XHR without a function callback the chances are that the header is wrong, because there has not been an intervening yield. I think this will always be true.
>>> 
>>> It may well be that the DNT headers that arrive don’t yet reflect the exception you know you have; this was something we realized when we made the decision. If that’s actually a practical problem for sites (and I can imagine it might be for large sites), that might be a reason to revisit.
>>> 
>>>> 
>>>> -----Original Message-----
>>>> From: Roy T. Fielding [mailto:fielding@gbiv.com] 
>>>> Sent: 29 September 2015 22:30
>>>> To: Mike O'Neill <michael.oneill@baycloud.com>
>>>> Cc: singer@apple.com; public-tracking@w3.org; Adrian Bateman <adrianba@microsoft.com>; Mounir Lamouri <mounir@lamouri.fr>; Mike West <mkwst@google.com>
>>>> Subject: Re: Promises
>>>> 
>>>> The API doesn't need to be based on promises to enable the user agent to do other things via promises when the API is invoked. The UA can open a dialog if it really wants to be annoying, or send up flares, or blink the screen. None of that has any relevance to the calling API that is being called after the site has explicitly asked for and has been granted an exception. It is, of course, completely unnecessary and counterproductive to do so, but that isn't our call.
>>>> 
>>>> Regardless, the spec is supposed to be consistent with WG decisions. If it is inconsistent, the editors fix the spec to conform to those decisions unless and until those decisions are changed by the WG.
>>>> 
>>>> ....Roy
>>>> 
>>>> 
>>>>> On Sep 29, 2015, at 1:28 PM, Mike O'Neill <michael.oneill@baycloud.com> wrote:
>>>>> 
>>>>> Changing the text in that way is unacceptable. The current text makes UA
>>>>> user confirmation a MAY, which I and others accepted because it left the
>>>>> door open to privacy supporting innovation. The Article 29 in their TPS
>>>>> comment letter asked for a MUST, which was refused.
>>>>> Removing the option of privacy oriented UAs to double check further reduces
>>>>> the chance that the W3C version of DNT will be accepted by civil society.
>>>>> The EFF has already started an alternative track, which differs
>>>>> significantly (they completely ignore the cross-origin consent capability
>>>>> for example), and there is a danger the whole project will be derailed
>>>>> through factional confusion.
>>>>> 
>>>>> -----Original Message-----
>>>>> From: singer@apple.com [mailto:singer@apple.com] 
>>>>> Sent: 29 September 2015 20:42
>>>>> To: Mike O'Neill <michael.oneill@baycloud.com>
>>>>> Cc: public-tracking@w3.org; Adrian Bateman <adrianba@microsoft.com>; Mounir
>>>>> Lamouri <mounir@lamouri.fr>; Mike West <mkwst@google.com>
>>>>> Subject: Re: Promises
>>>>> 
>>>>> 
>>>>>>> On Sep 29, 2015, at 1:19 , Mike O'Neill <michael.oneill@baycloud.com>
>>>>>> wrote:
>>>>>> 
>>>>>> That's why I suggested leveraging Permissions. The current system will
>>>>> work,
>>>>>> but if the confirm call is not the first executed in a document then some
>>>>>> construction using setTimeout or setInterval is necessary. Some
>>>>> implementers
>>>>>> will find that annoying.
>>>>>> 
>>>>>> What harm could there be in exploring an additional path?
>>>>> 
>>>>> 1) It’s a technical change that delays progression.
>>>>> 2) It reverses a decision of the WG without any new technical information.
>>>>> 
>>>>> I think we should fix the text to say that the UA may check with the user,
>>>>> not prior to, but when it has stored the exception.  (“Skanky Networks just
>>>>> stored an exception, claiming your informed consent. Do you agree, or want
>>>>> to review it, or delete it?”)
>>>>> 
>>>>> So now your workflow is simple. User arrives at site; do I get a DNT:0
>>>>> header? No, ask user for exception; if informed consent is given, store it
>>>>> and carry on. Otherwise go to the alternative content for DNT:1 people.
>>>>> (Note that no confirm call is really needed, but you could use confirm
>>>>> instead of looking for the header).
>>>>> 
>>>>>> 
>>>>>> -----Original Message-----
>>>>>> From: singer@apple.com [mailto:singer@apple.com] 
>>>>>> Sent: 28 September 2015 23:19
>>>>>> To: Mike O'Neill <michael.oneill@baycloud.com>
>>>>>> Cc: public-tracking@w3.org; Adrian Bateman <adrianba@microsoft.com>;
>>>>> Mounir
>>>>>> Lamouri <mounir@lamouri.fr>; Mike West <mkwst@google.com>
>>>>>> Subject: Re: Promises
>>>>>> 
>>>>>> 
>>>>>>>> On Sep 28, 2015, at 12:21 , Mike O'Neill <michael.oneill@baycloud.com>
>>>>>>> wrote:
>>>>>>> 
>>>>>>> It is the responsibility of the site, but it could also be that a UA
>>>>> wants
>>>>>>> to  double-check. The TPS says it, I would strongly resist that being
>>>>>>> portrayed as a bug.
>>>>>>> 
>>>>>>> Irrespective, my point is that asynchronism is intrinsic to the UA
>>>>>>> environment, and the Promise concept responds to that. I agree we should
>>>>>> not
>>>>>>> poke into the existing text unless we have to, but the Permission API
>>>>>> gives
>>>>>>> us a parallel path. If we don't follow it others may anyway.
>>>>>> 
>>>>>> OK, but Mike — we had a formal last-call comment from Anne suggesting we
>>>>> use
>>>>>> promises, and our consensus reply was that the call was immediate and not
>>>>>> asynchronous.  It would be a significant change of direction now.
>>>>>> 
>>>>>> 
>>>>>>> 
>>>>>>> I am volunteering to attempt it.
>>>>>>> 
>>>>>>> Mike
>>>>>>> 
>>>>>>> -----Original Message-----
>>>>>>> From: singer@apple.com [mailto:singer@apple.com] 
>>>>>>> Sent: 28 September 2015 18:40
>>>>>>> To: Mike O'Neill <michael.oneill@baycloud.com>
>>>>>>> Cc: public-tracking@w3.org; Adrian Bateman <adrianba@microsoft.com>;
>>>>>> Mounir
>>>>>>> Lamouri <mounir@lamouri.fr>; Mike West <mkwst@google.com>
>>>>>>> Subject: Re: Promises
>>>>>>> 
>>>>>>> 
>>>>>>>>> On Sep 28, 2015, at 9:38 , Mike O'Neill <michael.oneill@baycloud.com>
>>>>>>>> wrote:
>>>>>>>> 
>>>>>>>> You only know that you have requested it, not that it has been granted.
>>>>>>> 
>>>>>>> It’s been granted.  This was a long conversation we had; since it’s the
>>>>>> task
>>>>>>> of the SITE to get the user’s permission, there is nothing in real-time
>>>>>> for
>>>>>>> the user-agent to do.
>>>>>>> 
>>>>>>>> The use could also have set the UA never to grant an exception, so even
>>>>>> if
>>>>>>>> there is no prompt you still have to check.
>>>>>>> 
>>>>>>> Then the site should not be calling store…
>>>>>>> 
>>>>>>>> 
>>>>>>>> From the TPS:
>>>>>>>> 
>>>>>>>> The user agent MAY provide interfaces to the user:
>>>>>>>> 
>>>>>>>> To indicate that a call to store an exception has just been made;
>>>>>>>> To allow the user to confirm a user-granted exception prior to storage;
>>>>>>> 
>>>>>>> that line may be a bug
>>>>>>> 
>>>>>>>> To indicate that one or more exceptions exist for the current top-level
>>>>>>>> origin;
>>>>>>>> To indicate that one or more exceptions exist for sites incorporated
>>>>> into
>>>>>>>> the current page;
>>>>>>>> To allow the user to see and possibly revoke stored exceptions;
>>>>>>>> Other aspects of the exception mechanism, as desired.
>>>>>>>> There is no required user interface for the user agent; a user agent
>>>>>>>> MAYchoose to provide no user interface regarding user-granted
>>>>> exceptions.
>>>>>>> 
>>>>>>> all the rest are right; the user can later revoke
>>>>>>> 
>>>>>>>> 
>>>>>>>> Mik4
>>>>>>>> 
>>>>>>>> 
>>>>>>>> -----Original Message-----
>>>>>>>> From: singer@apple.com [mailto:singer@apple.com] 
>>>>>>>> Sent: 28 September 2015 17:02
>>>>>>>> To: Mike O'Neill <michael.oneill@baycloud.com>
>>>>>>>> Cc: public-tracking@w3.org; Adrian Bateman <adrianba@microsoft.com>;
>>>>>>> Mounir
>>>>>>>> Lamouri <mounir@lamouri.fr>; Mike West <mkwst@google.com>
>>>>>>>> Subject: Re: Promises
>>>>>>>> 
>>>>>>>> 
>>>>>>>>>> On Sep 28, 2015, at 3:01 , Mike O'Neill <michael.oneill@baycloud.com>
>>>>>>>>> wrote:
>>>>>>>>> 
>>>>>>>>> In the last call I reported on some experience of implementing the API,
>>>>>>>> all of which I will write up soon, but for now I want to expand a point
>>>>> I
>>>>>>>> made.
>>>>>>>>> 
>>>>>>>>> The usual pattern will probably be for script on a first party page ,
>>>>>>>> after storing an exception,  to check the  tracking status
>>>>>>>> (confirmSiteSpecificTrackingException or
>>>>> confirmWebWideTrackingException,
>>>>>>> or
>>>>>>>> look at the doNotTrack property).
>>>>>>>>> 
>>>>>>>>> Even if the UA does not prompt the user but stores the exception
>>>>>>>> immediately, the status returned from the synchronous property or
>>>>>> function
>>>>>>>> will not have been updated (unless the UA implementation includes an
>>>>>>>> implicit “yield”). Some construction like:
>>>>>>>>> 
>>>>>>>>> storeSiteSpecificTrackingException(propertyBag);
>>>>>>>>> setTimeout(function(){
>>>>>>>>>        var result  =
>>>>>>>> confirmSiteSpecificTrackingException(propertyBag);
>>>>>>>>>        // take action on result
>>>>>>>>> }, arbitraryDelay);
>>>>>>>>> 
>>>>>>>>> is necessary.
>>>>>>>> 
>>>>>>>> No, it’s not.  You *know* you have the exception, so you just go ahead.
>>>>>>>> There is no need to call the confirm API at all, at the time you call
>>>>>>> Store.
>>>>>>>> 
>>>>>>>> We talked about this, and we decided that we didn’t need any kind of
>>>>>>> async.
>>>>>>>> 
>>>>>>>>> If a UA implementation of the API only registers the grant after
>>>>>>>> confirming it with the user, then this code would have to be executed
>>>>>>>> continuously. The arbitraryDelay adds annoying latency when in many
>>>>> cases
>>>>>>> it
>>>>>>>> is unnecessary. Returning a Promise is a much better way to handle this
>>>>>>> but
>>>>>>>> that is not how the spec is currently. 
>>>>>>>>> 
>>>>>>>>> I have been looking at the draft Permissions API
>>>>>>>> http://www.w3.org/TR/permissions/ and I wonder if we could leverage this
>>>>>>> to
>>>>>>>> create an additional alternate for the synchronous confirm call we have
>>>>>>> now.
>>>>>>>>> 
>>>>>>>>> The Permissions interface has a function, query, that returns a
>>>>> Promise.
>>>>>>>> At the moment the only PermissionNames defined are “geolocation”,
>>>>>>>> “notifications”, “push-notifications” and “midi-sysex”.
>>>>>>>>> 
>>>>>>>>> We could define a new Permission, with PermissionName “tracking”, with
>>>>>>> the
>>>>>>>> appropriate TPS propertyBag properties e.g. arrayOfDomainStrings defined
>>>>>>> in
>>>>>>>> the new Permission’s dictionary. We would then have an alternative way
>>>>>> for
>>>>>>>> script to get the status using a method more in keeping with the
>>>>>>>> asynchronous style. We do not need to change the TPS, just create an
>>>>>>>> alternative path via a supplement to the Permissions API.
>>>>>>>>> 
>>>>>>>>> Can we talk about this next call?
>>>>>>>>> 
>>>>>>>>> Mike
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Mike O'Neill
>>>>>>>>> Technical Director
>>>>>>>>> Baycloud Systems
>>>>>>>>> Oxford Centre for Innovation 
>>>>>>>>> New Road
>>>>>>>>> Oxford
>>>>>>>>> OX1 1BY
>>>>>>>>> Tel. 01865 735619
>>>>>>>>> Fax: 01865 261401
>>>>>>>>> <image003.png>
>>>>>>>>> Email: michael.oneill@baycloud.com
>>>>>>>>> <image004.png>Professional Profile
>>>>>>>>> See who we know in common
>>>>>>>>> Want a signature like this?
>>>>>>>> 
>>>>>>>> David Singer
>>>>>>>> Manager, Software Standards, Apple Inc.
>>>>>>> 
>>>>>>> David Singer
>>>>>>> Manager, Software Standards, Apple Inc.
>>>>>> 
>>>>>> David Singer
>>>>>> Manager, Software Standards, Apple Inc.
>>>>> 
>>>>> David Singer
>>>>> Manager, Software Standards, Apple Inc.
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>> 
>>>> 
>>> 
>>> David Singer
>>> Manager, Software Standards, Apple Inc.
>>> 
>>> 
>>> 
>> 
>> David Singer
>> Manager, Software Standards, Apple Inc.
>> 
>> 
>> 
> 
> David Singer
> Manager, Software Standards, Apple Inc.
> 
> 
> 

David Singer
Manager, Software Standards, Apple Inc.

Received on Thursday, 8 October 2015 11:37:50 UTC