Notarizing Your Mac Software for macOS Catalina | Hacker News Reader

Notarizing Your Mac Software for macOS Catalina

developer.apple.com

221 pointsdraugadrotten270 comments

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?

I was concerned MacPorts would stop working on my computer. I don't plan on publishing apps for Mac, but I depend on apps others publish.

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?

They sign literally everything. There is no human review process involved in notarization.

They sign malware?

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've probably got enough info from your signup for the developer program to send the FBI to your door afterwards.

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.

So is this similar to Windows "this file was downloaded from the Internet" warning?

Yes, but slightly more difficult to override - it's not presented as an option in the warning itself.

Basically.

https://lists.macports.org/pipermail/macports-dev/2019-April...

> 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.)

https://lists.macports.org/pipermail/macports-dev/2019-Septe...

> * 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.

Isn't the "right click > open" trick only valid for user accounts who are Administrators?

In defense of Apple, if the account someone is using is not an administrator, they probably shouldn’t be downloading things in the first place.

Huh?! Explain your position here, please.

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.

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.

I don't quite see how an IT nightmare follows. Where do you work that people are downloading and installing software on work computers every day?

> Most consumer laptops and PCs I've seen (and I've seen a lot) don't even have a non-admin user account setup.

Have you ever used macOS or are you basing this on Windows laptops?

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.

>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.

”My position is nobody ought to probably be running as admin for the vast majority of tasks”

Who disagrees with that? For most users, by a long shot, installing software is only a tiny fraction of the tasks they perform.

Anybody, including that substantial IT department has to elevate to an admin account to install software, and that is a good thing.

Any halfway smart IT department won’t have to type an admin password on every machine or even visit every machine, though.

I'm the owner of my device and use a non-admin account day-to-day. Is it really that unusual?

The account you choose to use does not change the fact that you are the de facto admin.

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.

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).

Arbitrary programs cannot use de facto 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.

Do you use macOS?

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.

> Do you use macOS?

Almost exclusively.

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.

Also in defense of users, they should be able to use any app they install without worrying whether or not it's malware.

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.

> The Mac App Store is the experience we're describing

It isn't if the user wants to use software that isn't available on the App Store.

Arbitrary programs can be run with the macOS sandbox, there is no need for the App Store for security.

Very few applications opt in to the macOS sandbox outside of the App Store.

We're talking about an optimal security platform. Apple could very well build macOS security around sandboxd without the App Store, but chose not to.

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 thinking of something like QubesOS. Apple could enable the sandbox by default for all applications. There's no need for an App Store.

>"right click > open" brings up an admin challenge/authentication if executed by a non-admin user.

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.

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.

Oh, I do that too. Completely different purpose though.

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...).

Ed: seems there is a more general check now - but limited to checking against known "malware" - not "whitelist" (motorized) https://news.ycombinator.com/item?id=21180317

No dog in the fight here.

But just from a security and privacy perspective, why would a non-admin be downloading and installing random software packages?

"were any of you who are complaining in this thread planning on actually publishing an app for macOS"

I have the chicken and egg problem.

I refuse to develop for Apple due to their anti-developer and anti-consumer policies.

So would I make Apps for Apple is they played nicely? Yes.

Anti-developer? Sure.

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).

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.

>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.

> 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.)

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).

But you can sideload an application, you just need to use as computer to do it.

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.

You don't actually need the latter.

It only works for a short amount of time which makes this rather impractical.

Have you heard/of looked at AltStore?

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...

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.

No, its the fact that you need to re-upload that app every 7 days..

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 don't quite see how that at all follows, considering that notarization is something you can do from e.g. a CI server.

I'm concerned at this point about if anybody that this supposedly effects has actually done any research at all on it.

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.

Should people be required to own a Mac to release desktop software for the Mac?

How do you test your software without the machine you're targeting? Every programmer knows that VMs aren't as good as the real thing.

You send it to a friend of yours that has a mac, but isn't a developer.

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.

No one says you need a bunch of Macs. People are saying that you need one, which is one more than the OP wanted to use.

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...

And that's why Electron is popular. People don't have to deal with these issues.

More specifically, developers don't have to deal with these issues. They simply create more issues for their users.

> 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.

> 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.

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.

> Anyway, were any of you who are complaining in this thread planning on actually publishing an app for macOS

Yes. I take offense to you generalizing all complaints as just wanting to "beat a dead horse"

Yea for real. Just google "macOS signing issues on GitHub" and you can see a whole swarm of real example complaints.

How does one get something notarized without a paid developer account? Is apple now letting people submit their apps for notarization without paying?

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).

>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?

Every OS does have their own signing system like this! That's how all the Linux package managers work.

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!

I was under the impression there's a process involved with Apple to approve these things. From: https://developer.apple.com/documentation/security/notarizin...

"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.

Kind regards.

I'm just here to complain because it's annoying to incorporate yet another step in a CI flow.

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.

>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.

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

early versions

beta

I think you answered your own question there.

People have to stop treating betas like gospel.

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).

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.

How does one actually notarize an app without paying? I believe it requires Developer ID, which does actually cost $99/year I’m unclear on this.

I too am curious.

You only need an apple id to notarize apps for macOS.

https://appleid.apple.com/account#!&page=create

Nope, you need to have a Developer account.

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.

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?

If so that's a huge barrier.

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).

[1]: https://developer.apple.com/videos/play/wwdc2019/701/ (Transcript: https://asciiwwdc.com/2019/sessions/701)

[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.

Thank you for the summary and links.

And to remove the quarantine attribute when you are sure you want to run something:

    xattr -d com.apple.quarantine FILE

IIRC, brew cask does actually set the quarantine bit in the downloaded binaries

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.

Slow boiling frog.

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.

>Slow boiling frog.

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.

It's worth noting that frogs will in fact jump out of hot water no matter how slowly you bring it to a boil.

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.

Do you honestly believe the T2 serves no useful/practical purpose? Apple just put it there to be malicious? lol

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).

Scary looking submission, but from what I've read the right-click-menu-open trick to bypass Gatekeeper still works.

I can't speak to that particular method as I haven't personally played with Catalina, but you are correct.

  $ sudo spctl --master-disable

definitely works.

Problem is, the average user will never ever do that or even think it's possible.

This is exactly the opposite of a problem.

How is that a problem?

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.

Apples position might also be the knowledge about creating money from signatures that can increase the value of their company from their possession.

https://www.zdnet.com/article/illicit-certificates-worth-mor...

I think the security effect will be marginal.

Are you saying that Apple is the market maker for some shady marketplace of code signing certs?

This is quite a reach: I'm sure the amount of money Apple could possibly make with something like this is marginal.

> 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.

That's perfect. Best of both worlds.

That's not the problem, that's the design!

There are various ways around this if you know what you're doing.

is this the thing that permanently turns off having to go to privacy settings?

This is the setting that System Preferences doesn't offer and turns off everything.

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.

[1] https://system76.com/

You don't need a developer license to write software on OS X.

You do if you want to release it and have your users be able to use it without being warned that your product is insecure.

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?

I see this trotted out every time someones mad with Apple. JFYI System 76 are just rebadged Clevo/Sager. Save yourself some money lol

https://www.sagernotebook.com/Notebook-NP8454.html

The blog post below contains a useful flowchart showing how to open a non-Mac App Store app on Catalina.

https://eclecticlight.co/2019/10/04/will-gatekeeper-let-me-r...

A follow-up post mentions that standard users will not see an Open button at all.

https://eclecticlight.co/2019/10/05/what-to-do-when-a-newly-...

How does this work with Brew? (Dear lazyweb...)

It shouldn't affect brew or software you build yourself.

How can it tell you've compiled it and haven't just signed it yourself?

Or does it only check signatures when you're launching things from the GUI?

Yes. If you;re tinkering with Homebre, you are not the target demographic.

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).

That third option is hidden in the GUI, but can be re-enabled via:

sudo spctl --master-disable

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.

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.

brew cask quarantines, but not regular brew.

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.

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.

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.

Some background on this btw:

Installed casks didn't used to be quarantined at all. Quarantining installed casks was actually a Homebrew cask feature introduced in 2016: https://github.com/Homebrew/homebrew-cask/issues/22388

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.

"Notarised", what a loaded, feel-good term.

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.

> And I attribute that to increasing complexity.

I attribute it to Apple focusing on iOS and letting their desktop products slide.

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 basically SmartScreen, and I think SmartScreen is great to have enabled by default for the same reason as the parent comment above.

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.

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.

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.

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.

Notarization is an automated process. It's not a human-made review.

So I can add it to my CI that builds a new app several times a day and have my CI upload the noterized binary to github release like it does now?

Pretty much.

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.

If we instead focused of containerization / sandboxes and/or capabilities-based security, life would be much better (not to mention more secure).

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.

So they're going to also vet all webpages before consumers can visit them? That's ridiculous.

The concept of HTTPS must sound crazy to you. Edit: Or this guy: https://www.intego.com/mac-security-blog/wp-content/uploads/...

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.

How to notarize a binary if one does not have macOS? I used to have a cross-platform build on Docker for macOS, I wonder how would I do it now.

You do not notarize. Apple does. You submit the app to Apple for them to notarize. Pretty sure you don't need a Mac for that.

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.

> Pretty sure you don't need a Mac for that.

Maybe you do, I can't find any way besides using Xcode, either on the GUI or using "altool", which comes with it.

Indeed the only instructions rely on Xcode tools. That sucks.

I’m pretty sure you do.

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.

Enough with the fucking greed already.

What about python and node binaries? Assuming those don’t fall under the same group, can we also run electron from the cli if it’s not notarized?

None of those involve GateKeeper at all, so they'll be fine.

Is software that isn't currently notarized going to stop working when we upgrade to Catalina?

That's good. I wish things were a little clearer.

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.

...how exactly is right-clicking (once) to run an app approaching strangulation, again?

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.)

> Macs don't have a right-click button

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.

> You can't even install them without having to chase down esoteric instructions.

You literally just run the installer like anywhere else, what on earth are you talking about? How is that an esoteric instruction?

Well I think the one thing that I'm gathering is that a normal user won't know to do that (right-click and click "open").

The scary thing to me is there's no "Open Anyway" button that was mentioned further up in the thread.

I haven't used Catalina yet though so I'm not super sure of all these facts.

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.

Unsigned software will continue to work.

About notarizing:

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?

What is the extent of this? Dos it apply to every binary I could run on my computer?

Only binaries downloaded via a browser.

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.

There is no fee.

Thanks for the info!

For now.

One more reason to switch to Linux.

Most apps you'd care about in those cases would be perfectly buildable via Homebrew.

Note that "buildable" is much more of a hassle than "installable".

There is a reason not everybody is using gentoo.

homebrew removes that hassle. "brew install" doesn't make you download and build everything from source.

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

You don't own your computers, folks!

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.

This is not necessarily the case:

http://thedjbway.b0llix.net/license_free.html

http://cr.yp.to/softwarelaw.html

Sure, if you accept the feel-good corporatist double-speak that is "owning copies" of intellectual property.

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?

Unless, of course - you control click on first launch to bypass the check.

> You don't own your computers, folks!

You do, you just don't necessarily own the software running on it.

»Beautiful General Computation Device you got there. Would be a shame if it couldn’t generally compute anymore..«

(this was just a joke, sorry if it annoyed you)

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?

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.

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.

There's that, but I also just kind of like the operating system more than others ¯\_(ツ)_/¯

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

There's no relation between proper sandboxing (actual security) and a walled-garden like apple is building.

You also can download malware on the App Store.

Okay, your wish is granted. "Apps that want to escape an extremely minimal runtime sandbox need to be approved by Apple."

I would prefer to leave that choice to the user.

And the user can choose to bypass that check by removing the quarantined flag.

You have a point but that's exactly the same on an app store. They can just select "yes" to the permission dialog and we have exactly the same issue.

On the other hand, people who have been doing this for a living will have less work to do!

People have been saying this for a decade.....

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.

The parent post is factually false. The $99/year developer account fee is not a prerequisite for notarizing macOS apps.

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!"

Please limit your criticism to what Apple is actually doing, not what your imagination speculates they might do in future.

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.

You are implying that notarized apps will still not just run normally after this change. I believe that is false.

Is the $99/year actually required? I thought there was a way to sign apps without it.

It's not a cash grab; it's a power grab.

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.

So now you need a 100$ a year license to publish any software on MacOS?

No, Apple doesn't require a paid developer account for you to receive a notarizing certificate.

*yet.

This sort of things are always gradual to not scare people off. First it's a popup that you need to right click->open to bypass, then it's notarising, soon no software from outside the store will be allowed.

So when? The Mac App Store was introduced over a decade ago and people have been making this prediction.

Worry about the slippery slope when the slippery slope actually slips. For now there's good reasoning behind what Apple has done and I applaud their active concern for badware.

> Worry about the slippery slope when the slippery slope actually slips.

Wouldn't that be too late? After all we have "warning! slippery surface" signs to avoid slipping, we don't just let people slip and fall over to figure out the surface is indeed slippery.

Too late for what?

For not falling down. By the time you have slipped, you are already in pain.

If you want to develop apps for Windows you have to get around their smart screen which is particularly difficult to do if you are not well known. I don't think Apple should charge so much because it doesn't cost them that but it is a good thing that they have some sort of mechanism for connecting the original authors to the built software. Follow the money and you find the source.

Actually, Apple doesn't charge anything for a developer account to notarize Mac software.

Cheers, that's good to know

Reply on news.ycombinator.com