Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

It seems like the right balance. As the author says:

> As a Mac developer, it's nearly impossible to run a viable software business when this is the first-run experience of new customers. You'll never get any new customers! This is why every Mac developer I know signs up for Developer ID and ships only signed, notarized apps. It would be financial suicide to do otherwise.

If you have hung your shingle out to make a profit, then the developer account, signing, notarizing, etc. is a cost of doing business, and you can easily justify it. The more customers you get, the more money you get, so you are motivated to reduce the first-run friction.

If you are not in it for profit, you probably have a lot more tolerance for a little first-run friction, and having users drop out of the funnel. Fewer users does not affect you financially. As a hobbyist programmer, I wouldn't care. I'm just releasing a program--not looking to dominate a market.



I appreciate this view except for the last point. As a hobbyist programmer, I am not "just releasing a program". I am usually "helping solve user's problems". And if my solution requires users to go through even more problems before they can use my tools, that's problematic.

I don't need to many money on my side projects. I do, however, want to help people. If I can't help people on a Mac because of the install friction, then it isn't worth my effort to create a MacOS port of my software at all.


> the developer account, signing, notarizing, etc. is a cost of doing business, and you can easily justify it.

But what if I'm not doing this for profit? Can Nirsoft or Mozilla apply for a waiver? Can I? We may not be looking to dominate the market, but it would be a shame if our work just went to waste because people would rather pay for something crappier that is closed source rather than our free (as in freedom & beer) software.

(Yes, Mozilla is a huge project where it isn't worth employee's time to apply for a waiver, I just needed at least one name that people know is a non-profit software developer as an example.)


I would generally like my open-source software not not be marked as malware.


I would generally like my software, regardless of it is open source or not, not be marked as malware when it is not malware.


Sure, but I picked that specifically because it seemed to be what the parent comment was talking about.


Is there any automatic way to tell your software apart from malware?

Because that's part of what this mechanism tries to provide...


> Is there any automatic way to tell your software apart from malware?

There is no universally agreed-upon definition of malware. One man's operating system is another man's malware. For me, an operating system that "calls home" for each new executable you compile is a crystal clear case of malware. In the case of this article, then, the only malware in question is macOS.


Plus like this little thing by a guy named Turing…


If an Apple engineer were to compile a variant of Apple’s notarization algorithm where ok means no and no means ok, would the resulting binary notarize its own source fed into it?


Well, if the mechanism is e.g. a blacklist of APIs that shouldn't be used, and a blacklist of known malware hashes (as is the case), then Apple's "is this malware" routine could trivially print "no" for itself.

Sorry to the grandparent, but this is nothing like the halting problem...


This already exists and it is called XProtect. My question through these threads has been "why does notarization exist" and I am still trying to understand why it does, because every answer I have been given simplifies down to "here is a reason that it should exist…wait, that's just what code signing or Apple's built-in MRT does already".


Nothing is calling home when you run a new executable. You're not understanding how gatekeeper works. It works entirely offline without network access.


Dude, just try it.

Close your browser and monitor your network traffic. Compile a hello world with a unique text string. Run it. It calls home the first time you run it. Then it doesn't.

If you are not connected to the internet, it does not call home indeed.

Here is a concrete description of this experiment: https://sigpipe.macromates.com/2020/macos-catalina-slow-by-d...

I just reproduced it on a newly installed macOS 10.15.6


>There is no universally agreed-upon definition of malware.

Doesn't have to be. Just the common user's definition is OK.

>For me, an operating system that "calls home" for each new executable you compile is a crystal clear case of malware. In the case of this article, then, the only malware in question is macOS.

Which is neither here, nor there.


In theory no, that's impossible. In practice, I publish checksums on my website and people trust that I am not malicious.


I'd rather also have a party in whose interest it is to not get malware on their operating system confirm your claim that your software doesn't contain malware.


> I publish checksums on my website and people trust that I am not malicious.

Users who know how to verify checksums know how to work around unnotarized Mac apps.


It would be nice if the OS automatically verified these checksums. That would have been a nice OS X feature, but instead Apple ignores the verification process that already exists and invents their own, with themselves in control.


>with themselves in control.

That's the whole idea to protect from malware. You don't want the software publisher (which could just as well be a malware publisher) in control.


>In theory no, that's impossible

It's impossible in the general "is this file malware?" case.

It's totally possible in the "is this file a copy of known malware?" case.


The thing is, your friendly scammer could also publish checksums on their website.

It is clear to you that you're writing fine open source software, not malware. But how is the consumer supposed to tell?

If people trust you, why bother with the checksums? (Over HTTPS, the downloaded content cannot be tampered with. If someone tampered with the content on your website, or performs a MITM, they can also replace the checksums.)


The checksums are there if they happen to grab the binary in some way that is not "using HTTPS directly from my website" and they'd like to check. Why do the know I'm not writing malware? Trust in my software, mostly? It is unclear that notarization actually stops malware–Apple has failed to explain how it helps, but enforces it by decree.


Pretty easy to figure out what's going on:

1. You submit your app bundle and your credentials to Apple for notarization.

2. Apple records your information and goes through each library, framework, and your code, checking the code signing info and "fingerprint" of each for known malware.

3. Apple issues the ticket for stapling to the app bundle.

Now say, for example, that libffmpeg-0.1.2-beta2.dylib is found to mine cryptocurrency:

1. Apple goes through their database and finds the app where the malware was reported.

2. Apple marks that fingerprint as malicious.

3. Apple now flags any other apps that use libffmpeg-0.1.2-beta2.dylib (by checking the fingerprint) and disables any versions of any app running that version. Additionally, any other attempts to notarize apps with the malicious dylib are rejected.

Notarization provides 2 major benefits for devs that I can see:

1. Apple doesn't need to revoke your entire certificate just to block one version of an app.

2. Apple's audit trail of who notarized the app (and from where) prevents cases where stolen credentials result in a DoS of the victim (e.g. your account being locked, your name and address permabanned, and funds frozen).


I'd be interested to see the track record since they implemented notarization. How often has it caught malware, both before and after the fact? I haven't seen any headlines about e.g. a popular application failing to launch one day because Apple found a miner in it some time after initial notarization.


Why can’t Apple just push that through XProtect?


They can do that if they’ve obtained a copy of the specific binary with malware. But with notarization they can proactively scan for things that look like they might be malware, and follow up with either automatic rejection, or approval followed by manual inspection.


Ok, I guess that does make sense. Still, it does have the drawback that all distribution must go through Apple, and you need to now need to pay to develop software for the platform :(


Why not do both?


Because notarization has the very concrete downside of costing money to do, plus the fuzzier steps of it being a fairly complicated and often picky/opaque process to have to deal with when shipping your software.


I would generally like my malware to not be marked as malware.




Consider applying for YC's Fall 2026 batch! Applications are open till July 27.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: