Replying to Avatar Ava

nostr:nprofile1qqsyvrp9u6p0mfur9dfdru3d853tx9mdjuhkphxuxgfwmryja7zsvhqpzamhxue69uhhv6t5daezumn0wd68yvfwvdhk6tcpz9mhxue69uhkummnw3ezuamfdejj7qgwwaehxw309ahx7uewd3hkctcscpyug AFAIK, #Nostr clients currently lack native functionality to prevent AI tools like Gemini from accessing mobile users' screens—unlike some other apps I've used recently. I think it would be a solid feature to add to #Amethyst. What do you think?

Hum.. i am not sure there is a way to prevent it if the OS is controlled by Google. You have to install graphene to get out of it. 🤔

Reply to this note

Please Login to reply.

Discussion

There must be. I'm running Google Android 15 on Pixel 9 Pro XL for my daily driver, and there are some apps where I get a notification saying access to the app screen is disallowed if I try to scan it.

For example: PayPal Business app

Yeah, bitwarden does this on my stock 8 pro.

Very likely, but please keep UX and convenience in mind. It's annoying AF if you want to take a screenshot or record a screen video, because you have to use scrcpy or other tools. I would reserve this only for the most private screens of Amethyst—if bothering with it at all... On the end there is Amber.

I've sent a Fediverse link because I recently lost the images at my Blossom server.

(🪦)

GrapheneOS is popular because it’s privacy-ready out of the box—sane defaults mean users don’t have to harden everything themselves.

Yes, the process you linked to is a stop-gap solution, and thank you for sharing, but having a default toggle in Amethyst to block screenshots, Circle to Search, and similar features (like Apple’s) would prevent accidental data leaks.

You would be surprised how many people still screenshot their keys/seed phrases etc. because they don’t realize Google/Apple scan photos, much less build-in AI screen scanning technology. Not everyone is technically literate, or know much about good OPSEC.

When dealing with sensitive information, basic privacy features should be a default, not a bonus feature that needs the user to enable it—that is the kind of thinking that doxxed so many users messages on Telegram (they didn't know they had to manually enable E2EE and that it wasn't enabled by default).

A built-in toggle (enabled by default) preventing screen access would boost privacy, just like Amethyst’s Tor integration avoids IP leaks when users forget to reenable VPN/Orbot.

To me, this would be a sane default—the same way this app screen privacy protection is enabled by default in Banking apps and privacy messengers. If they user wants to take a screenshot, then they can temporarily disable it, or disable it for good, but in my opinion it should be enabled by default.

Privacy in the age of AI should not be an afterthought or a bonus feature hidden in settings—or worse, non-existent as an in-app setting, or something one has to dig into Google/Apple settings to restrict.

#Amethyst has always put user privacy at the forefront. This feature would not permanently affect UX, it would simply allow users greater control over who and what has access to their data out of the box.

Got it. I fully understand where you’re coming from and support your point of view with my own habits (as per my post above).

On the other hand… the same normies you’re talking about would very likely bother Vitor and other Amethyst mantainers about why they can't take screenshots of their social media app by default... Seriously, I've been there, it's hard enough to get family members to use a password manager; it took me ages to get them onto Signal, etc. I know this sounds awful to anyone into tech and privacy, but the default response from most people is: they don’t care because "they have nothing to hide". The average user picks convenience every time.

My take on this is: maybe always enable FLAG_SECURE for windows dealing with nsecs, payment-related stuff, etc. The toggle is also a great idea, it can be displayed on first login as well as at the very top of the configuration settings.

But IMO, and I understand this might be disappointing, I fully expect most people to disable FLAG_SECURE if it was the default for regular Amethyst windows. And from a usability angle, we'd circle back to imposing defaults that users don’t want but are good for them (the "Eat your broccoli" toggle). I hope this makes sense.

Thank you for contributing to the discussion. I appreciate your perspective, and I am inclined to agree with you.

The social media component lends itself to screenshots. At the very least, disabling screen access to the most sensitive areas (nsec, payment-related features, DMs, etc.) by default would be a viable solution.

This could be paired with a toggle or slider in settings, where users could set one of three options:

- least private (allows access to all screens)

- default privacy (denies access to screens with sensitive data)

- maximum privacy (denies access to all screens)

...allowing users to screenshot freely while maintaining privacy for sensitive data, keeping everyone happy.

Either way, it’s clear that we need something. The average end user is not going to dig into Google/Apple settings an harden AI access to apps individually.

This is why I opened the discussion.

The current default of allowing unrestricted AI access to all app screens has become an unnecessary liability—and one that could be easily rectified in the same way Amethyst increased user privacy and security by baking-in Tor, giving users control over the auto-loading of media etc.

That said, I've said my peace. I hope Vitor considers this feedback and decides to incorporate it in a future Amethyst release.

You are right, I was thinking that FLAG_SECURE can't be changed by user input and it is something "compiled" into the app, but that is not true. So yes, Amber should have this option 100% and it would be nice to have in Amethyst as well.

ohhh I see what you mean now.. The flag doesn't block AI, it just blocks the screenshots. The AI is still running over other things, like keyboards, cameras, pictures saved in the device, etc.

Yes, it is my understanding from the official Android documentation that:

"FLAG_SECURE is a Window flag that tells Android not to allow screenshots or to display the window view on a non-secure display"

And for HIDE_OVERLAY_WINDOWS: "your app can opt-out of having application overlays drawn over it... essentially allowing your app to block overlays from third-party apps."

These protections directly impact Gemini since it works by "activating an overlay experience that tells Gemini what is on their screen."

When FLAG_SECURE is enabled, the system prevents any screen content capture—which effectively blocks AI assistants from analyzing protected screens.

These protections are designed to work regardless of how integrated Gemini is with Android.

It's worth noting that while FLAG_SECURE/HIDE_OVERLAY_WINDOWS block standard Gemini access, technically sophisticated users could grant Gemini elevated privileges (e.g., accessibility services). However, this requires manual user action, not automatic integration.

The keyboard/camera concerns are separate issues that don't negate these protections for actual screen content.

Could be the same feature that prevents screen shots of apps.

But we like screen shots!

I don't think Graphene has any control over this on behalf of apps. It has normal screenshots unless the app specifically doesn't allow them. My banking app blocks them by force and Molly (Signal) does by default but has a toggle.

But software toggles can just be ignored by an OS. You wouldn't know if a closed software was ignoring it, nor could you reasonably verify the source even if you were skilled to.

These privacy switches are a complete farce beyond trust. They may or may not work. I trust that Graphene isn't ignoring them, but they could be. I absolutely wouldn't trust Google one way or the other. But Amethyst should have the toggle either way in my opinion. People could choose. The debate over convenience is totally moot.