Re: [EXTERNAL] Re: [blink-dev] Re: Intent to Prototype: Confirmation of Action API

['Sara Tang' via blink-dev]

Hi Roberto, thanks for your feedback  Responses inline:


From: Roberto Clapis 
Sent: Tuesday, February 8, 2022 9:05 AM
To: blink-dev 
Cc: Roberto Clapis ; Sara Tang ; 
blin...@chromium.org ; Daniel Libby 
; yoav...@chromium.org 
Subject: Re: [EXTERNAL] Re: [blink-dev] Re: Intent to Prototype: Confirmation 
of Action API

There is one additional question that was brought forward during the discussion:

  *   What information can be read by the users of this API? This is mentioned 
in the security concerns but it doesn't seem to be specified elsewhere. Is this 
just about learning of an existence of a AT or is this some additional info?
  *   Here are some security concerns and possible mitigations. These are also 
re-iterated in the "Privacy and Security Considerations" section of the 
proposal:
  *   - readback: Do not readback AT configuration settings. Doing so makes the 
user an easier target for fingerprinting.
  *   - authoritative-sounding notifications: announcements can be crafted to 
deceive the user. We should suppress notifications when focus moves outside of 
the web content.
  *   - Maybe only offer this feature to Secure Contexts (instead of 3rd party 
browsing contexts)

On Tuesday, February 8, 2022 at 11:06:43 AM UTC+1 Roberto Clapis wrote:
Hi All,

During a discussion about this proposal a few concerns were raised:

  *   What pipeline of data would be used to pass the new messages to a 
potential screen-reader? Would screen-readers need to implement a new API or 
would this use pre-existing ones?
  *   A small nuance: screen-readers do not implement APIs, they consume ones 
that are exported by the Web Platform.
  *   - In the case of Windows systems, we use the UIA notifications API to 
pass information along to screen-readers.
  *   - In the case for other systems, we can hijack the existing ARIA live 
regions implemenation. In the case where the confirmation of action API is 
called without a DOM element/ARIA node, we can attach the announcement to an 
internal "root" node instead.
  *   Does this new API allow pages to have a more direct or a less restricted 
way to pass data to a screen reader?
  *   Less restrictive; possible restrictions we'll need to employ are listed 
in the next response.
  *   Would this API allow potential attackers to use different character sets 
or might this allow them to pass potentially malformed data to screen readers 
that was not possible to pass before?
  *   Here are some possible mitigations we have for this scenario:
  *   - Truncating strings, employing a max queue length
  *   - Restricting to alphanumeric input.
  *   - Running the announcement-text through a 
HTML-parser/DOM-parser/setInnerHtml or similar JS API

  *   If a pre-existing channel is used to communicate with the screen reader 
(e.g. already existing APIs) how would a user distinguish this new mechanism 
from content on the page?
  *   I don't think it's necessary for the user to distinguish between 
different screen-announcing APIs. Is there a particular scenario you are 
thinking of where a distinction would be needed?

Thanks in advance,
Rob



On Wednesday, February 2, 2022 at 1:05:58 AM UTC+1 Sara Tang wrote:
Good suggestion Yaov! I've opened one here: Review request for Confirmation of 
Action API · Issue #713 · w3ctag/design-reviews 
(github.com)

From: Yoav Weiss 
Sent: Monday, January 31, 2022 6:33 AM
To: Sara Tang 
Cc: blin...@chromium.org ; Daniel Libby 

Subject: [EXTERNAL] Re: [blink-dev] Re: Intent to Prototype: Confirmation of 
Action API



On Sat, Jan 29, 2022 at 1:27 AM 'Sara Tang' via blink-dev 
 wrote:
+Daniel Libby

From: Sara Tang
Sent: Friday, January 28, 2022 4:26 PM
To: blin...@chromium.org 
Subject: Intent to Prototype: Confirmation of Action API

Contact emails
sar...@microsoft.com

Explainer
https://github.com/WICG/aom/blob/gh-pages/notification-api.md

Specification


Summary

This effort aims to create a JavaScript API so that developers can better 
notify AT users of actions/changes to a webpage not necessarily tied to UI 
elements.


Blink 

Re: [blink-dev] Intent to Ship: Multi-Screen Window Placement

[Mike Taylor]

Hi Michael,

I think you and team have done a great job incorporating TAG and API 
ergonomics feedback (hi Jake!) as well as privacy concerns. Nice work.


LGTM1.

On 2/14/22 8:28 PM, Michael Wasserman wrote:



Contact emails

m...@chromium.org 


Explainer

https://github.com/webscreens/window-placement 




Specification

https://webscreens.github.io/window-placement/ 




Design docs


https://web.dev/multi-screen-window-placement/



Summary

Adds new screen information APIs and makes incremental improvements to 
existing window placement APIs, allowing web applications to offer 
compelling multi-screen experiences.



The existing singular window.screenoffers a limited view of available 
screen space, and window placement functions generally clamp bounds to 
the current screen. This feature unlocks modern multi-screen 
workspaces for web applications.



Blink component

UI>Browser>WebAppInstalls>Desktop 




Search tags

window placement 
, screen 
enumeration 
, window 
, open 
, moveTo 
, moveBy 
, requestFullscreen 
, screen 
, display 
, monitor 
, multi-screen 
, multi-display 
, multi-monitor 
, cross-screen 
, cross-display 
, cross-monitor 




TAG review

https://github.com/w3ctag/design-reviews/issues/413 
https://github.com/w3ctag/design-reviews/issues/522 
https://github.com/w3ctag/design-reviews/issues/602 




TAG review status

Issues addressed


Risks


Interoperability and Compatibility

Feature detection of new screen information APIs and Permission API 
integration allows sites to handle different levels of feature 
support. The Screen IDL interface duplicates EventTarget members for 
RuntimeEnabled experimentation without changing the stable JS API; 
this will be rectified after launch approval.



Existing window placement APIs generally use compatible multi-screen 
coordinates, but implementations often restrict bounds to the current 
screen. We expect low levels of risk in supporting permitted 
cross-screen placement requests, and falling back on legacy 
same-screen behavior otherwise.



A detailed assessment of API design risks, including Wayland 
compatibility, multiple virtual workspaces/desktops, and more, can be 
found at: 
>



API surface changes made during the second origin trial are limited to 
some minor renames, the removal of two unimplemented screen 
properties, and support for permission policy. An exploratory 
permission-gated capability to swap the screen of fullscreen windows 
without a user gesture was reverted to enhance usable security. See 
>



The spec is being incubated in the W3C Second Screen CG 
> and is pending adoption by 
the W3C Second Screen WG >



Gecko: No signal 
(https://github.com/mozilla/standards-positions/issues/542 
) We 
requested a position and are waiting for feedback. Firefox supports 
cross-screen window.open/move*()requests. This work partly pursues 
compatibility with that behavior.



WebKit: No signal 
(https://lists.webkit.org/pipermail/webkit-dev/2021-June/031903.html 
) 
We requested a