While other posts on this topic are too alarmist, this one is way too Apple apologetic for my taste.<p>* There is no information on how often the validation happens. All this investigation concludes is that it doesn't happen when closing and immediately re-opening an app. Is it every week? Every reboot? Every hour? If it's less, that's essentially the same as doing it on every launch.<p>* There is no justification for sending this information in cleartext. I don't follow the "browsers and loops" argument. This is a system-service that only has to trust a special Apple certificate, which can be distributed via other side-channels.<p>* Many developers only publish a single app or a certain type of app. So it still is a significant information leak. It's really not much different from sending a app-specific hash. Think: remote therapy/healthcare apps, pornographic games, or Tor - which alone could get you into big trouble or on a watchlist in certain regions.<p>I assume they will push a fix with better timeouts and availability detection.<p>But Apple simply has to find a more privacy-aware system designs for this problem which does not leak this kind of data without an opt-in and also does not impact application startup times. (revocation lists?)<p>I imagine this data might just be too attractive not to have. Such a "lazy" design is hard to imagine coming out of Apple otherwise.
> macOS does actually send out some opaque information about the developer certificate of those apps, and that’s quite an important difference on a privacy perspective.<p>Yes, and no. If you're using software that the state deems to be subversive or "dangerous", a developer certificate would make the nature of the software you are running pretty clear. They don't have to know exactly which program you're running, but just enough information to put you on a list.<p>> You shouldn’t probably block ocsp.apple.com with Little Snitch or in your hosts file.<p>I never asked them to do that in the first place, so I'll be blocking it from now on.
So the takeaways are:<p>* Your Mac periodically sends plain text information about the developer of all apps you open, which in most cases makes it trivial for anyone able to listen to your traffic to figure out what apps you open. Better not use a Mac if you're a journalist working out of an oppressive country.<p>* Because of this Macs can be sluggish opening random applications.<p>* A Mac is not a general purpose computing device anymore. It's a device meant for running Apple sanctioned applications, much like a smartphone. Which may be fine, depends on the use case.<p>Yeah... No Mac for me anytime soon then.
> You should be aware that macOS might transmit some opaque information about the developer certificate of the apps you run. This information is sent out in clear text on your network.<p>Wow, that is bad from a privacy perspective!<p>Since certificate revocation is rare, it makes more sense to simply periodically update a list of revoked certificates instead of repeatedly checking each certificate. That would solve the privacy issue while still allowing certificates to be revoked.<p>OCSP seems like a bad idea for web browsing for similar reasons.
When it comes to these article, you should really apply the following "smell" test:<p>Replace "Apple" with "Google", "Facebook", "Verizon". Re-read the article. If it sounds horrifying, then it's also horrifying if Apple does it. There's no such thing as "trust" into a single corporation - especially the one which just argued that you not paying 30% to them is "theft".<p>Applying this test helps weed out the marketing bias these corpos constantly try to push at you.
OCSP doesn't seem like the right protocol for this. Apple should probably just ship you a list of hashes of revoked certificates once a day, and should do the check locally. (Obviously, the global certificate database is too big to send to every user, but Apple should be able to determine the subset of certificates they trust, and the even smaller subset of those that are revoked or compromised.)<p>To me, it sounds like they decided to take the quick-and-easy path of reusing an existing protocol for the use case of stopping malware, but it doesn't really fit. The latency, privacy, and availability guarantees of OCSP just don't match with the requirements for "run a local application".
Can someone explain my why is this significantly less problematic than sending out app hashes? If we accept that most developers don't have many similarly popular apps, then isn't this enough to infer what apps are users running?<p>In the example from the article: if Mozilla's certificate is sent, then it's very likely that the app that has been opened is Firefox, as the a priori likelihood of using Firefox is way higher than eg using Thunderbird.<p>If the developer is Telegram LLC, then ... and so on.
There will be a day when all apps on a mac will only be installable from the app store. Developers will be forced to buy macs and subscribe to Apple’s developer program to support it. Customers will be trained to not care. And HN Apple fanboys and fangirls will try to justify why this is a Good Thing(TM).
Clearly this article doesn't reveal every truth. Certificates authority should have been decentralized but is it happening?<p>And just by looking ip address, and app usage and other data they receive they can connect the data and identify its me. And what security has apple provided till now?<p>"You shouldn’t probably block ocsp.apple.com with Little Snitch or in your hosts file."<p>That's far better than freezing computer which doesn't work, doesn't run any apps. If I don't need apple mercy and protection please don't force me.<p>Already installed Linux and its a start.
Yeesh, "It's not THAT bad, it ONLY leaks the developer of every app you open, via cleartext. Oh, and it cripples your offline software when someone spills coffee over Apple's servers"<p>This is the reason people laugh at this website.
Being able to identify the developer of any app I run on my own machine is already too far. You have to assume all these requests are logged and available for state actors on legal demand.<p>I wonder how big a local revocation list would be. I would support a on-by-default local check.
A caveat to blocking ocsp.apple.com is that I discovered Apple is running more than one service on that domain.<p><a href="http://ocsp.apple.com/ocsp-devid01" rel="nofollow">http://ocsp.apple.com/ocsp-devid01</a> is Developer ID, but <a href="http://ocsp.apple.com/ocsp03-apevsrsa2g101" rel="nofollow">http://ocsp.apple.com/ocsp03-apevsrsa2g101</a> is something else, which if blocked can prevent the Mac App Store from loading.
Has anyone used a pi-hole to block apple privileged servers, like the OCSP one, while running Big Sur? I'm thinking of setting one up---not necessarily to block OCSP, because the points in this post about actually wanting to know when a certificate has been revoked are sensible---but to at least have the option in case of another disaster...<p>Relatedly, does anyone know if Big Sur allows one to use a custom DNS server on the device level with those privileged destinations? (He says, mulling the complexities of getting a pi-hole working with his mesh system.)
Not sure whether the non-privacy related aspect about OCSP is less worrying. Officially Apple does this to protect innocent users from malware, but as we've seen it also allows them to remotely disable any developers' software. Not really something that I'd want on my machine.
Now just waiting for the trolls to write some software that makes the response always cause it to be invalid. With a wee bit of ARP magic, you could make a bunch of mac users very unhappy at the cafe's.
“It doesn’t send a hash of the app, it sends a thing that is a encoded hash that uniquely identifies the app! Totally different!”<p>It wasn’t a misunderstanding, it was a simplification so that people could understand the issue without me explaining OCSP and app signing and x509 and the PKI. Dozens of people wrote me to thank me for explaining it in a way that they could understand.<p>It is indeed a hash, and it does indeed uniquely identify most apps, and it is indeed sent in plaintext, when you launch the app (and is cached for a half day IIRC). I very deliberately didn’t claim it is a hash of the content of the app file.<p>It also doesn’t send a unique identifier, but I would be willing to wager that the set of apps that you launch in 48h is probably enough to uniquely identify your machine in the vast majority of cases.
By default, Android logs every app you use. You have to disable - bafflingly - features including saving locations in Google Maps and fully-functional voice recognition to (supposedly) disable that behavior. What I'm saying is: don't look so surprised.
> As you probably have already learned during Apple’s OCSP responder outage, you can block OCSP requests in several ways, the most popular ones being Little Snitch<p>Uninformed advice - apple prevents little snitch from blocking this traffic in big sur.
I get that a dev cert isn't the same as identifying the software itself... but that only applies for developers that have multiple apps, and I suspect most do not.<p>Then unencrypted requests are also a Bad Thing, because anyone has access to the same info - it may require a lot of work to get general knowledge of what apps someone is using, but if you were looking for a specific one then I don't see any real difficulty identifying that.<p>e.g. if I wanted to know if someone was using signal I just look for the signal cert being queried. That's a much easier problem, and can be dangerous to the end user.
The fact that this was included in the OS without raising alarms is quite revealing in terms of privacy concerns.<p>Question, is there a good justification to use not use hierachical certificates like web browsers or other OSes ?
Apple's decisions about OCSP decry two indisputable facts that contradict Apple marketing:<p>Apple does not prioritize privacy.
Apple does not prioritize availability.
Good write-up.<p>I write a lot of Go on my Mac at home. The first run is _always_ slow, but I've never measured it or bothered to find out why. This is a real "lightbulb moment" for me.<p>I just built a Go executable and timed it: 0.194 for the first, and ~0.018 for subsequent. I haven't signed code on Mac platforms before, so I figured I'd give it a go using the Apple code signing guide [0]. So, I created a self-signed certificate using Keychain, changed and built a Go project, signed the executable [1], and ran it: ~0.400 for the first run, and ~0.018 for subsequent. It... doubled? Will this happen on every first run still? Is there a way to exclude executables?<p>[0] <a href="https://developer.apple.com/library/archive/documentation/Security/Conceptual/CodeSigningGuide/Procedures/Procedures.html" rel="nofollow">https://developer.apple.com/library/archive/documentation/Se...</a><p>[1] codesign -s <cert_id> <path>
Worked a major virus company. This was the same Basic technique. W e would download a list of all md5 hashes. All executables would have to match against it.<p>Periodically there would be an issue downloading the updates. Would result in similar problems.<p>Managing size of updates was a big issue. Just checking against an online server is certainly a more up to date approach
in my opinion, this seems like Apple, once a computer company that catered to computer users and the expectations of computer users, is now a mobile phone company catering to and responsive to the lower expectations of phone users. to engineer these plain text surveillance communications over the public internet between a users private computer and the company responsible for building that computer is like if my home informed the company that built my home every time I started any unique activity while inhabiting said home, as long as I hadn’t been engaged in that activity for some amount of time. It’s extremely disrespectful to Apples users, who are also Apples customers, who are also mostly all of us on this message board. My goal is to one day grow a backbone and stop putting up with this.
Apple has always been a gated community, but now there’s a guard at the gate checking everything that goes in and out. This is something most users probably don’t want. It has me personally considering what a future without Apple would look like.
This still allows Apple (and ISPs, employers etc) to correlate very sensitive information: developer certificates and IP addresses. Plenty of developers only create one application,
and most Macs will be used most frequently on a small number of (ranges of) IP addresses. In essence that still let’s Apple see way more than a self-proclaimed “privacy conscious” company should.<p>Why not take a more privacy-centric approach? Antivirus companies have been working with “virus definitions” for ages. Ad blockers use the same model, but for locally stored blacklists. Why can Apple not regularly download a list of revoked certificates and maintain it locally?
I have always been annoyed by OCSP being HTTP. It is really the fault of the standard that this is the way we revoke certificates. I basically agree that Apple should just be downloading revoked certificates and checking them locally. This is what we are doing at various SaaS companies that have to check these in order to avoid downtime. We have also mistakenly failed-closed. We now default to fail-open but customers have the option to change that if they are paranoid.
Very curious, what's opaque about a uniq developer id of an app you start? Sure looks like gaslighting.<p>"You should be aware that macOS might transmit some opaque information..."
whatever happened to letting the user decide which application they wanted to run? now the mothership has to give their blessing before they let you run it... sounds insane.
The request obviously sends lots more information than just the serial number of the developer certificate. Is it "harmless" data or could they have more info about the executable in there?<p>Why don't the author post the OCSP request of Thunderbird too? And how about another request for Firefox so we can compare the data?
This article really doesn't clear anything up for me...
> Maybe the hash is computed only once (e.g. the first time you run the app) and it is stored somewhere.<p>This would explain why some games take minutes to launch the first time to run them. I've experienced this many times with Steam. You install a game, you launch it, and nothing happens for up to several minutes, and then the game runs. No delays after in launching after that.
Technically AFAIK, the revocation list could be turned into a Bloom filter (or one of its alternatives) and updated from the servers periodically.<p>edit: on 2nd thought just a list of hashed cert ids could suffice because it is hard to imagine there ever being thousands of revocations.<p>That way the provider would have no knowledge of which certs are being verified.
I see no reason why OCSP checks on developer certificates cannot be encrypted. This whole "oh no there could be a loop for a SSL cert check" argument seems like gaslighting. Why can't the client know if it wants to access an OCSP server using HTTP or HTTPS, and default to HTTPS when possible?
The idea that sending information about the cert is somehow not exposing the app is crazy. An attacker could easily download apps and sniff the network traffic to correlate cert info with an app.<p>Also i don't get the argument for using HTTP. Aren't these two separate systems?
There is a local save which manages your app Screen Time (App Settings -> Screen Time) but did not imagine hashes sent.<p>How does one go about setting up (easy) server of some sort to see what servers are being connected say when investigating a different area?
If this is just a matter of revoked certificates, Apple could very easily setup a subscription for developer certificates on the machine when an app is installed. Why wait to check if a certificate is revoked once an app is launched?
It feels like this is the type of response where we were at with Windows when they were forcing updates etc.<p>They backpedaled a little bit when you were forced to log in through a Microsoft account and people semi-rioted but came back pretty strong.
Are there any pi-hole settings to prevent Apple from phoning home? And the same for Windows 10? I can't trust my computers any longer so I need to rely on external enforcement.
To be generous, Apple has unwittingly created an app use surveillance possibility. All from the idea of developer certificates and diligent revocation checks.
i feel this is irrelevant.
apple offers app analytics to developers.
which means app usage data is going to apple anyway.<p><a href="https://developer.apple.com/app-store-connect/analytics/" rel="nofollow">https://developer.apple.com/app-store-connect/analytics/</a>
If anyone is concerned with ocsp activity and verifications being requested all over the web, then oh boy stay away from https.<p>OCSP is a good thing, and the web - and your signed applications - are better off with it.
tldr: no, but yes.<p>It logs app certificate requests which in real life is pretty much equivalent to logging app runs. And that line about only calling the server from time to time is bullcrap. I have years of experience on this issue because my internet is pretty shitty. And that "from time to time" is every couple of hours.
We have been warned and ignored the warning:
<a href="https://prism-break.org/en/" rel="nofollow">https://prism-break.org/en/</a>
There are two issues here. One is the privacy problem which I agree is not quite as bad as some think. The second is the stupid fact that if some server goes down you can’t launch apps. That is just awful.
I think it would help if someone could quote or reference Apple's official position / explanation on this (if there is one).<p>You know, before declaring the end of the world, is there any information from the source (Apple)? Discussions here seem to have had several thousand comments without obtaining this basic info. It would be good to know, I would think?