5 ms·

Wow, I had no idea things worked this way. It makes sense but is also terrifying to think about, that I might be copy-pasting some sensitive data and then accid

Wow, I had no idea things worked this way. It makes sense but is also terrifying to think about, that I might be copy-pasting some sensitive data and then accidentally tab into some app and it'd just ghost-paste the data into its cache.

dan-robertson 5y ago
You don’t need to tab into the app (on a desktop os at least). It’s generally possible to read the clipboard from the background. The app mightn’t even need a visible window.
spiorf 5y ago
> accidentally tab into some app I think in most systems you don't even need to do that. The app should be able to get the clipboard while in the background.
wruza 5y ago
accidentally tab into some app Apps do not even have to be foreground to fetch clipboard contents, afair. On windows, a clipboard is shared with the entire session (i.e. everything that you or the system runs for you after you log on).
progval 5y ago
As other pointed out, you don't even need to tab into some app. The security model on desktop OSs is that by default, every app has access to everything owned by the current user, even memory of other apps or hijacking commands by adding scripts in ~/.local/bin. It is slowly being worked on (on Linux, this is done via control groups (containerization), AppArmor, SELinux, ...) but takes time to carefully tune so legitimate existing apps don't crash because they expect access to something. IIRC, macOS and Windows are also working on this. There is also Qubes OS, taking a more radical approach of isolating everything by default, like Android or iOS. But it can be painful to use, as apps are not designed to support it.
- bryanrasmussen 5y ago
  capabilities based security http://www.skyhunter.com/marcs/capabilityIntro/index.html http://www.skyhunter.com/marcs/capabilityIntro/index.html
  - badsectoracula 5y ago
    > Suppose you were running a capability-secure operation system, or that your mail system was written in a capability-secure programming language. In either case, each time an executable program in your email executed, each time it needed a capability, you the user would be asked whether to grant that capability or not. So Melissa, upon starting up, would first find itself required to ask you, "Can I read your address book?" Since you received the message from a trusted friend, perhaps you would say yes - neither Melissa nor anything else can hurt you just by reading the file. But this would be an unusual request from an email message, and should reasonably set you on guard. > Next, Melissa would have to ask you, "Can I have a direct connection to the Internet?" At this point only the most naive user would fail to realize that this email message, no matter how strong the claim that it came from a friend, is up to no good purpose. You would say "No!" That sounds like a usability nightmare. Also it is something that users ignore even at the coarse level of application permissions on mobile phones - imagine having Every.Single.Action on a computer do that. Instead of just people ignoring those, they'd turn outright hostile to any application doing that.
    - bryanrasmussen 5y ago
      >That sounds like a usability nightmare. sure but any email system should not have to request the capabilities to do any of these things, so basically if a message came in and it started requesting these capabilities - it would only be malicious messages that would do it. This is following the principle of least access/authority http://wiki.erights.org/wiki/POLA http://wiki.erights.org/wiki/POLA
      - badsectoracula 5y ago
        An email client certainly needs the capabilities mentioned there. The ILOVEYOU virus (which is what the page refers to) was an executable (a VBS script but any executable could do the same thing) that asked Outlook Express for the address book and use it to send mail with itself as an attachment. The issue with it was that Outlook Express was too happy to run programs attached to mail (also that Windows hide file extensions by default and... people tend to respond to affection - at the end of the day you can't solve social issues with technical solutions) without even a warning (though a warning would be most likely ignored anyway due to the social aspect of the message - which is also what would happen with the warning in the dialog mentioned in the linked page too). And at some point you'll have to request these capabilities and the user will have to grant them. So the user, as is seen with mobile permissions nowadays that serve more to make developers feel good about providing security and pat each other on the back about how thoughtful they are (meanwhile there is a ton of malware on Android phones), will simply grant the permissions because they want to run the application - the reason they went into obtaining it in the first place. You can see the issue clearly in that infamous video from Linus Tech Tips where Linus tried to install Steam and end up breaking his desktop despite lots of warnings from the system - he had a goal (to run the program) and in the pursuit of that goal he ignored pretty much every warning the OS gave him, including even forcing him to type "yes i know what i am doing". These solutions are pointless and only help to make the programmers who implement feel good that they implemented them. Like the solution to problem above where now you have to make a special file in the root folder to do that, as if someone who ignores everything in the pursuit of a goal to type "yes i know what i am going" aren't going to type "sudo touch /.magic_file" (that they copied from a forum post). The only way to stop people from doing something it to make it technically impossible to do it. But at that point you are starting to make tasks impossible to achieve and people use computers to do things and anything that goes towards that is missing the forest (people using computers to do things) for the tree (some things can be unsafe so let's not anyone do it).

dan-robertson 5y ago

You don’t need to tab into the app (on a desktop os at least). It’s generally possible to read the clipboard from the background. The app mightn’t even need a visible window.

spiorf 5y ago

> accidentally tab into some app I think in most systems you don't even need to do that. The app should be able to get the clipboard while in the background.

wruza 5y ago

accidentally tab into some app Apps do not even have to be foreground to fetch clipboard contents, afair. On windows, a clipboard is shared with the entire session (i.e. everything that you or the system runs for you after you log on).

progval 5y ago

As other pointed out, you don't even need to tab into some app. The security model on desktop OSs is that by default, every app has access to everything owned by the current user, even memory of other apps or hijacking commands by adding scripts in ~/.local/bin. It is slowly being worked on (on Linux, this is done via control groups (containerization), AppArmor, SELinux, ...) but takes time to carefully tune so legitimate existing apps don't crash because they expect access to something. IIRC, macOS and Windows are also working on this. There is also Qubes OS, taking a more radical approach of isolating everything by default, like Android or iOS. But it can be painful to use, as apps are not designed to support it.

bryanrasmussen 5y ago
capabilities based security http://www.skyhunter.com/marcs/capabilityIntro/index.html http://www.skyhunter.com/marcs/capabilityIntro/index.html
- badsectoracula 5y ago
  > Suppose you were running a capability-secure operation system, or that your mail system was written in a capability-secure programming language. In either case, each time an executable program in your email executed, each time it needed a capability, you the user would be asked whether to grant that capability or not. So Melissa, upon starting up, would first find itself required to ask you, "Can I read your address book?" Since you received the message from a trusted friend, perhaps you would say yes - neither Melissa nor anything else can hurt you just by reading the file. But this would be an unusual request from an email message, and should reasonably set you on guard. > Next, Melissa would have to ask you, "Can I have a direct connection to the Internet?" At this point only the most naive user would fail to realize that this email message, no matter how strong the claim that it came from a friend, is up to no good purpose. You would say "No!" That sounds like a usability nightmare. Also it is something that users ignore even at the coarse level of application permissions on mobile phones - imagine having Every.Single.Action on a computer do that. Instead of just people ignoring those, they'd turn outright hostile to any application doing that.
  - bryanrasmussen 5y ago
    >That sounds like a usability nightmare. sure but any email system should not have to request the capabilities to do any of these things, so basically if a message came in and it started requesting these capabilities - it would only be malicious messages that would do it. This is following the principle of least access/authority http://wiki.erights.org/wiki/POLA http://wiki.erights.org/wiki/POLA
    - badsectoracula 5y ago
      An email client certainly needs the capabilities mentioned there. The ILOVEYOU virus (which is what the page refers to) was an executable (a VBS script but any executable could do the same thing) that asked Outlook Express for the address book and use it to send mail with itself as an attachment. The issue with it was that Outlook Express was too happy to run programs attached to mail (also that Windows hide file extensions by default and... people tend to respond to affection - at the end of the day you can't solve social issues with technical solutions) without even a warning (though a warning would be most likely ignored anyway due to the social aspect of the message - which is also what would happen with the warning in the dialog mentioned in the linked page too). And at some point you'll have to request these capabilities and the user will have to grant them. So the user, as is seen with mobile permissions nowadays that serve more to make developers feel good about providing security and pat each other on the back about how thoughtful they are (meanwhile there is a ton of malware on Android phones), will simply grant the permissions because they want to run the application - the reason they went into obtaining it in the first place. You can see the issue clearly in that infamous video from Linus Tech Tips where Linus tried to install Steam and end up breaking his desktop despite lots of warnings from the system - he had a goal (to run the program) and in the pursuit of that goal he ignored pretty much every warning the OS gave him, including even forcing him to type "yes i know what i am doing". These solutions are pointless and only help to make the programmers who implement feel good that they implemented them. Like the solution to problem above where now you have to make a special file in the root folder to do that, as if someone who ignores everything in the pursuit of a goal to type "yes i know what i am going" aren't going to type "sudo touch /.magic_file" (that they copied from a forum post). The only way to stop people from doing something it to make it technically impossible to do it. But at that point you are starting to make tasks impossible to achieve and people use computers to do things and anything that goes towards that is missing the forest (people using computers to do things) for the tree (some things can be unsafe so let's not anyone do it).