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

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

> Regarding issue-256, I wanted to explain my concern with the proposed changes regarding promises and site explanation strings. I think we don't need to make changes on these points.
> 
> Thanks,
> Nick
> 
> ## 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 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.

> 
> ## 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 yet whether these parameters are likely to see use in real-world implementations, but I don't think we need to remove them as a security risk, for the reasons just stated.
> 
> We could add a note to implementers that the explanationString, siteName and detailURI are provided by the site and care may be needed to make that clear to end users.
> 
> I think Anne is right that "explanationString" is redundant and that "explanation" is preferable, as long as it doesn't break existing code. I don't care about URI/URL myself.

David Singer
Manager, Software Standards, Apple Inc.

Received on Tuesday, 11 November 2014 23:29:08 UTC