Manifest: Forbid browser to take screenshots

[nicofrand]

Hi,

on Android at least, there is a flag, used by banking apps for example, that forbid screenshots to be taken, for security reasons (mainly because another app should not be able to capture a screen with such sensitive data).

I'd expect webapps with similar sensitive data to be able to tell the browser that screen capture should not be allowed when the webapp is used. The webmanifest seems to me like the best approach for that.

Example: I build my own banking webapp, and I don't want other apps on my phone to be able to take a screenshot while I use my webapp.

Thanks for reading.

[kenchris]

That should probably be an API instead. You might allow screenshots of some parts of the app, but not all.

It might be possible to combine with a field in the manifest though. @owencm @PaulKinlan

[raucao]

Same for secure messaging apps, for example Signal uses this as well.

[kenchris]

Are the usages always for the whole app? Or just for some screens? If some vendor is interested in adding support for this, then we can easily add a field to the manifest

[raucao]

Personally, I only know it from the whole app, but I haven't looked into it really.

[nicofrand]

I can't imagine a need for an app to allow only a part of the screen either.

[kenchris]

You can have help and configuration screens which are not sensitive at all. We might be able to do this per scope.

[Schoumi]

The flag is set for the window. The window is the container of Activity. Each Activity or Fragment (part of an activity) is in this window. So it's easier to set it only once for the whole app than only for some Activities (screens) only. It can be remove or set easily but i think if it is set, it's very rare that it is set only for some screens.

[Zykino]

From my experience (Signal messaging app mainly) the restriction is always on. If I want to screenshot the config / a message thread I will unset it, take my screenshot, reset it back on and share my screenshot.

As a user I'm more comfortable when the app never have screenshots enabled (it reminds me of an Android bug: even if Signal used the flag you could have a preview in the recent app list)

And if the app want to have an "easy share page" they could generate an image to download, a PDF or something else.

[marcoscaceres]

I don't thinks iOS supports this at all?

[mgiuca]

Such an API could only be offered on a best-effort basis. Some platforms (most?) won't support it. It can always be worked around by using another browser that doesn't support the feature. On Desktop platforms, you can't really prevent screen-capturing tools from capturing the entire desktop (unless maybe you dig deep into a DRM-video pipeline).

I worry that a) this may be used to stop the user doing what they want (not just preventing sensitive information from getting out, but also as a form of DRM, perhaps triggering a new EME debate), and b) this may lull users into a false sense of security; e.g., trusting that when they send a "self-destructing" message, the recipient will be unable to screenshot it, when in practice there will be lots of ways around it.

[marcoscaceres]

I agree with everything @mgiuca said. This doesn't seem practical.

[g-ortuno]

For b), apps get around it by detecting that a screenshot has been taken and informing the sender. There are still ways around it, but I think they just want to cover the most common, casual case.

But still, I don't think we could reliably fire this event on all platforms. It's sad because some very popular apps do this e.g. Instagram and Snapchat.

[raucao]

1. What's wrong with best-effort? You can do a lot of things on desktop that you can't do on mobile, and vice-versa.
2. There's no DRM issue, because this is a user setting. Similarly, a user can forbid access to the webcam or microphone, so why not allow them to do the same with screenshots on Android, so Web apps have the same capability as native apps there?

[nicofrand]

I totally agree with @skddc.

this may lull users into a false sense of security

Why is Android allowing to do so then ? Are they wrong too ?

[patrickkettner]

outside of the fact that this is trivally worked around and completely security theater, the manifest is not a great place for this concept to live.

It _is_ a somewhat commonly requested feature, I know the starbucks PWA folks were sad about its lack of support. If we wanted to bring the ability to block screenshots on the web, I believe a much better way to go about it would be to expose it as a global cancellable event. Putting it in the manifest feels like a shoehorning it in. @marcoscaceres wdyt?

[nicofrand]

I think the browser should still also allow the user to force the capture if he wants to (maybe toggling a switch temporarily) ? Would that be possible with a global cancellable event @patrickkettner ?

[patrickkettner]

I don't understand the question. The event does not exist today and there
is no way to prevent the user from taking a screenshot either.

Assuming it did exist, I don't imagine any browser adding a toggle to
disable the specific API once it reaches a stable point.

On Sat, Mar 17, 2018, 10:44 AM Nicolas Frandeboeuf [e-mail]
wrote:

I think the browser should still also allow the user to force the capture
if he wants to (maybe toggling a switch temporarily) ? Would that be
possible with a global cancellable event @patrickkettner
https://github.com/patrickkettner ?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/w3c/manifest/issues/661#issuecomment-373910793, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAcaBv74bs1jDRiocp-FxTFdVbssjbc9ks5tfOj5gaJpZM4SmpLb
.

[nicofrand]

When requesting this feature, I should have added that the browser should still allow the user to take a screenshot if she or he wants to (ie. he is aware of the risks). Some apps allow you to disable this "security" for example.

[kenchris]

If the event fails the web app will also know so, unlike with a manifest entry

[mgiuca]

AIUI, there are two use cases for this:

1. Snapchat, etc, protecting "secure messages" that are supposed to be deleted, from being screenshotted by the recipient.
2. Banking and other sensitive-content sites, preventing malicious apps from secretly screenshotting the user's information displayed on the site.

If the browser allows the user to override the API, then it defeats the use case 1, which is protecting the sender from having their information stolen by the receiver (who is our user). Satisfying that use case requires much stricter DRM controls to prevent the user from circumventing it. (Perhaps you literally can use EME for this?)

Use case 2 is protecting the user from their system. I'd say if you have malicious native software screenshotting your apps, then you have bigger problems to worry about (and a browser API to prevent screenshotting is unlikely to help).

For b), apps get around it by detecting that a screenshot has been taken and informing the sender.

That's also necessarily a best-effort thing. You won't always be able to tell if a screenshot was taken; e.g., on Windows I could just have screen recording software running and I doubt the browser can reliably detect that.

What's wrong with best-effort? You can do a lot of things on desktop that you can't do on mobile, and vice-versa.

Because most APIs that are best-effort simply mean a feature isn't working sometimes. If this API fails then you have information leakage (and that's worse than not having the API at all, because then you haven't made any false promises).

a user can forbid access to the webcam or microphone, so why not allow them to do the same with screenshots on Android

That's different. The cam/mic setting is protecting the system from the site. The promise of the web is that sites you visit will not be able to harm or read data from your system, so this is well within the scope of web APIs. This feature request is about protecting the site from the system. It is generally outside of the web's scope from doing so, since native apps generally have unlimited powers and we can't make any guarantee that web apps will be safe from rogue native apps.

Why is Android allowing to do so then ? Are they wrong too ?

I can't speak for the Android platform.

outside of the fact that this is trivally worked around and completely security theater, the manifest is not a great place for this concept to live.

I agree; this should be raised on some other spec. It would presumably be an API, not a manifest flag.

[marcoscaceres]

I think we have consensus that manifest is probably not the right place to do this. Closing, but happy to reopen in light of additional information.

[js-choi]

Those who are still interested in this sort of feature may want to make a new thread in the WICG Discourse forum and post their use cases there.