The advantages of OCSP are that you get a real-time understanding of the status of a certificate and you're not needing to download large CRLs which are stale very quickly. If you set security.OCSP.require appropriately, you don't have any risk of the browser failing open, either.

It seems to me like the people who most dislike OCSP are CAs who have to maintain the infrastructure capable of responding to queries. I have really limited sympathy, that should be part of running a CA.

The privacy concerns could be solved by mandating OCSP stapling, and you could then operate the OCSP responders purely for web-servers and folks doing research.

Unfortunately the ship has sailed with ballot SC63 now, and we are where we are. I don't necessarily agree that OCSP as a concept was unfixable, though.

My main privacy related concern isn't about domains being sent in plaintext but that they are sent to the CA and they can then theoretically do analytics on this data and profile web users.

But maybe this concern doesn't really make sense as we have strict personal-data regulations now.

When you're network is all Linux everything actually does "just work" more so than it ever did with OSX. Everything is just an SSH away, it's really pretty amazing.

We were using complex passwords; this was when 10.6 was latest OS, so perhaps security is better now with simple password-based SSH — but I would never take such a risk again.

Plus, if you know what OCSP is and care about it, chances are you don't use MacOS anymore. Nobody who conscientiously objects to OCSP tracking should be assenting to the rest of MacOS and it's perverse sense of "security".

Fact: Little Snitch resolves the IP address (i.e. does domain-to-IP lookup) before the Deny/Allow dialogue ever appears onscreen. Only by pressing "Allow" does Little Snitch then allow/initiate connections to the already-resolved IP ADDRESS.

I run four, locally [50+ users].

Local DNS Server issues default lookup server @x.x.x.2 (e.g. minimal blocklist PageAd, CloudFare), for maximal client compatibility.

Users can thereafter upgrade levels of blocking by manually increasing DNS IP +1 (e.g. x.x.x.3 for stricter blocking, whereas default x.2 only blocks seven very common trackers), at host-level.

They can also manually enter x.x.x.1 and thereafter have no DNS-restrictions [this is the router itself, which each x.x.x.N itself resolves to, via our ISP's own DNS serverlist].

Our x.x.x.5 is top-notch white-page browsing, but many applications won't work (e.g. banking; although surprisingly Youtube still works although you do have to watch pre-roll ads).

I have one user who there-after has his own local subnet/PiHole, although you can hop-up to PiHoles, as long as the subnet is a child or sibling of that DNS-resolver.

Just blocking ocsp2.apple.com is probably fine if you're running anything recent-ish.

... and then claim it was necessary for "updates and upgrades". Not sure why TextEdit.app needed a kernel network extension for "updates and upgrades".

They also denied it was possible until it was provably demonstrated that they did.

I like Apple stuff, everything I use is Apple. But too many see them as infallible or go to the whataboutism for missteps like these.

Well, the goal of a bridged net adapter for VMs is to make the VM as if it were physically plugged in directly into the network, independently of the host, so it makes sense for it not to be affected by a firewall.

> running a VM in your evil app.

IIRC back then, creating a bridged net adapter required a special entitlement (special as in you can't get it without explicitly asking Apple for it and the dev cert for it has additional entries, like for kernel extensions). Dunno if that's still the case.

It's not very practical though. Better to block the address with little snitch or a hosts file

Bluntly: if you don't trust your OS vendor, then you can't use OS updates. There are people in this category but it's a lot of work.

Much easier to trust your OS vendor (at least to this extent).

That's notable, as we're discussing a case where Apple said they would do something, and then not only didn't do it, but went out of their way to pretend that they never said they would.

From that lens, Google is also commited to never give your personal data (think Gmail content, Maps behaviour, pins etc) to other companies and keep it all in their ecosystem, for themselves only. Your data is their key advantage, the base of the ad empire, and they won't let another company run away with it.

If we call Apple privacy focused, Google also fits the bill, the question just falls down on whether we see Apple or Google as part of our intimate circle, within our private life. I assume you do for Apple but not for Google.

They need you in their ecosystem, the same way Google needs you in theirs.

And I totally agree with you, I wouldn't't call Google privacy focused, and I don't call Apple privacy focused either, even as they market it harder than anyone else.

Methinks you're holding a double standard. Compared to Android and Linux, Apple's "promise" is no better than the one Microsoft offers Bitlocker customers.

I’ve always thought it was either far too time or far too space intensive to be practical.

Do you have sources on this, either from Apple or academic papers of the scheme they’re planning on using?

No, I don't have to trust Apple or anyone absolutely, and I can and do use a Mac, as the least bad option for my purposes, without fully trusting Apple. You're presenting a false dichotomy. Trust is a matter of degree, not all or nothing. In general I trust my mother (except her advice, which I often ignore), but if she insisted that she had to install cameras in my home for my "safety", I would start to have serious doubts about her.

> Because they have the ability at any point to push software to your computer that compromises your privacy and security in almost undetectable ways. And short of them having an entirely open-source OS that will always be the case.

1) They can't push software to my computer, because I've blocked the software update mechanism with Little Snitch and only install when I'm ready.

2) Open source is not a panacea, as demonstrated by the XZ Utils backdoor.

Moreover, closed source does not render users helpless. Closed source software can be reverse engineered; indeed, I've done that myself with macOS many times. The behavior of closed source software can also be observed in various ways with various tools, for example, the aforementioned Little Snitch. And even when macOS bypassed Little Snitch one time a few years ago, that was detected by developers. The whole world is watching Apple closely, so the company can't simply get away with whatever they want undetected.

> The whole point of their privacy stance is to protect you from companies like Google and rogue governments who we already know can't be fully trusted

We already know that Apple can't be fully trusted.

We also know that Apple actually caters to "rogue" governments such as China, by removing apps from the App Store at the Chinese government's request, as well as handing over control of iCloud servers to China, and reportedly Apple source code too, for inspection.

They can because they (Apple) run in kernel space and Little Snitch no longer does/can. So LS, god love it, only works because Apple lets it. If Apple wanted to they could push updates to your OS without LS knowing about it.

I already addressed this later in my comment: "And even when macOS bypassed Little Snitch one time a few years ago, that was detected by developers. The whole world is watching Apple closely, so the company can't simply get away with whatever they want undetected."

> If Apple wanted to they could push updates to your OS without LS knowing about it.

They could release an update that allows later updates to bypass Little Snitch, but they can't magically make that ability retroactive and get it on a Mac that doesn't currently have that update installed.

Or the ability could be there already without us knowing.

But fortunately we can still run our own routers/switches and see outgoing traffic. If you configure LS to block everything then you could confirm it with your network gear.

Which is useless if they simply encrypt the data before sending it over SSL.

Then you will never know what they are sending to their servers.

Not entirely useless, you'd still know they were sending something and it would be proof they could bypass Little Snitch.

An empirically baseless conspiracy theory.

> But fortunately we can still run our own routers/switches and see outgoing traffic. If you configure LS to block everything then you could confirm it with your network gear.

That was my point. Apple isn't actually capable of completely avoiding detection.

Anyway, just as I don't trust Apple absolutely, I don't distrust Apple absolutely either. They do some user-hostile things, which are richly deserving of criticism, but I prefer to engage with facts and evidence rather than idle speculation and paranoia.

You misunderstand I think. I don't think it's likely. It would be easy to catch them. I also don't distrust Apple completely. I was (pedantically) replying to your comment that "They can't push software to my computer, because I've blocked the software update mechanism with Little Snitch". "Can't" is too strong. They could is what I'm saying, as in, they have the ability/possibility to do so. They can't time travel, because that's impossible. But they can establish network connections, because they control the firmware and kernel, which exceeds your control via Little Snitch.

Google's better in that they chose not to do business in China the same way. For now.

On the other hand, the issue is not as simple as Apple following the law, because Apple chose to lock down iPhone and set themselves up as the sole gatekeeper for app installations. On the Mac, which allows distribution from outside the App Store, it's not possible to completely ban apps in this way.

US companies keep trying to impose local US rules, policies and way of thinking of their HQ whenever they operate abroad, especially in Europe, but totally do an 180 when they operate in China.

That doesn't really fit, because the course of action would be the same in both cases. If the CCP says they have to ban apps then enable side loading or third party stores so customers in China can install the banned apps from another source but the company can still feign compliance. This is the same thing the EU says they have to do anyway, except that it actually defeats the onerous regulation in China whereas in the EU the regulation is intended to benefit rather than oppress the user and Apple objects to it because they're the one wearing the boot.

The explanation that fits is that they care about their own control (and so fight the EU) but don't care as much about China oppressing their customers (and so bend the knee there).

> US companies keep trying to impose local US rules, policies and way of thinking of their HQ whenever they operate abroad, especially in Europe, but totally do an 180 when they operate in China.

In general company leaders should try to have morals and use their influence to push back against rules from governments trying to harm their people. Obviously publicly-traded companies have a perverse tendency to do the opposite of this once they're controlled by Wall St rather than the original founders.

We know this isn't true because the contrary to this is how we know this is happening. Even when the OS is closed source, someone can still inspect its network traffic or get it running in a virtual machine and see what it's doing, and then publish the result if they find something untoward.

But once your data has been exfiltrated onto their servers, you no longer have any way of auditing what they do with it after that. So the only way to have any assurance of your own privacy is to call any behavior that exfiltrates your data a violation of trust.

It might be easier to audit open source code than closed, and maybe then we should be demanding open source operating systems, but there is still a large difference between "this is difficult but possible and so someone in the world could do it and let everyone else know" and "there is no mechanism for members of the public to validate their claims at all".

I don't believe such things would be undetectable. If that were the case, how would we have discovered the OCSP server?

Another point I don't understand is that, if it were made open-source, wouldn't Apple have the same level of control? After all, they'd still be the ones building the binaries. As another commentor noted, the XZ backdoor proved that even open-source software shouldn't be blindly trusted.

Because Apple is not trying to obfuscate anything.

If they did you would never have discovered it.

As opposed to the orderly and just governments, that are so clearly-defined and well trusted?

Or are you more highlighting the unlawful conduct from businesses like NGO Group that are so shamefully allowed to persist without government scrutiny? It's hard for me to tell, since both of them have hacked iPhones to attain privileged access and will likely do it again. From where I'm standing it looks like their "promise" has more holes in it than swiss cheese.

macOS preferences aren't magically locked away from the rest of system, regular users can change their own user preferences, and root can change system preferences. An antivirus has to still work against an attacker who has root. It's why you can't block certain apps/domains from the firewall as well.

You could put the preference in recovery mode along with disabling SIP and I think that would accomplish everyone's goals.

It's not. There are multiple layers of security, including notarization and XProtect.

> I'm pretty sure I know what the first thing any malicious software is gonna do.

What?

> macOS preferences aren't magically locked away from the rest of system, regular users can change their own user preferences, and root can change system preferences. An antivirus has to still work against an attacker who has root.

You sound confused about admin vs. root. Anyway, if you have a local attacker running on your Mac, then it's already too late for OCSP.

Mkay.

> OSCP is how notarization actually works, that's what's being checked to validate the notarization.

No, you are misinformed. OCSP is checked by the trustd process on ocsp2.apple.com, whereas notarization is checked by the syspolicyd process on api.apple-cloudkit.com.

OCSP is simply checking whether the Developer ID certificate has been revoked. Notarization, on the other hand, requires uploading a build to Apple and receiving a special notarization ticket. The notarization ticket is either "stapled" to the app or downloaded from Apple when the app is first launched.

Well they're not. What would you call it? Windows Defender and Microsoft's code signing requirement aren't super related. You could purge discovered malware with a signature/scan but that's not impossible to get around.

I'm not sure I really grok the difference from a security perspective when the main thing with notarization is ensuring it's signed with your developer cert.

I guess the Venn diagram isn't technically a circle but is it not that the actual security of notarization is provided by OSCP? I suppose I could have phrased that bit better.

Is there a case where a hypothetical notarization process that excludes that bit provides any real security? Because Apple "scanning it for malware" isn't going to be that different from Xprotect.

I'm really not sure what I did to get such an, idk hostile? response.

The security of notarization is provided by Apple's signature over the hashes of the executables in the app [0]. The hashes and signature are put into a "ticket". This ticket is stored on Apple's servers, and can also be "stapled" to the app. Gatekeeper (one of the macOS security systems) will prefer to fetch the ticket from Apple if possible, and fall back to the stapled ticket if available. Notarization is meant to guarantee that the code was sent to Apple and checked for malicious code.

OCSP checks that the Apple Developer ID certificate used to sign the app hasn't been revoked.

They are two separate checks done by the Gatekeeper system, which is meant to ensure that only trusted software runs on macOS. I believe it makes sense to call the OCSP check part of the Gatekeeper system, but this may be incorrect.

[0]: https://forums.developer.apple.com/forums/thread/710738

It's not the main thing.

> is it not that the actual security of notarization is provided by OSCP?

No.

I tried to explain the difference in my previous reply, but I'm not going to sit here and write an entire essay on the subject (though I could). The information is out there, for example on developer.apple.com. Or even on my own website. Inform yourself, or at least stop spouting falsehoods.

I’d rather you shill your own blog posts. Even without reading them, I know they are better. ;)