Apple doesn't require a paid developer account to do this, and it's also not actually required. A user can still click "Open" from the right-click menu on a newly downloaded app to open it for the first time, and then double click the app to open it subsequent times like normal.
This is Apple's official line, but no one is going to actually have to do anything different if they don't want to. Some not-so-tech-savvy users might end up with apps they don't understand how to open after downloading them, but those are also the user most susceptible to falling for malicious downloads, so I'd call it a pretty good security feature.
Anyway, were any of you who are complaining in this thread planning on actually publishing an app for macOS, or just here to beat a dead horse?
> Anyway, were any of you who are complaining in this thread planning on actually publishing an app for macOS, or just here to beat a dead horse?
Anecdotally, I find that the people who are loudest about Apple's misdeeds (both real and assumed) are often people who've never even used an Apple product.
There is plenty of legit criticism of Apple to be made, and you certainly don't have to be an Apple customer to make it. But half the time what I see instead is pearl-clutching from people who don't have enough experience with the platform in question to tell what an announced change even does, blowing up what amount to minor inconveniences into the end of all life as we know it.
> Anecdotally, I find that the people who are loudest about Apple's misdeeds (both real and assumed) are often people who've never even used an Apple product.
The other side of this is, when I complain about Apple not allowing sideloading on iOS, I get asked why I use an iPhone if I don't like the policy.
(fwiw, I have no issues with macOS as long as unsigned apps can still be run, and lots of issues with iOS where they cannot be.)
there’s no way to publish apps to iOS except paid Apple Developer account.
That’s different than all other platforms where we can get any binary to run.
Other companies only require account for using non-OS API such as Firebase / Google Services for example.
You very much can build and sideload an IPA on iOS if you have (access to) a computer running macOS.
Sure that's beyond the reach of most people, but how on earth do you people imagine that people develop and test new apps on iOS devices if you think an app _must_ be published to the App Store to run at all?
I feel like I have this discussion every week. It’s technically possible but—by design—practically unworkable for apps you actually want to use rather than just test. They expire after seven days, at which point you need to reconnect to a computer and reinstall them.
Yes. It’s interesting approach. Still your apps will be timebombed for 7 days.
Imagine making a app for private use by my family and going on vacation longer than 7 days. I must have access to my computer...
And that's a legitimate complaint, and one I have as well (though my issue is less with not allowing sideloading and more with the pretty high barrier to entry to the only official distribution method. I'd be pretty much okay with being unable to sideload apps on iOS, but having a free and more lax tier of the App Store for hobbyists (somewhat akin to Youtube's unlisted videos or Qt's licensing).
I'm not sure that I follow. You can sideload apps on iOS. Is the issue that you have to use a computer to do it?
I kinda like that requirement because it means that I'm technically capable enough to make a potentially system-breaking change. It's not as nice and friendly about it as macOS but I think it's a fair compromise.
> Anecdotally, I find that the people who are loudest about Apple's misdeeds (both real and assumed) are often people who've never even used an Apple product.
Interesting. The number of people of who I know that they have complained about Apple, and of who I also know that they have never used an Apple product is zero.
And the number of people I know who complain about Apple and who have never used an Apple product is non-zero. _Interestingly_, that's kind of what the word "anecdotally" implies.
If one actually considers the spirit of my comment (people getting caught up in outrage about issues they can't actually judge properly), several of the comments of this very post make it pretty clear that their authors have likely never interacted with a Mac for a day in their lives but are nevertheless very opinionated about how this change will affect macOS users.
If your comment wasn’t the one that I was describing...or even responding to, then I think you can safely assume that your comment wasn’t the one that I was talking about. xD
I was agreeing with this person that I responded to and talking about the one that you responded to.
It’s definitely easy to get confused with the HN ui though. I wish they would put vertical lines or something to the parent comment or just think of something better. I thought we had half of the worlds software geniuses here! Can’t we figure this out?
Interestingly, I find the same to be true about people who complain about Android here on HN. And I feel it is for the same reason as you've mentioned. I cannot count the number of times I've had to laugh in pain at the shocking ignorance displayed by a large number of users when talking about Android and other associated Google products.
> Anecdotally, I find that the people who are loudest about Apple's misdeeds (both real and assumed) are often people who've never even used an Apple product.
And those who are loudest about animal abuse in factory farming, don't eat meat.
I have to use so Apple products, although mainly mobile devices. I don't have any deeper prejudice against the users but think the devices are mostly useless.
Should people be required to own a Mac to release desktop software for the Mac? It is - or at least was - quite possible to make an application in Electron or Java or some other tool and release it cross-platform, having beta testers handle platforms specific testing.
Now, Apple is making that impossible, which hurts developers who can't afford to go all-in on the mac platform.
I hope you are being sarcastic! That’s a low quality assurance bar, even by a hobbyist’s standards. “My friend with one Mac running one OS version says it works, therefore I’m ready to release?”
I'm not. When you're a high school student releasing your first computer game on a well-tested engine, that's a perfectly valid level of quality assurance.
Not everyone can afford to keep around a lab full of macs running multiple versions of macOS.
I’d think any developer would want at a bare minimum two test machines: one representing the minimum system required by your application including minimum targeted OS version, and a higher end machine running the latest.
Judging my the reaction to my comment, Today I Learned it’s acceptable to release software with only cursory testing on a friend’s computer. Explains a lot about recent software quality actually...
The last place I worked at, it was socially forbidden to automate the digital signing process, such as in a CD pipeline. Now I'm curious to hear if we were being paranoid.
No, from what I understand this only affects binaries through Gatekeeper. Gatekeeper is “opt-in”—sort of. The way it works is that your web browser has an option “LSFileQuarantineEnabled” set in the bundle, and this makes it so files it creates have the “com.apple.quarantine” extended attribute on them by default. This attribute is propagated when you extract archives. When you open a program with the quarantine bit, you get the Gatekeeper warning.
All MacPorts has to do is either avoid setting the quarantine bit in the first place (easy enough) or remove it. The quarantine bit is nothing more than an xattr called “com.apple.quarantine” which you can inspect or remove with the xattr tool.
The MacPorts .pkg installer is probably the only thing affected, and they should be able to get that signed. (Plus, anyone using MacPorts should be capable of the right-click+open workaround.)
Actually an interesting question: will Apple be happy to sign third party app stores and package managers? Including those that, say, sell apps and take a percentage?
Pretty sure they do. Part of the point is that they can revoke the signature once it’s found to be malware, and likely the signatures for everything associated with that developer account.
They try not to, but it certainly seems like Notarization is more to be able to disable malware after it's detected than preventing it from being signed at all.
> The MacPorts installer pkg will need to be submitted, but I don't think much else will change. Using MacPorts-built kernel extensions is already impossible because of signing requirements (we don't have a kext signing certificate and I don't think we qualify for one.)
> For general apps, Gatekeeper doesn't prevent running locally built ones due to them being unsigned, and I gather than notarization is only required in the same circumstances as signing. (It would be incredibly inconvenient for developers to test anything if this were not the case.)
> * For 10.14 users: The pkg meets Apple's new requirements for notarization. This includes enabling the hardened runtime for all executables, which has the potential to cause new issues due to denying access to certain system resources and preventing the loading of unsigned plugins. Please let us know about any such problems.
MacPorts .pkg installers are notarized since 2.6.0.
In early versions of the MacOS beta, the right-click open did not work, nor did starting the app from the command line. I never tried checking for the quarantine attribute and subsequently altering so I cannot comment there.
You also couldn't notarize old apps that weren't built with secure timestamp, hardened runtime, etc (a lot of versions of some software I'm supporting back to 10.7 preexisted some of the required criteria) until the beta release that coincided with this announcement in early September.
I think Apple relaxed their stance here because they did not want the average person to think that Catalina was breaking their apps and have subsequently deferred their "hardening" to January 2020.
10.15 requires signed apps that were signed after 1 July (or June, I don't remember exactly) to be notarized. If you were running a signed after 1 July app but not notarized, that explains it.
Even though you can run unsigned app easily, you can easily apps with a broken signature.
I was trying to run versions of our app built between 2011 - 2016. None of them would open in the MacOS 10.15 beta. Before this September 3rd announcement, any attempt to notarize the app would be rejected for not having hardened runtime. I can still use `xcrun altool --notarization-info` to view old notarization reports and reasons for rejections. One such app from 2014, which I attempted to notarize on 2019-08-23 was rejected for reasons such as:
{
"severity": "error",
"code": null,
"path": "my/app/path",
"message": "The signature does not include a secure timestamp.",
"docUrl": null,
"architecture": "x86_64"
},
{
"severity": "error",
"code": null,
"path": "my/app/path",
"message": "The executable does not have the hardened runtime enabled.",
"docUrl": null,
"architecture": "x86_64"
}
I saw this announcement on September 3rd and upgraded the beta. My apps would not open still. So I went and notarized my old apps and this time all of them succeeded in notarization. As soon as the app was notarized, I could open the app in the beta.
In my opinion, a number of people in these threads are missing the point when they suggest: "You can easily run these programs if you just do these quick tricks like using the command line or removing an xattr from the file or a special click workflow" There are companies out there making software for normal people (ie non technical) who will think your app is broken if double clicking doesn't work. These people will call your support lines and this will cost your company money
>and have subsequently deferred their "hardening" to January 2020
Two months? So Catalina will start breaking apps for average users after only two months? It hardly seems worth it for Apple to have that short of a delay.
Nothing will break. Apps signed before will continue to work like before, apps signed now will required to be notarized. Unsigned apps will work like before.
I was just going by what the person I was replying to (who wasn't you) was saying. If, as that person said, apps will break (or appear to break to average users) once "hardening" kicks in, then delaying it by a mere two months seems almost pointless. On the other hand, if as you say nothing will break, then a two-month delay in hardening seems equally pointless.
Apps that you currently have will not break, as they will not be quarantined. The requirement helps developers of apps that will be downloaded in the future.
If my app completely stops working during a beta, are you suggesting that I should just wait until the actual release to find out that my app is in fact really broken should that be the case? And only then develop a new release for my app and release it as soon as possible, all the while having a deficient product for however long this may take?
I've always viewed a beta as a way to test that my app has not regressed. If it has, I open issues with Apple (or whomever). If these issues are either cited as not-to-be-fixed or I hear nothing back, I will create a release of my apps that works around whatever issues are there. IMO determining breaking changes in beta versions allows one to develop fixes as well as create and plan the rollout of the new software before the beta goes lives (and therefore avoid any regression/downtime).
>Anyway, were any of you who are complaining in this thread planning on actually publishing an app for macOS, or just here to beat a dead horse?
I find this a common problem when it comes to just about anything these days including tech sites where I appreciate that the local community generally is knowledgeable and the likelihood is high that someone(s) has granular knowledge of the topic.
But man when it comes to the big general topics that get a lot of spin in the press it's all "OMG Google" "OMG Apple" "OMG JavaScript" and so forth. But nobody really talks about what the topic means on a functional level.
Ok, imagine if EVERY OS out there had their own signing system like this. Can you imagine how hard it would be to publish multi-platform software!? Sure macOS and Windows are the largest consumer OSes, and I'd be very shocked to hear Linux OSes doing this, but does that really make it OK?
I must be misunderstanding this then... if all I need to do is sign the binary with my GPG key (or comparable) then I don't see what all the fuss is about either!
"Give users even more confidence in your software by submitting it to Apple for notarization"
So it seems the "key" difference here is that while most Linux package managers seem to use GPG to sign based on the author's verification, here Apple is the trusted source, forcing application authors to bow down and submit to review (even if it's automated).
Whereas for all GPG packages I just sign the same way, here my process is different, and Apple is forcing my hand.
Don't get me wrong, I don't want users getting viruses or generally bad software any more than the next guy, but it seems out of place to rely on some specific Apple protocol to do this. Though, it doesn't surprise me at all that Apple wouldn't try to "play nice" in this space.
Edit: further reading finds the following.
"Notarization requires Xcode 10 or later. Building a new app for notarization requires macOS 10.13.6 or later. Stapling an app requires macOS 10.12 or later."
As a developer of some cross platform applications who happily doesn't know anything about Xcode (and plans to keep things that way) I'm upset by this.
> I was under the impression there's a process involved with Apple to approve these things
You're under the wrong impression.
Think of it more like Google's certificate-transparency log.
Apple will have a log of all applications distributed outside of the app-store and macs can consult this transparency log during installation and warn the user if (a) Apple has revoked the certificate because Malware has been detected or (b) the developer who made the software being installed doesn't have an email address. Users will still be free to ignore the error messages (just as they are on Linux and Windows).
> As a developer of some cross platform applications who happily doesn't know anything about Xcode (and plans to keep things that way) I'm upset by this.
I generally advise people to not get upset about things they don't understand and don't care to understand. It feels strange to me that I feel have to give that advice, but what else can I do? People might read your (well-written) comment and develop the same fears and hysteria you have about something they don't understand either, but care to, and that makes the world a worse place.
> I generally advise people to not get upset about things they don't understand and don't care to understand.
I wouldn't say I don't care to understand. In fact quite the opposite. If someone can explain to me how this process should work for applications that distribute to, let's say, 10 different operating systems I'd be all ears.
But what fears and hysterias are you talking about? I quote Apple's own developer material, and complain about what it says. I don't want to deal with Xcode to package apps for macOS, sorry. And I find it somewhat oppressive to force communication upstream to Apple in order to run applications smoothly on their OS.
> I don't want to deal with Xcode to package apps for macOS, sorry.
Then don't.
> I find it somewhat oppressive to force communication upstream to Apple in order to run applications smoothly on their OS.
Yeah, I know, but that's what packaging and releasing is.
On Debian, you need to contact Debian (or a Debian packager) to make your application easy to install and run on Debian because the Debian expectation is that the user runs apt install myprogram to install it, and navigates to the menu and clicks on myprogram to run it.
On Fedora, same same, but with Fedora (and it's rpm/yum/dnf).
On FreeBSD, same same, but with FreeBSD (and it's ports, etc).
And so on.
About the only operating system where the user-expectation was you don't need to talk to anyone is Microsoft, and building the expectation into users that programs can "come from anywhere" is why we had so much malware and junk on Windows. This wasn't a good thing.
I suggest you just get over this. It's better for macOS users, and it doesn't impact power users at all.
> what fears and hysterias are you talking about?
Look around this thread: It's chock full of fudding about how Apple is taking away their freedoms of some kinds, or there's a slippery slope, or that this somehow isn't 100% better for end-users (the people who buy Apple products).
How is having a lot of people afraid about nothing a good thing?
> If someone can explain to me how this process should work for applications that distribute to, let's say, 10 different operating systems I'd be all ears.
I mean, I'm happy to teach you, but I don't work for free. What do I get out of it?
> Look around this thread: It's chock full of fudding about how Apple is taking away their freedoms...
So you project your frustrations with them onto me?
But given how you'd rather type up a long winded rant about ranters rather than answer my simple question, I suspect you either don't know how to do it, or it's in fact not possible. I'm not trying to get free lessons, I'm trying to get someone to prove to me how this works.
> I suspect you either don't know how to do it, or it's in fact not possible. I'm not trying to get free lessons, I'm trying to get someone to prove to me how this works.
Does this work on your tax preparer? I suspect you either don't know how to do my taxes, or it's in fact not possible.
Does this work on your driving instructor? I suspect you either don't know how to drive a car, or it's in fact not possible.
Does this work on your plumber? I suspect you either don't know how to unclog my toilet, or it's in fact not possible.
No? So why the fuck would you think it would work on me?
> But given how you'd rather type up a long winded rant about ranters rather than answer my simple question: If someone can explain to me how this process [of packaging and signing] should work for applications that distribute to, let's say, 10 different operating systems I'd be all ears.
As short a statement this is, it's not a question, let alone a simple question.
I typically charge companies as much as £30k a week to listen to "questions" like this, and I'm not much interested in doing it for free on the Internet. If you can figure out how to ask a question maybe someone will answer it (heck, maybe it will even be me), but if this is how you want to talk to me it'll have to be at my day rate.
Don't know if it still works, but I used to get around this on school computers by loading the app binary (SomeApp.app/Contents/macOS/SomeApp) in the Terminal.
Gatekeeper really isn't a stringent measure, it just protects people who don't know what they're doing.
Interesting. So it's not implemented as a check on fork()/exec() for example? (checking an xattr shouldn't be too onerous to do practically. Not sure I think it's a good idea. Then again, we've had the "exec" bit for many decades...).
I still use this trick sometimes, because it's a way to get stdout logging output you might not otherwise see. Sometimes it leads to a quick pinpoint of your issue.
That's an odd position to take. I purposefully make my primary account a non-administrator and elevate permissions with my administrator account when I need to perform administrative tasks. This prevents scripts or programs from misusing permissions without my knowledge.
It's also the default policy of my work, a university. Staff do have local administrator access to their machines, but are not supposed to use it for regular operations for safety.
Me too, and when I need to install non-Apple-approved software, I log into my admin account, do it, then log out of it again.
Once the software is installed, I can use it from my regular account.
> Staff do have local administrator access to their machines, but are not supposed to use it for regular operations for safety.
The point of this exercise is that installing random software from the Internet shouldn't be a regular operation; users should take extra care when doing it.
Just out of curiosity, why don't you just put in your admin credentials when the prompt displays? Logging completely out of the current account and logging in to another account just to install software seems way more convoluted than necessary.
That's what I do if it's an option, but I think I've run into some software where that didn't work and I had to actually log into my admin account to install it. (But not log out of my regular one; more than one account can be logged in at once.) I can't recall what software that was, though.
> I purposefully make my primary account a non-administrator and elevate permissions with my administrator account when I need to perform administrative tasks
So...elevate permissions when you need to perform this new administrative task? I don't see how that changes the crux of the matter (you still are the de facto admin, even though you've applied artificial constraints to yourself, because you hold the admin credentials).
...yes, they can? You're prompted to provide credentials (in some cases biometrics is fine, in others you must enter the password) if you/an application is trying to do something that requires escalated privileges.
Right, but now you have explicit consent required to elevate to that level, whereas if you’re running as root already you can just silently do things without the user knowing.
This is fairly standard best practice: your day-to-day account should not have admin-level privileges. It's the rough equivalent of running as root all the time (hand-waving a bit here).
Admin accounts on MacOS have to provide the admin password again (essentially sudo) to make any significant change to the system config. That includes installing applications, changing security, privacy and accessibility changes, etc.
In defense of users, when my parents want to use an app, I'm not going to send them documents on the Unix security model or explain how macOS security diverges from it.
They should be able to download and app and use it without having to call tech support.
Agreed. This is why a robust sandbox/containerization system is preferred to an arbitrary approval system.
Anti-user features like intrusive telemetry are standard fare in commercial software, and running those apps in a sandbox could protect the user without having to rely on Apple's approval system.
Yup, that's why Mac App Store apps are sandboxed. The Mac App Store is the experience we're describing: install an app and use it without having to call tech support or worry about malware.
You’re free to use the sandbox outside of the App Store, but the problem is that there is little incentive to do so unless Apple forces you to through App Store review.
I'm curious about _your_ position, actually. If a user doesn't have admin privileges and doesn't have the credentials to gain admin privileges, that's a clear indication that they both do not own the device _and_ haven't been trusted by the owner of the device to do whatever they want with it. Why exactly should they then be able to install and run random untrusted software on it?
My position is nobody ought to probably be running as admin for the vast majority of tasks, and having to elevate to an admin account in order to "download anything" would be a nightmare for any substantial IT department to support.
Accounts ought to be granted privileges based on the user's need to get things done.
Most consumer laptops and PCs I've seen (and I've seen a lot) don't even have a non-admin user account setup.
>My position is nobody ought to probably be running as admin for the vast majority of tasks
in macOS, even if you run as admin, the only thing that gives you is `sudo` access. Your "admin" user still is a normal user, but it's allowed to gain elevated privileges by supplying their password (or doing biometric auth).
The only difference between running as an admin and not running as an admin is that in the former case you don't have to type in your user name.
>having to elevate to an admin account in order to "download anything" would be a nightmare for any substantial IT department to support
normal users can download all they want. They can't execute it though. That's absolutely what I would like my machine to be configured as.
I work on both, have friends and family and coworkers and acquaintances who use both. If they really didn’t want grandma running as admin they would make it harder to find.
This response seems very pedantic. If you are the owner of the device and know the admin password, you are the admin regardless of what user account you're using.
No, it’s not pedantic in my opinion. Using the least privileged account you can get away with is the best practice I was referring to in OP. I’d hate to have to login into my domain admin account for something my daily job required, for instance. Reduce your own ability to shoot your self (and your employer) in the foot.
Not the OP but: Some sysadmins and devs work in institutions where this wouldn’t be allowed or be practical to support (e.g. schools, some healthcare, etc.). It’s not universally applicable to every environment but it’s easy to get in the mindset that it is after you’ve seen what a determined idiot can do.
Oh, I agree there are plenty of scenarios where you want to restrict a user's ability to do something. But to draw that line at the admin level seems a bit overkill to me (and de-values the idea of having varying levels of privilege, which is more or less exactly what's going to happen for organizational users anyway). I'm not super familiar with Apple's business features but in a Microsoft shop this would (to an extent) be managed through group policy on the domain controller anyway.
Isn't the experience for a notarized app the same as the current experience for an unsigned app? (i.e., right-click or go into the settings and allow.) If so, I really feel all this freak-out is unwarranted, because any moderately technical user will know how to do that.
You don't. But even before you couldn't sign an app without paying Apple, because the only valid certificates (Developer ID) are distributed by Apple (with the $99 Developer program).
I have published apps for iOS and Mac. It was a horrible experience. Apples ecosystem is dogshit and they make you jump through far too many hoops, all just to target a small minority of overall smartphone/computer users. Most of the time it's just not worth it.
What is the default user setting? Do you have to go to the setting and change it to be able to launch apps not downloaded from the app store or unsigned apps?
I for one welcome it, and would like to see sandboxes everywhere, given that it doesn't seem to be any other way to force people to actually care about security.
But anti-consumer? How is this anything but good for 99% of Mac users? It keeps totally un-savvy users safer, puts savvier users on high alert, and doesn’t affect power users at all (other than the minor inconvenience of right clicking the first time you open a non-notarized app).
This particular policy isn't anti-consumer, but other policies they have are anti-consumer - like breaking functionality that applications you bought are depending on in newer versions of the OS (which you need to update to because other applications and/or hardware will require it very soon).
>other policies they have are anti-consumer - like breaking functionality that applications you bought are depending on in newer versions of the OS
This is such a HN comment. On what planet is it Apple's responsibility to maintain their operating system in such a way that third-party apps from developers who don't give a shit about maintaining compatibility can continue running until the heat death of the universe? It's like being angry that Microsoft didn't stick with 8.3 character filenames forever.
> On what planet is it Apple's responsibility to maintain their operating system in such a way that third-party apps
On planet Earth.
> who don't give a shit about maintaining compatibility
Or the developer does not exist anymore or has "pivoted" to something else entirely or has discontinued the program or they have no funds to do the conversion or they rely on technologies by others that (do not exist anymore, have "pivoted" to something else entirely, have discontinued the technology, have no funds to do the conversion, rely on technologies by others that (do not exits anymore, ...)), or simply the newer version is undesirable for the user (due to worse UI/UX, lower performance, monetization-driven user-hostile changes, etc).
As a user all i care about my programs keep working.
> It's like being angry that Microsoft didn't stick with 8.3 character filenames forever.
When Microsoft introduced long file names it was implemented in a way that was backwards compatible with existing software in a way that would be possible to both use existing volumes with 8.3 format, add/rename files with long filenames and have those be visible in a 8.3 form for compatibility with older software.
And 8.3 character compatibility still exists on Windows 10. For example if you have any GOG games installed you can type DIR C:\GOGGAM~1 on command prompt to see the contents of C:\GOG Games. You can disable this via the registry, but it is enabled for backwards compatibility.
I can see anti-consumer and pro-consumer at the same time. Over the recent years I've perceived Apple as being more and more anti-consumer, for consumers that are developers or graphic artists, and pro-consumer if you are a non-developer/non-graphic artist. This is regrettable, especially since devs and graphic artists were among their original consumer base that helped get them where they are today.
I'm not sure how that dichotomy applies, especially when you are -say- a graphics artist who wants to stick with an older pre-subscription model version of -say- Photoshop that you bought in a box, instead of being forced to pay a rent for the latest version.
If you are interested in how app notarisation is enforced in detail, I recommend watching the WWDC 2019 session "Advances in macOS Security" [1]
Here's a quick summary:
App Notarisation is enforced by Gatekeeper. Gatekeeper only checks software with the "quarantined" attribute [2]. The "quarantined" attribute is set by web browsers, email clients, messaging apps, etc.
So this means that Gatekeeper does not check software installed with curl / brew / port.
You can circumvent Gatekeeper by right-clicking the file in Finder, or by removing the quarantine attribute.
A change from previous versions of macOS is that Gatekeeper now also checks programs you start from the command line (if they have the quarantine attribute set).
[2]: Actually Gatekeeper now also checks programs that don't have the quarantine attribute set, but it only checks the signature against a known malware database, and doesn't require notarisation. Details are in the video linked above.
As far as I can tell, Notarization only impacts apps/executables that have the quarantine bit set in their extended attributes. This bit is typically added by web browsers and other programs when they download files directly from the internet.
Before notarization, when this bit was set, the user would receive a simple warning that the software was downloaded from the internet and they should proceed with caution.
All notarization does is add additional logic to this flow. If the notarization is "stapled" to the executable, then macOS can verify it offline, otherwise macOS will connect to Apple's servers to verify the notarization of an app/binary. This means that by notarizing an existing app, you do not need to re-distribute it.
This quarantine bit behavior is why upgrading to Catalina does not impact previously installed apps (regardless of their notarization status) as they do not have this bit set.
Given the history of what Apple did in the past, I think it's very naive that this is the last restriction Apple will add.
First the user could run any app.
Then you had to sign the app or the user would see a scary warning.
Then you had to sign the app or, by default, the user could not open the app, unless he enables it via a UI that is very confusing (and I assume on purpose).
Now you have to notorize the app.
It's pretty clear that the end goal for Apple is to lock down Mac OS the same way they locked down iOS.
Apple needs to protect the hostages, I mean users, from the likes of Mozilla which produces a dangerous app that duplicates built-in OS functionality, which is confusing. And it can deliver porn so think of the children!
And they will in Mac OS 10.20, unless the government steps in.
I agree. All this infrastructure and support doesn't make sense if it is only used on executables that have some easily modifiable fs attribute set.
I fully expect apple to try to expand this on all executables at some point in the future. It'll be interesting to see if they will be able to pull it off.
Whait until 10.16 MacOS is out. Then you will not be able anymore to open not notarized app.
And for 10.17, Developers will have to pay for notarization, as an "insurance" low quality app will not end on your Macbook.
For 10.18 or 10.19, nothing will run unless it's installed from the Apple store or certified with an enterprise certificate delivered by Apple. Just like on iOS.
Apple has previously expressed frustration about the poor financial performance of the Mac App Store...
They want to bring the iOS App Store business model on Mac in order to optimize financial return on the platform.
It's on par with the T2 ship insertion in new models in order to prevent third party repair (google Rossman macbook) just to be able to ask outrageous prices for minor repair or to push for the purchase of a new model at every random glitch on your device outside of the Apple Care contract or legal warranty..
Beside, in Catallina, they just put the /System folder as a separate partition in read only mode... But even if you can still currently mount it in read-write mode, in a future version it will not be possible anymore, unless if you start in recovery mode, system used by Apple to install new version of MacOS.
Soon, you will have to jailbreak your Macbook, taking advantage of a providential "bug" on a specific version, and lost all unix permission system benefits in order to install third party software (at that point cracked, because all legit developer will either have already paid for notarization/Mac App Store or abandonned the platform), just like on iOS.
It's all writen betweens the lines. They're just going forward slowly enough to avoid brutal outcry from the MacOS power users base and the press.
Phone vendors (iOS + Android) invented the whole "t'is your phone, but actually, it isn't, we'll decide what you're allowed to run on it" trend.
It was just a matter of time until the disease spread to the desktop.
I am no fan of RMS for many reasons, but one thing can no one can take away from him: he totally foresaw the curtailing of freedoms decades before anyone else did.
It's fully here now.
I expect the next step to be: if you use an unrestricted platform (Linux, OpenBSD, etc...), you won't be granted access to major chunks of the internet.
And then next: if you want to use Linux, you'll need the IT equivalent of a carry permit from the govt.
> I expect the next step to be: if you use an unrestricted platform (Linux, OpenBSD, etc...), you won't be granted access to major chunks of the internet.
We already have this in the form of browser drm modules. It's not hard to imagine similar modules being implemented for network stacks. ISPs and internet exchanges can be required by law to drop any unencrypted traffic.
Lock down is an inevitability for any technology. General computing, Machine learning, Encryption, and other technology will inevitably get locked behind a sea of regulation. The only way to combat this is to keep governments playing catch up by innovating faster than they can legislate (e.g. mesh networks as a response to telecom overregulation).
Apple’s position is that the average user isn’t supposed to be installing apps from outside the App Store anyway. Who is the average user, you ask? No one who posts to or reads HN, that’s for sure. Your parents, grandparents, and clueless neighbors are all average users. They will benefit from the decrease in malware and increase in assurance that the app won’t do something fishy.
Everyone else will bypass protections and continue as before.
But from the perspective of a dev it means you will need to either go through the App Store (and pay / let Apple have any list word on your app) or have your users drastically reduced because they can't even open the app.
It's an acceptable price to pay for security. This price is dictated not by Apple, but by all the malicious actors who have abused the frictionless path from dev to user in order to distribute virii, malware, adware, spyware, and all the other crap that non-technical uses have been contending with for decades.
> Apple’s position is that the average user isn’t supposed to be installing apps from outside the App Store anyway.
Is this Apple's position, or is their position that apps you install on your system should be vetted in some way (either via the App Store, or via the notarization process)? It seems to be the latter based on reading the link, but I might be wrong.
I'm not sure I'd call that a "problem". This is exactly what I'd like tbh: parents/less technically inclined siblings will gain some degree of security (no more mac cleaner), and has virtually zero impact on me.
Right, signed apps will requires to be notarized.
Unsigned apps will run like before with either right-click open or by clicking open in System Preferences -> Security.
I've used a Mac since the IIGS. This year I bought my first non-Mac (a desktop) in a long time. Now I am looking at a laptop. I don't think I'll ever own a Mac again because of this, plus all the other semi-recent things (I need to have a developer license to write software for an OS built on BSD, what I perceive as deteriorating quality, low-value features such as the touch bar, Mac OS becoming more and more IOS like, and more).
My new go-to for dev laptops is a System 76 machine [1]. I am unaffiliated with System 76 in any way.
Considering they have their own hardware and software (well, not exactly their own, but they customize both and work on both before release), is System 76 as problem-free and solid as Mac OS X was during the Snow Leopard times?
It definitely affects UI applications that have been installed via brew cask. I think I also had to "unlock" a bottled command line executable, but since most programs installed via brew are compiled from source on macOS betas I have a hard time reproducing that.
Quarantining files is opt-in from the app perspective. Apps and programs (like Chrome and cask) have to explicitly support setting the quarantine bits on things they consider downloads. Apps and command-line programs create files all the time for all sorts of purposes, and without app cooperation, macOS has no idea whether each file is something potentially unsafe downloaded from the internet.
So hopefully this shifts the perspective a little. Makers of apps that download things _like_ quarantining because it distances them from the responsibility of ensuring the quality of each download, so much so that they will spend time to implement support for it. If quarantining isn't a good feature, apps like Chrome and cask wouldn't use it or would stop using it. This provides a great check and balance in the system imo.
--
Btw, there are two separate Homebrew projects that are unfortunately named -- one of them is named like a subset of the other. Here are some clarifications for people unfamiliar with this:
- `brew install` builds apps and programs from source, or downloads binaries built from source ("bottled") by machines maintained by the Homebrew project. Neither of these are quarantined, I think.
- `brew cask install` downloads and installs apps similarly to how you would install them manually, but in an automated way. (For example, it will download a dmg, mount it, copy the app to apps, and unmount the dmg.) My comment above is only about this option, and not the other one.
It doesn't need to know that. When you use a GUI app to download an app (web browser, for example), the executable is marked 'quarantine.' When you build an app yourself, it doesn't get marked 'quarantine.'
Items marked 'quarantine' get the "Are you sure?" (or "you can't" or "find another way" or whatever) dialog.
The check happens at a lower level than the Finder, I believe.
I think it checks things with the quarantine flag set on the executable or app. This is set by your browser and other similar software when downloading an app. Once cleared, the notarization check isn't done.
Brew doesn't set the quarantine flag in the first place as far as I know.
I don't know how Catalina works specifically, but if I was designing for this contingency I'd have it so that any software compiled locally by a user with sudo rights would be automatically notarized against a localhost certificate.
So you could easily install a graphical shell that doesn't check that.
heh people probably need to chill out about all this. I got a mechanical engineering student (read: "doesn't understand computers") to play open arena with me the other month dispite all of this. It's just a couple buttons you have to press.
...which makes it all the more annoying for "power users" that there's no simple switch anymore to allow all apps to run without the scare/confirmation popups (there used to be a third option in "Security & Privacy" settings next to "App Store" and "App Store and identified developers" for this).
I use quite a few applications that aren't from the App store. I've had 'App store and identified developers' as my default for ever and I've come across, possibly three? unidentified developers in the last three years. It's not a massive inconvenience and to be honest, I welcome the 'Hmmm - its not signed' pause for thought.
I for one welcome our notarizing overlords. Running a terminal command to disable it is a very minor inconvenience for us nerds... in return we'll get fewer tedious house calls from family and friends asking why their computer is doing weird things.
I already posted it elsewhere but: on the other hand, people who have been doing this for a living will have less work to do! I know some people who live off those calls. :)
Don't worry, endlessly escalating software complexity will keep us all busy. I love current MacOS but my perception it's never been quite as bug-free as it was in the Snow Leopard era. And I attribute that to increasing complexity.
Part of me wishes that Apple would slow down the big innovation for a couple of years and get the entire development team working on bug-fixes and polish.
Using the spctl disable command on the computers of unwary non-tech relatives is irresponsible. Your personal convenience is no excuse for increasing the attack surface of their computer and the risk that they could download and run malware without knowing any better.
I think he's talking about disabling it on his own Mac and the added security benefits of having it enabled on Macs used by normal users which benefit from the additional security.
I don't know the intimate details of Windows SmartScreen, but aren't these basically the same thing? This seems to be a welcomed change while SmartScreen seems largely hated.
It's not bad. It's better than various other terminology failures like the https padlock or secure boot. Since notarised is sufficiently boring, it will hopefully never mean anything other than an annoyance. At least for me, notarised clearly signals unnecessary paperwork. So it is faithful in that sense. I hope secure, certified, trusted etc. all change to notarised wherever applicable.
Yes. I am wondering what will happen when an app is submitted for notarisation and the app is in competition with an Apple created application. Will there be bias? Based on the stories I've read regarding App Store approvals and take-downs, it's a valid concern.
Seems appropriate to me, but what do you feel is loaded about it? I haven’t followed this too closely so I imagine there are plenty of nuances that I haven’t thought about.
This does not require developer membership at least for the moment. That being said, it's worrying that Apple is becoming the single point of failure in Mac App Distribution. Windows allows your binary to be signed by third party CA.
MacOS has all of this, but none of this can protect against abuse of privileges or tricking customers into thinking their copy of an app is legitimate and entering third party information into it.
This process, agree with it or not, is meant to stop things that cannot be stopped with just basic security technology.
Ah, I see what you're getting at. Well, there's better ways of achieving that, other than just banning non-compliant apps. Like, similar to HTTPS, we could add "ticks" into the app toolbar (or something similar) to indicate "verified" apps. Currently, there's nothing preventing websites from impersonating other websites, except consumer vigilance and green ticks in the adderss bar.
The tool that's used to submit a binary to Apple only runs on macOS. Short of something like a hackintosh (which is against the macOS license) or maybe Darling, it's not clear how one would do the submission without a mac.
This is a real issue for me, as my open source project is a cross-platform game development tool. It used to be that it was possible for someone to click a button and get Linux, Windows, and Mac distributions - but now the Mac side is proving more and more difficult.
I hope Apple is prepared for a massive exodus of developers / ISVs and a class action or three if they try to force all software through the App Store.
I owned a business focused on iOS and shut it down because of the dumpster fire the App Store has become. My livelihood will not depend on some halfwit middle manager.
The day they force Mac software through that dumpster fire is the day 100% of my Apple products go in the trash.
The other person who replied to you is wrong (edit: assuming they meant in general, not for only software that you have specifically already downloaded and run on a single computer before upgrading it to Catalina.)
Non-"notarized" software, when freshly downloaded to a computer running Catalina, will not run. A dialog will be displayed, telling the user that the developer needs to update their app for compatibility. There is no further indication telling the user what to do, and no "run anyway" button.
The developer will need to "notarize" the software with Apple, and receive their approval. If that happens, then the "notarization" information for the app bundle will be available via Apple's servers when users attempt to run the program, and Gatekeeper will attempt to look it up from the Apple's servers if the "notarization" information is not "stapled" into the app bundle. Optionally, and probably preferably, the app developer can "staple" the notarization information directly into the app bundle, and Gatekeeper won't need to look anything up over the internet the first time the user attempts to run the program.
They aren't "wrong" - sure there's no further indication telling the user what to do, but you can right-click and run the app from Finder all the same (requires admin permissions).
It's basically an upgraded Gatekeeper. I'm not quite sure what the pearl-clutching is about.
It's a problem for commercial software for end-users that isn't from the Mac App Store. Apple continues to tighten the leash, and it's approaching strangulation.
Please. I don't think you are replying to me in good faith. (Edit: on further reflection, I don't think I have anything useful to exchange with you. If you can't understand why this is a problem, there is nothing more we have to say to one another. Here's a hint, though: there is no regular menu item to do this. It's not discoverable at all, intentionally. Macs don't have a right-click button, and right-clicking or control clicking is not expected to be necessary to accomplish anything in macOS.)
I am...rather confused as to how you think people bring up context menus on macOS.
Unless you're being extremely pedantic and mean that I should call it "secondary-click" instead of "right-click", which wouldn't exactly be in the best of faith.
Apps that aren't distributed on the App Store are treated like second-class citizens on macOS. You can't even install them without having to chase down esoteric instructions.
If you don't understand why that would be an issue for a company that sells applications outside of the App Store, I don't know what to tell you.
No it won't stop working.
The only software that will stop working (and in 10.14 too) is software that was only signed and not notarized after 1 June. If the software was signed before 1 June, it will continue to work.
Give users even more confidence in your software by submitting it to Apple to be notarized. The service automatically scans your Developer ID-signed software and performs security checks. When it’s ready to export for distribution, a ticket is attached to your software to let Gatekeeper know it’s been notarized.
So, on this page it reads:
Mac software distributed outside the Mac App Store must be notarized by Apple in order to run on macOS Catalina
What does this mean? Is this something that affects merely the default security setting?
Is there some contingency for open-source softwares? Some really nice app out there are release by a single dev that does this as a hobby, and imposing a fee on them to release a software they make simply out of passion may make them leave the platform if that is the case.
At present. The impression I got from the threads above is that will change with this requirement.
> brew cask quarantines, but not regular brew.
> ...which makes it all the more annoying for "power users" that there's no simple switch anymore to allow all apps to run without the scare/confirmation popups
Correct. And that's almost universally true for any software program and operating system you didn't personally write. You don't "own" any software on your computer, including your favourite Linux & GNU distribution. You agree to a license which almost always places certain restrictions on what you can do with the software.
There are restrictions on what you can do with almost all products, commercial and open source, e.g., see licenses, copyrights, moral right, trademarks, patents, trade secrets, etc.
What do you want “own” to mean, exactly? What do you want to do with your software that you can’t do right now?
Officially this is being done in the name of security... is it really or is this a cash grab to coerce everyone making apps for macOS to pay the $99/year fee which is required for the signing/notarizing being mentioned?
While you are right, it is adding an extra hurdle that is obviously trying to stride dev toward the store.
"Hey, you can have your software notirized (which we might not accept), people will be warned before opening the app and some other bs or you can pay us 99$ and stop worrying!"
I am criticising what they are doing now. Which is making everything harder if you don't go through the App Store, and they have been doing it for a while now. It's the same they are doing with their hardware and everything (you can't repair it yourself because "quality") so I can't really see them doing anything different.
I think that is actually a smaller part of what's at play. The money is in Apple getting everything to be on the store, getting fees on the money spent on the store and the control over it. They will have the final say over everything.
If that’s actually Apple’s goal, it’s taken them over a decade to get there. The Mac software market is so small and insignificant for Apple’s revenue that it wouldn’t be worth the trouble.
By introducing themselves as gatekeepers, they can analyse software and reject it. For example, if they decide to deprecate an API, they can decline to notarise any software that uses it.
The thin end of the wedge is, of course, free notarisation with few limitations. Then once that is in place, they can increase their power to the level they enjoy in the iPhone app store.
The "security" part is of course complete bullshit. They slowly want to turn macOS into a walled garden for more control and profit like they did in the mobile space.
Except of course it isn't complete bullshit. It's saved me a few times where naive family members (one greater than the age of 80, the other under 12) has inadvertently downloaded mal/annoyanceware and tried to install it.
Crapware is a substantial cause of 'my machine's not working properly' among the less technically savvy
I don't know about everyone else but the only reason I even have macOS computers is because I'm making apps for iOS. If it were possible to develop for iOS on Windows 10 or Linux I would do that in a heartbeat.
I don't know much about it but I thought you could develop for iOS using C# using Visual Studio 2017/2019 and it remotely deploy to Mac?
I read a bit about it because I wanted to do it myself but I haven't upgraded from Sierra yet due to no support/broken for my audio hardware in newer versions.
This is Apple's official line, but no one is going to actually have to do anything different if they don't want to. Some not-so-tech-savvy users might end up with apps they don't understand how to open after downloading them, but those are also the user most susceptible to falling for malicious downloads, so I'd call it a pretty good security feature.
Anyway, were any of you who are complaining in this thread planning on actually publishing an app for macOS, or just here to beat a dead horse?
reply