Re: asynchronous/promise (was Re: TPE last-call issues on my plate, summary)

On Nov 11, 2014, at 15:50 , Nicholas Doty <npdoty@w3.org> wrote:

> On November 11, 2014, at 3:28 PM, David Singer <singer@apple.com> wrote:
>> On Nov 11, 2014, at 15:23 , Nicholas Doty <npdoty@w3.org> wrote:
>>> ## Asynchronous/promises
>>> 
>>> An earlier iteration of this API did employ an asynchronous pattern, with the assumption that sites would initiate the request and that the browser would present permission UI to the end user and return a value to the site based on their having said yes or no. But the Working Group decided to change away from that model. Under the assumption that sites didn't want to use browser UI for a permission request, that browsers didn't want to implement a new permissions dialog and that setting DNT exceptions wasn't a security permission (since it's only expressing a preference, not actually changing the information disclosed), the API was changed to be synchronous. That is, sites are to get permission from the user in their own UI and then the method call is just to store the exception (hence the name storeSiteSpecificTrackingException) in the UA. There is no return value.
>> 
>> well, UAs are still *allowed* to ask the user, or to take their time, aren’t they?  the ‘model’ presented is that the site is supposed to call the confirm API before it carries on (it might have been denied, or pending).
> 
> I understood the model to specifically *not* be that sites needed to call confirm (or worse, loop while calling confirm), but rather that the site had already obtained the user's permission and was storing it in the UA (hence the name "storeSiteSpecificTrackingException"). That is, we chose to create a synchronous API, not an asychronous one, when we decided that sites would ask for permission rather than the UA.

No, see section 7.7: 

"User agents are free to implement exception management user interfaces as they see fit. Some agents might provide a notification to the user at the time of the request, or even not complete the storing of the exception until the user approves. Some agents might provide a user-interface to see and edit the database of recorded exception grants. The API parameters siteName, explanationString, and detailURI are provided so that the user agent may use them in their user interface.”

and 7.10:

"The 'Store' calls do not have a return value, and return immediately. If there is a problem with the calling parameters, then a Javascript exception will be raised. In addition, it may be that the user agent does not immediately store the exception, possibly because it is allowing the user to confirm. Even though the site has acquired the user's informed consent before calling the 'Store' API, it is possible that the user will change their mind, and allow the store to proceed but then later ask it be removed, or even by denying the storage in the first place.

Sites can call the 'Confirm' APIs to enquire whether a specific exception has been granted and stands in the user agent. This is the call to make to determine whether the exception exists, and hence to control access to the function or operation; if it fails (the exception has been deleted, or not yet granted), then the user is ideally again offered the information needed to give their informed consent, and again offered the opportunity to indicate that they grant it. As stated in the normative text, the site needs to explain and acquire consent immediately prior to calling the Store API, and not remember some past consent; this allows the user to change their mind.”


>>> I don't think we should move to using promises (unless the WG and relevant implementers want to reverse the previous decision). Site JavaScript is not relying on an interactive permission dialog, which we don't expect to be a typical implementation, and does not need an asychronous callback to take actions once the user has granted or denied permission. UAs still have flexibility on how they store exceptions or ask users about them, but the API doesn't need to be changed in order to handle asynchronous interactivity.
>> 
>> Is it harmful?  If you ignore the promise, the calls look exactly like today.  Otherwise, the site can sit on the page until the promise comes back, and then trigger definitive action.
> 
> Well, it's harder to implement, and we'd then have disparate existing implementations (IE). It also makes it confusing as to whether the UA is supposed to confirm the permission or not. Currently, we don't require that of UAs, but having an asychronous API might suggest that the user was involved.

The UA has a low of latitude in the current model; one can write a ‘strict’ UA that checks and exposes everything (or a UA that has a ‘strict’ mode).

> 
>>> ## Explanation string
>>> 
>>> Similarly, the explanation and detail URI parameters are unlikely to be presented in an interactive dialog
>> 
>> unlikely and not allowed to be are different
>> 
>>> and this storing of permission doesn't change the information exposed by the end user. While I would generally like to see W3C increase the use of these site-provided strings (as native platforms increasingly do), I'm aware of the UI challenges when it comes to phishing/spoofing. However, in this case, I don't believe that phishing is a particular problem. Servers can already ignore expressed DNT preferences: deception in explaining to the user isn't something that can be avoided by browser UI. Also, these aren't likely to be expressed in interactive permission dialogs, but could provide information to end users when they're reviewing their list of stored exceptions.
>> 
>> But the sites you would question are almost certainly going to try to hide here, too.  Basically, these strings are of marginal utility for the honest sites but of huge utility to the dishonest.
> 
> I'm not sure of their utility for the dishonest. (I don't like to make arguments based on "good guys" and "bad guys", but I'm trying to be brief.) A server that doesn't intend to respect the user's preference anyway doesn't get much utility out of storing a DNT exception when they can as easily retain/share user data when a DNT:1 is sent.

I guess they may feel that there is a difference between explicitly ignoring DNT (while claiming to honor it) and ‘scaring’ the user into granting/retaining an exception by using an explanation string that’s a bit scary “this exception is essntial to keep news sites operating correctly”

> 
> A deceptive publisher who works with preference-respecting third-party advertising networks might see an advantage in storing an exception without the user's permission and then deceptively dissuading users from subsequently removing it. But that's the kind of problem third-party advertisers and regulatory/self-regulatory groups are going to have to handle anyway, and having a log of a deceptive string would actually make it easier for the auditor. Such publishers could communicate to their third-party partners that user consent was in place (when in fact it wasn't) through some out-of-band mechanism, for example.

But this seems to be arguing that having the string is a trap for the deceptive, in that we can also catch them providing deceptive strings.

Given the lack of required UI, and the possibility (probability) that the strings are at best mildly useless, and at worst mildly harmful, I don’t think it’s worth keeping them, but it’s not a strong opinion.

David Singer
Manager, Software Standards, Apple Inc.

Received on Wednesday, 12 November 2014 00:12:47 UTC