Screen Capture API (2019)

[jan-ivar]

Hello TAG!

This supersedes #309 as a request for a TAG review of:

• Name: Screen Capture
• Specification URL: https://w3c.github.io/mediacapture-screen-share/
• Explainer (containing user needs and example code)¹: explainer.md
• GitHub issues (if you prefer feedback filed there): here or TAG review w3c/mediacapture-screen-share#59
• Tests: wpt (lack of green is due to Tests involving "permissions" API/UI web-platform-tests/wpt#5671)
• Primary contacts (and their relationship to the specification): @jan-ivar (co-chair), @martinthomson (editor)

Further details:

• Relevant time constraints or deadlines: Would like to go to CR soon. Charter ends March 2020.
• I've read & filled out the Self-Review Questionnare on Security and Privacy. Answers are here.
• I have reviewed the TAG's API Design Principles
• The group where the work on this specification is: WebRTC

You should also know that...

This has been implemented in all major browsers (behind a flag in Safari), on desktop platforms only (mostly). No opposition recorded.

• Simple demo page.
• The feature is broadly adopted by most major web conferencing services (hangouts, whereby, jitsi, meet, cisco, meetecho and many others).
• Audio is a recent addition, limited to Chrome atm afaik.
• The user gesture requirement is new, and only implemented by Safari atm (patch in Firefox).
• Some concern (from yours truly) that elevated permissions are not established rigorously enough in all browsers.

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 @jan-ivar

Thanks!

[hadleybeeman]

Hi, @jan-ivar, and thanks for sending this. @torgo and I have started looking at it at our TAG face-to-face in Wellington.

We've seen that the Security and Privacy section has matured a lot since we last looked at this document. But we got lost a bit in the current wording. Specifically:

1. For sections 8.2.1. and 8.2.2., it's not clear to us what use cases you have in mind. It may be useful to spell them out explicitly.

For 8.2.1., what is active user consent (perhaps it's asking for a permission?), and how is it different to the "novelty" mentioned in 8.2.3?

And for 8.2.2., when do you foresee content crossing origins? With the sharing user, or somehow including the recipient? Also, what elevated permissions are you expecting here? Perhaps those in the OS, or on the specific origin? If it's the origin, then what permissions, and how are they different to what you're thinking of in 8.2.1?

2. On 5.5 device identifiers: we are pleased that you're concerned about enumerated devices revealing too much information. That's great!

But we're a bit confused... how do you think that UAs will solve that problem? Is it necessary to spell that out, or is flexibility useful here?

Specifically, we were wondering if you are expecting them to create temporary device IDs? Do you see any danger of them being preserved, and therefore causing the same problem?

[torgo]

Also, we were happy to see how much throught went into the responses to the privacy & security questionnaire, especially since this API has some tricky privacy considerations. We'd appreciate it if that doc could be brought over into your repo instead of living as a google doc.

[jan-ivar]

Hi, and thanks! I'm happy to elaborate since the privacy issues aren't super evident. (Part 1/2)

For 8.2.1., what is active user consent (perhaps it's asking for a permission?),

In short, yes. It's one of two forms of mandated consent interactions; the one required regardless of source. This spec tries hard to not assume what shape UX might take, hence these abstractions.

Example of Active User Consent: all current implementations implement a screen/window/tab picker, which imply giving permission much like a file upload dialog does.

and how is it different to the "novelty" mentioned in 8.2.3?

It should be less severe/novel than the elevated permission required for scary sources.

Importantly, "elevated permissions are not a substitute for active user consent." In other words: sharing a scary source requires both elevated permission and active user consent.

Example of Elevated Permission: an installation procedure akin to installing an extension, where the user understands they're making a high-trust special exception. At the time of writing years ago, Chrome still required installation of an extension to enable screen sharing, and Firefox required an about:config whitelist of websites (i.e. an extension).

Since then, implementations have lowered the bar:

1. Firefox shows a ⚠️ warning in the preview pane (seen here) of scary sources only.
2. Chrome makes no distinction (in violation of the spec in my opinion).

[jan-ivar]

(Part 2/2)

And for 8.2.2., when do you foresee content crossing origins?

If a web site controls both what is being captured and the resulting stream, then it has a power tool to circumvent the same origin policy. See the blog for an explanation of this exploit.

On 5.5 device identifiers:

Device identifiers are not exposed to JS ("MUST NOT be enumerated by enumeratedevices()").

[jan-ivar]

@hadleybeeman @torgo. I've added the questionnaire in w3c/mediacapture-screen-share#137

[torgo]

Hi - I think we are happy to close this. Thanks for taking our feedback on board.