RE: Promises

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.

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.

Received on Monday, 28 September 2015 19:22:21 UTC