Re: [webkit-dev] Request for position: Conditional Focus

[Elad Alon via webkit-dev]

A kind soul has informed me that WebKit now uses GitHub. I've posted the
request to: https://github.com/WebKit/standards-positions/issues/73

On Thu, Oct 13, 2022 at 10:02 PM Elad Alon  wrote:

> This is a request for WebKit's position on introducing a new API called
> Conditional Focus. The API integrate with screen-capture (getDisplayMedia).
> It allows a capturing application to decide whether, once a display surface
> has been captured, that surface should be focused, or whether the capturing
> tab should retain focus.
>
> Links:
> * Explainer: https://github.com/WICG/conditional-focus/blob/main/README.md
> * Spec:
>   * Generally, it's in:
> https://www.w3.org/TR/screen-capture/#dom-capturecontroller-setfocusbehavior
>   * The two PRs that introduced this are:
> * https://github.com/w3c/mediacapture-screen-share/pull/235/files
> * https://github.com/w3c/mediacapture-screen-share/pull/240/files
> * ChromeStatus entry: https://chromestatus.com/feature/5646614535340032
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] Request for position: Conditional Focus

[Elad Alon via webkit-dev]

This is a request for WebKit's position on introducing a new API called
Conditional Focus. The API integrate with screen-capture (getDisplayMedia).
It allows a capturing application to decide whether, once a display surface
has been captured, that surface should be focused, or whether the capturing
tab should retain focus.

Links:
* Explainer: https://github.com/WICG/conditional-focus/blob/main/README.md
* Spec:
  * Generally, it's in:
https://www.w3.org/TR/screen-capture/#dom-capturecontroller-setfocusbehavior
  * The two PRs that introduced this are:
* https://github.com/w3c/mediacapture-screen-share/pull/235/files
* https://github.com/w3c/mediacapture-screen-share/pull/240/files
* ChromeStatus entry: https://chromestatus.com/feature/5646614535340032
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] Request for position: DisplayMediaStreamConstraints.surfaceSwitching

[Elad Alon via webkit-dev]

This is a request for WebKit's position on extending getDisplayMedia to
also accept DisplayMediaStreamConstraints.surfaceSwitching.
The PR that introduced this behavior to the getDisplayMedia spec was
approved by Apple engineer Youenn Fablet.

Links:
* Explainer:
https://docs.google.com/document/d/1kqdLoUcwWe8znVCMXyz2FHk9WMylHbIo7gUjhyHmY_w/edit?usp=sharing
* Spec: https://github.com/w3c/mediacapture-screen-share/pull/225/files
* ChromeStatus entry: https://chromestatus.com/feature/5067650299330560
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] Request for position: MediaTrackConstraintSet.displaySurface

[Elad Alon via webkit-dev]

This is a request for WebKit's position on extending getDisplayMedia to
also accept MediaTrackConstraintSet.displaySurface. The PR that introduced
this behavior to the getDisplayMedia spec was approved by Apple engineer
Youenn Fablet.

Links:
* Explainer:
https://docs.google.com/document/d/1uI51R4YfFQtfiDTw1KfnLqzIu45OgxhYoUT7khlhmwQ/edit?usp=sharing
* Spec: https://github.com/w3c/mediacapture-screen-share/pull/186/files
* ChromeStatus entry: https://chromestatus.com/feature/5186392840732672
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] Request for position: MediaTrackSupportedConstraints.suppressLocalAudioPlayback

[Elad Alon via webkit-dev]

This is a request for WebKit's position on extending getDisplayMedia
to also accept DisplayMediaStreamConstraints.systemAudio. The PR that
introduced this behavior to the getDisplayMedia spec was approved by
Apple engineer Youenn Fablet.

Links:
* Explainer: 
https://docs.google.com/document/d/1OmuV1W4f2UvToeNxUVGHv8NcFuL63r94gWwz9i_-VBc/edit?usp=sharing
* Spec: https://github.com/w3c/mediacapture-screen-share/pull/164/files
* ChromeStatus entry: https://chromestatus.com/feature/5201258309746688
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] Request for position: DisplayMediaStreamConstraints.selfBrowserSurface

[Elad Alon via webkit-dev]

This is a request for WebKit's position on extending getDisplayMedia to
also accept DisplayMediaStreamConstraints.selfBrowserSurface.
The PR that introduced this behavior to the getDisplayMedia spec was
approved by Apple engineer Youenn Fablet.

Links:
* Explainer:
https://docs.google.com/document/d/1M63lyDHV-v6LPFzHjfsjBDMfyn075pySa3xfIRSB9zU/edit?usp=sharing
* Spec: https://github.com/w3c/mediacapture-screen-share/pull/216/files
* ChromeStatus entry: https://chromestatus.com/feature/5118675366445056
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] Request for position: DisplayMediaStreamConstraints.systemAudio

[Elad Alon via webkit-dev]

This is a request for WebKit's position on extending getDisplayMedia to
also accept DisplayMediaStreamConstraints.systemAudio.
The PR that introduced this behavior to the getDisplayMedia spec was
approved by Apple engineer Youenn Fablet.

Links:
* Explainer:
https://docs.google.com/document/d/1q3oGy7hLJmdQA4ZK7QG7DnwgtcpL6oB2pqLQJ6MP1tY/edit?usp=sharing
* Spec: https://github.com/w3c/mediacapture-screen-share/pull/222/files
* ChromeStatus entry: https://chromestatus.com/feature/4649448880734208
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] Request for position: Region Capture

[Elad Alon via webkit-dev]

This is a request for WebKit's position on introducing an API that allows
cropping video tracks resulting from the capture of the current tab.

Links:
* Explainer: https://github.com/w3c/mediacapture-region/blob/main/README.md
* Spec: https://w3c.github.io/mediacapture-region/
* ChromeStatus entry: https://chromestatus.com/feature/5712447794053120
___
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

[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

[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

Re: [webkit-dev] Request for position: preferCurrentTab

[Elad Alon via webkit-dev]

>
> Doesn't this property go against that conscious design decision? What is
> your security analysis here?


Both preferCurrentTab=true as well as preferCurrentTab=false result in a
user-prompt that is spec-compliant. (The user agent is free to display the
current tab as the most prominent option regardless, and that too would be
spec-compliant.)

Stepping *outside* of the realm of specs for a second - for Chrome we
consider this to be a security *improvement*, since our current picker's
first option is otherwise a superset of the current tab option. *Back* to
the realm of specs - the UA could choose to only show the current-tab as
the most prominent option, if the most prominent option would otherwise be
more dangerous.

Worth mentioning - we consider the restriction over influencing user choice
to be ill-advised in its current form. An interesting discussion is in full
swing here <https://github.com/w3c/mediacapture-screen-share/issues/184>.

Also, getCurrentViewPort is trying to solve the same problem, in a safer
> way (site-isolation), without a device picker. Isn't this a better solution
> than preferCurrentTab?

Or do you see that as a short-term solution that would become irrelevant
> when getCurrentViewPort is available?


The discussion about getViewportMedia began 8-9 months ago and consensus is
still not in sight. And when we do finally standardize it, its security
requirements will take a long time to gain widespread adoption. Another
solution is needed in the few years in between. We can deprecate once
getViewportMedia is widely deployed.

Has Chrome tried such approaches that do not require a new API?


We have considered this, but don't believe this to be a good solution.
Heuristics can backfire. They don't produce a good, consistent user
experience.



On Thu, Jun 10, 2021 at 9:03 PM youenn fablet  wrote:

> Hi Elad,
>
> At the time of getDisplayMedia design, people advocated against the
> ability for a web page to influence or restrict user choice, for security
> reasons.
> Doesn't this property go against that conscious design decision? What is
> your security analysis here?
>
> Also, getCurrentViewPort is trying to solve the same problem, in a safer
> way (site-isolation), without a device picker. Isn't this a better solution
> than preferCurrentTab?
> Or are you restricting preferCurrentTab to some specific tabs? Or do you
> see that as a short-term solution that would become irrelevant when
> getCurrentViewPort is available?
>
> Finally, User Agents are free to remember past user choices so that
> prompts can be updated in case a web page is often self-captured by a user.
> Has Chrome tried such approaches that do not require a new API?
>
>
> Le mer. 9 juin 2021 à 13:20, Elad Alon via webkit-dev <
> webkit-dev@lists.webkit.org> a écrit :
>
>> This is a request for WebKit's position on adding a dictionary member in
>> MediaStreamConstraints called preferCurrentTab. If preferCurrentTab is set
>> to true, the user agent will display the current tab as the most prominent
>> option in the media-picker which getDisplayMedia invokes.
>>
>> Links:
>>
>>- Explainer
>>
>> <https://docs.google.com/document/d/1Og-TUBJQ4SAgReBr7xrd7y-0ZwkjGJMCqBnzDv7_-vs/edit?usp=sharing>
>>- Spec <https://eladalon1983.github.io/prefer-current-tab/>
>>- ChromeStatus
>><https://www.chromestatus.com/guide/edit/5045313003847680>
>>
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> https://lists.webkit.org/mailman/listinfo/webkit-dev
>>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Request for position: preferCurrentTab

[Elad Alon via webkit-dev]

We could rename to preferCurrentBrowserDisplaySurface, referencing a browser
display-surface
<https://w3c.github.io/mediacapture-screen-share/#dfn-browser>, but I find
it to be a mouthful. But I'm open to suggestions.
Name notwithstanding, what is Apple's official, quotable position? :-)

On Thu, Jun 10, 2021 at 12:44 AM Sam Weinig  wrote:

> Hi Elad,
>
> Are there other existing uses of the term “tab” in other web exposed APIs?
> It feels a bit wrong to be wrong to be encoding that specific UI treatment
> into API.
>
> - Sam
>
> On Jun 9, 2021, at 4:20 AM, Elad Alon via webkit-dev <
> webkit-dev@lists.webkit.org> wrote:
>
> This is a request for WebKit's position on adding a dictionary member in
> MediaStreamConstraints called preferCurrentTab. If preferCurrentTab is set
> to true, the user agent will display the current tab as the most prominent
> option in the media-picker which getDisplayMedia invokes.
>
> Links:
>
>- Explainer
>
> <https://docs.google.com/document/d/1Og-TUBJQ4SAgReBr7xrd7y-0ZwkjGJMCqBnzDv7_-vs/edit?usp=sharing>
>- Spec <https://eladalon1983.github.io/prefer-current-tab/>
>- ChromeStatus
><https://www.chromestatus.com/guide/edit/5045313003847680>
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] Request for position: preferCurrentTab

[Elad Alon via webkit-dev]

This is a request for WebKit's position on adding a dictionary member in
MediaStreamConstraints called preferCurrentTab. If preferCurrentTab is set
to true, the user agent will display the current tab as the most prominent
option in the media-picker which getDisplayMedia invokes.

Links:

   - Explainer
   

   - Spec 
   - ChromeStatus 
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev