No, notarization is about preventing malware. That's all. This has been promised to us by Apple many many times. Malware prevention only. Fortnite is not malware.
Notarization is not a stick-less carrot. Anyone can sign up and agree to the rules and pay the fee begin notarizing apps. If you break the rules you agree to when you sign up, you lose access to notarization.
It seems like we disagree about this basic understanding, so I'll take a couple guesses at it.
Are you, perhaps, arguing that Apple should not be allowed to terminate developer access to notarization under any circumstance — regardless of their behavior? Or are you arguing that Epic's behavior is "acceptable" rule breaking, but other kinds of behavior are "unacceptable" rule breaking?
I'm happy to consider that I could be wrong here, but I'll need a few more sentences from you to do so.
At the very least such decisions should be subject to appeal to an independent board, and failing that the legal system.
Should they have not exercised that right, and left us all at risk — even though the daemon itself wasn't malware, nor had it been abused for such purposes by anyone?
Checks and balances are not a new concept.
If Apple wants to suspend someone's App Store developer account, fine. But you should be able to distribute outside the App Store regardless.
The whole point of distributing outside the App Store is to avoid all that nonsense with Apple's rules.
Since most people are essentially prevented from running non–notarized macOS software, Apple should treat notarization as a rubber stamp. As long as your app is not literally malware, Apple should notarize it.
Apple's use of notarization as a stick for Epic here certainly goes against if not the letter, then the spirit of their developer documentation: [1]
> Notarization gives users more confidence that the Developer ID-signed software you distribute has been checked by Apple for malicious components. Notarization is not App Review. The Apple notary service is an automated system that scans your software for malicious content, checks for code-signing issues, and returns the results to you quickly. If there are no issues, the notary service generates a ticket for you to staple to your software; the notary service also publishes that ticket online where Gatekeeper can find it.
[1] https://developer.apple.com/documentation/xcode/notarizing_m...
1. You can submit software anonymously, or with a free account, or with a paid account.
2. Apple can refuse notarization for the usual reasons they do now.
3. Apple can, in the future, revoke notarization and notify you.
3a. If you choose to submit anonymously, notification is impossible.
3b. If you choose to submit with a free developer account, they'll notify you of revocation and why.
3c. If you choose to submit with a paid developer account, they'll allow you to contest the revocation.
"2.3.1 Don’t include any hidden or undocumented features in your app; your app’s functionality should be clear to end-users and App Review."
In old sci-fi books, there's a couple that describe a future where connecting an old device to the Internet without having first installed updates will result in the device being exploited and/or ruined within a few seconds.
I notice that the Xcode worm was reposted again this morning, which seems like the perfect mechanism for covertly preparing for a worldwide hack of all iOS devices through a backdoor that has been compiled into all software. (You could get a similar effect by introducing malware into CocoaPods, and with similar reach.) All of these protections Apple has with Gatekeeper and Notarization would, to many extents, protect end users against that attack.
As you said, it's definitely a broad brush. The risk is absolutely real, though I imagine we all disagree on how important it is. It's the same problem as the risk of Python/Ruby/Node dependency compromises. Any solution that would work for protecting us against an NPM compromise would also work for protecting us against a macOS software compromise. Apple's solutions have a higher total value of protection, in exchange for a higher total value of bothersome.
Is the NPM model (you can ship any code worldwide, have fun!) safe enough for non-technical users, such that Apple could just drop Gatekeeper and let us all go back to the wild west macOS days? If not, what model is acceptable, given that Apple's model isn't?
Does the sale require me to submit payment details to a not-already-trusted platform?
The change remotely triggered by Epic redirects users to a third-party (Epic) payment system, but what if it were, say, a malicious Epic insider? How much user payment info/cash could they grab before they were detected and disabled?
Well, it kinda is, isn't it?
> Programs are also considered malware if they secretly act against the interests of the computer user.
Is convincing children that they need to spend money to not be a "default" really in the interest of a computer user? Is taking advantage of gambling addictions with lootboxes really in the interest of a computer user (or society at large)?
I get what you really mean, and I'm probably stretching the definition a bit much; Yet it's worth considering if Fortnight is really a good thing in the first place.
IMO that's a fine conversation to have, but it is not Apple's place to make that decision for me.
Apple and Google are hardly faultless, but Epic is is the one who started this dick-measuring contest.
That's a fine argument to make, but it's nothing to do with what we're discussing here :)
If you wrote a blog post about how Apple and Google should ban gambling reward techniques from their app stores, I'd read it if you posted it to HN!
Well, except we're talking about how these measures are generally reserved for malware. Thence my (pseudo) logic chain.