> Apple has gone one step further, and now macOS on ARM Macs requires signed binaries, and it will not run unsigned ones.
Apple Silicon Macs will not run unsigned binaries, but the binaries can have any signature, so you can just generate one yourself and add it. There's no need for a developer account, or any other external party. And there are no issues with legacy support either, because ARM Mac binaries didn't exist until now (and the requirement does not apply to Intel apps being run via Rosetta).
This really isn't a big deal.
I was initially worried that mandatory code signing would prevent me from hex editing binaries (which is a thing I do sometimes), but I recently learned that codesign can replace a binary's existing signature. So even that shouldn't be a problem.
> They will not run unsigned binaries, but the binaries can have any signature, so you can just generate one yourself and add it. No need for a developer account, or any other external server or party. And there's no issues with legacy support because ARM Mac binaries didn't exist before now (and the requirement does not apply to Intel apps being run via Rosetta).
Self-signed applications are treated as if they're radioactive by macOS, too.
> This really isn't a big deal.
They've been turning the screws slowly over the last two years. It only takes another turn for them to switch off support for self-signed apps for security reasons. Browsers already do this for self-signed certificates.
It's just not something I'm willing to base my purchasing decisions on, nor the decisions about what desktop platforms I target with my applications.
> Self-signed applications are treated as if they're radioactive by macOS, too.
But not if you turn off Gatekeeper! I can understand how this is annoying if you're creating apps for other people, but in terms of my own personal experience with my computer, the only time I think about Gatekeeper is when I'm talking about it on HN. It gets turned off as part of a bash script I run after installing macOS, at which point it's gone for good.
On my list of annoyances with macOS, Gatekeeper is somewhere below the Library folder being hidden by default. I can't say what Apple will decide to do in the future, but I have a very clear line in the sand, and Apple has absolutely not crossed it.
Gatekeeper-by-default is sensible IMO. I've seen how some people interact with these devices, and how easily malware gets on a computer.
As long as the walled garden can be easily circumvented, advanced users can do what they wish. "Able to learn about Gatekeeper and decide if they should turn it off" is probably an okay heuristic for "can tell a fake Flash installer site apart from a real one" or even "knows that Flash is pretty much abandoned, do everything you can to avoid it".
That said, it absolutely changes the incentive structures, and Apple is also doing it for profit. Will they cross the line in the future, with this goal? I expect they will conclude losing the advanced users would be a net loss.
> As long as the walled garden can be easily circumvented, advanced users can do what they wish. "Able to learn about Gatekeeper and decide if they should turn it off" is probably an okay heuristic for "can tell a fake Flash installer site apart from a real one" or even "knows that Flash is pretty much abandoned, do everything you can to avoid it".
That's exactly how I see it! And this mentality continues throughout the chain, too—if you want to actually install unsigned kernel extensions, or inject code into other processes, you need to boot into recovery mode to disable SIP. This is still not at all onerous if you know what you're doing (and, like Gatekeeper, you only need to do it once), but it's definitely a next-level test for next-level privileges.
IMO, the way Apple designed this process is brilliant! And that's why I'm not personally concerned by the boiling water argument, at least not yet—whatever Apple's incentives, the current setup strikes me as the best way to handle things.
All of that said, where I am starting to get annoyed is with the root snapshot stuff in Big Sur. Having to reboot every time I want to edit a system file is a clear progression from "trivial speed bump" into "consistent pain-in-the-ass" territory. If you want to talk about Apple locking down the Mac, I'd start there!
Can't you still go through the song and dance of disabling SIP and authenticated root and then editing the root snapshot? It's incredibly annoying but should still work, right?
Generally things don’t like it very much when I lie to them about what OS they’re running on; I try to set the version just before opening Xcode and fix it then right after I’m done submitting the app so my computer isn’t confused. More than once that has been long enough for Software Update to get confused and offer me a new build :P
The problem is that it makes it clear that the market for third-party software is completely at Apple's pleasure.
If Apple chooses not to issue me a Developer ID, they have effectively removed 95%+ of my market.
If this is because I distributed malware, that's reasonable. But there are a lot of other reasons why Apple might choose to revoke a Developer ID. (Think pressure from the state, for one.)
I also feel like in the spirit of the OP: it’s like telling customers that they can drive without a seatbelt and it will save them time getting in/out of the car.
Most will look at you like you’ve got three heads, and (I suspect) the majority will simply walk away without purchasing.
Your just assuming it’s a pot and want to persuade me to jump into the freezing river instead. But Apple may have no intention to completely lock down the Mac. It may well be just a hot tub, and right now it’s quite comfortable. If it gets too hot, I’ll just get out.
I understand the analogy. You are asserting that it's a pot, but that's just an opinion. Anyway the analogy just doesn't work. Why can't I get out of the Apple ecosystem if it gets too hot, what's stopping me?
"The boiling frog is a fable describing a frog being slowly boiled alive.
The premise is that if a frog is put suddenly into boiling water, it will jump out, but if the frog is put in tepid water which is then brought to a boil slowly, it will not perceive the danger and will be cooked to death.
The story is often used as a metaphor for the inability or unwillingness of people to react to or be aware of sinister threats that arise gradually rather than suddenly."
In the case of Apple, at some point when they do something you really dislike you might be too invested into the ecosystem and it will be easier to just accept it instead of leaving.
But if you were not on their ecosystem already and were thinking of switching to Apple you would just think "Yeah, I really dislike that new move, I'm not buying into it".
I believe to get the behavior you need a brainless frog - they are shockingly functional due to how much behavior is in bodily reflexes. In that context the brainless frog sort of fits as a metaphor of "cargo culted" or tradition fixed behavior or single strategy. An approach well adapted enough to the expected environment that no thinking is required but is doomed as soon as it has to deal with change.
sorry to be pedantic, but if you believe wikipedia, it is true (just you probably cant reproduce it on your kitchen stove)
--
The New Psychology (1897): "a live frog can actually be boiled without a movement if the water is heated slowly enough; in one experiment the temperature was raised at a rate of 0.002°C per second, and the frog was found dead at the end of 2½ hours without having moved."
> But Apple may have no intention to completely lock down the Mac.
They've been very gradually locking it down for years and show no signs of stopping. Plus they have an obvious financial motivation to lock it down. To give them the benefit of the doubt here is naive to say the least.
There isn't really any - it's just a smaller change than banning unsigned apps completely. Their strategy for forcing people to use the app store is to very gradually make it more and more inconvenient not to. This is one of those gradual changes.
Imagine the next ones:
1. You have to enable an option in settings to allow running self-signed apps.
2. You have to disable SIP to allow running self-signed apps.
3. Apps can only be self-signed via Apple's website.
Apple Silicon Macs will not run unsigned binaries, but the binaries can have any signature, so you can just generate one yourself and add it. There's no need for a developer account, or any other external party. And there are no issues with legacy support either, because ARM Mac binaries didn't exist until now (and the requirement does not apply to Intel apps being run via Rosetta).
This really isn't a big deal.
I was initially worried that mandatory code signing would prevent me from hex editing binaries (which is a thing I do sometimes), but I recently learned that codesign can replace a binary's existing signature. So even that shouldn't be a problem.