From ea96466ef49d0e386fbf2793a87c1bfa54d19e17 Mon Sep 17 00:00:00 2001 From: Marian Harbach Date: Thu, 11 Sep 2025 09:50:25 +0200 Subject: [PATCH 01/20] Replace asking for users for consent with designing for user intent First draft of the proposed replacement section. --- index.bs | 115 +++++++++++++++++++++++++++++++------------------------ 1 file changed, 66 insertions(+), 49 deletions(-) diff --git a/index.bs b/index.bs index 2cc3ce42..852c07f8 100644 --- a/index.bs +++ b/index.bs @@ -158,57 +158,75 @@ This is often used to attempt to trick users into visiting scam websites. If this feature was proposed today, it would probably not proceed.

- +

Design for user intent

In the context of fulfilling a user need, a web page may want to make use of a feature that has the potential to cause harm. -Features that have this potential for harm should be designed such that people can give -[meaningful consent](https://www.w3.org/2001/tag/doc/ethical-web-principles/#control) for that feature to be used, -and that they can refuse consent effectively. - -In order to give *meaningful consent*, the user must: -- **understand** what permission they may choose whether to grant the web page -- be able to choose to give or refuse that permission **effectively**. - -If a feature is powerful enough to require user consent, -but it's impossible to explain to a typical user what they are consenting to, -that's a signal that you may need to reconsider the design of the feature. - -If a permission prompt is shown, -and the user doesn't grant permission, -the Web page should not be able to do anything -that the user believes they have refused consent for. - -By asking for consent, -we can inform the user of what capabilities the web page does or doesn't have, -reinforcing their confidence that the web is safe. -However, the user benefit -of a new feature must justify the additional burden on users -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 +(e.g., personal information used, state changed). + +Design your API so its behavior matches what people intend and expect. +Then, in the best case, people don't need to get involved in allowing API access +and thus can't make decisions they regret later. +Only ask the user for confirmation in exceptional circumstances. + +

+For example, web pages don’t need to ask for permission to play sounds, +as they are only able to so when there is enough engagement +and it is therefore very likely that the user expects this. +Similarly, PWAs wanting to use [Window Control Overlay](https://wicg.github.io/window-controls-overlay/) don’t need to ask for permission, +as the user simply toggles this mode on when they need it. +

+ +

Help users make good decisions

+ +Asking for user approval has been a common way to handle remaining risk. +However, most people can't make good decisions on +the questions they're asked (e.g., permission prompts, FedCM prompts). +This is because they lack crucial context and information. +Being confronted with difficult or annoying questions leads +to decision fatigue, habitual responses, +annoyance from frequent interruptions, and regrettable decisions. + +When user involvement is unavoidable, +empower users to make good decisions. +Use these principles: + +* **Limit the consequences from a bad decision by addressing risk at the API level first.** + Try not to ask users questions where a "bad" decision can lead to severe consequences, + like a compromised device or serious personal data disclosure. + If you have to, make it harder for abusive sites to trick users into seeing the question. + If users’ decisions last longer than the current session, + user agents should remind users that their past decision still applies. +* **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, + 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. +* **Let people make decisions when *they* are ready.** + Websites should not be able to force the decision moment on the user, + while they're trying to do something else. + Instead, people should be able to choose the decision moment, + for example by clicking on a dedicated button like for the file chooser. + +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. +Instead, change the feature or API to address any remaining risk. In your specification, the [=request permission to use=] and [=prompt the user to choose=] algorithms from [[permissions]] are good ways to ask for consent. +If you ask a user to make a decision and they say no, the website shouldn't be able to do anything the user believes they just refused access to. + Refusal is most effective if the site cannot distinguish refusal from other, common situations. This can make it more difficult for a site to pressure users to grant consent. -

-For example, -the [Geolocation API](https://www.w3.org/TR/geolocation-API/) -grants access to a user's location. -This can help users in some contexts, -like a mapping application, -but may be dangerous to some users in other contexts - -especially if used without the user's knowledge. -So that the user may decide whether their location may be used by a Web page, -a permission prompt should be shown to the user asking whether to grant location access. -If the user refuses permission, -no location information is available to the Web page. -

- See also: * [The web is secure, and respects people's privacy](https://www.w3.org/2001/tag/doc/ethical-web-principles/#privacy) @@ -240,7 +258,7 @@ actively collected (for example, they have filled in a form). For such features, you should [understand the context](https://www.w3.org/TR/privacy-principles/#identity) in which it will be used, including how it will be used alongside other features of the web. -Make sure the user can [give appropriate consent](#consent). +Make sure to [design for user intent](#user-intent) and [help users make good decisions](#user-decisions). Design APIs to collect [the smallest amount of data](https://www.w3.org/TR/privacy-principles/#data-minimization) necessary. @@ -364,7 +382,7 @@ APIs should also provide granularity and user controls, in particular over personal data, that is communicated to sites. When additional functionality requires additional data, APIs can enable this -subject to user consent (e.g., a permission prompt or user activation). +if they [design for user intent](#user-intent) and [help users make good decisions](#user-decisions) when necessary.
A Font Enumeration API API was once proposed, but the tradeoff of user data exposed was not justified by the use cases. Instead, an alternative solution was proposed, which only exposed the font the user actually selected. @@ -765,8 +783,7 @@ a single user’s activity both in and out of private browsing mode, consider possible [mitigations](https://www.w3.org/TR/security-privacy-questionnaire/#mitigations) such as introducing noise, -or using permission prompts to give the user extra information -to help them meaningfully consent to this tracking (see [[#consent]]). +or [helping users make good decisions](#user-decisions) about this tracking, if necessary. Private browsing modes enable users to browse the web without leaving any trace of their private browsing on their device. @@ -863,8 +880,8 @@ once per API call ([transient consuming](https://html.spec.whatwg.org/#activatio Note that while user activation is in many cases necessary, it is not always *sufficient* -to protect users from invasive behaviours, -and seeking [meaningful consent](#consent) is also important. +to protect users from invasive behaviours. +[Designing for user intent](#user-intent) and [helping users to make good decisions](#user-decisions) is also important.

Support non-fully active BFCached documents

@@ -2984,9 +3001,8 @@ use these guidelines when exposing device information: : Hide sensitive information behind a user permission :: If you can't create a device identifier in an anonymous way, limit access to it. - Make sure the user can provide - [[#consent|meaningful consent]] - to a Web page accessing this information. + Make sure you [help the user make good decisions](#user-decisions) + about a Web page accessing this information. : Tie identifiers to the same-origin model :: Create distinct identifiers for the same physical device for each origin that has has access to it. @@ -3031,7 +3047,7 @@ you may not need to expose a list to script at all. An API which invokes a User-Agent-provided device picker could suffice. Such an API: - keeps the user in control, -- doesn't expose any device information without the user's [consent](#consent), +- [helps users understand](#user-decisions) what they are deciding about, - doesn't expose any fingerprinting data about the user's environment by default, and - only exposes information about one device at a time. @@ -3041,6 +3057,7 @@ the fact that there are devices are available to be picked. This does expose one bit of fingerprinting data about the user's environment to websites, so it isn't quite as safe as an API which doesn't have such a feature. +Ensure that such an API also provides sufficient information to [help users make good decisions](#user-decisions).
The {{RemotePlayback}} interface From c0283596938bbcc2151ddea0b968d3085089e1b2 Mon Sep 17 00:00:00 2001 From: Marian Harbach Date: Fri, 12 Sep 2025 09:54:35 +0200 Subject: [PATCH 02/20] Updates in response to comments from @hober and @martinthompson --- index.bs | 26 +++++++++++++++----------- 1 file changed, 15 insertions(+), 11 deletions(-) diff --git a/index.bs b/index.bs index 852c07f8..8b07860f 100644 --- a/index.bs +++ b/index.bs @@ -182,6 +182,8 @@ as the user simply toggles this mode on when they need it.

Help users make good decisions

+Empower good decision-making by limiting risk at the API level and +providing clarity, context, and user control. Asking for user approval has been a common way to handle remaining risk. However, most people can't make good decisions on the questions they're asked (e.g., permission prompts, FedCM prompts). @@ -195,15 +197,17 @@ empower users to make good decisions. Use these principles: * **Limit the consequences from a bad decision by addressing risk at the API level first.** - Try not to ask users questions where a "bad" decision can lead to severe consequences, + Do not ask users questions where a "bad" decision can lead to severe consequences, like a compromised device or serious personal data disclosure. - If you have to, make it harder for abusive sites to trick users into seeing the question. +* **Provide constant feedback about persistent decisions.** If users’ decisions last longer than the current session, user agents should remind users that their past decision still applies. + Provide a way to retract any ongoing permission, + including APIs to inform sites of the change in status. * **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, + For example, this usually means we can't ask permission to accept fingerprinting risks, 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, @@ -215,7 +219,7 @@ Use these principles: for example by clicking on a dedicated button like for the file chooser. 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. +that is likely an indication that asking the user isn't the right approach. Instead, change the feature or API to address any remaining risk. In your specification, the [=request permission to use=] and [=prompt the user to choose=] algorithms from [[permissions]] are good ways to ask for consent. @@ -599,8 +603,7 @@ if feature detection were available for the feature, then you should not support feature detection. Detecting the availability of a feature does not imply -detecting whether consent to use the feature -has been granted. +detecting whether the user has been asked to use the feature. Generally, detecting whether the feature is implemented can be done separately from determining whether use of the feature has been authorized. In some cases, it might be necessary to disable feature detection @@ -829,7 +832,7 @@ People who make use of assistive technologies are often [vulnerable members of society](https://www.w3.org/2001/tag/doc/ethical-web-principles/#noharm); their use of assistive technologies is [sensitive information](https://www.w3.org/TR/security-privacy-questionnaire/#sensitive-data) about them. If an API provides access to this information -without the user's [consent](#consent), +without [asking the user](#user-decisions), this sensitive information may be revealed to others (including [state actors](https://www.w3.org/2001/tag/doc/ethical-web-principles/#expression)) who may wish them harm. @@ -2133,7 +2136,7 @@ Promise-using code also tends to be easier to understand than code using callback functions. An API might need to be asynchronous if: - * the user agent needs to prompt the user for [permission](#consent), + * the user agent needs to prompt the user for [permission](#user-decisions), * some information might need to be read from disk, or requested from the network, * the user agent may need to do a significant amount of work on another thread, @@ -3023,7 +3026,7 @@ use these guidelines when exposing device information: See also: -* [[#consent]] +* [[#user-decisions]] * [[LEAST-POWER]] * [[FINGERPRINTING-GUIDANCE]] * [[UNSANCTIONED-TRACKING]] @@ -3047,7 +3050,7 @@ you may not need to expose a list to script at all. An API which invokes a User-Agent-provided device picker could suffice. Such an API: - keeps the user in control, -- [helps users understand](#user-decisions) what they are deciding about, +- [helps users understand](#user-decisions) their decisions, - doesn't expose any fingerprinting data about the user's environment by default, and - only exposes information about one device at a time. @@ -3057,7 +3060,8 @@ the fact that there are devices are available to be picked. This does expose one bit of fingerprinting data about the user's environment to websites, so it isn't quite as safe as an API which doesn't have such a feature. -Ensure that such an API also provides sufficient information to [help users make good decisions](#user-decisions). +Ensure that such an API ensures that it is possible to present sufficient information +on user interfaces that users are able to [make good decisions](#user-decisions).
The {{RemotePlayback}} interface From efbf7bc7071e23e9f0bdf5e6f2586a59bb884ad3 Mon Sep 17 00:00:00 2001 From: Marian Harbach Date: Tue, 23 Sep 2025 15:06:47 +0000 Subject: [PATCH 03/20] Addressed further comments from @martinthomson --- index.bs | 22 ++++++++++++---------- 1 file changed, 12 insertions(+), 10 deletions(-) diff --git a/index.bs b/index.bs index 8b07860f..56125d71 100644 --- a/index.bs +++ b/index.bs @@ -164,20 +164,22 @@ In the context of fulfilling a user need, a web page may want to make use of a feature that has the potential to cause harm. Using such a feature should only be possible -if the user’s expectation matches the feature’s consequences +if the user's expectation matches the feature's consequences (e.g., personal information used, state changed). Design your API so its behavior matches what people intend and expect. Then, in the best case, people don't need to get involved in allowing API access -and thus can't make decisions they regret later. +and thus can't make decisions they regret later. Only ask the user for confirmation in exceptional circumstances. +If a capability can be easily reverted or causes only mild annoyance without the chance for permanent harm, +afford users an option to stop capability access instead.

-For example, web pages don’t need to ask for permission to play sounds, -as they are only able to so when there is enough engagement -and it is therefore very likely that the user expects this. +For example, web pages don’t need to ask for permission to play sounds. +It is easy to stop audio output if a site is found to be abusing it +and browsers have a number of mechanisms for doing just that. Similarly, PWAs wanting to use [Window Control Overlay](https://wicg.github.io/window-controls-overlay/) don’t need to ask for permission, -as the user simply toggles this mode on when they need it. +as the user simply toggles this mode on when they need it.

Help users make good decisions

@@ -186,8 +188,8 @@ Empower good decision-making by limiting risk at the API level and providing clarity, context, and user control. Asking for user approval has been a common way to handle remaining risk. However, most people can't make good decisions on -the questions they're asked (e.g., permission prompts, FedCM prompts). -This is because they lack crucial context and information. +many of the questions they're asked +because they lack crucial context and information. Being confronted with difficult or annoying questions leads to decision fatigue, habitual responses, annoyance from frequent interruptions, and regrettable decisions. @@ -603,7 +605,7 @@ if feature detection were available for the feature, then you should not support feature detection. Detecting the availability of a feature does not imply -detecting whether the user has been asked to use the feature. +detecting whether [the user has been asked](#user-decisions) to use the feature. Generally, detecting whether the feature is implemented can be done separately from determining whether use of the feature has been authorized. In some cases, it might be necessary to disable feature detection @@ -622,7 +624,7 @@ See also: * [[#do-not-expose-use-of-private-browsing-mode]] * [[#do-not-expose-use-of-assistive-tech]] * [[#secure-context]] -* [[#consent]] +* [[#user-decisions]]

Design textual formats for humans

From 609b59a89bc1fa365786486d73ef434b7d1c60b5 Mon Sep 17 00:00:00 2001 From: Marian Harbach Date: Tue, 23 Sep 2025 15:12:32 +0000 Subject: [PATCH 04/20] Fixed more inconsistent apostrophes --- index.bs | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/index.bs b/index.bs index 56125d71..f7f66c52 100644 --- a/index.bs +++ b/index.bs @@ -175,10 +175,10 @@ If a capability can be easily reverted or causes only mild annoyance without the afford users an option to stop capability access instead.

-For example, web pages don’t need to ask for permission to play sounds. +For example, web pages don't need to ask for permission to play sounds. It is easy to stop audio output if a site is found to be abusing it and browsers have a number of mechanisms for doing just that. -Similarly, PWAs wanting to use [Window Control Overlay](https://wicg.github.io/window-controls-overlay/) don’t need to ask for permission, +Similarly, PWAs wanting to use [Window Control Overlay](https://wicg.github.io/window-controls-overlay/) don't need to ask for permission, as the user simply toggles this mode on when they need it.

@@ -202,7 +202,7 @@ Use these principles: Do not ask users questions where a "bad" decision can lead to severe consequences, like a compromised device or serious personal data disclosure. * **Provide constant feedback about persistent decisions.** - If users’ decisions last longer than the current session, + If users' decisions last longer than the current session, user agents should remind users that their past decision still applies. Provide a way to retract any ongoing permission, including APIs to inform sites of the change in status. @@ -220,7 +220,7 @@ Use these principles: Instead, people should be able to choose the decision moment, for example by clicking on a dedicated button like for the file chooser. -If you can’t adhere to all of the above principles, +If you can't adhere to all of the above principles, that is likely an indication that asking the user isn't the right approach. Instead, change the feature or API to address any remaining risk. From 67596e29ce2c585800504dafab3671ff9dec3bb2 Mon Sep 17 00:00:00 2001 From: Marian Harbach Date: Thu, 25 Sep 2025 22:15:19 +0200 Subject: [PATCH 05/20] Apply suggestion from @martinthomson Co-authored-by: Martin Thomson --- index.bs | 2 -- 1 file changed, 2 deletions(-) diff --git a/index.bs b/index.bs index 64326d20..3ff97401 100644 --- a/index.bs +++ b/index.bs @@ -181,8 +181,6 @@ afford users an option to stop capability access instead. For example, web pages don't need to ask for permission to play sounds. It is easy to stop audio output if a site is found to be abusing it and browsers have a number of mechanisms for doing just that. -Similarly, PWAs wanting to use [Window Control Overlay](https://wicg.github.io/window-controls-overlay/) don't need to ask for permission, -as the user simply toggles this mode on when they need it.

Help users make good decisions

From 723632e3bff7595cb17fd8ac80e1233e92811d30 Mon Sep 17 00:00:00 2001 From: Marian Harbach Date: Thu, 25 Sep 2025 22:15:32 +0200 Subject: [PATCH 06/20] Apply suggestion from @martinthomson Co-authored-by: Martin Thomson --- index.bs | 1 + 1 file changed, 1 insertion(+) diff --git a/index.bs b/index.bs index 3ff97401..0770e95a 100644 --- a/index.bs +++ b/index.bs @@ -187,6 +187,7 @@ and browsers have a number of mechanisms for doing just that. Empower good decision-making by limiting risk at the API level and providing clarity, context, and user control. + Asking for user approval has been a common way to handle remaining risk. However, most people can't make good decisions on many of the questions they're asked From e8a9a6cb335f9fec67f332564fcc628e078bac6f Mon Sep 17 00:00:00 2001 From: Marian Harbach Date: Thu, 25 Sep 2025 22:20:03 +0200 Subject: [PATCH 07/20] Apply suggestion from @martinthomson Co-authored-by: Martin Thomson --- index.bs | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/index.bs b/index.bs index 0770e95a..2144c411 100644 --- a/index.bs +++ b/index.bs @@ -228,7 +228,9 @@ Instead, change the feature or API to address any remaining risk. In your specification, the [=request permission to use=] and [=prompt the user to choose=] algorithms from [[permissions]] are good ways to ask for consent. -If you ask a user to make a decision and they say no, the website shouldn't be able to do anything the user believes they just refused access to. +If you ask a user to make a decision and they say no, +the website shouldn't be able to do anything +the user believes they just refused access to. Refusal is most effective if the site cannot distinguish refusal from other, common situations. From 462df7e5cc795b10618bf66668170c4dfe3655b5 Mon Sep 17 00:00:00 2001 From: Marian Harbach Date: Thu, 2 Oct 2025 12:51:38 +0200 Subject: [PATCH 08/20] Addressed remaining comments from @martinthomson --- index.bs | 28 +++++++++++++++++++++++----- 1 file changed, 23 insertions(+), 5 deletions(-) diff --git a/index.bs b/index.bs index 2144c411..7d0791a8 100644 --- a/index.bs +++ b/index.bs @@ -163,6 +163,9 @@ If this feature was proposed today, it would probably not proceed.

Design for user intent

+Use your API design to encourage websites to +meet user expectations when accessing exceptional capabilities. + In the context of fulfilling a user need, a web page may want to make use of a feature that has the potential to cause harm. @@ -216,16 +219,31 @@ Use these principles: * **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. -* **Let people make decisions when *they* are ready.** - Websites should not be able to force the decision moment on the user, - while they're trying to do something else. - Instead, people should be able to choose the decision moment, - for example by clicking on a dedicated button like for the file chooser. If you can't adhere to all of the above principles, that is likely an indication that asking the user isn't the right approach. Instead, change the feature or API to address any remaining risk. +
+A browser is responsible for managing requests for permission. +Browsers will not be able to understand +precisely how a user's interaction with a site +might result in a reasonable expectation of a permission request. +The web platform provides sites with many ways +of both effectively communicating purpose and intent, +or to employ deception and trickery. + +The responsibility for clearly communicating intent is therefore shared +between the design of APIs, +user interface design in browsers, +and how websites are constructed. +It is preferable if respect for user intent +is a natural outcome +of following the simple, obvious, or default usage pattern for the API. +This principle only asks that API designs encourage +to construct sites that respect user intent. +
+ In your specification, the [=request permission to use=] and [=prompt the user to choose=] algorithms from [[permissions]] are good ways to ask for consent. If you ask a user to make a decision and they say no, From 3148189b95c888bed186bb5c9123aa7177301b58 Mon Sep 17 00:00:00 2001 From: Marian Harbach Date: Tue, 7 Oct 2025 11:27:46 +0200 Subject: [PATCH 09/20] Apply suggestion from @jyasskin Co-authored-by: Jeffrey Yasskin --- index.bs | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/index.bs b/index.bs index 25cdde5e..1458ae77 100644 --- a/index.bs +++ b/index.bs @@ -157,7 +157,7 @@ This is often used to attempt to trick users into visiting scam websites. If this feature was proposed today, it would probably not proceed.

-

Design for user intent

+

Design for user intent

Use your API design to encourage websites to meet user expectations when accessing exceptional capabilities. From 87bc0566051528b2cf190788476fd9ced589e9c7 Mon Sep 17 00:00:00 2001 From: Marian Harbach Date: Tue, 7 Oct 2025 11:28:23 +0200 Subject: [PATCH 10/20] Apply suggestion from @jyasskin Co-authored-by: Jeffrey Yasskin --- index.bs | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/index.bs b/index.bs index 1458ae77..9a45ac43 100644 --- a/index.bs +++ b/index.bs @@ -167,7 +167,7 @@ a web page may want to make use of a feature that has the potential to cause harm. Using such a feature should only be possible if the user's expectation matches the feature's consequences -(e.g., personal information used, state changed). +(e.g., the personal information it reveals or the state it changes). Design your API so its behavior matches what people intend and expect. Then, in the best case, people don't need to get involved in allowing API access From 7754dca745c1fd1795dbca5c39c321db69a34f4f Mon Sep 17 00:00:00 2001 From: Marian Harbach Date: Tue, 7 Oct 2025 11:28:41 +0200 Subject: [PATCH 11/20] Apply suggestion from @jyasskin Co-authored-by: Jeffrey Yasskin --- index.bs | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/index.bs b/index.bs index 9a45ac43..2adaf971 100644 --- a/index.bs +++ b/index.bs @@ -178,7 +178,7 @@ afford users an option to stop capability access instead.

For example, web pages don't need to ask for permission to play sounds. -It is easy to stop audio output if a site is found to be abusing it +It is easy to stop audio output if a site is found to be abusing it, and browsers have a number of mechanisms for doing just that.

From 6f8fd9c27c4538f4ca0be59e51bbb48709d9af5f Mon Sep 17 00:00:00 2001 From: Marian Harbach Date: Tue, 7 Oct 2025 11:28:51 +0200 Subject: [PATCH 12/20] Apply suggestion from @jyasskin Co-authored-by: Jeffrey Yasskin --- index.bs | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/index.bs b/index.bs index 2adaf971..7cd42b00 100644 --- a/index.bs +++ b/index.bs @@ -187,7 +187,7 @@ and browsers have a number of mechanisms for doing just that. Empower good decision-making by limiting risk at the API level and providing clarity, context, and user control. -Asking for user approval has been a common way to handle remaining risk. +Asking for user approval has been a common way to handle the remaining risk. However, most people can't make good decisions on many of the questions they're asked because they lack crucial context and information. From c7b38c1c9899f173eb044a174931c65cf3ccbb56 Mon Sep 17 00:00:00 2001 From: Marian Harbach Date: Tue, 7 Oct 2025 11:29:04 +0200 Subject: [PATCH 13/20] Apply suggestion from @jyasskin Co-authored-by: Jeffrey Yasskin --- index.bs | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/index.bs b/index.bs index 7cd42b00..25bd834d 100644 --- a/index.bs +++ b/index.bs @@ -188,8 +188,8 @@ Empower good decision-making by limiting risk at the API level and providing clarity, context, and user control. Asking for user approval has been a common way to handle the remaining risk. -However, most people can't make good decisions on -many of the questions they're asked +However, people often can't make good decisions on +the questions they're asked because they lack crucial context and information. Being confronted with difficult or annoying questions leads to decision fatigue, habitual responses, From 12c179aba8d1903c59418aad39d7cf5051409c52 Mon Sep 17 00:00:00 2001 From: Marian Harbach Date: Tue, 7 Oct 2025 11:35:45 +0200 Subject: [PATCH 14/20] Apply suggestion from @jyasskin Co-authored-by: Jeffrey Yasskin --- index.bs | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/index.bs b/index.bs index 25bd834d..ef20e1c0 100644 --- a/index.bs +++ b/index.bs @@ -205,8 +205,8 @@ Use these principles: * **Provide constant feedback about persistent decisions.** If users' decisions last longer than the current session, user agents should remind users that their past decision still applies. - Provide a way to retract any ongoing permission, - including APIs to inform sites of the change in status. + Provide a way to retract any ongoing permission., + APIs should include a way for sites to learn of the change in status. * **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. From 960856d7aba0a9e40cdc6529dde98ca3a839e1e9 Mon Sep 17 00:00:00 2001 From: Marian Harbach Date: Tue, 7 Oct 2025 11:37:22 +0200 Subject: [PATCH 15/20] Apply suggestion from @jyasskin Co-authored-by: Jeffrey Yasskin --- index.bs | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/index.bs b/index.bs index ef20e1c0..455b2bd8 100644 --- a/index.bs +++ b/index.bs @@ -208,8 +208,9 @@ Use these principles: Provide a way to retract any ongoing permission., APIs should include a way for sites to learn of the change in status. * **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. + When a typical user reads the question about a feature, + they should immediately think of the associated risks. + The risks should also be directly connected to the feature's or API's utility. For example, this usually means we can't ask permission to accept fingerprinting risks, as they are subtle, technical, and commonly have nothing to do with the capability itself. * **Provide sufficient context.** From 63307eeda76d1a4ee285d3d32416b80f64db2666 Mon Sep 17 00:00:00 2001 From: Marian Harbach Date: Tue, 7 Oct 2025 11:38:35 +0200 Subject: [PATCH 16/20] Apply suggestion from @jyasskin Co-authored-by: Jeffrey Yasskin --- index.bs | 1 + 1 file changed, 1 insertion(+) diff --git a/index.bs b/index.bs index 455b2bd8..219f666f 100644 --- a/index.bs +++ b/index.bs @@ -222,6 +222,7 @@ that is likely an indication that asking the user isn't the right approach. Instead, change the feature or API to address any remaining risk.
+ A browser is responsible for managing requests for permission. Browsers will not be able to understand precisely how a user's interaction with a site From 63450e90bfcb62a8d7160d2c71e06f39eaca7193 Mon Sep 17 00:00:00 2001 From: Marian Harbach Date: Tue, 7 Oct 2025 11:38:55 +0200 Subject: [PATCH 17/20] Apply suggestion from @jyasskin Co-authored-by: Jeffrey Yasskin --- index.bs | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/index.bs b/index.bs index 219f666f..2d639bf4 100644 --- a/index.bs +++ b/index.bs @@ -228,7 +228,7 @@ Browsers will not be able to understand precisely how a user's interaction with a site might result in a reasonable expectation of a permission request. The web platform provides sites with many ways -of both effectively communicating purpose and intent, +either to communicate purpose and intent, or to employ deception and trickery. The responsibility for clearly communicating intent is therefore shared From 52b7f0d0845643ce9dc5e278790c20d0766c7ebd Mon Sep 17 00:00:00 2001 From: Marian Harbach Date: Tue, 7 Oct 2025 11:39:19 +0200 Subject: [PATCH 18/20] Apply suggestion from @jyasskin Co-authored-by: Jeffrey Yasskin --- index.bs | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/index.bs b/index.bs index 2d639bf4..4d02dd0c 100644 --- a/index.bs +++ b/index.bs @@ -246,7 +246,9 @@ In your specification, the [=request permission to use=] and [=prompt the user t If you ask a user to make a decision and they say no, the website shouldn't be able to do anything -the user believes they just refused access to. +the user believes they just refused access to. +For example, if the user agent asks permission to reveal a piece of information via one API, +the same information shouldn't be available with no permission via a different API. Refusal is most effective if the site cannot distinguish refusal from other, common situations. From d5000531ec4b3a85eb6cb5d065abfdedf389521c Mon Sep 17 00:00:00 2001 From: Marian Harbach Date: Tue, 7 Oct 2025 11:42:17 +0200 Subject: [PATCH 19/20] removed a superfluous comma. --- index.bs | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/index.bs b/index.bs index 4d02dd0c..448345d8 100644 --- a/index.bs +++ b/index.bs @@ -205,7 +205,7 @@ Use these principles: * **Provide constant feedback about persistent decisions.** If users' decisions last longer than the current session, user agents should remind users that their past decision still applies. - Provide a way to retract any ongoing permission., + Provide a way to retract any ongoing permission. APIs should include a way for sites to learn of the change in status. * **Ask questions people can understand.** When a typical user reads the question about a feature, From bf0f95a6103d473ff8fb53651038a544ce6360dc Mon Sep 17 00:00:00 2001 From: Marian Harbach Date: Wed, 8 Oct 2025 07:56:57 +0200 Subject: [PATCH 20/20] Included suggestions from @jyasskin --- index.bs | 21 +++++++++++---------- 1 file changed, 11 insertions(+), 10 deletions(-) diff --git a/index.bs b/index.bs index 448345d8..9c569445 100644 --- a/index.bs +++ b/index.bs @@ -199,23 +199,25 @@ When user involvement is unavoidable, empower users to make good decisions. Use these principles: -* **Limit the consequences from a bad decision by addressing risk at the API level first.** +
    +
  • **Limit the consequences from a bad decision by addressing risk at the API level first.** Do not ask users questions where a "bad" decision can lead to severe consequences, - like a compromised device or serious personal data disclosure. -* **Provide constant feedback about persistent decisions.** + like a compromised device or serious personal data disclosure.
    • +
  • **Provide constant feedback about persistent decisions.** If users' decisions last longer than the current session, user agents should remind users that their past decision still applies. Provide a way to retract any ongoing permission. - APIs should include a way for sites to learn of the change in status. -* **Ask questions people can understand.** + APIs should include a way for sites to learn of the change in status.
    • +
  • **Ask questions people can understand.** When a typical user reads the question about a feature, they should immediately think of the associated risks. The risks should also be directly connected to the feature's or API's utility. For example, this usually means we can't ask permission to accept fingerprinting risks, - as they are subtle, technical, and commonly have nothing to do with the capability itself. -* **Provide sufficient context.** + 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. + what the decision is about, and how the website will use any information they might share.
    • +
If you can't adhere to all of the above principles, that is likely an indication that asking the user isn't the right approach. @@ -855,8 +857,7 @@ that site can deny or restrict the user's access to the services it provides. People who make use of assistive technologies are often [vulnerable members of society](https://www.w3.org/2001/tag/doc/ethical-web-principles/#noharm); their use of assistive technologies is [sensitive information](https://www.w3.org/TR/security-privacy-questionnaire/#sensitive-data) about them. -If an API provides access to this information -without [asking the user](#user-decisions), +If an API provides access to this information, this sensitive information may be revealed to others (including [state actors](https://www.w3.org/2001/tag/doc/ethical-web-principles/#expression)) who may wish them harm.