Replace asking for users for consent with designing for user intent #584
Conversation
First draft of the proposed replacement section.
index.bs
Outdated
| * **Ask questions people can understand.** | ||
| The associated risks should be obvious from the question for a typical user | ||
| and be directly connected to the feature's or API's utility. | ||
| This usually means we can't ask permission to accept fingerprinting risks, |
There was a problem hiding this comment.
It would be nice to make this clause linkable, and to link to it from other places in the document that touch on fingerprinting. Basically, one of the many reasons we need to be reluctant to expand the fingerprinting surface of the web platform is precisely because it's difficult to secure meaningful user consent about it.
There was a problem hiding this comment.
great idea. Since I'm not as familiar with the structure of documents like this, what's the best way to make this linkable?
There was a problem hiding this comment.
Like Tess, I think that this is a significant improvement. Thanks for doing the work.
I have tried to make suggestions rather than provide criticism as much as possible; happy for you to disagree, of course.
There were a few places where I didn't have an easy suggestion to hand though. Those will need more thought.
index.bs
Outdated
| If you can’t adhere to all of the above principles, | ||
| then there's a "design smell" and asking the user isn't the right mitigation. |
There was a problem hiding this comment.
| If you can’t adhere to all of the above principles, | |
| then there's a "design smell" and asking the user isn't the right mitigation. | |
| If you can’t adhere to all of the above principles, | |
| that is likely an indication that asking the user isn't the right way to manage permission. |
There was a problem hiding this comment.
Thanks for the suggestion. I replaced "mitigation" with "approach" instead, as I don't want to frame it as a decision about managing permission but really about managing risk. The following sentence hopefully communicates that. Wdyt?
|
Thank you for your thoughts, Tess and Martin. I addressed most of your comments and left a few thoughts on the remaining ones. 🙏 |
There was a problem hiding this comment.
I wonder if this is a case where the principle needs to acknowledge that there are limits to what a browser can do to provide the necessary context ahead of a decision. In that way, the best we can expect a browser to achieve is to make it possible - and maybe even easy - to build applications that promote these principles. There are obvious cases of abuse that browsers can cut back on (popups, etc...), but the platform is too powerful to have all responsibility fall on a browser.
index.bs
Outdated
| to decide whether to grant permission for each feature | ||
| whenever it's requested by a Web page. | ||
| Using such a feature should only be possible | ||
| if the user’s expectation matches the feature’s consequences |
There was a problem hiding this comment.
We have inconsistent apostrophes now. Just an observation, really.
There was a problem hiding this comment.
Thanks for flagging. I'll fix them.
There was a problem hiding this comment.
Thanks for taking another look, Martin. I addressed most of your comments.
I wonder if this is a case where the principle needs to acknowledge that there are limits to what a browser can do to provide the necessary context ahead of a decision. In that way, the best we can expect a browser to achieve is to make it possible - and maybe even easy - to build applications that promote these principles. There are obvious cases of abuse that browsers can cut back on (popups, etc...), but the platform is too powerful to have all responsibility fall on a browser.
I think that is a fair statement. Do you have a proposal on how we can articulate this in the design guidelines?
index.bs
Outdated
| to decide whether to grant permission for each feature | ||
| whenever it's requested by a Web page. | ||
| Using such a feature should only be possible | ||
| if the user’s expectation matches the feature’s consequences |
There was a problem hiding this comment.
Thanks for flagging. I'll fix them.
Co-authored-by: Martin Thomson <[email protected]>
Co-authored-by: Martin Thomson <[email protected]>
Co-authored-by: Martin Thomson <[email protected]>
index.bs
Outdated
| as they are subtle, technical, and commonly have nothing to do with the capability itself. | ||
| * **Provide sufficient context.** | ||
| People need to easily understand who they're dealing with, | ||
| what the decision is about, and how the website will use any information they might share. |
There was a problem hiding this comment.
"how the website will use any information they might share" isn't usually something the UA can ensure the user is told, especially with our historical resistance to include website-provided strings in browser UI.
I'm ok with keeping the text anyway because I don't have any suggestions for how to fix it.
There was a problem hiding this comment.
Yes, it is something that we haven't ever solved for on the web platform, but other platforms have and I hope that we can start doing more of it in the future. So this is indeed more aspirational.
Co-authored-by: Jeffrey Yasskin <[email protected]>
Co-authored-by: Jeffrey Yasskin <[email protected]>
Co-authored-by: Jeffrey Yasskin <[email protected]>
Co-authored-by: Jeffrey Yasskin <[email protected]>
Co-authored-by: Jeffrey Yasskin <[email protected]>
Co-authored-by: Jeffrey Yasskin <[email protected]>
Co-authored-by: Jeffrey Yasskin <[email protected]>
Co-authored-by: Jeffrey Yasskin <[email protected]>
Co-authored-by: Jeffrey Yasskin <[email protected]>
Co-authored-by: Jeffrey Yasskin <[email protected]>
index.bs
Outdated
| Do not ask users questions where a "bad" decision can lead to severe consequences, | ||
| like a compromised device or serious personal data disclosure. |
There was a problem hiding this comment.
Fair point and I think these features do violate the principle for good reasons. These seem to be table-stakes-type features that enable a large number of use cases. Maybe if they didn't exist today, we might be hesitant to ship them, given what we know about abuse on the web. But yes, I still believe this is a good principle to keep.
index.bs
Outdated
| as they are subtle, technical, and commonly have nothing to do with the capability itself. | ||
| * **Provide sufficient context.** | ||
| People need to easily understand who they're dealing with, | ||
| what the decision is about, and how the website will use any information they might share. |
There was a problem hiding this comment.
Yes, it is something that we haven't ever solved for on the web platform, but other platforms have and I hope that we can start doing more of it in the future. So this is indeed more aspirational.
After an initial discussion around existing Chromium guidance to discourage the use of permission prompts in WebAppSec WG, I was encouraged to propose a change to TAG's design principles doc. This is that change.
My intention is to provide guidance around designing features and APIs in ways that limit the need for asking users questions. When there is a strong and justified need to ask such questions, I want to offer some principles on what needs to be true for users to be able to make good decisions.
H/t to @heisenburger, @mikewest, and @jyasskin for their input on this initial draft.
Preview | Diff