[webkit-dev] Request for position: preferCurrentTab

[Elad Alon]

>
> 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 <youennf at gmail.com> 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 at 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 at lists.webkit.org
>> https://lists.webkit.org/mailman/listinfo/webkit-dev
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20210615/2d0d3c32/attachment.htm>