I hope they will at least prompt the user to let them know what’s going on. I’ve run into this before on macOS, where an app wouldn’t launch, and on a hunch I went into the security settings and saw a section there were it was blocked and I could allow it. There was not even a hint of this in the error message when trying to launch the app. It was a very poor experience.
I’ll also be curious if placing the app in ~/Applications avoids the restriction. This has long been my way to get around some of the restrictions at work. /Applications requires admin rights, ~/Applications does not. Apps still show up in LaunchPad and work as normal (as far as I’ve seen), they are just only available to the user, instead of all users, which is fine for my situation. I used to have to request admin rights every time VS Code wanted to update on my work laptop, but since I put it in my user folder instead, it’s been smooth sailing.
Yes, make macOS more and more like iPadOS so their users can do less and less other than buying apps from the app store and scrolling through the slop on Safari.
Apple kinda reminds me of Intel in the 2010's ( not 1-1 comparison ), hollowed and rotting inside but in a constant party because $$ coming in and line going up..
They wrongly think because they control the dials when things start to go south they can just step on the gas and change course, it's a fools illusion because the people who actually can make a difference will not be there and the whole organization already is tuned for the wrong incentives, so when Tim Apple's minions step of the gas... nothing will happen other than pumping out more "beautiful, amazing, thinner" but useless slop.
> Yes, make macOS more and more like iPadOS so their users can do less and less other than buying apps from the app store and scrolling through the slop on Safari.
This doesn't seem at all a fair characterization of what happened here - you can still run these applications, they just added a (seemingly pretty reasonable) step to do so. I don't see this as allowing users to do less, and I struggle to find a strong argument against this when the typical user is not a l33t hacker type and most typical users find it extremely easy to download and run malware.
> you can still run these applications, they just added a (seemingly pretty reasonable) step to do so.
Every version of macOS makes it harder and harder to run unsigned code. They keep pushing the bypass deeper and making it less convenient. It’s super super annoying and stupid.
Protecting users against malware should be the job of XProtect. If a naive user can run malware via right-clicking, they can do it nearly as easily through the Privacy & Security page. All this change does is bring unsigned software closer to outright deprecation, at which point Apple can backdoor app review through notarization just like they do on iOS in the EU.
I’m probably viewing this too much in the lens of an IT administrator, I absolutely do not want any of my machines to run unsigned applications and I can’t think of any reasons I personally would want to, so for me, that friction is a good thing.
As to what Apple may eventually do, just seems a little speculative.
You don't need to distribute via the app store for your app to be notarized, you just need to have an apple developer account ($99/year) and go through the notarization flow, which is automated and typically takes less than a minute.
You're free to distribute (and sell) your notarized app however you want.
Sure, to notarize a new version you need to have an active subscription. I pay the fee out of my entertainment budget because writing Apple platform apps in my free time is more fun than tv. It’s less than the price of Netflix too.
~$100/year is not nothing outside the first world. Esp when you need to balance it with other subscription costs. The hardware is owned by other people. Why should one have to pay Apple for running a binary outside their premises ? Its just plain tyranny.
This is something I could see a group like Software in the Public Interest doing. They’re not going anywhere or changing hands for the next foreseeable version of your GUI Mac App
It also adds a new permission prompt for screenshot and screen recording apps that doesn’t allow a user to permanently grant permission, but requires a weekly re-authorization.
I hate the periodic location permission prompts on iOS. Big tech companies are increasingly paternalistic with this stuff, like their users are all idiots who need to be managed like little children. Some other examples I've recently encountered:
- 1Password requires supplying a password hint when changing the master password.
- Unifi OS enforcing password quality requirements even when locally/self hosted.
- "Set up later" (instead of "No") as the negative option for various "helpful" feature prompts in iOS.
It’s worth keeping in mind that in the case of Apple platforms, a lot of this has roots in the revelation a decade and change ago that third party software on mobile platforms can and will exploit every affordance the operating system offers to extract data, often silently. It’s no different on desktop OSes, but users have been more acclimated to it there since full blown access to everything has been the norm there longer than it hasn’t.
That said I can certainly see the argument that Apple isn’t going about handling this set of problems correctly, but ignoring it or pretending it doesn’t exist isn’t right either.
> It’s no different on desktop OSes, but users have been more acclimated to it there since full blown access to everything has been the norm there longer than it hasn’t.
This is a problem with proprietary software markets in particular. You can largely escape this dilemma if you source your software from a free software distribution like a Linux distro, Conda, Pkgsrc, F-Droid, etc., because they have their own processes and standards for curating, vetting, categorizating and sometimes even patching software.
One of the reasons that desktop Linux has lagged with app sandboxing and binary attestation compared to macOS is that proprietary apps are marginal and few on most Linux desktops. Linux users are not choosing the bulk of their software from a giant pile of borderline malicious shitware like users of mobile apps generally are. (It's a good thing that Linux is catching up in this respect because some proprietary crap, like Discord, Google Chrome, VSCode, Steam, and Zoom, is extremely sticky for new users coming from proprietary operating systems where proprietary apps are the norm as well as strongly incentivized by powerful network effects. Vendors of such software have proven that they can't be trusted to follow reasonable conventions with DEB or RPM repositories, and Flatpak will suits untrustworthy vendors and other third parties better.)
> I can certainly see the argument that Apple isn’t going about handling this set of problems correctly, but ignoring it or pretending it doesn’t exist isn’t right either.
Apple is understandably prioritizing the realities of the ecosystems that the bulk of their existing users navigate, namely one of publishers selling software as commodities and services for financial profit. But it's not the only conceivable path forward because not all ecosystems of usable software are dominated by producers facing such incentives. You can answer the proprietary hellscape by stepping away from it instead of letting yourself be hampered by shit like this on your own machine.
Most people would not have an easy time completely eliminating proprietary software from day to day usage. Reducing the amount of it is certainly possible (though may come with caveats WRT ease of use/UX; F-droid for example is not fun to try to comb through to find the good bits), but some amount is going to linger even if it’s just games the user plays to blow off some steam at the end of the day.
Even if full-FOSS were practical, I’d still want robust sandboxing and permissions to help limit the blast radius if some malicious executable manages to find its way in and to feel confident that nothing is poking around where it shouldn’t be. There’s not really a good reason for everything to have access to everything except for convenience.
But if you're looking for a way out from Apple's paternalism without giving up too much practical security, getting your software from free software distributions as much as possible and treating F/OSS as your 'home base' is a doable first step for readers of this site that will go some distance. For example, on macOS, disabling Gatekeeper for software that you install via a package manager whose repositories have a code review process and which cryptographically verifies what it downloads is not a big deal. (Homebrew does such verification, but not for all packages. You can tell it to refuse to install what it can't verify in this way, though. So all my Homebrew apps get installed only if the package has a checksum in the repos, and when installed they get --no-quarantine.)
And if you can switch to Linux on the desktop, it's reasonable to approach app sandboxing in an opt-in way. It's nice to be able to do that, especially as some of the UX pain points are still being worked out. It's also nice to know that no matter what nice capabilities your OS offers for securing your system by treating apps as untrusted by default, you'll ultimately be in control.
Sandboxing is also somewhat a separate issue from code signing and notarization, and idk what's even really practically available on the Linux desktop for that. But I'm not really sold on those so much for use of those outside the enterprise. I imagine most people here would opt out of those given the choice.
>like their users are all idiots who need to be managed like little children
Most are.
But the OSes could be designed way better for this stuff too.
Give the user security but also total visibility. A central place to grant/revoke app permissions, and to check what all apps ask for, click to see their "privacy policy" or lack thereof, has an easy way to filter to see e.g. "which apps use the camera, when they last used it", etc.
When some app is blocked and you wonder why it doesn't work, it should be easy to see a list of "blocked apps" and sort them by "when they were blocked" and other such things.
I'm not; it's passive-aggressive. Any dialogue of the form "Yes"/"Ask Later" is a framing that prevents you from saying "No, go away forever, I don't want this ever".
I've spend literally days attempting to get a Python-based GUI application "signed", using every available packaging option and dozens of different approaches recommended by a multitude of different sources.
Absolute failure -- and no usable error messages indicating what might be wrong. Just basically "no, you can't upload that.".
I think that's the biggest issue with code signing, Xcode should come with a "Sign and Notarize.app" that allows you to sign anything you point it at with a single click.
Admittedly, I've done 99% of my development to target Linux, and just happen to use a Mac for its simpler and less time-consuming day-to-day GUI management.
This is the first time I've tried to develop something to target a macOS installation -- and it was a train-wreck.
This will mostly affect advanced users. Hopefully, my next update will be Asahi, once its hardware support (especially HDMI output) has advanced enough.
I tried Asahi on my older M1 macbook and the battery life is still very bad. I am pretty experienced trying to dive into CPU schedulers and kernel settings, etc. to try and fix it, but I was unable to squeeze more than about 3 hours of battery out of the laptop WHILE CLOSED! In contrast just booting up mac os the battery lasts about 36 hours+ while closed.
When did you try it? There were some big improvements recently:
> Putting EAS and utilisation clamping together, we took a 15" M2 MacBook Air from about 6 hours of useable battery life just sitting at the desktop to about 8-10 hours of 1080p30 YouTube, 12-15 hours of desktop use, and an enormous 25-28 hours of screen-off idle time. We still have many more tricks up our sleeves to eke out more battery life, and a deep dive on EAS utilisation clamping is in the works. Watch this space!
I bought a used M1 Max MBP recently, in part because the Asahi features table is starting to look pretty good.
But with the remaining outstanding hardware issues and the battery life gap in mind, I will probably get an overall better experience sooner if I just pony up for the upcoming Snapdragon X Elite laptop from Tuxedo Computers¹. :-\
On the other hand, the whole Linux desktop stack has benefited from work that Asahi devs have done, so I think that project is still undeniably valuable even for users on other aarch64 hardware.
Apple seems to like to coerce their users onto their preferred track little by little, release after release, instead of hamfistedly forcing it on day one. Instead, each release is a small drip of inconvenience and nudging.
Long time ago, you could run any executable you wanted. Then, you got a little nag, but whatever. Then (I think) you had to right click and take an extra step to run them, with a scary warning. Then, you got an even scarier warning and had to navigate into Settings to select "Allow applications downloaded from" -> Anywhere. Then, they removed the "Anywhere" option, but you could re-enable it with the command line.
It's also directionally clear: They surely intend to fully boil the frog one day and remove the ability to do this.
Se also: The UX you have to navigate in order to fill your own password into web pages on Safari.
> In macOS Sequoia, users will no longer be able to Control-click to override Gatekeeper when opening software that isn’t signed correctly or notarized.
Will Right Click > Open still work? That is how I currently bypass this issue with unsigned applications.
As well as `sudo spctl --master-disable`, except it now gets reset sometimes because you know, computers are so unreliable, they forget things all the time.
I've had some apps refuse to run until I acknowledged their signer in the Security & Privacy section of System Preferences even though the quarantine bit was not set, unfortunately.
Did the app include a system or kernel extension? Because I'm pretty sure these always require Security & Privacy authorization even when unquarantined, signed, and notarized.
The two that I saw this were OrbStack and Podman Desktop, when their signatures were replaced (I think to ensure that their trampoline (launcher shim) apps could have the same signatures as the real apps).
Maybe apps that use Apple's virtualization APIs qualify here?
Here's the context of that experiment, after which I went back to installing those apps via brew and using them without such modifications: https://news.ycombinator.com/item?id=41126387
Sorry Apple, but I have no intention to pay 100€ per year for the privilege to notarise an application I have up for free on a GitHub repo no matter how shitty you make the process.
At the moment I'm just linking to https://disable-gatekeeper.github.io/ and hoping that if anyone ever comes across my repo, that they know how to read and won't bother me about it. Maybe in the future the optimal solution would be to just not provide any pre-built binaries.
Yeah, this is exactly the problem. Apple doesn't want hobbyist programmers either on iOS or MacOS. They see inconveniencing open source programmers who aren't selling a product (and therefore not going to pay Apple for the right of being an "official developer") as a good thing.
The usual arguments I hear for this is grandma or kid following these specific instructions and installing a malware. But how many attacks make use of these?
It's a cancer in the sense that it is a growing and spreading idea in Apple's ecosystem, and is strangling the usability of its products. It doesn't really resemble a genocide metaphorically.
I’ll also be curious if placing the app in ~/Applications avoids the restriction. This has long been my way to get around some of the restrictions at work. /Applications requires admin rights, ~/Applications does not. Apps still show up in LaunchPad and work as normal (as far as I’ve seen), they are just only available to the user, instead of all users, which is fine for my situation. I used to have to request admin rights every time VS Code wanted to update on my work laptop, but since I put it in my user folder instead, it’s been smooth sailing.