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

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.

>> 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.

>> ## 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.

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.