Disclosure: Another macOS privacy protections bypass

Yeah...Hint to Apple: When somebody discloses something, responsibly, you react to that with a proper process and understand you get 90 days in most cases as is industry standard (that's typically how Google Project Zero operates).

Otherwise don't be surprised when exploits end up sold for much more on a black market because nobody wants to cooperate with you.

Think we need a few more 0-days that cost Apple a few bad PR spins (as well as others like Valve) to make them wake up and actually have a proper process.

Please don't do this when reproducing exploits. Yes, it's just source code, and yes, the url is dead. But it's still source code that, when compiled, will grab your real safari data and attempt to upload to a url that could be switched on.

There's a difference between repro'ing an exploit and weaponizing an exploit. alert(1) is generally the best thing to aim for, or even alert(some user data) to illustrate the point. Whereas upload(some user data, my server) is a bit too close to the moral equivalent of `rm -rf $HOME/*`: all of these illustrate the point, but rm'ing a homedir is generally not a great thing to have in your repro; ditto for uploading real user data.

exmaple.com was explicitly reserved for scenarios like this, which would accomplish the same thing safely.

It may seem like a pedantic point, but it was something I was taught as a pentester: don't weaponize exploits; simply reproduce them. So my instincts kicked in, and it's impossible not to mention it. (That said, I don't mean to make a fuss – it's not a big deal in this case.)

By the way, I found this post via the author's twitter: https://twitter.com/lapcatsoftware I've been following them for about a year now, and their tweets on Mac programming have been quite informative.

If every attempt to improve something were disproven by the presence of flaws, it would disprove all attempts to do anything with software ever. I get that people don't like the macOS privacy protection efforts, but that's no reason to construct a logical fallacy.

> I was really hoping they'd take some time to address Catalina's glaring issues — its slowness, bugginess, just general sloppiness — and instead they did the opposite.

I didn't include "security exploits" in that list because of course they're going to fix security exploits, right? Especially one that they're already aware of, and can reproduce — they wouldn't just sit on it in favour of making the UI glossier, right?

Apple have just been getting so much wrong lately. This pretty much dashes any hopes I had of ever upgrading, because even if this particular flaw gets fixed by the time Big Sur comes out, there are almost certainly others that they've ignored. I expected to eventually have to grit my teeth and upgrade so I wasn't behind on security updates, but I guess that's not the case. Ugh, now I have to figure out how to mute that annoying (1) in System Preferences. I've heard they keep making it come back now.

Substitute "security" for "privacy" and you immediately see why the argument is flawed. "Other people and I have found bugs that bypass security features, ergo security features are security theater and only harm legitimate developers. Better have a free-for-all OS and be mindful of what you install." (Yes, you should be mindful of what you install, regardless.)

So this is just another abuse of the term "security theatre." Door locks, for example, are legitimate security. There are plenty of lock picking sets on the market. But that does not mean door locks do not work. TCC works because a casual user isn't trying to override it. But if it didn't exist then users would have no protection at all. It still comes down to the person sitting behind the computer is in complete command of it. And security knowledge is the best security you can buy.

This 10.9 incarnation on TCC is much weaker, however. It doesn't apply to most Apple Events—only UI scripting—and once the user whitelists an application, that application can control any other app on the machine. Also, because SIP wasn't introduced until 10.11, there was originally nothing to stop an application with admin privileges from editing tcc.db directly and whitelisting itself—as Dropbox later did!

This is a pretty glaring security issue actually - after reading this, it seems like Apple's choice to track app permissions / security exceptions by the app's bundle ID and not its file path was a pretty big mistake.

I wonder if this is a case of iOS security engineers working on macOS, forgetting that app bundle IDs aren't enforced by a central install flow on the platform?

I really disagree. This feature has revealed that Google Drive by default spies on my ~/Downloads folder - something it has no business doing, nor did I ever intend for it to do.

I actually love the many things Apple are implementing to improve user privacy from third-party apps and services right now. To an extent, their privacy brand actually is real, and helpful.

Just don't expect any privacy from Apple themselves (and by extension the government). At least they help reduce Google and Facebook's rampant surveillance. That's some good news, in today's era of tech.

Or phrased differently. All installations of the same app have the same privilege.