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 Screenshots in PWAs #1154

Open
yashrajbharti opened this issue Dec 23, 2024 · 1 comment
Open

Prevent Screenshots in PWAs #1154

yashrajbharti opened this issue Dec 23, 2024 · 1 comment

Comments

@yashrajbharti
Copy link

Abstract

This proposal explores adding a feature to the Web Manifest that would allow developers to prevent screenshots of specific PWA screens. The functionality aligns with native app behaviors like Google Pay disabling screenshots on payment pages or WhatsApp restricting profile page captures. While the implementation for the web has complexities (e.g., bypassing DRM on Mac by disabling CSS hardware acceleration), PWAs can leverage secure APIs to emulate native app security.

Google Pay HomePage Google Pay Screenshot not allowed Netflix

Background and Motivation

Native apps commonly use features like Android's FLAG_SECURE or DRM to protect sensitive information from being screenshotted. Implementing similar behavior for PWAs would provide a more secure and privacy-conscious user experience, especially for financial transactions, private messages, or sensitive media.

Proposed Solution

  • Add a new attribute in the Web Manifest, e.g., "screenshot-protection": ["page1", "page2"].
    • Developers can specify an array of page routes or URLs within the PWA where screenshots should be disabled.
    • The browser, upon detecting these routes, disables screenshots or screen recording for the specified pages.
  • Leverage platform-specific APIs (e.g., Android's Screen Capture API and FLAG_SECURE) to implement this functionality.

Challenges and Scope

  1. Cross-platform Differences:
    While mobile platforms like Android support APIs for screenshot prevention, desktop platforms (e.g., macOS) present challenges due to the potential for bypassing using developer tools or hardware configurations.

  2. Web DRM Complexity:
    Implementing DRM for web-based applications has historically been difficult and may require additional considerations for PWAs.

  3. Developer and User Expectations:
    Balancing security with usability is critical to avoid over-restrictive or intrusive behavior.

Future Considerations

  • Explore how this feature can integrate with existing DRM technologies to safeguard media.
  • Evaluate browser-level implementation feasibility across platforms.
  • Investigate potential mechanisms for developers to dynamically enable or disable screenshot protection based on runtime conditions.

References

@benfrancis
Copy link
Member

This is entirely anecdotal feedback from a user perspective, but I find these kinds of restrictions on native mobile app platforms incredibly irritating and trivial to work around (e.g. by just taking a photograph of the screen). It's a bit like the flawed attempts to prevent right clicking on images on web pages to prevent them being downloaded - irritating for the user and trivial to work around for someone with a little knowledge of how the web works.

The main use case I have seen for this (other than Netflix) is preventing screenshots inside banking apps, which is a genuine use case that shouldn't be taken away from users IMHO. It results in the silly situation of having to submit a photograph of a phone screen in an expense claim for example.

I understand there's an argument that some companies may choose not to use the web platform due to the absence of this feature (which is available on native app platforms), but I really think they're just fighting against the laws of physics - in that generally speaking if you can see an image with your eyes then it can be captured by a camera. At best it increases user friction as a weak mitigation of a perceived threat to a corporate interest, but rarely benefits the end user (which is ultimately who a "user agent" should represent).

Apart from that, I'm of the opinion that DRM should be kept away from the web platform as much as possible, since it's the antithesis of the open nature of the web.

Just my two cents.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants