Address click-jacking concerns

[jan-ivar]

In https://github.com/w3c/mediacapture-surface-control/issues/48 ~we seem to agree~/lists ~serious~ click-jacking concerns [that] remain with this API.

Undesirable behaviors:

• Attempts to click-jack scrolling input from the user, through techniques such as
  • div covering entire page
  • transparent element
  • element following the mouse
  • element larger than visible preview video
  • element not visible to the user
• Attempts to induce over-scroll
  • no preview video
  • delayed preview video
  • inauthentic preview video

Also https://github.com/w3c/mediacapture-surface-control/issues/48:

• Pop a video element where the user was already scrolling.
• Have the video already there, but obscured by another element, then remove the obscuring element.

[IMHO] Permission prompts have shown to be useless in explaining click-jacking threats to users. If users can't understand the risk then we have not obtained meaningful consent.

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
• provide design recommendations to implementers to disable forwarding when click-jacking is suspected
• 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)

[eladalon1983]

we seem to agree serious click-jacking concerns remain with this API.

I disagree with this characterization of the discussion in w3c/mediacapture-surface-control#48.

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

As has been explained here, this misrepresents the intention of the prompt, as well as the discussion around potential attacks.

[jan-ivar]

I've edited the OP to not assume agreement.

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

As has been explained https://github.com/w3c/mediacapture-surface-control/issues/48, this misrepresents the intention of the prompt, as well as the discussion around potential attacks.

This is my statement, and isn't meant to represent anyone else's intention or discussion. Clarified with "IMHO"

[eladalon1983]

Thank you.

[eladalon1983]

In w3c/mediacapture-surface-control#48 (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 and then this comment.

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. 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-surface-control/issues/48.

[eladalon1983]

Issue transferred; heads up to those discussion participants who might otherwise be looking for it elsewhere: @jan-ivar, @youennf

[jan-ivar]

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

What mitigations?

The threat vector would be a malicious website that cajoles the user into sharing a tab of interest, then "attempts to click-jack scrolling input" to "induce over-scroll" or hijacks zoom controls to zoom all the way out. Both are means to attempt to capture as much of the document as quickly as possible.

If the captured tab is a google doc or presentation, the difference between capturing the first slide and the entire doc can be substantial, and lost on the casual user.

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-surface-control/issues/48.

I think you're jumping ahead here. I think we should be able to agree on the problems before discussing solutions.

Between this and #48 we should be able to agree on the threats. Because without threats there's no need for permission either.

None of your links work BTW.

[eladalon1983]

What mitigations?

The ones listed here.

The threat vector would be a malicious website that cajoles the user into sharing a tab of interest, then "attempts to click-jack scrolling input" to "induce over-scroll" or hijacks zoom controls to zoom all the way out. Both are means to attempt to capture as much of the document as quickly as possible.

The risk/reward trade-off here seems quite favorable; I would NOT classify the threat as "serious". I might even go so far as to label it "mostly theoretical". A hypothetical attacker needs to:

1. Get the user to load the malicious application.
2. Get the user to approve the capture of something.
3. Make sure the user shares something of relevance to the attacker.
4. Get the user to approve a permssion prompt for zooming and scrolling.
5. Get the user to scroll over the capturing app or click an element in the capturing app.
6. (This attack obviated if the content of relevance is already visible.)
7. (This attack obviated if the content of relevance is not reachable through scrolling or zooming.)

Theoretically? Yes, there is some new vector of attack here. But in practice? I am not concerned; this is not an appreciable increase in attackers' capacity to do users harm. While we can debate the benefits of additional mitigations, it's not a blocking issue; we have enough mitigations as-is.

None of your links work BTW.

That's the result of moving the repo from the SCCG to the WebRTC WG. I have now updated some of the comments on this thread. If you run into remaining ones, please s/screen-share/w3c and s/captured-surface-control/mediacapture-surface-control, and they'll work for you. Links to specific comments within threads, however, can only be restored manually; if you run into one that you're unsure of, ask me and I'll do my best to reconstruct what it used to point to.