Hacker News Reader

Comment by darklajid | Hacker News Reader

There is also ongoing work to figure out how best to support taking screenshots of the whole desktop. Users expect the feature, but it has major security implications. If an application can take a screenshot unattended, it can also use that capability to record username/password combinations and other sensitive data. The straightforward solution is to force screenshot capture to require a user to verify the action; that would at least allow the user to detect if an unauthorized screenshot attempt is made.

I know how this will come across, but .. sounds like UAC?

View on HN

There was never anything wrong with the idea of UAC; the problem was the implementation. When the feature was first introduced so many Windows programs did things that caused UAC pop-ups that it because nothing more than an annoying click-through that no one paid attention to. It became nothing more than a default "okay."

The problem wasn't the elevation request itself, it was the amount of requests for a single [user-perceived] action. My record was 5, but a friend managed to get 7 requests in early Win Vista... I wish I could remember what for.

I don't know... we've generally used suid binaries for this in the past? I suppose the display server will run as root, so the sane approach is to add a screenshot api, possibly writing the screenshot to a file/folder/socket with special permissions? ("special" because the gist here seems to be a wish to limit capabilities more finely than traditional unix user/group/others -- after all the user has access to the whole desktop (say with a digital camera) -- so the goal here is apparently to limit which applications can access other applications. At any rate, root should be able to read all process' memory, so taking a screenshot shouldn't be a problem... (I'm not saying take a screenshot by reading video memory, just that the level of access is equivalent).

Could another approach be to allow applications to flag a graphical element as secure and it will be excluded from any attempt by another process to read the screen? Don't even allow the superuser to take screenshots of passwords, credit cards, etc. They'll just show up as a black box.

Don't even talk about not allowing something to superuser. It could be nontrivial to enable though.

And that is perfectly fine by me. There's a very limited subset of features which would require this kind of explicit authorization.

Sure, but UAC doesn't have to be as badly designed and implemented as it was in Windows. Allan Day has some great plans for adding this to GNOME: http://blogs.gnome.org/aday/2014/07/23/sandboxed-application...

An application can do all kinds of shit, can't it? It could probably replace your Browsers icon with an icon that starts a custom version of your Browser which uploads everything you type to some server.

Which is why we¹ are working on sandboxed apps.

https://news.ycombinator.com/item?id=8219309

¹I say "we" as in DE developers, I'm not a GNOME dev.

yeah, something like that. I guess it'd be cool if you could just whitelist applications to do stuff, and have others pop out when requiring the permission.

Sounds like a security hole: non-whitelisted malicious app launches whitelisted app as an external process, and then mayhem ensues.

User permission should be required when launching external processes.

And whitelisted processes don't have to take input from anything other than the user himself; a command-line screenshot tool that can be run by any program and doesn't ask for interactive confirmation through a trusted channel (ie. keyboard events directed into its own window by the compositor itself) would be a pretty stupid thing to whitelist unless you've got proper sandboxing for any untrusted apps.

Reply on news.ycombinator.com