Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Prevent unintentional leaks #6

Open
NDevTK opened this issue Apr 24, 2022 · 17 comments
Open

Prevent unintentional leaks #6

NDevTK opened this issue Apr 24, 2022 · 17 comments
Labels
enhancement New feature or request

Comments

@NDevTK
Copy link

NDevTK commented Apr 24, 2022

It seems currently this API exposes the contents of all website with just a attacker controlled navigation.

I think if websites had the global screen recording state maybe via navigator.mediaDevices.isRecording they would be able to implement privacy protections.

  • Warning about a navigation causing emails to be listed when recording and using "Sec-Fetch-Site cross-site"
  • Redact notifications (I think discord already attempts to detect screen recording on the desktop app)
  • Allows banks to panic.

Should probably also be an option to bypass it.

I would be surprised if this was a valid issue and I did understand the API correctly.

@eladalon1983
Copy link
Member

eladalon1983 commented Apr 25, 2022

The general problem is that exposing "you are being recorded" allows websites to self-censor even against the user's wishes. What if the user is making an informed decision to share their bank situation with an out-of-town spouse, parent or other trusted individual? If the Web does not offer the user a mechanism to share, then that user will install a native application to achieve this goal. Or they would share their password with that person...

@eladalon1983
Copy link
Member

eladalon1983 commented Apr 25, 2022

Zooming in on the concern over navigation, I have previously suggested, and still support, that the user agent should re-prompt the user for validation of "I still want to keep on sharing this" when the shared tab is navigated. (I believe this new behavior should be app-controlled at first, and we can discuss tightening the screws and making it mandatory later.)

@youennf
Copy link

youennf commented Apr 25, 2022

It seems worth listing the potential downsides for both choices.

If exposing the state, we can end up with website censoring what is being captured.
The workaround is to select the UA window instead of the UA tab, or to capture the UA tab as a window surface.

If not exposing the state, the website might expose very sensitive information like bank credentials, login windows...
There might be more use cases like this and it would be worth enumerating them.
Prompting the user on navigation/cross origin navigation might solve part of these use cases, probably not all of them.

@eladalon1983
Copy link
Member

Prompting the user on navigation/cross origin navigation might solve part of these use cases

Agreed.

probably not all of them.

Agreed.

@NDevTK
Copy link
Author

NDevTK commented Apr 26, 2022

Only asking on navigation might mean stuff like .focus() .close() .moveBy .moveTo may be abused to show information the user could not see such attacks seem to need a entire screen recording but thats strangely the first option on chrome.

And it also would not affect information that is shown later like notifications (unless a confirmation API existed) or allow for redacting just parts of the page like hiding password or API keys that are set to be visible.

However having confirmation on cross-origin navigation would probably be less work for web developers and would need to exist as an opt in alternative for websites that try to abuse knowing the state.

@eladalon1983
Copy link
Member

The problem originally stated in this issue appears to me unassailable. Curtailing the user's ability to capture arbitrary content would drive users away from the Web platform and towards native applications. Furthermore, which browser will implement that limitation first? That browser will lose users to competing browsers.

The user is king, and is rightfully accustomed to being obeyed. If the user wants to capture their bank, that is the user's prerogative. The browser can, however, make doubly sure that the king's orders were correctly understood...

@NDevTK
Copy link
Author

NDevTK commented Apr 26, 2022

Im not trying to prevent the user but before showing an API key or the users emails that where navigated to from cross-site there should be some user acknowledgement unless not wanted.

Hiding parts of the UI means screen recording can still be done without sharing all the information from the site but the browser should make it an optional feature.

I think navigation attacks are more important however and agree there should be a confirmation for navigation when cross-origin maybe it should also include when a window becomes visible to avoid attacks with .focus();

@eladalon1983
Copy link
Member

I think if websites had the global screen recording state maybe via navigator.mediaDevices.isRecording
...
Im not trying to prevent the user

Regardless of our intentions, if we make it possible for a website to censor itself rather than be captured, some websites will use this mechanism, sometimes against the user's wishes, and we will be limiting the user. Some users will come out with the impression that "screencapture on browser-X Just Works™, but on browser-Y it keeps breaking." Users will be upset, browser-Y will roll the feature back, and browser-X will end up with a few new users.

@NDevTK
Copy link
Author

NDevTK commented Apr 26, 2022

I understand the issues with sharing the state. (would have needed a permission)
Is there a better solution to the navigation issue?
It would be a nice feature if users could protect a website and its notifications from being shared.

Updated title to reflect the concern instead of my bad idea to prevent it.

@NDevTK NDevTK changed the title Consider exposing screen share state to websites. Prevent unintentional navigation leaks Apr 26, 2022
@NDevTK NDevTK changed the title Prevent unintentional navigation leaks Prevent unintentional leaks Apr 27, 2022
@eric-carlson
Copy link

I think if websites had the global screen recording state maybe via navigator.mediaDevices.isRecording they would be able to implement privacy protections.

Without commenting on the advisability of exposing capture state to a page, it might be better to do it via a CSS media query feature so it can be used from CSS and JavaScript.

@NDevTK
Copy link
Author

NDevTK commented Apr 27, 2022

Yeah something dynamic like media query or have an event In terms of advisability I think it would require opt in per origin.
The user would have to perform an action but then the alternative of confirmation on navigation's would require more actions.

@josephrocca
Copy link

josephrocca commented Oct 14, 2022

Just want to chime in here to say I agree that:

  • Unintentional leaks are definitely an issue worth trying to solve.
  • It's probably not a good idea to let a website know that it's being recorded.

But what about allowing a web page to mark itself, or elements of itself as being "sensitive". Then the user can e.g. click a checkbox next to the "Stop Recording" button to censor elements/pages that have declared themselves as being sensitive (maybe it's checked by default).

Not sure how practical that specific suggestion would be, and there are issues to consider like users having a false sense of security when they have checked the "censor sensitive info" checkbox (i.e. they don't realise that some websites might not have implemented the sensitivity feature), but it's perhaps another direction to consider here.

Edit: Oh, I've just realised that there might be a version of Eric's CSS media query suggestion that would be basically equivalent to what I'm suggesting here? Assuming it's not possible for JS to access CSS media query state? Like how you can't detect whether a link is "purple" (visited) with JS.

@bradisbell
Copy link

It should not be up to the user agent to decide what the user can't share. There are already far too many hurdles to simple tasks such as screen sharing. Additional dialogs requesting or confirming the user's choice are a bad user experience as they create additional friction and confusion. Confused and frustrated users are much more likely to click through to bypass dialogs without understanding them.

Users are responsible for what they intentionally choose to do. The user agent is responsible for acting on behalf of the user at the user's request. If a user intentionally shares their entire screen or other display surface, it is not up to the user's agent to add its own intent by hiding what it thinks is "sensitive". It is fundamentally impossible for the user agent to know the full context of what the user wants. Therefore, the user agent should trust the demonstrated intent of the user.

That is to say, if a user clicks "share screen", it is not the user agent's place to question this action.

@NDevTK
Copy link
Author

NDevTK commented Oct 14, 2022

If a user intentionally shares their entire screen then thats fine this is about unintentional leaks.
If a user clicks a button to hide sensitive content as defined by the website that seems opt in.
The browser can detect if content has been made hidden and the user would obviously be allowed to opt out.

@NDevTK
Copy link
Author

NDevTK commented Oct 14, 2022

Like how you can't detect whether a link is "purple" (visited) with JS.

You can on chrome no user interaction needed they would normally pay 5K for it :/
https://bugs.chromium.org/p/chromium/issues/detail?id=713521

@shreyaskaundinya
Copy link

Any updates on this issue?

Would help content creators in protecting their Intellectual property + digital rights of content if the website had context/state about media capture.

@NDevTK
Copy link
Author

NDevTK commented Jan 23, 2024

I think websites preventing what the user wants such as for DRM is why this feature is not added. I guess video DRM already does prevent screen recording not that sure on the state of it.

@jan-ivar jan-ivar added the enhancement New feature or request label Jan 23, 2024
@dontcallmedom dontcallmedom transferred this issue from w3c/mediacapture-screen-share Feb 23, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

8 participants