"User notifications" section should be more specific

[pes10k]

This issue is being filed as part of the requested PING review

Theres a "user notifications" recommendation section (which is good), but I think more detail is needed for this section to be helpful to implementors. For example, whats the scope of the notification (the entire browser? What happens if a page uses it in the background, etc?). How do the APIs react if a user uses the notification dialog to revoke access in the middle of the document executing? etc.

[anssiko]

I believe what goes beyond "show some form of unobtrusive notification" would be an implementation detail due to diversity of browser and OS UI/UX, device form factors and screen sizes etc.

@pes10k do you have an example of an exemplary web spec that goes into further detail we could learn from?

[pes10k]

I dont have a precise example off hand, but you might consider some of the WebPayments and WebAuthn work, which details in places what kinds of elements should be presented by the browser, and what text should be present, etc.

The bigger point is that, if the group thinks that a user notification is an important privacy mitigation, I think its important to say more about the properties that notification should have. Presumably a console.log message wouldn't suffice, for example. So even if its only guidance, some specificity is important

[anssiko]

Thanks @pes10k. I looked at those two specifications you mentioned. Do you perhaps refer to the following text as good examples to look for inspiration:

Some kind of user interface will be presented to the user to facilitate the payment request after the show() method returns.

Each payment handler controls what happens when multiple browsing context simultaneously call the show() method. For instance, some payment handlers will allow multiple payment UIs to be shown in different browser tabs/windows. Other payment handlers might only allow a single payment UI to be shown for the entire user agent.

Note in https://www.w3.org/TR/payment-request/#show-method

---

The authenticator presents the user with a notification that their attention is needed. On opening the notification, the user is shown a friendly selection menu of acceptable credentials using the account information provided when creating the credentials, along with some information on the origin that is requesting these keys.

Step 6 of https://www.w3.org/TR/webauthn-2/#sctn-sample-authentication

---

In addition to the above script interface, the authenticator MAY implement (or come with client software that implements) a user interface for management. Such an interface MAY be used, for example, to reset the authenticator to a clean state or to inspect the current state of the authenticator. In other words, such an interface is similar to the user interfaces provided by browsers for managing user state such as history, saved passwords, and cookies. Authenticator management actions such as credential deletion are considered to be the responsibility of such a user interface and are deliberately omitted from the API exposed to scripts.

3rd text block in https://www.w3.org/TR/webauthn-2/#sctn-api

---

Please let us know if this level of abstraction would be helpful for this spec too to guide implementers on user interface aspects in respect to the user notification. As you know, there's a limit to how much we can normatively specify in terms of UI/UX, but we agree this section would benefit from updates.

After we hear back from you we'll enhance the user notification section of the specification and seek your review for the proposed improvements. Thank you!

[pes10k]

Yes, i think these are good models to build from. Thanks!

[anssiko]

While pondering this I realized that a change in one important keyword in this section could make a major difference in how implementers will perceive and approach this recommendation.

@pes10k, what do you think if we'd change "unobtrusive" to "user-visible"? I personally prefer concise guidance because it is more likely to be read (and adhered to) by implementers. Here's how this section would read with this improvement (emphasis mine):

It is RECOMMENDED that a user agent show some form of user-visible notification that informs the user when a pressure observer is active, as well as provides the user with the means to block the ongoing operation, or simply dismiss the notification.

AFAICT the adjective "unobtrusive" does not have a special meaning in web specs and its dictionary definition reads:

unobtrusive /ʌnəbˈtruːsɪv/
adjective
not conspicuous or attracting attention.

"Unobtrusive" could indeed be interpreted so that a console.log message could suffice which clearly is not an appropriate way to inform users.

OTOH I see "user-visible" appear in a few web specs. While also not a web spec defined concept, it is more concrete and better understood by non-native speakers I believe. If there's a better word for this please let us know!

@pes10k maybe this is the significant change we need in this section for now? Small yet impactful. Thank you for your continued contributions!

(As a bonus, this updated user notifications section could in part also help mitigate the proposed cross-site covert channels attack discussed in #197. Perhaps we could note in the mitigations section that if an implementation detects a long-running script that is using this API we could recommend this user notification to become more prominent akin to unresponsive script warning in some browsers.)

[anssiko]

@pes10k here's a PR with the proposed changes, PTAL: #218

[anssiko]

@pes10k we believe #218 addresses this issue.

Feel free to propose any additional text for inclusion into this User notifications section as appropriate.

We will revisit this section if new information emerges or if there are further learnings or user feedback from the ongoing trial. Thanks for your suggestions!