Application Trust Is Hard, but Apple Does It Well ⇥ security-embedded.com

I promise just one more link about this overblown Apple certificate mess, but it is a good one. Phil Vachon’s piece is comprehensive, and I thought this was a thoughtful counterpoint:

One might argue Apple has catered to the lowest common denominator in this case. There’s some truth to this — you don’t want to start a war against your users and assume they’re stupid. But if people who are “information security professionals” can’t even tell you what the implications of various controls truly are (due to the vast complexity of these systems), how could your average user make these decisions?

Finally, there’s the open source argument — if I have the code, build the code, nothing can hide in the code. This is a fallacy that people buy in to thanks to effective marketing by the open source community. Software systems are so complex today that subtle issues lurk in even the most carefully curated code bases. Would a Chrome build that you built yourself and are running be inherently more secure or less likely to be compromised than one you downloaded from Google that was co-signed by Apple? Definitely not (I’d argue the other direction, in fact, but that is not germane to this conversation), but the Chrome build co-signed by Apple could be revoked if there turns out to be some malware embedded in the package. This is an interesting control that benefits users massively.

If you are absolutely furious with the way certificates are handled on MacOS, Apple is working on a solution for you. For what it is worth, I am keeping these protections switched on unless I hear a terrific reason for disabling them. I am fairly confident in my ability to avoid malware and other nefarious processes, but I am not so conceited as to think that I could not use a second set of eyes, as it were. This is especially true now that I have been working from my home computer for eight months.