Prevent Screenshots in PWAs

[yashrajbharti]

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.

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

• Android's Screen Capture API
• DRM-based applications like Netflix, which restrict screenshots through hardware and software combinations.

[benfrancis]

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.

[yashrajbharti]

Thanks for the feedback!

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.

I agree from the UX point, one of the cons of the feature would be if this gets used way too much for the most irrelevant reasons. This is also why making web apps for Banking might be the right use case.

I hope this gets done carefully with approach to move forward without hurting the users, as well as possible solutions for businesses.

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

I agree with this too, even DRM can be cracked through and one can still take pics, not to mention external devices just like a user's eyes. While this is true, the native app features are not going anywhere, and I would love to take an approach forward where web can implement this for the purpose of security.

[benfrancis]

Follow-up question: If this was a feature of a web app manifest which is only applied when installing a web app, wouldn't that mean that the restriction doesn't apply when the web app is not installed (i.e. just loaded in a web browser). So rather than progressive enhancement (as per the PWA term you used), installing the app would take features away?

[christianliebel]

@yashrajbharti Thank you for your suggesting this feature.

I don't think the Web Application Manifest is the right place for this functionality. As @benfrancis pointed out, the feature would only work if the manifest is applied, i.e., if the app was opened from the home screen, dock, or taskbar. Moreover, limiting this functionality to specific routes might not be suitable, as some pages may need to only temporarily prevent screen recordings (e.g., while entering sensitive information like credit card details) without having to change the route.

I suggest you submit this feature proposal to the Web Incubator Community Group (WICG) proposals repository. The WICG is the appropriate place to discuss potential web features like this one and determine whether such a capability should be adopted at all, as @benfrancis raised.

As the request doesn't really align with the Web Application Manifest, I will close this issue. Thank you for your contribution and feel free to reach out if you have any other questions.

[yashrajbharti]

I see, I shall try to understand how this feature could, if at all, help the web and propose a WICG proposal, thanks a lot for such a detailed answer, @christianliebel.