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.

Received on Tuesday, 29 September 2015 19:42:37 UTC