Re: pending/privacy (was Re: Notes of June 30 teleconference)

On July 13, 2016 at 6:33:59 AM, Nick Doty (npdoty@ischool.berkeley.edu) wrote:
> While it might be described as a privacy issue, I don't think it was a particular fingerprinting
> issue, but just an issue of user control over how they communicate with their browser
> and with the site. As I understand it, the issue with these asynchronous permission dialogs
> has often been that users either ignore them, or want to ignore them without making a decision.

No, it's been that they literally lose the dialog in some browsers
(ok, just in Firefox, AFAIK - but we are fixing this [1]) because the
browser hides the dialog if the user tries to do anything that doesn't
relate to making a choice (e.g., they click on another tab, they
switch to a different window, or worst, they explicitly choose "not
now", etc). It's a UX issue, seen in [2].

> It's not clear if that should be reported as denied-permission back to the site.

Agree - that is contentious.

Most browsers agree that it should be reported back to the site
through either an error callback or promise rejection. We are changing
Firefox to behave in such a way that it will now report back to the
site as denied... if the user presses "esc", this will also reflect as
"denied".

Chrome allows users to press "esc" and it does not report that choice
back to the site. Not sure if that is a bug in Chrome or not.

Safari (desktop) maps "esc" to "deny" also.

No idea about Edge - would like it if someone could check.

> That is, it might be that the user just doesn't want to decide on something right now. "pending
> forever" seems possible in the case where a user just doesn't act on the permission prompt
> (however presented in UI).

Yes, there is agreement on that. So long as the UI is shown, then the
promise is pending.

> The long Firefox bug debate seems to be about taking that to
> allow the user, from the site's point of view, to not act, but still get rid of the doorhanger
> or hide whatever the UI is.

Yes - and this the behavior we are changing with a new set of
permissions in Firefox [1].

> There is certainly developer frustration around this topic, but I suspect that developers
> are always going to have to handle the case where users just don't respond, unless browsers
> want to move to modal permission dialogs (which I hope they don't!).

We can, and have, semi-modal (non-blocking) dialogs that still allow
interaction in desktop browsers: Chrome's are a good example of
this... Safari on iOS is a counter example, which is modal.

> Sending fake/default battery values might be one way to respond to the malicious site
> case (which the Uber hypothetical seemed to be about). But in any case, it seems the API
> and site developers will have to accommodate the case where the site asks the user for
> access to the battery and the user doesn't respond.

Yes, but again, that is not the problem: the whole point of the
promise is to model the user pondering the decision to choose to
either allow or deny (the user may ponder this decision forever, which
is totally fine).
But we can't have the user "deny" and the battery API resolve with a
fake battery - that would be odd.

[1] https://twitter.com/marcosc/status/750877523290890240
[2] https://www.youtube.com/watch?v=CNF0js2hDG0

Received on Wednesday, 13 July 2016 05:36:03 UTC