Re: [mediacapture-screen-share-extensions] Address click-jacking concerns with capture control (#24)

> In #14 (comment) we seem to agree/lists serious click-jacking concerns [that] remain with this API.

Could you clarify the "serious" attack vectors, and why the existing mitigations appear to you insufficient?

To me, it seems extremely benign when a user:
1. Shares a tab.
2. Interacts with a prompt.
3. Clicks and scrolls things on the capturing app and has those gestures forwarded to the captured surface. (Modulo processing for zoom, as clicks get translated into changes in zoom level.)

I could conjure up in my imagination an **unlikely** story where a user interacts with a malicious app, honestly trusts it to share just a few pixels, accidentally approves the prompt, then gets their gestures over the capturing app intentionally misinterpreted, leading to more pixels being revealed than intended. But it's an extremely unlikely story.

A much more likely story would have been one where the user did not even intend to share that tab; yet we have standardized `getDisplayMedia()` out of an understanding that the risk/reward trade-off was favorable. And even more so for Captured Surface Control, the trade-off between usability and security appears favorable, as the security losses seem to me quite hypothetical, while the gains appear actual - evidenced by the support of reputable Web developers who use this API to genuinely serve their users.

> Permission prompts have shown to be useless in explaining click-jacking threats to users.

The answers to this has been posted in [this comment](https://github.com/w3c/mediacapture-screen-share-extensions/issues/14#issuecomment-2434741283) and then [this comment](https://github.com/w3c/mediacapture-screen-share-extensions/issues/14#issuecomment-2437850738).

> As such, permission does not seem sufficient as a remedy to these attacks. The spec needs to address this:
> 
> - by documenting risks and approaches under security considerations

I believe the spec already does this; see [here](https://screen-share.github.io/captured-surface-control/#privacy-and-security-considerations).
I welcome PRs to improve this even further.

> - provide design recommendations to implementers to disable forwarding when click-jacking is suspected

That would work for me.

> - choose API designs that help user agents mitigate these risks, such as
> 
>   - limit scope of functionality to live, user-visible and stable video playback (e.g. of a preview area)

Real, serious risks call for mitigations that work.
Mitigations of unreal risks limit Web developers and users (who would otherwise have benefited of features).
Flawed mitigations, that fail to limit abuse, nevertheless hurt honest Web developers, forcing them to contort their applications into strange shapes, rendering them expensive to develop and maintain.

In the case at hand, the mitigation proposed (("limit scope... to live, user-visible...")) falls short of a robust definition of "user-visible and stable video". This has been discussed in multiple other threads, such as https://github.com/w3c/mediacapture-screen-share-extensions/issues/14.

-- 
GitHub Notification of comment by eladalon1983
Please view or discuss this issue at https://github.com/w3c/mediacapture-screen-share-extensions/issues/24#issuecomment-2459155169 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Wednesday, 6 November 2024 09:48:33 UTC