Improve guidance on UI for user consenting

[anssiko]

In a response to the DAS WG's TAG review summary, the following question was brought up and would benefit from a revisit:

dbaron commented on Dec 8, 2017
Let me restate annevk's question another way: How do you ask the user a question that is both concise and accurate enough that the user's consent is meaningful? Will the user understand, for example, that accurate accelerometer, gyroscope, and magnetometer measurements might reveal all the text that the user types while they're being measured, or what sorts of activities the user is doing, and perhaps their location (based on mapping a pattern of movement to paths that exist on a map)?

The DAS WG's current position on the issue is that such UI aspects (including related strings, UI elements, UX flow) are considered implementation details. The specifications in review reflect this position.

However, given this issue was brought up suggests implementers might benefit from more elaborate informative guidance, so I'd ask the group to look into opportunities to further clarify related informative guidance in the related specification(s).

[anssiko]

I'll provide my personal perspective to this particular question with my chair hat off:

How do you ask the user a question that is both concise and accurate enough that the user's consent is meaningful?

Implementers who think prompts provide a good UX for their users are encouraged to do user studies on different strings for prompts to better understand what would work for their users. I feel this questions is not something a web specification should provide an answer to.

Some implementers might wish to innovate further in terms of the UI. Since the spec does not mandate any specific strings or UI patterns to be used for user consenting, implementers are free to implement e.g. a tutorial the user has to click through on the first use of a particular sensor API to ensure s/he's aware of the potential risks. My hunch is an animated guide would work much better than any string. That said, I leave it to interested implementers to do a user study on that topic. What I can say is such an on-boarding experience is a common convention in mobile apps on the first use, and people seem to get it, since that pattern is proliferating.

My suggestion is the sensor specifications stay agnostic with respect to UI details, and instead provide needed hooks for implementers (Secure Context, Permissions API, Feature Policy etc.) and use an appropriate API design (e.g. non-blocking) to allow UI innovation to happen.

[alexshalamov]

dbaron raised good points, few comments from my side.

In my opinion, measurements might reveal all the text that the user types while they're being measured is not applicable after focused area restriction was added and enforced in can expose sensor reading.

As for the UX related point, at the moment, we are experimenting with UI that should improve user awareness and provide setting to control access to device sensors. Experimentation includes:

• Global and per-site access control
• Page info dialog
• Location bar indicator (1, 2, 3, 4)
• Informative disclosure UI (WIP)

I think that the specification should not enforce UI concepts, rather than provide extension points that can be used by browser engineers to improve privacy & security aspects. In my opinion, we have communicated security threats and possible mitigation strategies in the core spec, moreover, extension specifications have more information whenever applicable.

[anssiko]

@annevk and @dbaron, please take a look at the proposed fix #353 to clarify user consenting aspects based on your TAG review feedback.

[annevk]

I feel this questions is not something a web specification should provide an answer to.

You should, because if you can't answer it, it's unclear whether it's even viable.

[anssiko]

You should, because if you can't answer it, it's unclear whether it's even viable.

No web specification mandates any specific strings for prompts. Maybe I misunderstood what you meant? Things related to UI and UX have historically been out of scope for web specifications and an area that allows product innovation and differentiation.

We added text to the spec in an attempt to address this issue: #353

We appreciate your feedback.

[annevk]

Let me put it differently: I don't think there's a way to ask this question and that's why this feature might not be viable. For other specifications it was much clear that a somewhat reasonable UX could be created.

[anssiko]

I don't think there's a way to ask this question

The group seems to agree on this first part of the assertion if we consider it scoped to prompting as a mechanism for user consenting.

and that's why this feature might not be viable

But think differently regarding the second part.

Chrome also felt it is hard to present a prompt to the user in an easily understandable way (see w3ctag/design-reviews#207 (comment)) and that's why we implemented new disclosure mechanisms and related UI as described in #352 (comment).

It should be said, Chrome team working on the feature is not stopping here. We will improve related mechanisms based on user feedback and further research.

Based on the concrete feedback received, this group added a note at the top of the security and privacy section to communicate the essence of this important issue and also provided some concrete examples, see https://w3c.github.io/sensors/#security-and-privacy

If you have further suggestions on how the group could reword the note, please let us know.

[anssiko]

Per discussion on the WG call, closing this issue. To be reopened if new information surfaces.

[anssiko]

Chromium implementation of "ask for forgiveness" UI has landed: https://crbug.com/796904

AFAICT, this implementation is conformant with the additional privacy-enhancing mechanisms the spec proposes in its informative note: https://w3c.github.io/sensors/#security-and-privacy