Design Review #645

#645: Capture Handle Identity

Opened Jun 8, 2021

Ya ya yawm TAG!

I'm requesting a TAG review of Capture Handle Identity.

The proposed capture handle is a mechanism that allows a web-application to ergonomically and confidently identify the web-application which it is display-capturing - provided that the captured application has opted-in. Such identification allows these two applications to collaborate in interesting ways. For example, if a VC application is capturing a presentation, then the VC application can expose user-controls for previous/next-slide directly in the VC application. This lets the user navigate presentations without having to jump between the VC and presentation tabs.

Explainer: https://github.com/w3c/mediacapture-handle/blob/main/identity/README.md
Specification URL: https://w3c.github.io/mediacapture-handle/identity/
Tests: N/A
Security and Privacy self-review: https://github.com/w3c/mediacapture-handle/blob/main/identity/security-privacy-questionnaire.md
Primary contacts (and their relationship to the specification):
- Elad Alon (@eladalon1983), Google
Organization(s)/project(s) driving the specification: Google
Key pieces of existing multi-stakeholder review or discussion of this specification: w3c/mediacapture-handle#52
External status/issue trackers for this specification (publicly visible, e.g. Chrome Status): https://chromestatus.com/feature/4854125411958784

Further details:

I have reviewed the TAG's Web Platform Design Principles
Relevant time constraints or deadlines: Origin Trial has started in Chrome m92
The group where the work on this specification is currently being done: WebRTC WG
The group where standardization of this work is intended to be done (if current group is a community group or other incubation venue): W3C under mediacapture-handle/identity/.
Major unresolved issues with or opposition to this specification: N/A (minor issues remain and are being discussed)
This work is being funded by: Google

We'd prefer the TAG provide feedback as (please delete all but the desired option): 💬 leave review feedback as a comment in this issue and @-notify @eladalon1983

Discussions

2021-06-28

Minutes

Amy: haven't had chance to look, defer

Peter: more people assigned to this?

Amy: ask in plenary?

2021-07-12

Minutes

Amy: capture handle lets the captured app communicate witht he capturing app - share info with the capturing app - on top of the existing screen share API.

Dan: What's the usert need.

Amy: Explainer is a google doc - 4 uses cases - sharing in video conference via another tab - being able to change slides without switching tab. Another about analytics. Not convinced - some surveillancy thing possibly. Detecting unintended captures... "you're about to screen cap this maybe not a good idea..." Then avoiding the hall of mirrors.

Dan: Why would you want to avoid the hall of mirrors?

Amy: would like to see abuse cases spelled out. They're S&P questionnaire answers is minimal. On the basis that the captured app is the one deciding what to share.

Dan: the captured app needs to opt in?

Amy: yes -

Dan: we could ask them to put it in markdown - and elaborate on the abuse cases...

Amy: it's been moved to WICG. Contraversial issue - they've listed it in the request - problems with Mozilla and Apple - that might be out of date.

Dan: where would it end up after wicg?

Amy: it started in webrtc maybe?

Dan: Was there not consensus in webrtc wg on it?

Hadley: it would be useful to know more history.

Dan: left a comment

Amy: will follow up about abuse cases and multi stakeholder support, and check for relation/dependencies to capturetab