[webkit-dev] Request for position: Capture Handle Identity

youenn fablet youennf at gmail.com
Fri Mar 11 03:38:22 PST 2022

Hi Elad,

For those following, the new link to the spec is

A few thoughts:
1. The use cases are fine, although the proposal is currently restricted to
tabs having a tight coordination (same origin typically). Reducing a lot
the level of required coordination between capturee and capturer seems like
an important requirement.
3. The current API allows to share a single string for all capturers no
matter the capturer origin (as long as origin is in the allowed list). It
seems that identity could be different depending on the capturer origin.
For instance, a capturee could expose its context ID (
https://w3c.github.io/ServiceWorker/#client-id)) if capturer is same origin
but just its origin for all other capturers. Replacing the allowed list
mechanism by a map-like API would be more flexible without adding much
4. The idea is to share identity from captured page to capturer page. On
the web, the foundation of page identity is origin. The current API allows
exposing a partial identity, i.e. an application-provided string without
the origin. The scenarios in the document do not motivate AFAICS this
'partial' identity. It seems origin should be the first thing a captured
page might want to share if it desires so. The fact that, by default, the
origin is not exposed is not encouraging either.
5. Some of the usecases would be better suited with their own specific
solution (use case 3 and 4 for instance, a property that directly tells
whether capturee === capturer). I think they should be pursued on their own
and removed from the document.
6. Capture handle creates a one way broadcast/postMessage-limited-to-string
mechanism if capturee repeatedly calls the capture handle API as events
will be fired on capturer for each API call. If introducing a messaging API
as use case #1 mentions, this mechanism might become redundant with this
future messaging API. It would be good to consolidate the current proposal
based on use case #1 next steps.
7. Capture Handle Identity is really about screenshare, not about
camera/microphones, it would be good to make that clear in the links/spec
short names.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20220311/5f799265/attachment.htm>

More information about the webkit-dev mailing list