7 ms·

As an old person my assumption is that a desktop app can basically do whatever it wants with the screen, mouse, keyboard, or audio while it's actually running.

by CPLX 9y ago

As an old person my assumption is that a desktop app can basically do whatever it wants with the screen, mouse, keyboard, or audio while it's actually running. Isn't that what apps are for? This just seems like expected behavior. If you don't want apps doing stuff don't run them on your desktop computer.

comex 9y ago
The sandbox is designed to make that not expected behavior - even if, as demonstrated here, it has holes…
- threeseed 9y ago
  Since when ? OSX has never outlawed this sort of thing. The sandbox has always been completely different from iOS e.g. it doesn't ask permission to access photos, microphone, webcam.
  - igloofoo 9y ago
    Wrong. 1) Your webcam turns a light on. Not permission, but you know what's going on. 2) "People must grant permission for an app to access personal information, including the current location, calendar, contact information, reminders, and photos." https://developer.apple.com/macos/human-interface-guidelines/user-interaction/requesting-permission/ https://developer.apple.com/macos/human-interface-guidelines...
    - threeseed 9y ago
      Those are if you are using the APIs directly. But you can always go straight to the files themselves for cases like Photos and Calendars and also to the SQLite databases that back a lot of user data. And current location is easy to get on OSX. You can simply look up the user's IP address and WiFi networks to triangulate the user's location with about the same accuracy as Apple can do. With webcam you can easily switch the camera on, take the photo and switch it off. Could easily trick people into thinking it was a hardware fault rather than something nefarious with the app. The fact is that none of what I listed above is possible on iOS.
      - MaxGabriel 9y ago
        Aren’t the files outside of your app inaccessible from within the Sandbox, unless you give the app permission to read them? I mostly use non Mac App Store apps but one I use, the Unarchiver, needs permission to open files
      - kakarot 9y ago
        If my webcam light ever flickered on and then off, I'm chucking my laptop off the side of a bridge. Willing to be most other people wouldn't attribute it to a hardware fault, either.
        CodeWriter23 9y ago
        You could just cover it with a post-it instead of chucking it off a bridge. The thing that bugs me is there’s no indication an app is connected to my microphone.
        kakarot 9y ago
        Thing is, at that point I'd be worried about the mic as well, as you point out. Better safe than sorry!
        CodeWriter23 9y ago
        Touché
      - jakobegger 9y ago
        That stuff is not possible if you have a sandboxed app from the Mac App Store. Sure, if you download software from the web, it can do whatever it pleases. But if you download apps only from the Mac App store, you should be safe. On iOS, Apple checks all your software. On the Mac, they give you a choice: If you want "safe" software, go to the Mac App Store. If you want any software, go somewhere else. The sandbox isn't as complete as on iOS, but the stuff you listed requires special permissions and confirmations when you get your software from the Mac App Store.
krisives 9y ago
Even HTML5 web capturing works in a similar way. Once you give an site like Discord access to your microphone or screen it can pretty much access it whenever the page is open - granted it will show a little badge on screen by default. A lot of users got tired of the on-screen badge being on all the time and probably set it to hidden (very easy to do) so not everyone is actually aware of when an HTML5 application is accessing a microphone/camera/screen.
- danieldk 9y ago
  A small aside: on the Mac, Micro Snitch [1] can let you know about any app that accesses the mic or webcam. It can use overlays, notifications, and/or just the systray to indicate that an app is using the mic/webcam. It also has an activity log that can you show past use. [1] https://www.obdev.at/products/microsnitch/index.html https://www.obdev.at/products/microsnitch/index.html
userbinator 9y ago
I agree. This feels to me to be more like inducing paranoia to push some hidden agenda. The "open" design is a feature, not a bug, and why mobile apps and their isolated design only encourage silo'd data and horribly wasteful workarounds (upload something from one app into some distant third-party cloud service, and download it again for another app to access it... provided those two apps' developers have explicitly decided to provide such a feature.) Every binary I run could delete all my data or steal my passwords or whatever else. That's not something to be afraid of --- it's something to cherish and be proud of[1], and it's why you don't run anything you don't trust. This "free-for-all" sharing and access encourages the sort of ad-hoc and unpremeditated interactions which are beneficial to the software ecosystem as a whole. I usually have a magnifier, color identifier, and clipboard-listening-translator running. None of those would be easily implementable or may not even exist, had computers started out as locked-down systems from the beginning. [1]https://boingboing.net/2012/08/23/civilwar.html https://boingboing.net/2012/08/23/civilwar.html
- abecedarius 9y ago
  There's a difference between locked-down-by-Apple and locked-by-you according to your own choices (e.g. Qubes). Being able to run software from others without being completely vulnerable to them is essential to that open ecosystem we want. A free-for-all OS is like a meatspace without private property -- it can work at a small scale.
- marcoperaza 9y ago
  A design that dooms even savvy users to being compromised is simply not acceptable anymore. Most people are not discriminating enough about the software they install. But okay, maybe you actually are and never make mistakes[1]. But is all the software you use signed? By a certificate traceable to a real, accountable person? Can a software update, perhaps released by someone who has hacked the original developer, come along and turn it into malware? Because all of your apps have full-capabilities, it can now do things that you would never grant if explicitly asked. Now you're completely screwed. All of your emails, pictures, medical information, other embarrassing personal information/media, bank logins, and so forth are compromised. Maybe you have two-factor authentication for all of your accounts (doubtful), but who cares? It can just read the memory of your browser process, quietly wait for you to login to the various services, and then hijack your sessions in the background. So tell me: how in the world is this an acceptable situation? [1] I sure hope you never use any of these new-school package managers for various programming languages, text editors, and such. You know, the ones that grab the latest commit from GitHub repositories run by total strangers and then run them with full privileges.
fadzlan 9y ago
My thought exactly. I was like yes of course! How does he think that desktop app can do many different things? Now, sandbox is a different issue. But of course, yes it have access to the screen. If apps on desktop is going to be as restrictive on mobile, why use desktop at all?
cesnja 9y ago
Much work is being done on Wayland compositors and window managers to change this. Among other expected results are also the security aspects where the user is able to know which program is reading certain inputs and outputs, and might be able to control this data. As a basic example, a desktop app is only able to read/write the pixels inside the rectangle assigned by compositor, and it only receives keyboard events and mouse clicks that were sent inside this rectangle. I think this is an assumption one could make about a modern desktop. Sadly not enough users care about this type of security, so we stick to the old, X11 style of altruistic desktop computing where every program can see everything.
- cududa 9y ago
  Couldn’t you just hook the wayland compositor to detect where focus is and eat up all those inputs?
osteele 9y ago
I submit that the macOS interface leads to a reasonable expectation of greater security than an old-school executable running in the 90's or 00's, because macOS requires that the user explicitly grant permission to access so many other sensitive resources, such as location and contacts. If an app has to ask me permission in order to access my keystrokes, I think it's fair to assume that the same would be true of apps that read (anything outside their window regions) from my screen. The fact that macOS doesn't require this is discoverable by sleuthing (browsing the Privacy pane, or remembering that screenshot apps don't ask for it), but there's reasonable, and probably common, mental models that don't make it obvious. It would be like renting a house with four locks on the front door and none on the back. Yes, you could audit the house, but it's a weird asymmetry to have to look for. (P.S. I'm older than you, FWIW :-)
- clebio 9y ago
  Are you talking about High Sierra, or iOS devices? Because this just isn't true about my macbook pro running Sierra. There is no granular permissions model as in, for instance, Android 7. I give my (super) user password to install apps on my mac, and then after that, they run. There's no further permissions I can or can't grant, and there's no way to run install many desktop apps without my (super) user password. Edit: It seems you a many of the others replying to the GP are talking about apps from the App Store, which I basically never use. And that's sort of the parent's point, I think. I get apps from the internet, install them, and use them, like and old-school desktop/PC computer user. I rarely need to use the app store (except for updates, and it's weird UX that OS updates are in the app store to begin with) and have no compelling reason to do so.
  - osteele 9y ago
    I'm talking about High Sierra, and apps loaded from App Store or non-store download links. For example, System Preferences > Security & Privacy > Privacy > Accessibility lists (among others) “Backup & Sync from Google”, BetterTouchTool, Dash, Dropbox, Google Chrome, Google Software Update, Keyboard Maestro, Little Snitch Agent. Many of these aren't even available from the app store. If I keep Accessibility unselected, some of these have degraded functionality. For example, I keep the Google apps and Dropbox unchecked, and then they can't annotate my Finder icons. (I'm okay with that.) I keep Dash unchecked, and keyboard snippets don't work. You're right that this isn't super fine-grained. This single checkbox seems to govern several unrelated things, such as keystroke logging and insertion (Dash and Keyboard Maestro), mouse recording and control (Keyboard Maestro), and whatever APIs are used to badge Finder icons (Google and Dropbox). My belief is that an app that I haven't checked off there doesn't have access to my keystrokes. (Maybe this is wrong?) In which case I'm surprised there's nothing like this for recording the screen.
mwfunk 9y ago
Sandboxing isn't to prevent people from damaging their own computer (i.e., the "sudo rm -rf /" case), it's to impose a ceiling on how much damage can be done by an exploited process that the user doesn't realize has been exploited. It's not to save you from yourself, it's to save you from stuff that you wouldn't otherwise have any way of knowing was even happening. Sandboxing restrictions are more like using asserts in your code than anything else- they only stop programs from doing things that the programs themselves are stating that they would never attempt to do. Having said that, plenty of useful apps can't ship in sandboxed form because of limitations in the current sandboxing model. And of course the fact that sandboxing is required for store distribution makes the store less useful. The implementation has much room for improvement, as do the store distribution policies.
granitosaurus 9y ago
or run trusted open source apps, preferably built from official upstream source. It's a bit crazy but I liked Stallmans analogy that back in the day computers didn't need user passwords, because logically speaking the person who sits in front of the computer owns it - it's extremely empowered idea. This applies well to this subject as apps should be the same - they should be able to do everything you are able to do on the machine. You already gave full trust to the app once you installed it, to somehow go back on this trust is nothing but a paradox.

by CPLX 9y ago

comex 9y ago

The sandbox is designed to make that not expected behavior - even if, as demonstrated here, it has holes…

threeseed 9y ago
Since when ? OSX has never outlawed this sort of thing. The sandbox has always been completely different from iOS e.g. it doesn't ask permission to access photos, microphone, webcam.
- igloofoo 9y ago
  Wrong. 1) Your webcam turns a light on. Not permission, but you know what's going on. 2) "People must grant permission for an app to access personal information, including the current location, calendar, contact information, reminders, and photos." https://developer.apple.com/macos/human-interface-guidelines/user-interaction/requesting-permission/ https://developer.apple.com/macos/human-interface-guidelines...
  - threeseed 9y ago
    Those are if you are using the APIs directly. But you can always go straight to the files themselves for cases like Photos and Calendars and also to the SQLite databases that back a lot of user data. And current location is easy to get on OSX. You can simply look up the user's IP address and WiFi networks to triangulate the user's location with about the same accuracy as Apple can do. With webcam you can easily switch the camera on, take the photo and switch it off. Could easily trick people into thinking it was a hardware fault rather than something nefarious with the app. The fact is that none of what I listed above is possible on iOS.
    - MaxGabriel 9y ago
      Aren’t the files outside of your app inaccessible from within the Sandbox, unless you give the app permission to read them? I mostly use non Mac App Store apps but one I use, the Unarchiver, needs permission to open files
    - kakarot 9y ago
      If my webcam light ever flickered on and then off, I'm chucking my laptop off the side of a bridge. Willing to be most other people wouldn't attribute it to a hardware fault, either.
      - CodeWriter23 9y ago
        You could just cover it with a post-it instead of chucking it off a bridge. The thing that bugs me is there’s no indication an app is connected to my microphone.
        kakarot 9y ago
        Thing is, at that point I'd be worried about the mic as well, as you point out. Better safe than sorry!
        CodeWriter23 9y ago
        Touché
    - jakobegger 9y ago
      That stuff is not possible if you have a sandboxed app from the Mac App Store. Sure, if you download software from the web, it can do whatever it pleases. But if you download apps only from the Mac App store, you should be safe. On iOS, Apple checks all your software. On the Mac, they give you a choice: If you want "safe" software, go to the Mac App Store. If you want any software, go somewhere else. The sandbox isn't as complete as on iOS, but the stuff you listed requires special permissions and confirmations when you get your software from the Mac App Store.

krisives 9y ago

Even HTML5 web capturing works in a similar way. Once you give an site like Discord access to your microphone or screen it can pretty much access it whenever the page is open - granted it will show a little badge on screen by default. A lot of users got tired of the on-screen badge being on all the time and probably set it to hidden (very easy to do) so not everyone is actually aware of when an HTML5 application is accessing a microphone/camera/screen.

danieldk 9y ago
A small aside: on the Mac, Micro Snitch [1] can let you know about any app that accesses the mic or webcam. It can use overlays, notifications, and/or just the systray to indicate that an app is using the mic/webcam. It also has an activity log that can you show past use. [1] https://www.obdev.at/products/microsnitch/index.html https://www.obdev.at/products/microsnitch/index.html

userbinator 9y ago

I agree. This feels to me to be more like inducing paranoia to push some hidden agenda. The "open" design is a feature, not a bug, and why mobile apps and their isolated design only encourage silo'd data and horribly wasteful workarounds (upload something from one app into some distant third-party cloud service, and download it again for another app to access it... provided those two apps' developers have explicitly decided to provide such a feature.) Every binary I run could delete all my data or steal my passwords or whatever else. That's not something to be afraid of --- it's something to cherish and be proud of[1], and it's why you don't run anything you don't trust. This "free-for-all" sharing and access encourages the sort of ad-hoc and unpremeditated interactions which are beneficial to the software ecosystem as a whole. I usually have a magnifier, color identifier, and clipboard-listening-translator running. None of those would be easily implementable or may not even exist, had computers started out as locked-down systems from the beginning. [1]https://boingboing.net/2012/08/23/civilwar.html https://boingboing.net/2012/08/23/civilwar.html

abecedarius 9y ago
There's a difference between locked-down-by-Apple and locked-by-you according to your own choices (e.g. Qubes). Being able to run software from others without being completely vulnerable to them is essential to that open ecosystem we want. A free-for-all OS is like a meatspace without private property -- it can work at a small scale.
marcoperaza 9y ago
A design that dooms even savvy users to being compromised is simply not acceptable anymore. Most people are not discriminating enough about the software they install. But okay, maybe you actually are and never make mistakes[1]. But is all the software you use signed? By a certificate traceable to a real, accountable person? Can a software update, perhaps released by someone who has hacked the original developer, come along and turn it into malware? Because all of your apps have full-capabilities, it can now do things that you would never grant if explicitly asked. Now you're completely screwed. All of your emails, pictures, medical information, other embarrassing personal information/media, bank logins, and so forth are compromised. Maybe you have two-factor authentication for all of your accounts (doubtful), but who cares? It can just read the memory of your browser process, quietly wait for you to login to the various services, and then hijack your sessions in the background. So tell me: how in the world is this an acceptable situation? [1] I sure hope you never use any of these new-school package managers for various programming languages, text editors, and such. You know, the ones that grab the latest commit from GitHub repositories run by total strangers and then run them with full privileges.

fadzlan 9y ago

My thought exactly. I was like yes of course! How does he think that desktop app can do many different things? Now, sandbox is a different issue. But of course, yes it have access to the screen. If apps on desktop is going to be as restrictive on mobile, why use desktop at all?

cesnja 9y ago

Much work is being done on Wayland compositors and window managers to change this. Among other expected results are also the security aspects where the user is able to know which program is reading certain inputs and outputs, and might be able to control this data. As a basic example, a desktop app is only able to read/write the pixels inside the rectangle assigned by compositor, and it only receives keyboard events and mouse clicks that were sent inside this rectangle. I think this is an assumption one could make about a modern desktop. Sadly not enough users care about this type of security, so we stick to the old, X11 style of altruistic desktop computing where every program can see everything.

cududa 9y ago
Couldn’t you just hook the wayland compositor to detect where focus is and eat up all those inputs?

osteele 9y ago

I submit that the macOS interface leads to a reasonable expectation of greater security than an old-school executable running in the 90's or 00's, because macOS requires that the user explicitly grant permission to access so many other sensitive resources, such as location and contacts. If an app has to ask me permission in order to access my keystrokes, I think it's fair to assume that the same would be true of apps that read (anything outside their window regions) from my screen. The fact that macOS doesn't require this is discoverable by sleuthing (browsing the Privacy pane, or remembering that screenshot apps don't ask for it), but there's reasonable, and probably common, mental models that don't make it obvious. It would be like renting a house with four locks on the front door and none on the back. Yes, you could audit the house, but it's a weird asymmetry to have to look for. (P.S. I'm older than you, FWIW :-)

clebio 9y ago
Are you talking about High Sierra, or iOS devices? Because this just isn't true about my macbook pro running Sierra. There is no granular permissions model as in, for instance, Android 7. I give my (super) user password to install apps on my mac, and then after that, they run. There's no further permissions I can or can't grant, and there's no way to run install many desktop apps without my (super) user password. Edit: It seems you a many of the others replying to the GP are talking about apps from the App Store, which I basically never use. And that's sort of the parent's point, I think. I get apps from the internet, install them, and use them, like and old-school desktop/PC computer user. I rarely need to use the app store (except for updates, and it's weird UX that OS updates are in the app store to begin with) and have no compelling reason to do so.
- osteele 9y ago
  I'm talking about High Sierra, and apps loaded from App Store or non-store download links. For example, System Preferences > Security & Privacy > Privacy > Accessibility lists (among others) “Backup & Sync from Google”, BetterTouchTool, Dash, Dropbox, Google Chrome, Google Software Update, Keyboard Maestro, Little Snitch Agent. Many of these aren't even available from the app store. If I keep Accessibility unselected, some of these have degraded functionality. For example, I keep the Google apps and Dropbox unchecked, and then they can't annotate my Finder icons. (I'm okay with that.) I keep Dash unchecked, and keyboard snippets don't work. You're right that this isn't super fine-grained. This single checkbox seems to govern several unrelated things, such as keystroke logging and insertion (Dash and Keyboard Maestro), mouse recording and control (Keyboard Maestro), and whatever APIs are used to badge Finder icons (Google and Dropbox). My belief is that an app that I haven't checked off there doesn't have access to my keystrokes. (Maybe this is wrong?) In which case I'm surprised there's nothing like this for recording the screen.

mwfunk 9y ago

Sandboxing isn't to prevent people from damaging their own computer (i.e., the "sudo rm -rf /" case), it's to impose a ceiling on how much damage can be done by an exploited process that the user doesn't realize has been exploited. It's not to save you from yourself, it's to save you from stuff that you wouldn't otherwise have any way of knowing was even happening. Sandboxing restrictions are more like using asserts in your code than anything else- they only stop programs from doing things that the programs themselves are stating that they would never attempt to do. Having said that, plenty of useful apps can't ship in sandboxed form because of limitations in the current sandboxing model. And of course the fact that sandboxing is required for store distribution makes the store less useful. The implementation has much room for improvement, as do the store distribution policies.

granitosaurus 9y ago

or run trusted open source apps, preferably built from official upstream source. It's a bit crazy but I liked Stallmans analogy that back in the day computers didn't need user passwords, because logically speaking the person who sits in front of the computer owns it - it's extremely empowered idea. This applies well to this subject as apps should be the same - they should be able to do everything you are able to do on the machine. You already gave full trust to the app once you installed it, to somehow go back on this trust is nothing but a paradox.