W3C home > Mailing lists > Public > public-tracking@w3.org > November 2014

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

From: Nicholas Doty <npdoty@w3.org>
Date: Tue, 11 Nov 2014 15:23:14 -0800
Message-Id: <F16C5426-D33B-4F19-A36B-3F19E688FF6F@w3.org>
Cc: David Singer <singer@apple.com>
To: public-tracking@w3.org
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.

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.

## Explanation string

Similarly, the explanation and detail URI parameters are unlikely to be presented in an interactive dialog 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.

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.

Received on Tuesday, 11 November 2014 23:23:28 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:40:15 UTC