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