> "Those who consider that Apple’s current online certificate checks are unnecessary, invasive or controlling should familiarise themselves with how they have come about, and their importance to macOS security. They should also explain how, having enjoyed their benefits for a couple of years, they’ve suddenly decided they were such a bad idea after all, and what should replace them."
A simple opt-out toggle, for privacy reasons, would be a good start... people should stay in control of their own data and be able to choose themselves whether or not they are willing to trade in their privacy (for security in this case).
Apple has said they plan to do this, and also encrypt the checking payload. Sounds good to me, though definitely a privacy failure that they didn't do this in the first place.
The other thing I'd like to see is the app open immediately, w/ the check happening asynchronously in the background. (This seems like super-basic good engineering to me.) No idea if they're planning to fix that or not.
> The other thing I'd like to see is the app open immediately, w/ the check happening asynchronously in the background. (This seems like super-basic good engineering to me.) No idea if they're planning to fix that or not.
How would this work? The point of the check is to block malware from running, and opening without the check would, by definition, negate the entire system. If malware authors get wise to the async scheme, they can write programs that deliver their payload in the opening milliseconds of an app’s execution, while the network call is running (even the fastest pings would leave 1 or 2 ms worth of window).
Fair question. My thinking was the system is already not designed to be failproof, just mitigitive (it turns off entirely if no internet), and that malware would be pretty limited in what it could do in just a few hundred ms.
Waiting to open an app based on a network request is basically just guaranteed to give you a terrible experience some % of the time.
Maybe fancier solutions like a local blacklist are needed. (Which weirdly it looks like Apple had and then moved away from?)
But that would defeat the purpose. Apple can be thought of as the equivalent of the NSA: they "care" about your privacy in the sense that they don't want anybody but themselves to have access to it.
Unfortunately we don't have an Apple competitor that cares enough about your privacy to not want anybody, including themselves, to have access to it.
> navigating the complexities of dealing with different governments
That's how kids call "handing over all cloud customer data to FBI" these days?
Holy whitewashing batman, that's a lot of speculative mental gymnastics.
To put it simply you have no evidence that supports Apple here other than a "but perhaps the alternative was... whatever I just came up with" .
To paraphrase yourself in another comment: "that's intellectual dishonesty about Apple."
If Apple cared a single bit about privacy it would have encrypted customer data from the begining instead of planning to eventually do it one day only to give up uppon FBI request.
This is turning out to be a bit of a similar case as the iPhone battery degradation performance throttling issue. Instead of clearly messaging what they were doing to your phone, they did things behind the scenes because they knew better, and decided not to give the user the choice to run the phone at full performance.
You clearly need to familiarize yourself with the actual facts of this case. Also, I'm pretty sure that for 99% of users, "full performance" is not characterized by "randomly crashing due to lack of intelligent power management".
A simple opt-out toggle, for privacy reasons, would be a good start... people should stay in control of their own data and be able to choose themselves whether or not they are willing to trade in their privacy (for security in this case).