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

[Elad Alon via webkit-dev]

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
 for the issues, so that we
may continue the discussion there?

Thanks,
Elad

On Fri, Mar 11, 2022 at 12:38 PM youenn fablet  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.
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

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

[youenn fablet via webkit-dev]

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.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

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

[Elad Alon via webkit-dev]

This is a request for WebKit's position on introducing an API that allows
captured Web-applications to declare their identity to a would-be capturing
Web-application.

Links:
* Explainer: https://github.com/WICG/capture-handle/blob/main/README.md
* Spec: https://wicg.github.io/capture-handle/
* ChromeStatus entry: https://chromestatus.com/feature/4854125411958784
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev