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

[Elad Alon]

Hi Youenn,

Thank you for these thoughts. I have some counter-thoughts, but I am not
sure this is the best forum to continue with the discussion.
* Could you please explain the bottom-line Apple position for this API?
* Could you please file issues in w3c/mediacapture-handle
<https://github.com/w3c/mediacapture-handle/> for the issues, so that we
may continue the discussion there?

Thanks,
Elad

On Fri, Mar 11, 2022 at 12:38 PM youenn fablet <youennf at gmail.com> wrote:

> Hi Elad,
>
> For those following, the new link to the spec is
> https://w3c.github.io/mediacapture-handle/identity/index.html.
>
> 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
> complexity.
> 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/20220314/e22b575f/attachment.htm>