4 ms·

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 implic

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?

aroman 12y ago
And that is perfectly fine by me. There's a very limited subset of features which would require this kind of explicit authorization.
adestefan 12y ago
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."
- vacri 12y ago
  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.
dethstar 12y ago
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.
- mercurial 12y ago
  Sounds like a security hole: non-whitelisted malicious app launches whitelisted app as an external process, and then mayhem ensues.
  - jhasse 12y ago
    User permission should be required when launching external processes.
    - wtallis 12y ago
      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.
itry 12y ago
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.
- scrollaway 12y ago
  Which is why we¹ are working on sandboxed apps. https://news.ycombinator.com/item?id=8219309 https://news.ycombinator.com/item?id=8219309 ¹I say "we" as in DE developers, I'm not a GNOME dev.
e12e 12y ago
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).
catern 12y ago
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-applications-for-gnome-part-2/ http://blogs.gnome.org/aday/2014/07/23/sandboxed-application...
whoopdedo 12y ago
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.
- ansgri 12y ago
  Don't even talk about not allowing something to superuser. It could be nontrivial to enable though.

aroman 12y ago

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

adestefan 12y ago

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."

vacri 12y ago
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.

dethstar 12y ago

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.

mercurial 12y ago
Sounds like a security hole: non-whitelisted malicious app launches whitelisted app as an external process, and then mayhem ensues.
- jhasse 12y ago
  User permission should be required when launching external processes.
  - wtallis 12y ago
    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.

itry 12y ago

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.

scrollaway 12y ago
Which is why we¹ are working on sandboxed apps. https://news.ycombinator.com/item?id=8219309 https://news.ycombinator.com/item?id=8219309 ¹I say "we" as in DE developers, I'm not a GNOME dev.

e12e 12y ago

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).

catern 12y ago

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-applications-for-gnome-part-2/ http://blogs.gnome.org/aday/2014/07/23/sandboxed-application...

whoopdedo 12y ago

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.

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