Skip to content

Latest commit

 

History

History
259 lines (208 loc) · 14.5 KB

security_and_privacy.md

File metadata and controls

259 lines (208 loc) · 14.5 KB
Raw

Security & Privacy

The following considerations are taken from the W3C Security and Privacy Self-Review Questionnaire.

2.1 What information might this feature expose to Web sites or other parties, and for what purposes is that exposure necessary?

This feature exposes information about screens connected to the device, which is necessary for multi-screen window placement use cases explored in the explainer.

Currently, some limited information about the screen that each window currently occupies is available through its Screen interface and related media queries. Information about the window's placement on the current screen (or in more rich cross-screen coordinates) is already available through the Window interface.

This feature provides a surface to optionally expose information about all connected screens, additional display properties of each screen, and events when the set of screens or their properties change. It also allows window placements to be exposed in multi-screen coordinates. The newly exposed information has been tailored to what would typically be required for the most essential multi-screen window placement features. See the ScreenDetailed definition for the full set of new screen properties exposed and their respective utility.

It should be noted that existing Window.screenLeft, screenTop, and non-standard Screen.left and top values, are generally given in cross-screen coordinates, so it may already be possible for sites to infer the presence of, and limited information about, screens other than the one its window currently occupies. Also, some user agent implementations already allow cross-screen window placement without permission, making it possible to gather multi-screen information through brute-force movement of a window outside the current screen's bounds, checking the resulting position and window.screen object.

If Screen, accessed via Window.screen does not expose non-standard left and top values, then specifying Window.screenX and screenY in multi-screen coordinates (rather than relative to the current screen) may allow sites to infer the presence of, and limited information about, screens other than the one its window currently occupies.

2.2 Is this specification exposing the minimum amount of information necessary to power the feature?

Generally, yes. The information exposed is widely useful to a variety of window placement use cases, but not all information will be relevant to every use case. Further limiting what overall information could be exposed, may be a valuable general principle, but would either render this API useless or add nontrivial implementer work and API complexity for questionable utility and protections.

For example, user agents could show a UI to select the screen used for element fullscreen, but this has no real advantage for users over the cumbersome current pattern of dragging windows between screens before entering fullscreen, and existing APIs like window.screen would expose most of the same information about that screen anyway. Additionally, user agents lack the context around a web application's window placement actions, and declarative arrangements specified by a site are unlikely to provide the requisite expressiveness for most use cases.

All newly exposed information could be gated by the proposed window-management permission, limited to secure contexts, top-level frames, gated by user gesture, active window contexts, and other protections to help mitigate concerns around fingerprinting.

The amount of information exposed to a given site would be at the discretion of users and their agents. Exposing the full set of proposed information (with user permission) enables web applications to offer compelling functionality, but exposing a limited subset of new information may be useful in some scenarios.

Supporting queries for limited pieces of information is not directly useful to sites conducting window placement use cases, and does not specifically prohibit abusive sites from requesting all available information. Broad filters or making multiple calls with opposite filters wouldn't constrain the information returned (e.g. getScreenDetails({minWidth:10}) or getScreenDetails({internal:true}) + getscreens({internal:false})).

2.3 How does this specification deal with personal information or personally-identifiable information or information derived thereof?

Information about the device's screens and the placement of a site's windows are exposed to the site when the user grants permission, and when other conditions are satisfied (e.g. secure context).

2.4 How does this specification deal with sensitive information?

This API does not expose any sensitive information, beyond that described above.

2.5 Does this specification introduce new state for an origin that persists across browsing sessions?

The user agent could persist screen permission grants.

2.6 What information from the underlying platform, e.g. configuration data, is exposed by this specification to an origin?

This API proposes exposing about 10-18 new properties for each connected screen, most of which directly correlate with underlying platform configuration data. See ScreenDetailed for all properties exposed and their respective utility.

2.7 Does this specification allow an origin access to sensors on a user’s device?

No. If anything, this API may expose the presence of touch or pen sensors associated with each display, but not access to sensor data itself.

2.8 What data does this specification expose to an origin? Please also document what data is identical to data exposed by other features, in the same or different contexts.

The API exposes a new attribute and event on the Screen interface:

  • Whether the visual workspace extends over 2+ screens
    • Not web-exposed, but inferrable when a site has windows on multiple screens
  • Events fired when Screen attributes change
    • Not web-exposed, but observable with polling

The API exposes a set of ScreenDetailed objects in a ScreenDetails interface, providing info about each connected display, extending the singular Screen object currently available to each window, and similar to the set of Screen objects available to an origin if separate windows for that origin were placed on each of the connected screens, by aggregating the respective window.screen objects.

This API proposes exposing these properties on each ScreenDetailed object:

  • The width of the available screen area
  • The height of the available screen area
  • The width of the screen area
  • The height of the screen area
  • The bits allocated to colors for a pixel of the screen
  • The bits allocated to colors for a pixel of the screen
  • The orientation type of the screen
  • The orientation angle of the screen
  • The left screen coordinate
    • Not standardized, but already exposed by some browsers via Screen.left
  • The top screen coordinate
    • Not standardized, but already exposed by some browsers via Screen.top
  • The left available coordinate
  • The top available coordinate
    • Not standardized, but already exposed by some browsers via Screen.availTop
  • Whether it is internal (built-in) or external
  • Whether it is the primary display or a secondary display
  • The device pixel ratio for the screen
  • A generated identifier for the screen
    • Not web-exposed, but a more persistent id is available via the Chrome Apps system.display API
  • Whether the screen supports touch or pen input
  • A user-friendly label for the screen

Some window placement information is already exposed by the Window interface, but the proposal requires that bounds be specified in a cross-screen coordinate space, not relative to the window's current screen:

2.9 Does this specification enable new script execution/loading mechanisms?

No.

2.10 Does this specification allow an origin to access other devices?

This API allows an origin to read properties of screens connected to the device. The screen may be internally connected (e.g. the built-in display of a laptop) or externally connected (e.g. an external monitor).

An origin cannot use this API to send commands to the displays, so hardening against malicious input is not a concern.

Enumerating the screens connected to the device does provide significant entropy. If multiple computers are connected to the same set of screens, an attacker may use the display information to deduce that those computers are in the same physical vicinity. To mitigate this issue, user permission is required to access the display list, the API is only available on secure contexts, and the ids of each screen are generated on a per-user per-origin basis, reset when cookies are cleared.

2.11 Does this specification allow an origin some measure of control over a user agent’s native UI?

No.

2.12 What temporary identifiers might this specification create or expose to the web?

None.

2.13 How does this specification distinguish between behavior in first-party and third-party contexts?

Only first-party contexts can generally control the window's placement. Third party contexts in iframes can already discern the dimensions of their frame; nothing in this proposal should affect that. Additionally, third party contexts can request element fullscreen (with the allowfullscreen feature policy) and open and place popup windows; this proposal extends those functionalities for cross-screen requests, with similar permission requirements to the first-party context of the main frame.

2.14 How does this specification work in the context of a user agent’s Private \ Browsing or "incognito" mode?

The behavior should be the same as for regular mode, except that the user agent should not persist permission data and should request permission every session.

2.15 Does this specification have a "Security Considerations" and "Privacy Considerations" section?

Yes.

2.16 Does this specification allow downgrading default security characteristics?

No.

2.17. What should this questionnaire have asked?

The questionnaire could ask if implementing the proposal would yield or enable any additional Security and Privacy protections.

By adding the proposed window-management permission, browsers could further limit unpermissioned access to existing information and capabilities.

For example, without the permission, browsers could:

  • Disregard left and top values requested via window.open()'s features argument string to reduce clickjacking risks.
  • Disregard requests to move popup and web application windows via window.moveTo(x, y) to reduce clickjacking risks.
  • Return the corresponding innerWidth and innerHeight values for Window's outerWidth and outerHeight to limit information exposed about the window frame size, which can be used to infer more granular information about the user agent, its version, and the window frame type used than would otherwise be exposed.
  • Return 0 for Window's screenX and screenY attributes to limit similar unnecessary information exposure.
  • Perhaps limit other existing Screen and Window information and capabilities.

The questionnaire could also dig deeper into potential security concerns of the API, which are explored in the Privacy & Security section of the explainer.