
Sandboxed Mac apps can record screen any time without you knowing - Sujan
https://krausefx.com/blog/mac-privacy-sandboxed-mac-apps-can-take-screenshots
======
ridiculous_fish
I was an AppKit engineer when the Mac app sandbox was introduced in 10.7. Much
of our effort that release (and in following releases) was dedicated to making
Mac features work within sandboxed apps. Think open and save panels, copy and
paste, drag and drop, Services menu, Open Recents, etc.

We did our best but the fact is that sandboxed apps run more slowly, have
fewer features, are more isolated, and take longer to develop. Sometimes this
cost is prohibitive (see Coda 2.5).

IMO the app sandbox was a grievous strategic mistake for the Mac. Cocoa-based
Mac apps are rapidly being eaten by web apps and Electron psuedo-desktop apps.
For Mac apps to survive, they must capitalize on their strengths: superior
performance, better system integration, better dev experience, more features,
and higher general quality.

But the app sandbox strikes at all of those. In return it offers security
inferior to a web app, as this post illustrates. The price is far too high and
the benefits too little.

IMO Apple should drop the Mac app sandbox altogether (though continue to
sandbox system services, which is totally sensible, and maybe retain something
geared towards browsers.) The code signing requirements and dev cert
revocation, which has been successfully used to remotely disable malware, will
be sufficient security: the Mac community is good at sussing out bad actors.
But force Mac devs to castrate their apps even more, and there won't be
anything left to protect.

~~~
veidr
I agree, it's terrible. As a user, I often go to pains to avoid getting the
App Store version of an app, if an alternative exists, because those apps are
crippled to such a degree that they aren't worth using.

If I'm using the App Store stuff, then my text editor can't edit all my files,
my video player can't open videos when I double-click them, my Evernote can't
print to PDF, my disk usage analyzer can't analyze my disk because it can't
ask me for authorization to do so, and so on.

At the same time, though, in theory I _do_ want sandboxing, at least by
default. I _do_ want to have to explicitly authorize some random app before it
can install a printer system extension, or before it can scan my entire disk.

I feel like the problem is more political/cultural: Apple prioritizes their
low-information, low-computer-literacy users (hi, Dad!) so dearly, that they
aren't willing to expend resources to find any compromise for their
technically proficient ones. And through the sandboxing requirements, they
force their third-party developers to either tell their power users to fuck
off, or to give up on the App Store.

Or, I don't know, perhaps they just don't have enough engineers left for the
Mac after moving so many of them to their higher-volume Candy Crush console
business.

Regardless, though, if there were mechanisms for the _user_ to control the
sandboxing enforcement to a greater degree, I would be all for it.

If we could tell our Macs "yes, dude, I hereby authorize DaisyDisk to see all
the files" and "Computer, hey bud do me a favor, overrule this restriction
that says CotEditor can't ask me to authorize modifying root-owned files",
then I would actually not only be happy with, but even prefer, the App Store
versions.

But we can't, and it's sad.

~~~
galad87
> If I'm using the App Store stuff, then my text editor can't edit all my
> files, my video player can't open videos when I double-click them, my
> Evernote can't print to PDF, my disk usage analyzer can't analyze my disk
> because it can't ask me for authorization to do so, and so on.

I fail to see how the macOS sandbox prevents this. Disk usage analyser can ask
you for disk access, sandboxed video players can surely open files double
clicked in Finder, sandboxed apps can print to PDF.

A few example: QuickTime Player is sandboxed, Pages is sandboxed.

~~~
veidr
> _I fail to see how the macOS sandbox prevents this_

I think you might be thinking of the reasonable sandbox we wish we had, not
the one we have.

[https://daisydiskapp.com/manual/4/en/Topics/Editions.html](https://daisydiskapp.com/manual/4/en/Topics/Editions.html)

(Apple's own apps do not have to follow the rules that third-party apps do.)

~~~
galad87
Ok, that's a limitation. What about the other ones you described? I wrote a
bunch of sandboxed app, and it's good enough for a document based app (when
working on a single document).

~~~
namelost
The sandbox allows apps to open files via three methods:

* Open dialogs

* A limited number of files that have been opened in the past via open dialogs (intended for e.g. recent files)

* Files that live in the app's sandboxed region of the filesystem.

That's it. So your text editor can't open ~/.bash_profile unless it pops up an
open dialog and asks you to manually click it.

~~~
ntaoe09unteont
How exactly is that a problem? You can open an open file dialog that is in the
user's home directory and you can even select ".bash_profile" for them. All
they have to do is click "OK" to start editing it. This gives them the
security that your app can't just go and erase or overwrite or add malicious
stuff to their .bash_profile without their consent, which seems like a really
good idea!

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

~~~
userbinator
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)

~~~
marcoperaza
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.

~~~
ploxiln
Everything you install from the core debian stable repositories, is pretty
much guaranteed to not have any actively malicious code. Otherwise it would be
discovered and removed. All debian packages are signed by the package-upload
process. It's not perfect, but it's been good enough so far. This is a world
that is now niche, but used to be practical!

It's very depressing to be transitioning into a world where you can't use a
small trusted open-source mail client and IM client etc, where you have to
install crazy huge untrusted piles of flaky and inefficient code in order to
interact with real-world people and institutions, and you can't easily control
which version you have installed, and mobile devices become obsolete after
just 3 years. (Even iPhones - not because of Apple, but because Instagram and
Snapchat got too heavy/shitty for the older models! This does not happen for
communication over SMTP or XMPP!)

So I see the "we need super sandboxes around every little thing" as a sort of
bandaid on a much bigger problem which is not going to be fixed in the
foreseeable future.

~~~
wander_homer
Like the XScreenSaver time bomb that caused a nag screen to pop up on April 1
one or two years ago on peoples screens? Debian distributed this code for
years without realizing because no one even glanced at the code. The developer
didn't even try to hide the time bomb, he even provided angry comments why he
added the code.

The only reason Debian didn't distribute some really bad malicious code (that
we know of) yet is because they got lucky and no developer tried to mess with
them.

------
fouc
Are we ever going to end up with the practice of running every app in their
own independent VM?

Should anything at all run in the host OS?

The advantage of running every app in their own VM means that apps won't get
necessarily tossed to the side in this constant arms race of upgrades,
especially for apps that don't need internet. Imagine still actively using
several perfectly good apps that were last updated 10 or 20 years ago?

~~~
amelius
> Should anything at all run in the host OS?

Isn't that equivalent to saying that the set of available kernel calls should
be more restricted?

(User mode is a kind of sandbox, after all)

~~~
koolba
Not just the set of kernel calls but the scope of the calls themselves. A text
editor should be able to fopen the file I’m editing but it doesn’t need to be
able to access ~/Documents/top-secret.txt. You can do this type of thing with
SELinux though I’ve yet to see it done in a user friendly way.

~~~
tzahola
You’re looking for capability-based systems.

------
oneplane
I get that this is about the Mac apps, but doesn't this apply to any general
OS? On Windows this is trivial, on any Linux distro using X11 too.

~~~
kibwen
Just goes to show that not all sandboxes are created equal (though I don't
think I've ever even used a properly sandboxed Windows or Linux app, so those
OSes don't get any points anyway). For example, reading other tabs or
processes out of the web browser sandbox isn't possible short of exploits like
Spectre and Meltdown, and even seeing something like the history of visited
links requires cleverly tricking the user (and coarse guesswork) e.g.
[https://tinsnail.neocities.org/](https://tinsnail.neocities.org/) and
[http://lcamtuf.coredump.cx/yahh/](http://lcamtuf.coredump.cx/yahh/) . I
imagine the behavior in the OP is impossible on both Android and iOS too?

~~~
abecedarius
There was a pre-Spectre proof of concept of a program telling what tabs you
have open in your web browser: [https://github.com/defuse/flush-reload-
attacks](https://github.com/defuse/flush-reload-attacks)

This was a program rather than another webpage, and I haven't bothered to read
how it worked beyond the general idea of exploiting a cache side-channel. I
expect the bit-rate is low compared to Spectre/Meltdown. But it made me leery
of confidentiality in current systems.

~~~
yzmtf2008
I think you have the idea of sandbox (or at least the idea of sandbox in the
context of a web browser) backwards: it means an application (webpage) running
_inside_ the sandbox cannot access resources not granted. This side channel
access does not run inside a sandbox at all.

~~~
abecedarius
If you don't consider an OS process a sandbox at all, why are even talking
about security here?

~~~
yzmtf2008
That’s not the point of GP though? The whole premise of virtualization is that
_an OS process is not a perfect sandbox_. There’s a hierarchy of sandboxes.
Protecting other processes from accessing something inside the sandbox is not
the job of a browser sandbox. This actually just goes to show the GP’s point:
_not all sandboxes are created equal_.

~~~
abecedarius
I was not arguing against kibwen, I was sharing some more points. People have
implicitly expected OS processes to be better isolated from each other than
they are. (I think there's a related problem that people tend not to think
about which of the properties of integrity, confidentiality, and availability
they rely on.)

------
igloofoo
So apps need to ask for location but not to see everything you do? WTF

~~~
amerine
I imagine a world where every application that wanted to read and write to
displays was required to go through an authorization-flow before it worked?

That sounds terrible. This behavior is how desktop applications are meant to
work. I’m surprised this surprised anyone.

~~~
igloofoo
Please humor me, why in the world does an app need to read/write your screen?
It is provided a window for that.

If it doesn't need to read/write your screen in order to provide its features,
and then does it, wouldn't you agree that something is fishy? Wouldn't you
like to know when fishy things are going on?

What is the point of security if any app you download can see everything you
do?

~~~
badsectoracula
> Please humor me, why in the world does an app need to read/write your
> screen?

The most obvious answer would be to take screenshots, like GIMP's "Create from
screenshot" command or a dedicated program like the snippet tool in Windows.
Many graphics tools offer that functionality, even some that you can run from
the command line.

Other, similarly widely available functionality, is to record the desktop - a
common functionality needed for screencasting and video streaming (think
Twitch) programs. This also need to capture audio. Also a more niche tool is
to create captures directly to GIF files (i have such a tool both in Windows
and Linux).

Of course less commonly implemented but still very useful functionality is for
remote access/remote desktop (in which case you also need to also capture
input events but also create fake input events indistinguishable from the
user's events).

Finally several utilities also benefit from being able to read the screen,
like utilities to magnify and perhaps enhance part of a screen (that can be
useful for people with sight issues, or for developers to inspect the output
of a graphics program at the pixel level without flattening their face on the
monitor) or utilities like color pickers or even just funny toys that
manipulate the screen contents (i've seen a game at the past grab a screenshot
of your desktop and then zoom it out when you launch it).

> What is the point of security if any app you download can see everything you
> do?

I'd turn that around: what is the point of security if the apps you download
cannot do their job because of it? At the end of the day computers need to be
useful, not to be burned and buried in a waste disposal field (where they'd be
in their most secure state).

~~~
CrystalLangUser
> not to be burned and buried in a waste disposal field (where they'd be in
> their most secure state)

This is just a simple strawman.

It's not that hard to have a middle ground, just disallow apps from using
things like your webcam or screen without your explicit permission. Just
because 1 program uses that functionality doesn't necessitate it to be common
to every single program you ever run.

iOS already manages this. Just have a notification pop up when you use the
program to allow X access from system settings. Certain programs already do
something similar by requesting access from Accessibility, like window
managers (albeit that's to get around certain limitations).

~~~
badsectoracula
If someone figures out a way for this sort of thing to be unintrusive while
still being effective, i wouldn't mind it but i haven't seen anything like
that. The notification popups you suggest are both intrusive _and_ ineffective
because, honestly, if i want to do some task anything that tries to alert me
about something unrelated to that task ("hey, this needs net access" \- sure,
ok whatever... i cannot think about that right now, i need to actually do what
i want to do) is something i am very unlikely to put any thought over so i'll
just accept. I mean, i used to check the permissions on my Android mobile but
after a year or so i stopped because at the end of the day the question is "do
you want to run this program or not"? And considering i already downloaded the
program to run it, the answer is obvious.

This stuff is really barely a notch above expecting people to read EULAs.

~~~
jurip
How often do you think most users read the screen, especially using something
other than the screenshot tool of the operating system?

As an iOS developer I run Xscope to check details of designs, I don't know,
maybe once every two weeks? And I guess I've probably used Acorn's color
picker outside its own window during the last year, but I'm not sure about
that.

I'd imagine that most users need apps reading arbitrary pixels off their
screen less often than I do. I'd appreciate a warning from the operating
system when an app tries to do that.

~~~
badsectoracula
> How often

I do not think the frequency of needing that functionality is really relevant
when you need to use it - you can either do it or you cannot.

But there are users who do need to use applications that capture the screen
way more often than once every two weeks. One example would be Twitch and
YouTube streamers (not necessarily about games - many stream other things,
like creating art, programming, composing music, etc) who do that for several
hours every day.

> do you think most users

There is no point talking about "most users" because really anything can be
attributed to what "most users" do or do not - "most users" is not something
that is well defined. We can only talk about specific use cases.

After all, all users (which by definition include most users) start as not
being able to do anything, that doesn't mean the OS should not be able to do
anything.

> As an iOS developer I run Xscope to check details of designs, I don't know,
> maybe once every two weeks? And I guess I've probably used Acorn's color
> picker outside its own window during the last year, but I'm not sure about
> that.

These are also useful examples for cases where you need screen reading, but
these are really niche. The most common is probably streaming, as i mentioned
above, but there are also other cases where you need frequent screen reading
capabilities - for example documentation writers will often need to capture
parts of the OS, either as screenshots or as short video segments (for
interactive docs) to use as part of the documentation. It is also very helpful
for customer support - in both sides of the equation (in a company i worked
many years ago, the employee responsible for tech support had SnagIt open all
the time).

> I'd appreciate a warning from the operating system when an app tries to do
> that.

I suspect that if that warning comes as part of your screenshot or video
capture you wont appreciate it that much :-P

~~~
jurip
But this is not about removing the ability to read screen content. It's about
removing the ability to read screen content without telling the user.

That's why I think questions about frequency and "most users" (nebulous term,
I admit) come into play: yes/no permission dialogs aren't the best and many
users do just click through them without thinking, but there's a world of
difference between asking several times a day and asking a couple of times a
month.

If my usage is far below average, then I agree that it's probably better not
try to restrict it. If, as I would guess, I use it more than most, then it
feels exceptional enough that letting the user know when it's happening would
be fine.

If you could give a permanent permission to a given app, I'd imagine even the
daily streamers wouldn't be too badly inconvenienced.

------
ThomPete
The Sandbox became the reason I left the mac app store and instead started
selling my directly from my website using Paddle and I haven't looked back
since.

It's been one of the most catastrophic decisions apple have ever made and IMO
is hindering actual progress for desktop apps.

------
dep_b
Felix Krause works for Google these days. Since he got hired he got a bit more
critical to the platform. Perhaps no more “I hope this doesn’t piss off Apple”
mentality?

------
floatingatoll
The login dialog for the Itch.io desktop client is magically excluded from the
accessible canvas on my OS X instance.

~~~
kuon
Knowing its dev, this doesn't surprise me:)

------
_trampeltier
I was worry about a kind of this too. I was worry an app could steal my
passwords from clipboard. I checked, at least a website can't just read from
the clipboard. At least in theory .. I still fill the clipboard after the use
to transfer a password (often) with random stuff ..

~~~
gruez
>I checked, at least a website can't just read from the clipboard. At least in
theory

AFAIK the logic is that any user initiated event (click, keystroke, touch,
etc) allows the page to see (and modify) clipboard contents for that instance.
So if you accidentally click in a rogue page, it's possible for your clipboard
contents to be stolen.

------
debt
Something has to give with the Mac ecosystem. The Mac App Store sucks, the Mac
has continuously for the past years of been having security issues, serious
security issues.

I believe Apple is at a crossroads, something needs to be done with the Mac.

~~~
EugeneOZ
Don't panic.

------
NietTim
Maybe Krause can also make an article on the paste board and get some more
clicks

------
jacksproit
I remember in the windows xp days there was an app you could run that would
show an alert any time a program tried to hook into your keyboard input or
display. I wonder why nothing like that exists any more.

~~~
deepfriedbits
Seems like a nice feature for something like Little Snitch.

------
igloofoo
Viewing your screen should be subject to permissions simply because it can
supersede all permissions to access sensitive data.

------
adultSwim
This is why I run Qubes. Trusting all software running on my system is
unreasonable. Other OS's need to catch up ASAP.

------
wavefunction
Why wouldn't we assume that?

------
techrich
You are sitting on this OS as an administrator/root and apps can do anything
that they want. I dont really see this as an issue. Its always been this way!
Go run Qubes OS if you want to protect against this.

------
TheDong
> > How can I protect myself as a user? > To my knowledge there is no way to
> protect yourself as of now.

That is the most FUD bit of this. There's a very easy way for a user to
protect themselves: don't download any untrusted applications. Only run code
you trust. Don't trust the sandbox that much.

Vulnerabilities like the android MMS one where anyone could send any number an
image and pwn it were "as a user you can't protect yourself".

Local roots and things like this require a user to opt-in to being exploited
by running a malicious app. That's significantly different and less scary.

~~~
felixkk
How can you know the app you’re using hasn’t been compromised? Publishing a
blog post about this specific topic next Thursday

