[HN Gopher] Apple's "notarisation" - blocking software freedom o...
___________________________________________________________________
Apple's "notarisation" - blocking software freedom of developers
and users
Author : DavideNL
Score : 253 points
Date : 2025-11-08 05:37 UTC (17 hours ago)
(HTM) web link (fsfe.org)
(TXT) w3m dump (fsfe.org)
| moi2388 wrote:
| I still don't see why you would want your parents to run
| untrusted software on their devices, but you do you I guess.
| Propelloni wrote:
| I still don't see why you would want Apple to have a say in
| what you run on your device, but you do you, I guess.
| MagicMoonlight wrote:
| Because they have thousands of employees who have the time to
| look at the source code and determine whether it is
| malicious.
|
| Nobody else would bother. That's why meme language
| repositories continuously lead to hacks and vulnerabilities.
| rkomorn wrote:
| Apple employees have access to the source code of apps on
| the App Store?
| BoredPositron wrote:
| Technically yes, if they want it you have to give it to
| them. The dev agreement and TOS is pretty broad.
| rkomorn wrote:
| Is that (Apple asking for source) a frequent thing?
| BoredPositron wrote:
| We don't know.
| aeonfox wrote:
| App developers do know. I can't say that I've ever worked
| on an app where this request has been made. Neither the
| App Store Connect Agreement[0] nor the Apple Developer
| Agreement[1] stipulates that the developer can be
| compelled to surrender their source code.
|
| [0] https://appstoreconnect.apple.com/WebObjects/iTunesCo
| nnect.w... [1] https://developer.apple.com/support/downlo
| ads/terms/apple-de...
|
| All the relevant agreements can be found here, so if
| there's something that specifies this kind of overreach,
| I'd both be very surprised and interested.
|
| https://developer.apple.com/support/terms/
| BoredPositron wrote:
| "If you are required by law, regulation, or court order
| to disclose any Apple Confidential Information (which can
| include requests related to legal investigations or
| audits), you agree to give Apple prompt notice and to
| cooperate in seeking a protective order or confidential
| treatment of such information"
| rkomorn wrote:
| What part of this says Apple can compel developers to
| share their apps' source with Apple?
|
| Edit: oh, are you saying that such requests would be
| "Apple confidential information" so nobody would say if
| it happened?
| aeonfox wrote:
| They haven't read the document properly. Here's the
| definition:
|
| > any information disclosed by Apple to you in connection
| with Apple Events will be considered and referred to as
| "Apple Confidential Information" and are subject to the
| confidentiality obligations of this Agreement
|
| The definition of Apple Events:
|
| > As an Apple Developer, you may have the opportunity to
| attend certain Apple developer conferences, technical
| talks, and other events (including online or electronic
| broadcasts of such events) ("Apple Events").
| lapcat wrote:
| We do know. It has _never_ happened.
| lapcat wrote:
| This has literally never happened.
| lapcat wrote:
| No.
| robertclaus wrote:
| Apple absolutely does not manually read all the source code
| they notarized.
| lapcat wrote:
| They don't notarize source code at all. They notarize
| compiled app binaries. Many or even most App Store apps
| are closed source.
| realusername wrote:
| You are mixing up with Fdroid, Apple doesn't do any source
| code reading and the tests they do are very basic.
|
| Right now you have a lot of piracy apps which are disguised
| as a "note taking app" and they passed the appstore review
| without any issues.
| heinternets wrote:
| Do you have any examples? Asking for a friend.
| moi2388 wrote:
| They don't. You can still run any software you'd like. You
| just get warnings, so people like parents don't just randomly
| open malicious programs from the internet.
|
| Which is exactly as it should be
| whatsupdog wrote:
| Tell me how I can side load apps on iphone? Even with
| warnings and stuff.
| owisd wrote:
| If you compile it from source yourself using Xcode you
| can deploy to your own device without an Apple developer
| subscription.
| lanyard-textile wrote:
| It unfortunately goes away. Last I checked you get 7 days
| before the app expires. The subscription makes it last
| much longer, but not forever.
| djantje wrote:
| It should be a setting (like macos) otherwise full control of
| all the devices is always at the mercy of Apple.
| realusername wrote:
| Implying the software in the appstore is ""trusted""
| wiseowise wrote:
| Who said anything about parents?
| noir_lord wrote:
| They are using it as a proxy for "people with low technical
| skills" (which is a specious argument since it was a friend
| of my parents who got me into programming and he remains one
| of the best I've ever known) and making the usual argument
| that we should limit control of our devices to make it safe
| _for them_.
|
| I actually don't have (much) of an issue with walled garden
| approaches as long as the wall _has a gate that is easily
| opened_ , give me an OS level toggle with a warning of "Here
| be dragons" and I can live with it - it's not ideal but it's
| not a terrible trade off.
|
| It's something Android _has_ had previously (but they seem to
| be trying to lock that gate) and iOS less so.
| graemep wrote:
| Which is something I find very annoying, because I know a
| lot of people who are parents (or adults) or grandparents
| which have greater technical skills than their children.
| brabel wrote:
| I can run anything on my Mac the way you described: go to
| security settings and tell it know what I am doing. Is that
| changing somehow?
| 15155 wrote:
| > has a gate that is easily opened
|
| Invariably, the argument is: "users will just be instructed
| to open the gate by the bad guys, so we can't have a gate!"
| rpdillon wrote:
| I think the burden of proof should be on them to show how
| often this happens.
| CuriousSkeptic wrote:
| How about instead of a single os level toggle you get a
| trillion dollar company, renowned for their high quality
| design, invested in providing the best possible UX while
| respecting the user as the owner of the device?
| gumby271 wrote:
| Tell me more about this mythical mobile device and I'll
| buy one immediately!
| CuriousSkeptic wrote:
| The idea being that if we put apple in a regulatory
| environment where rent-seeking is no longer the winning
| strategy they could be forced to redirect their resources
| towards competing on customer value instead.
| froh wrote:
| I think GP means "parents" as a class of not so tech savvy
| people in your family who need to be protected from naively
| installing malware.
|
| and the purported purpose of notarization is "blessing"
| trustworthy software.
| rogual wrote:
| It's funny how "think of the parents" is the new "think of the
| children".
| owisd wrote:
| It's tragic how many are baffled by the idea someone might
| genuinely accept a minor inconvenience to benefit their
| community.
| gumby271 wrote:
| Right, if we could educate users on the tools they use, and
| if the trillion dollar companies could provide tools to
| help community members protect each other, we wouldn't be
| here. Apple doesn't have to be a dictator if they would
| help the community support each other. Instead they took
| the easy way out of stripping freedoms from everyone so
| they can control every device out there. It's a minor
| inconvenience to be involved in protecting vulnerable
| people in our community, it's tragic that people just said
| Apple should take that role.
| orangecat wrote:
| I strongly dispute that giving megacorporations total
| control of how we're allowed to use our computing devices
| is beneficial to any community.
| saubeidl wrote:
| Because they're adults that can make their own decisions and
| not mentally challenged patients under a megacorps
| guardianship?
| gregoriol wrote:
| Sadly about 98% of real world users are going to fall into
| scams, ransomwares and stuff. They are not mentally
| challenged, there are just so many traps/fakes/tempting stuff
| that we as IT people are more aware of (but even we still
| fall into some).
|
| We also can't count on every person being able to check every
| single thing they do: how do you check if some food or drug
| you get is good or not? you can't really, you have to trust
| someone who knows.
| saubeidl wrote:
| > how do you check if some food or drug you get is good or
| not? you can't really, you have to trust someone who knows.
|
| Yes - the democratically elected government, not a
| monopolistic entity with capital interest.
| userbinator wrote:
| Then that's their own fault and responsibility. You can't
| build up immunity without exposure.
| owisd wrote:
| It's a bit like the Elizabeth Warren toaster analogy. If
| you bought a toaster with shoddy wiring and it caught
| fire and burned down your house, everyone would blame the
| manufacturer and not sneer at you online for not learning
| electrical engineering and not checking the wiring
| yourself before using it.
| beeflet wrote:
| I don't buy this in the first place. It is reasonable to
| expect consumers to do some background research into the
| products they buy. In fact, it is the only way capitalism
| can function as a meritocracy.
|
| Society should be more dangerous as a means to force
| people to learn more about technology they rely on.
| gumby271 wrote:
| It's more like if I buy a reliable toaster, but I buy
| bread that's secretly poisoned by the manufacturer and
| hurt myself. I'm not gonna demand the toaster maker add a
| poison sensor to the toaster and say "how dare they
| didn't protect me!"
| tacker2000 wrote:
| This argument is in the same vein as "chat control because of
| child safety".
|
| Its a smokescreen.
|
| You want less liberty because of the "least competent" user?
| tgv wrote:
| Software freedom, at least for end users, is a smokescreen,
| too. I can revert your argument: "you want more ransomware
| because of a few OSS enthousiasts?" What we need is a way to
| curb the excesses, such as high entrance barriers to the
| store.
|
| A phone/tablet is a tool, with very intense usage, and huge
| privacy value, not an engineer's toy.
| idle_zealot wrote:
| The real smokescreen is this freedom vs security false
| dichotomy. If you give up freedom for the promise of
| security, you get neither. Look at the App Store. It's full
| of harmful garbage designed to extract value and waste your
| time by any trick necessary. It's one step short of
| ransomware. Oh, unless you use an app for your important
| documents, then it comes under new management and demands
| you start paying monthly or lose your stuff. Suddenly that
| lack of freedom to continue using an old version of the app
| or to dig around its internals and pull out your data
| becomes a loss of security. It's fine though, because this
| type of ransomware is totally legal and inline with your
| benevolent platform dictator's policies.
| Ray20 wrote:
| Your argument falls apart when you consider iPhones' 60%
| market share. People have spoken out about whether they
| want dangerous, uncontrolled third-party apps on their
| phones.
| beeflet wrote:
| I don't care about what the riff-raff think, it is
| morally wrong and defies human freedom and dignity to
| require everyone walk around with a locked-down
| surveilance device in their pocket in order to function
| in the economy.
|
| 60% of society could be raptured tomorrow and the world
| would be better off.
| ffsm8 wrote:
| Just in case you unironically don't understand this and
| aren't just playing it up:
|
| Allowing third party installations does not mean
| uncontrolled third party apps. It merely means users have
| to option to install software on their phones - which
| continues to limit the softwares capabilities until the
| user was prompted to allow each.
|
| You could argue "but a braindead person can randomly go
| on a phishing website, randomly download some .app file
| and suddenly - through magic go through a theoretical
| installation dialog to finally explicitly grant this
| malware problematic permissions... And I'm sure there are
| going to be people that will do exactly that... But
| without it, they'll still manage to do the same to the
| same effect, just without the app installation by
| inputting their bank credentials in a phishing site or
| similar
|
| The thing your citing as a problem solved by disallowing
| app installs isn't actually solved - and it would not
| become more problematic either.
|
| Finally, the fact of the matter remains that almost
| nobody would actually use the capability to install from
| third party stores, as you've correctly insinuated. But
| if anything, that should be another proof that allowing
| third party installs doesn't reduce security.
|
| People just like to have everything provided to them from
| a single source, and will usually pay a premium for that.
| rpdillon wrote:
| This is called the tyranny of the majority, where you're
| arguing that because most people don't care about
| freedom, therefore freedom doesn't have value. It's not a
| sound argument, much like saying freedom of speech
| doesn't matter because most people have nothing to say.
|
| Editing to add: it seems particularly ironic that you
| think iPhone users make great purchasing decisions when
| they buy the phone, but are incapable of making good
| decisions when selecting software. What accounts for the
| discrepancy?
| idle_zealot wrote:
| What point are you even trying to make? That's not a
| counter-argument unless you assume that people in
| aggregate always make great purchasing decisions. Wait
| until you hear about cigarettes, heroine, slot machines,
| snake oil, tulips, and the rest of the effectively
| infinite list of fun and unique ways people make terrible
| choices or are bamboozled into acting against their own
| and others' interests. This is a comment thread _about_
| protecting people from scams. The premise acknowledges
| that people make widespread poor decisions. Is it so
| unthinkable that buying an iPhone is one of them?
| array_key_first wrote:
| Most people are stupid and short-sighted. Pointing to the
| stupid in support of your argument doesn't help it.
|
| And, the app store does absolutely nothing to prevent
| "dangerous" apps. Apple doesn't review the code. In fact,
| if your code _is_ reviewable, it 's even harder to get it
| on the app store.
|
| At the end of the day, the App Store and Play Store are
| filled with adware, spyware, and other malware - because
| Apple and Google like it that way. That's what they want.
| They don't give a single flying fuck about your security.
| They care about extracting 30% while simultaneously doing
| as little as possible. That's completely at odds with
| security, yes, and they know that. They just don't care.
| rpdillon wrote:
| The point is that they trust it, whether or not Apple trusts it
| is completely orthogonal, and irrelevant. Apple doesn't own the
| phone.
| sys_64738 wrote:
| What do your kids say to this?
| lapcat wrote:
| > I still don't see why you would want your parents to run
| untrusted software on their devices, but you do you I guess.
|
| I don't trust Apple's App Store review. They've approved
| countless scams that have tricked Apple users out of a lot of
| money, perhaps $billions in total.
| charcircuit wrote:
| DMA is about increasing competition of app stores. It is not
| about giving "freedom" to people. Notorization is an independent
| process from running an app store on Apple's platform.
| mort96 wrote:
| Well, it gives Apple editorial control over non-Apple app
| stores.
| drysart wrote:
| Notarization doesn't involve any sort of editorial control.
| It's just a virus scanner that's run up front and then
| stapling an attestation to your application that it passed
| the scan. It does not involve looking at the content of your
| app and making any value judgements about it; it's purely an
| automated static analysis system checking your application
| for known malicious code.
| mort96 wrote:
| This is just factually incorrect. See:
| https://9to5mac.com/2024/06/09/apple-blocks-pc-emulator-
| utm-...
|
| UTM wasn't denied notarization because some virus scanner
| found that it was a virus, but because it violated App
| Store guidelines. That's editorial control.
| lapcat wrote:
| You're talking about notarization on macOS. Notarization on
| iOS is vastly different. On iOS, notarization is more or
| less App Store review but with fewer rules.
| mort96 wrote:
| Honestly, iOS notarization really muddied the waters.
| IMO, because Apple decided to name them the same and thus
| presumably considers them the same, we should be just as
| critical of and worried about notarization on the Mac as
| we are of notarization on iOS.
| charcircuit wrote:
| That doesn't matter as it also gives editorial control over
| the Apple App Store itself. The DMA is not about giving full
| editorial control to competitors. It's about allowing for
| competition on a level playing field for alternate app
| stores. Since the Apple App Store also has to only sell
| notarized apps, they do not have an unfair advantage.
| immibis wrote:
| Everything you can get in an alternative app store has to be
| approved by Apple and they only approve stuff they'd allow in
| their store, making it not an alternative.
| charcircuit wrote:
| To be an alternative to the Apple App Store, it just needs to
| be able to match the abilities of the Apple App Store. Again,
| the DMA is not about freedom, but about fairness between app
| stores on the platform. Apple can define the playing field
| such as selling notarized apps only, but it must be an level
| playing field among all app stores.
| rpdillon wrote:
| What if I want an app store that doesn't require notarization?
| charcircuit wrote:
| Then if Apple chooses to serve this market demand by allowing
| unnotarized apps to be sold in their store, they must allow
| third party app stores to also sell unnotarized apps.
|
| The key thing here is that the Apple App Store and third
| party app stores must be on an level playing field to compete
| on.
| rpdillon wrote:
| The problem with this reply is it starts with the phrase
| "if Apple chooses". My point is it stopped being their
| choice when they sold the hardware to someone else.
| charcircuit wrote:
| Well if you want that you will need something other than
| the DMA.
| invaliduser wrote:
| The same thing exists on Windows, developers have to code sign
| their binaries. It's even worse in my experience because you have
| to use a token (usb key with cryptographic signing keys in it)
| and that's impractical if you want your ci/cd to run in a
| datacenter. At my company we had a mac mini with a windows VM and
| a code signing token plugged in just for the purpose of signing
| our macos and windows binaries.
|
| Another solution that is not mentioned in the article is that
| users of both macos and windows should be able to easily
| integrate the certificate of a third-party editor, with a process
| integrated in their OS explaining the risks, but also making it a
| process that can be understood and trusted, so that editors can
| self-sign their own binaries at no cost without needing the
| approval of the OS editor. Such a tool should ideally be
| integrated in the OS, but ultimately it could also be provided by
| a trusted third-party.
| tumult wrote:
| Nope. Notarization is not code signing. It's an extra step,
| after code signing, where you upload your software to Apple's
| servers and wait for their system to approve it. It's more
| onerous than code signing alone and, with hindsight, doesn't
| seem to have been offering any extra protection.
| jeroenhd wrote:
| It's not the same, but in practice it's also not so
| different. Microsoft keeps track of how many times a certain
| executable has been run and only after a certain threshold
| does the executable become openable without hunting for tiny
| buttons. The kicker: this also applies for signed binaries.
|
| Microsoft will upload these executables to the cloud by
| default if you use their antivirus engine ("sample
| collection").
|
| In a way, Microsoft is building the same "notarisarion
| database", but it's doing so after executables have been
| released rather than before it. Many vendors and developers
| will likely add their executables to that "database" by
| simply running it on a test system.
|
| On the other hand, SmartScreen can be disabled pretty easily,
| whereas macOS doesn't offer a button to disable notarisarion.
| makeitdouble wrote:
| Microsoft's notorisation sounds fully automated and
| transparent, while Apple's is more political and hands on.
| Individual apps getting their notorisation slowed down to a
| glacier pace because the platform owner doesn't like them
| doesn't seem to happen in Microsoft land.
| Earw0rm wrote:
| The bigger difference is that Apple isn't just checking
| for malware, it's checking for conformance with various
| APIs, manifest requirements and so on. Not as strict as
| the iOS App Store, maybe, but it will refuse to notarize
| if it detects use of unsanctioned API calls.
|
| You don't even need signing for Microsoft's system to do
| what it does - it can operate on unsigned code, it's all
| hash based.
| makeitdouble wrote:
| > it will refuse to notarize if it detects use of
| unsanctioned API calls.
|
| Or really any reason. They're not supposed to exert
| editorial control but that's how it has been happening in
| practice.
| robenkleene wrote:
| > detects use of unsanctioned API calls
|
| Is there a concrete example of this? We know this isn't
| blanket policy, because of a recent story
| (https://news.ycombinator.com/item?id=45376977) that
| contradicts it. I can't find a reference to any macOS app
| failing notarization due to API calls.
| drysart wrote:
| Notarization doesn't blanket block _all_ access to
| private APIs; but the notarization process _may_ look for
| and block certain known accesses in certain cases. This
| is because notarization is not intended to be an Apple
| policy enforcement mechanism. It 's intended to block
| malicious software.
|
| So in other words, using private APIs in and of itself
| isn't an issue. Neither is it an issue if your
| application is one that serves up adult content, or is an
| alternate App Store, or anything else that Apple might
| reject from its own App Store for _policy_ reasons. It 's
| basically doing what you might expect a virus scanner to
| do.
| robenkleene wrote:
| Yeah, don't disagree with any of that, but I'm looking
| for explicit evidence that that is true (right now it
| sounds like it's just an assumption)? E.g., either
| examples of apps failing notarization due to API calls,
| or Apple explicitly saying that they analyze API calls.
| Without that it sounds like we're just guessing?
| Earw0rm wrote:
| I have experienced it myself but this was some years ago,
| may not be current. Think it was things they were trying
| to deprecate, which are now fully gone - was around the
| time they introduced Hardened Runtime, 2018-19 ish.
| hkpack wrote:
| I have the opposite experience - on macOS you can
| guarantee what users will see when you distribute your
| notarized app, while on Windows you cannot for undefined
| time.
|
| How often do you notarize your apps? Why does the speed
| matter at all? In my cases it takes 2 seconds for the
| notarization to complete.
| makeitdouble wrote:
| The article is about iOS, and getting your notorization
| in 2 seconds or weeks is IMHO a big difference.
|
| There's obviously simple cases where the iOS notorization
| also flies in 2 secs, but there seems to be enough
| tougher cases:
|
| https://www.reddit.com/r/iOSProgramming/comments/1l9m7jd/
| how...
| robenkleene wrote:
| I went through the comment there, all of those look like
| the most likely explanation is just bugs in the
| notarization system.
| drysart wrote:
| The length of time notarization takes depends primarily
| upon how large and complicated your app is, and how
| different is from previous versions of the same
| application you've previously notarized. The system seems
| to recognize large blocks of code that it's already
| analyzed and cleared and doesn't need to re-analyze. How
| much your binary churns between builds can greatly
| influence how fast your subsequent notarizations are.
|
| A brand new developer account submitting a brand new
| application for notarization for the first time can
| expect the process might take a few days; and it's widely
| believed that first time notarizations require human
| confirmation because they do definitely take longer if
| submitted on a weekend or on a holiday. This is true even
| for extremely small, trivial applications. (Though I can
| tell you from personal experience that whatever human
| confirmation they're doing isn't very deep, because I've
| had first time notarizations on brand new developer
| accounts get approved even when notarizing a broken
| binary that doesn't actually launch.)
|
| And of course sometimes their servers just go to shit and
| notarizations across the board all take significantly
| longer than normal, and it's not your fault at all.
| Apple's developer tooling support is kinda garbage.
| Someone wrote:
| > I've had first time notarizations on brand new
| developer accounts get approved even when notarizing a
| broken binary that doesn't actually launch
|
| https://developer.apple.com/documentation/security/notari
| zin... (emphasis added):
|
| _"Notarize your macOS software to give users more
| confidence that the Developer ID-signed software you
| distribute has been checked by Apple for malicious
| components.
| _Notarization_of_macOS_software_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."_
|
| = It seems notarization is static analysis, so they don't
| need to launch the process.
|
| Also, in some sense a program that doesn't launch should
| pass notarization because, even though it may contain
| malware, that's harmless because it won't run.
| mort96 wrote:
| Wasn't there even a story some time ago about how some
| completely legit, legal, above-board app to virtualize
| old (pre OS X) versions of Mac OS got rejected by Apple's
| notarization process?
| makeitdouble wrote:
| Yes. Probably this story ?
|
| https://9to5mac.com/2024/06/19/iphone-pc-emulator-block-
| ille...
| raddan wrote:
| "UTM SE" is now on the App Store. Perhaps this was just a
| mistake?
|
| https://apps.apple.com/us/app/utm-se-retro-pc-
| emulator/id156...
| immibis wrote:
| It was the standard business pattern of denying your
| competitors everything you can, unless it causes a third-
| party fuss.
| mort96 wrote:
| I'm honestly not even sure it's about denying competitors
| anything. It feels more like denying their users. Apple
| has a long history of intently denying users the ability
| to do what they want LONG before any potential App Store
| competitors appeared.
| robenkleene wrote:
| Note this is an iPhone app (noting because this thread
| seems to mainly be about macOS).
| mort96 wrote:
| Notarization is the same for macOS and iOS AFAIK. Both
| platforms have a separate app store review process that's
| even more strict than the notarization process.
| robenkleene wrote:
| > Notarization is the same for macOS and iOS AFAIK.
|
| Assuming the basic facts are straight, the the linked
| story explicitly proves this is false:
|
| > UTM says Apple refused to notarize the app because of
| the violation of rule 4.7, as that is included in
| Notarization Review Guidelines. However, the App Review
| Guidelines page disagrees. It does not annotate rule 4.7
| as being part of the Notarization Review Guidelines.
| Indeed, if you select the "Show Notarization Review
| Guidelines Only" toggle, rule 4.7 is greyed out as not
| being applicable.
|
| Rule 4.7 is App Review Guidelines for iOS, so this would
| be a case of failing notarization for iOS App Review
| Guidelines, which means the policies (and implementation)
| are different between platforms.
|
| (Of course there's no such thing as "Notarization Review
| Guidelines" so maybe this whole story is suspect, but
| rule 4.7 is the App Review Guidelines rule that prohibits
| emulators.)
| mort96 wrote:
| The point is that notarization plays the same role for
| both platforms: checks whose _purpose_ is to make sure
| that the software won 't harm the user's device,
| unrelated to the App Store review process. Both platforms
| have an additional App Store review process which is
| significantly more strict, and the notarization process
| isn't _supposed to_ involve App Store review for either
| platform.
|
| When Apple denies notarization for bullshit reasons on
| one platform, it makes me highly suspicious of their
| motivation for notarization on all platforms.
| robenkleene wrote:
| > Notarization Review Guidelines (a subset of the App
| Review Guidelines).
|
| Just noting I was wrong, Notarization Review Guidelines
| are referenced here https://developer.apple.com/help/app-
| store-connect/managing-...
| lapcat wrote:
| > Notarization is the same for macOS and iOS AFAIK.
|
| It's not. They're totally different. The only thing they
| share is the word "notarization".
| mort96 wrote:
| Their decision to use the same word for both is enough
| for me to treat them as the same. Apple has tried to
| convince people that notarization exists for the user's
| benefit; the iOS implementation of notarization has
| convinced me that that's not the case.
| lapcat wrote:
| > Their decision to use the same word for both is enough
| for me to treat them as the same.
|
| Ok... you can believe whatever you want to believe based
| on one word, or you can read the documentation that Apple
| has published:
|
| https://developer.apple.com/help/app-store-
| connect/managing-...
| layer8 wrote:
| The important part is that once you have a code signing
| certificate, you can sign your executable independently,
| offline, without involvement from Microsoft, which isn't
| possible with Apple's notarization.
| Earw0rm wrote:
| It's more akin to an enforced malware scanner, at least in
| principle, kind of mandatory VirusTotal with a stapled
| certificate.
|
| In practice though they use it to turn the screws on various
| API compliance topics, and I'm not sure how effective it is
| realistically in terms of preventing malware exploits.
| robenkleene wrote:
| > In practice though they use it to turn the screws on
| various API compliance topics
|
| Do you have an example of this on macOS?
| robenkleene wrote:
| > doesn't seem to have been offering any extra protection.
|
| How would this be measured?
|
| Since no one has pointed it out here, it seems obvious to me
| that the purpose of the notarization system is mainly to have
| the code signatures of software so that Apple can remotely
| disable any malware from running. (Kind of unsavory to some,
| but probably important in today's world, e.g., with Apple's
| reach with non-technical users especially?)
|
| Not sure how anyone external to Apple would measure the
| effectiveness of the system (i.e., without knowing what has
| been disabled and why).
|
| There's a lot of unsubstantiated rumors in this comment
| thread, e.g., that notarization on macOS has been
| deliberately used to block software that isn't malware on
| macOS. I haven't seen a concrete example of that though?
| tumult wrote:
| Disabling malware via hash or signature doesn't require the
| Notarization step at all. Server can tell clients to not
| run anything with hash xxyyzz and delete it. I mean, just
| think about it. If disabling stuff required the
| Notarization step beforehand, no anti-malware would have
| existed before Notarization. Nonsense.
| robenkleene wrote:
| I think notarization is just a more automated way to do
| this approach, e.g., otherwise Apple has to hunt down all
| the permutations of the binary themselves. It seems like
| it just simplifies the process? (It makes it a white list
| not a black list, so it's certainly more aggressive.)
| tonyedgecombe wrote:
| >It's more onerous than code signing alone and ...
|
| I don't know, I sometimes contemplated sticking sharpened
| pencils in my eyes for light relief whilst trying to renew my
| code signing certificates.
| anang wrote:
| Just FYI, you don't have to use a USB stick, you can also use
| HSM like azure key vault and sign using azure signtool.
| nickf wrote:
| Azure Key Vault - even in the 'premium' HSM flavour can't
| actually prove the HSM exists or is used, which doesn't
| satisfy the requirements the CA has. In theory, it shouldn't
| work - but some CAs choose to ignore the letter and the
| spirit of the rules. Even Azure's $2400a month managed HSM
| isn't acceptable, as they don't run them in FIPS mode.
| Xiol wrote:
| I struggled with a similar problem recently. You can use
| osslsigncode to sign Windows binaries from Linux. It is also
| possible, with some pissing about, to get everything to work
| hands off.
|
| In the end we went with Digicert Keylocker to handle the
| signing, using their CLI tool which we can run on Linux. For
| our product we generate binaries on the fly when requested and
| then sign them, and it's all done automatically.
| scosman wrote:
| Highly suggest trying Azure Trusted Signing on a CI system with
| windows boxes (I use Github). Windows signing was an expensive
| nightmare before, but is now relatively painless and down to
| $10/mo (which isn't cheap but is cheaper than the
| alternatives).
| amaccuish wrote:
| Last time I checked it's still US/Canada only. Luckily I only
| needed code-signing for an internal app, so we just used our
| own PKI and pushed the certs over MDM.
| jtokoph wrote:
| It's also limited to companies that have a proven life span
| of at least 3 years IIRC (you have to provide a duns
| number). They may have reopened for individuals, but that
| means your personal name attached to every binary.
| drysart wrote:
| Azure Trusted Signing is a crapshoot. _If_ you can get
| running, it 's easy and fast and great. But if you run into
| any problems at all during the setup process (and you very
| well might since their onboarding process is held together
| with duct tape and twine), you're basically left for dead and
| unless you're on an enterprise support plan, you're not going
| to get any help from them at all.
| catlifeonmars wrote:
| You can virtualize an HSM FWIW.
| lapcat wrote:
| > The same thing exists on Windows, developers have to code
| sign their binaries.
|
| > Another solution that is not mentioned in the article is that
| users of both macos and windows
|
| The article is actually about notarization on iOS, which is
| vastly different from notarization on macOS. On iOS, every app,
| whether in the App Store or outside the App Store, goes through
| manual Apple review. But apps distributed outside the App Store
| have fewer rules.
| AzzyHN wrote:
| If I try and run an unsigned program, the UAC window will be
| yellow, but I can run it with zero issue.
|
| I cannot do the same thing on MacOS with the same ease, and
| that's the issue.
| fmajid wrote:
| You can see it in action. I have a M1 Ultra Mac Studio, an
| insanely powerful machine, and when building open source
| software, actual compilation flies but the autonomy step crawls
| because IIT has to build test binaries to test OS features and
| notarization slows that down dramatically.
| scosman wrote:
| Notarization is completely optional when building any OSS
| software on a Mac, and not part of any default build process I
| know. A Mac can sign builds for running locally, a process
| which is fast, completely local, and does require building test
| binaries or anything like that. Even a Mac building for an
| iPhone in developer mode has a local cert it can use, and
| doesn't require notarization.
|
| Notarization is only needed when distributing binaries to
| others. Personally I do it once a month for the Mac app I
| distribute.
| kkfx wrote:
| Mandatory FLOSS and open hardware is SERIOUSLY the sole way we
| can evolve positively.
| scosman wrote:
| Mandatory != free/libre
| idle_zealot wrote:
| Free/libre refers to user freedom. Mandatory licensing would
| restrict developer freedom in favor of user freedom, a common
| feature of consumer protection laws.
| amelius wrote:
| Freedom always comes at a cost.
|
| Absolute freedom does not exist.
|
| Etc.
| donatj wrote:
| I stopped releasing binaries for a number of my tools because I
| didn't want to pay the $100 a year for the right to do so, and I
| got tired of explaining how to run them without signing.
|
| The post I wrote to point people at anyway:
|
| https://donatstudios.com/mac-terminal-run-unsigned-binaries
| lapcat wrote:
| Note that the submitted article is about iOS, not macOS. The
| "notarization" process on iOS shares practically nothing with
| macOS except the name:
|
| https://developer.apple.com/help/app-store-connect/managing-...
|
| iOS notarization is just app review with fewer rules.
| hu3 wrote:
| Doesn't it also require the same $100 annual fee?
| lapcat wrote:
| Yes, the Apple developer program is $99 per year, but
| again, this has nothing to do with the submitted article.
| hu3 wrote:
| And a mac*
| archagon wrote:
| You can bet that Apple will pervert macOS notarization for
| app review just as soon as they can get away with it.
| lapcat wrote:
| > just as soon as they can get away with it
|
| Who is stopping them currently?
| archagon wrote:
| Developers would revolt if Apple introduced it right
| away. The steps will have to be gradual. But it's pretty
| clear that the open, Unix-based Mac is an odd duck in
| Apple's current lineup -- and Apple is a company that
| likes to homogenize.
| lapcat wrote:
| > Developers would revolt if Apple introduced it right
| away.
|
| What does "revolt" mean, exactly? I'm a developer myself,
| so I'd like to know what I would/should be doing?
|
| Keep in mind that a lot of Mac developers have iOS apps
| too, so they're accustomed to app review.
|
| > The steps will have to be gradual.
|
| Developer ID was introduced in 2012, and notarization was
| added in 2019. What are the next steps, and what is the
| timeline for them?
| thatfrenchguy wrote:
| easier to release the source code here and better for your
| customers right?
| SurceBeats wrote:
| Suffered that back in the day with an Electron desktop app. Not
| to mention that the notarization and signing integration itself
| is completely broken. The first time you submit a binary it can
| take DAYS to process, and setting everything up to work properly
| with GitHub Actions CI/CD is absurdly time-consuming. It's
| ridiculous, and if you add this new notarial verification policy
| on top of that... In the end it's just Apple being Apple.
| sys_64738 wrote:
| How can we trust software anymore? Open source projects are being
| sold to bad actors. Python default repos are full of malware.
| Originally blessed and trusted apps are being bought by software
| companies is dodgy countries. It seems like we can only trust big
| software companies like Microsoft and Oracle.
| nflekkhnnn wrote:
| Oracle has made several open source softwares closed source. Do
| not trust. At all.
| sys_64738 wrote:
| Why?
| loloquwowndueo wrote:
| I think you missed a /s marker. Big companies, trustworthy? And
| your examples are Oracle and Microsoft?
| yunnpp wrote:
| In Larry we trust. Only he can deliver salvation to his
| people.
| stackedinserter wrote:
| The only way is to run everything is strict sandboxes. E.g. for
| a photo editor there's absolutely no reason to open any network
| connections.
| 13415 wrote:
| I'm building an application that allows you to send a file to
| your colleagues. That's hardly a revolutionary or unusual use
| case, and it definitely requires network access and full
| access to the local file system. I also need the ability to
| lock files, writing file locks anywhere on the system, and I
| need to be able to index the contents of files.
|
| Not only are all of these functions and corresponding
| permissions completely standard for all kinds of
| applications, they belong to the core of what any system that
| calls itself an "operating system" should deliver to
| developers and end users.
| greatgib wrote:
| Can the fsfe also sur Google to try to prevent them to force the
| registration of all developer than want to install app on any
| Android phone outside of the play store?
|
| Again, I would happily donate to such an initiative before it is
| too late!
| amelius wrote:
| I stopped prostituting myself for Apple a long time ago.
|
| Glad more developers are seeing the light now.
| stackedinserter wrote:
| Same thing, I jumped off iOS/macos development long time ago,
| it was probably the best career decision.
| Someone wrote:
| FTA: _"Apple's complete review of apps - known as "notarisation"
| process - a mandatory step for distributing any software on its
| platforms, represents the very gatekeeping behaviour the DMA was
| written to prevent."_
|
| Notarization doesn't involve a complete review
| (https://developer.apple.com/documentation/security/notarizin...:
| _"Notarization of macOS software 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."_
|
| I also expect Apple will argue that requiring code to be
| notarized is explicitly allowed under the DMA, based on section
| 6.7:
|
| _"The gatekeeper shall not be prevented from taking strictly
| necessary and proportionate measures to ensure that
| interoperability does not compromise the integrity of the
| operating system, virtual assistant, hardware or software
| features provided by the gatekeeper, provided that such measures
| are duly justified by the gatekeeper."_
|
| So, the discussion would have to be on whether this is strictly
| necessary and proportionate, and whether Apple duly justified
| that.
|
| I think "strictly necessary" is a bit at odds with defense in
| depth
| (https://en.wikipedia.org/wiki/Defense_in_depth_(computing)),
| where you explicitly add redundancy to improve security, so we'll
| see how a judge rules that, but I can see them accepting it if
| Apple argues they'll implement a similar feature on-device
| instead if they have to.
| lapcat wrote:
| > "Notarization of macOS software
|
| The submitted article is about notarization on iOS, which is
| vastly different from notarization on macOS.
|
| It's a shame that Apple used the same word for both platforms,
| because it appears to be confusing everyone. Maybe that was
| deliberate...
| lapcat wrote:
| The submitted article is about iOS, not macOS. Apple
| unfortunately used the same word "notarization" on both
| platforms, but the processes are not even remotely similar.
| Perhaps the confusion was deliberate, but in any case, many
| commenters here are confused and mistakenly believe that iOS
| notarization is like macOS notarization.
|
| iOS notarization is still manual review by Apple, but with fewer
| rules and restrictions.
|
| https://developer.apple.com/help/app-store-connect/managing-...
|
| > If you've opted into alternative distribution for customers in
| the European Union, you can choose to make your app version
| eligible for distribution on alternative app marketplaces or
| websites only by selecting to have it evaluated based on the
| Notarization Review Guidelines (a subset of the App Review
| Guidelines). Otherwise, App Review uses App Review Guidelines to
| evaluate your app version to make it eligible for distribution on
| the App Store, alternative app marketplaces, and websites if
| approved.
| realo wrote:
| I suppose this kind of notarization across all digital platforms
| will have even more importance once the EU CRA (Cybersecurity
| Resiliency Act) takes full effect end of 2027.
| stackedinserter wrote:
| Where are all these "Apple can do whatever they want on their
| platform" bootlickers?
| rasengan wrote:
| In the end, it's the same for Windows too since you need to pay
| for a cert.
| dmitrygr wrote:
| As an iOS user, I love this and you are free to hate me for it.
| It keeps my grandma safer from scams. This is why I bought her an
| iPhone.
|
| I don't want to hear any of the usual "don't use sideloading if
| you don't like it". I don't want it to exist so nobody can talk
| my grandma into installing a fake bank app over the phone, like
| they did to her once when she had an android phone and stole all
| her money.
|
| Yes this is not foolproof still, some scam apps might make it
| past notarization. Just like cover fees in clubs and gates in
| gated communities -- it does not keep _all_ the riff-raff away,
| but it helps.
| hu3 wrote:
| App store is full of subscription scams and dubious apps.
|
| It's clearly not working as advertised. Specially not as
| advertised by those affected by the distortion field.
___________________________________________________________________
(page generated 2025-11-08 23:01 UTC)