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@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.