Unless I misunderstand this, notarization is an automated, real-time process - correct? It is just one extra step before the developer distributes. I don't see the issue for either developers or end-users - this won't stop side-loading of apps on the Mac.
That's the part that I don't get. If you develop Apple software, wouldn't you have a developers kit/license thing anyway? Wouldn't you want your software 'signed' so your users knew it was legit, etc? I can see how it introduces some extra steps, but unless there is some big cost or other downside, why is there so much unsigned stuff?
I can understand that all developers aren't going to want to go through the App Store, so if this is a move towards that, I get the concern. But, why not want to sign an app?
My biggest concern is: what does this all mean for in-house developed apps? Our company's operation depends on in-house software.
Yeh, that's a legitimate concern -- and it echos the ongoing battle between control versus free-wheeling that has been ongoing in the computer industry since the 90's:
I was a developer (among other duties) mostly involved with financial applications running on IBM mainframes for Fortune 500 corporations. The requirements there were in order of importance:
1) Absolute, total integrity of the application (both software and data)
2a) Functionality 2b) Cost to develop and maintain
3) Ease of use
On the flip side of that were hot-shot power users with a PC who's claim to fame was being able to develop an "Application" in days or weeks rather than months and years and at a small fraction of the cost -- and they could! They weren't lying.
But, the part they missed was the #1 requirement for mainframe based systems: Absolute, uncompromising integrity of both software and data. And that meant it was always 100% accurate and never, ever failed. (Can you imagine telling 4,000 steel workers that they wouldn't get paid because the computer had died? Or, the programmer/operator was sick with the flu?). As such, the mainframe systems incorporated multiple, expensive and complex layers to insure that they never failed. Ever.
So, to an extent, this thing with home grown systems and Apple sign-off of is an extension of that: Apple wants to insure the integrity of their systems and some users simply say "Forget that, I need this App!".
.... What makes it really tough is that they both have a legitimate point. Both are right and neither is wrong.
So what should Apple do to strike a balance?
Balance? I think today's political situation is a good analogy: When the sides are split between right vs left or, in this case, control vs freedom, there is no balance. It is an either / or situation --- a zero sum game where every win has an offsetting loser. But, what is generally ignored is that there is a less vocal majority lying in the center of those two extremes that will ultimately prevail with calm reason and logic. But, the two extreme sides will continue to cry foul -- so for them, there is no balance.
I can understand that all developers aren't going to want to go through the App Store, so if this is a move towards that, I get the concern. But, why not want to sign an app?
One reason may be the specific coding structure Apple requires for approval. It’s not just a case of submitting an app for Notarization, the app has to meet a bunch of conditions relating to how it’s written. Depending on how an app was developed, meeting those requirements may involve a lot of work.
Another reason may be that an app does something that Apple will never approve, no matter how it’s coded. MakeMKV comes to mind as a possible example. It converts Blu-Ray discs to MKV files. Apple is probably not going to provide its blessing to an app like that, so Notarization may not be an option.
lorin schultz said: One reason may be the specific coding structure Apple requires for approval. It’s not just a case of submitting an app for Notarization, the app has to meet a bunch of conditions relating to how it’s written. Depending on how an app was developed, meeting those requirements may involve a lot of work.
Another reason may be that an app does something that Apple will never approve, no matter how it’s coded. MakeMKV comes to mind as a possible example. It converts Blu-Ray discs to MKV files. Apple is probably not going to provide its blessing to an app like that, so Notarization may not be an option.
Thanks for the reply, that makes sense. I was kind of thinking of the 2nd example after I wrote that, as I also use MKV. But, I hadn't thought of how stringent Apple might be in approving things based on coding practices. I suppose it would be a lot of work to meet those if it required a substantial re-write.
I can understand that all developers aren't going to want to go through the App Store, so if this is a move towards that, I get the concern. But, why not want to sign an app?
One reason may be the specific coding structure Apple requires for approval. It’s not just a case of submitting an app for Notarization, the app has to meet a bunch of conditions relating to how it’s written. Depending on how an app was developed, meeting those requirements may involve a lot of work.
Another reason may be that an app does something that Apple will never approve, no matter how it’s coded. MakeMKV comes to mind as a possible example. It converts Blu-Ray discs to MKV files. Apple is probably not going to provide its blessing to an app like that, so Notarization may not be an option.
For myself, I see no problem with that. In my introduction to "app writing" (actually mainframe programming), the emphasis was on maintainability of the app and strict guidelines were set on exactly how it was coded -- then each program went through a multi-level peer review process where it was dissected and analyzed for adherence to those standards. And, any program that was not deemed adherent went back to the humiliated programmer for corrective action or, in some cases, a rewrite. But no program was allowed into the production environment with having passed muster.
To an extent, Apple is doing the same thing here and I as a user appreciate their efforts.
On the flip side -- if you want the anything goes / buyer beware environment, there is always Windows...
lorin schultz said: One reason may be the specific coding structure Apple requires for approval. It’s not just a case of submitting an app for Notarization, the app has to meet a bunch of conditions relating to how it’s written. Depending on how an app was developed, meeting those requirements may involve a lot of work.
Another reason may be that an app does something that Apple will never approve, no matter how it’s coded. MakeMKV comes to mind as a possible example. It converts Blu-Ray discs to MKV files. Apple is probably not going to provide its blessing to an app like that, so Notarization may not be an option.
Thanks for the reply, that makes sense. I was kind of thinking of the 2nd example after I wrote that, as I also use MKV. But, I hadn't thought of how stringent Apple might be in approving things based on coding practices. I suppose it would be a lot of work to meet those if it required a substantial re-write.
I'm also a MakeMKV user. Hopefully this certificate is just for the signing of the software so you know who it's from. Since it's not in the App Store there won't be a detailed investigation of what the software actually does (yet). At least that's what I'm hoping this means.
I can understand that all developers aren't going to want to go through the App Store, so if this is a move towards that, I get the concern. But, why not want to sign an app?
One reason may be the specific coding structure Apple requires for approval. It’s not just a case of submitting an app for Notarization, the app has to meet a bunch of conditions relating to how it’s written. Depending on how an app was developed, meeting those requirements may involve a lot of work.
Another reason may be that an app does something that Apple will never approve, no matter how it’s coded. MakeMKV comes to mind as a possible example. It converts Blu-Ray discs to MKV files. Apple is probably not going to provide its blessing to an app like that, so Notarization may not be an option.
For myself, I see no problem with that. In my introduction to "app writing" (actually mainframe programming), the emphasis was on maintainability of the app and strict guidelines were set on exactly how it was coded -- then each program went through a multi-level peer review process where it was dissected and analyzed for adherence to those standards. And, any program that was not deemed adherent went back to the humiliated programmer for corrective action or, in some cases, a rewrite. But no program was allowed into the production environment with having passed muster.
To an extent, Apple is doing the same thing here and I as a user appreciate their efforts.
On the flip side -- if you want the anything goes / buyer beware environment, there is always Windows...
Unless Apple has access to your source code, which they do not, they will not be performing the kind of source code inspection that you are describing. At best they will conduct a behavioral analysis of your app, look at what operating system and runtime libraries and APIs you are using (likely to verify you are not using "unsafe" deprecated APIs), check for valid security signatures on all binaries, and ensure your app responds correctly to security authority enforcement actions like revocation.
The general types of application/binary security enforcement processes Apple is putting in place are analogous to those Microsoft has been enforcing in Windows .NET applications for many years. However, with Windows .NET applications, the bulk of the enforcement actions are centrally managed by the .NET runtime which is analogous to a Java VM. Apple doesn't have the same convenience (from a security management perspective) to have a common runtime that serves as a centralized gatekeeper for a whole class of applications that were purposely built with the developers knowing the security rules ahead of time. On the other hand, Windows also allows "unmanaged" applications to run completely outside the managed .NET runtime and it has almost no security control over them. Apple is trying to provide a better and more holistic approach to application security to ensure the entire SYSTEM remains in a robust, stable, and highly available state, not simply putting a corral around an isolated collection of applications that were designed to play by the rules (like MS does with .NET) while allow others to run as hog wild as they wish.
Everything Apple is trying to do makes perfect sense from a system perspective. Apple's application security enforcement mechanisms may not be perfect from the start and may require some tweaking for legacy application support, like manual user overrides. Yes, this will piss off some individual developers, but all systems (of all ilk) should always prioritize the benefits of the many over the benefits of the few. The few that are negatively impacted should not be unfairly singled out and should be given the tools and support to get themselves on the path to compliancy. In the end, the users of the system, all of us, will be the beneficiaries of the actions Apple is taking.
Putting it more bluntly - for a couple of decades the makers of personal computers and the developers writing software for them, including microprocessors, operating systems, and applications, didn't have their shit together when it came to security. Yeah, they didn't know what they didn't know. But at some point they DID know and they still dragged their feet and users suffered. They can't keep ignoring the problem and they have to fix the whole damn system. Someone has to take responsibility for the system and Apple is (and has been) stepping up to the challenge. But the system is now much larger, but at least Apple is trying to do what they can do at the personal computer and device level while protecting their part of the system from the larger (internet, cloud, IoT, etc.) parts of the system that are still growing. If the worst indignity that Apple has to suffer for doing what's right at the levels they control is pissing off a few developers - I'd say they will have done a stellar job, thank you.
I can understand that all developers aren't going to want to go through the App Store, so if this is a move towards that, I get the concern. But, why not want to sign an app?
One reason may be the specific coding structure Apple requires for approval. It’s not just a case of submitting an app for Notarization, the app has to meet a bunch of conditions relating to how it’s written. Depending on how an app was developed, meeting those requirements may involve a lot of work.
Another reason may be that an app does something that Apple will never approve, no matter how it’s coded. MakeMKV comes to mind as a possible example. It converts Blu-Ray discs to MKV files. Apple is probably not going to provide its blessing to an app like that, so Notarization may not be an option.
For myself, I see no problem with that. In my introduction to "app writing" (actually mainframe programming), the emphasis was on maintainability of the app and strict guidelines were set on exactly how it was coded -- then each program went through a multi-level peer review process where it was dissected and analyzed for adherence to those standards. And, any program that was not deemed adherent went back to the humiliated programmer for corrective action or, in some cases, a rewrite. But no program was allowed into the production environment with having passed muster.
To an extent, Apple is doing the same thing here and I as a user appreciate their efforts.
On the flip side -- if you want the anything goes / buyer beware environment, there is always Windows...
Unless Apple has access to your source code, which they do not, they will not be performing the kind of source code inspection that you are describing. At best they will conduct a behavioral analysis of your app, look at what operating system and runtime libraries and APIs you are using (likely to verify you are not using "unsafe" deprecated APIs), check for valid security signatures on all binaries, and ensure your app responds correctly to security authority enforcement actions like revocation.
The general types of application/binary security enforcement processes Apple is putting in place are analogous to those Microsoft has been enforcing in Windows .NET applications for many years. However, with Windows .NET applications, the bulk of the enforcement actions are centrally managed by the .NET runtime which is analogous to a Java VM. Apple doesn't have the same convenience (from a security management perspective) to have a common runtime that serves as a centralized gatekeeper for a whole class of applications that were purposely built with the developers knowing the security rules ahead of time. On the other hand, Windows also allows "unmanaged" applications to run completely outside the managed .NET runtime and it has almost no security control over them. Apple is trying to provide a better and more holistic approach to application security to ensure the entire SYSTEM remains in a robust, stable, and highly available state, not simply putting a corral around an isolated collection of applications that were designed to play by the rules (like MS does with .NET) while allow others to run as hog wild as they wish.
Everything Apple is trying to do makes perfect sense from a system perspective. Apple's application security enforcement mechanisms may not be perfect from the start and may require some tweaking for legacy application support, like manual user overrides. Yes, this will piss off some individual developers, but all systems (of all ilk) should always prioritize the benefits of the many over the benefits of the few. The few that are negatively impacted should not be unfairly singled out and should be given the tools and support to get themselves on the path to compliancy. In the end, the users of the system, all of us, will be the beneficiaries of the actions Apple is taking.
Putting it more bluntly - for a couple of decades the makers of personal computers and the developers writing software for them, including microprocessors, operating systems, and applications, didn't have their shit together when it came to security. Yeah, they didn't know what they didn't know. But at some point they DID know and they still dragged their feet and users suffered. They can't keep ignoring the problem and they have to fix the whole damn system. Someone has to take responsibility for the system and Apple is (and has been) stepping up to the challenge. But the system is now much larger, but at least Apple is trying to do what they can do at the personal computer and device level while protecting their part of the system from the larger (internet, cloud, IoT, etc.) parts of the system that are still growing. If the worst indignity that Apple has to suffer for doing what's right at the levels they control is pissing off a few developers - I'd say they will have done a stellar job, thank you.
Great thoughtful informative post. Thank you.
Makes me think of the phrase “you can’t make an omelette with breaking a few eggs”.
I can understand that all developers aren't going to want to go through the App Store, so if this is a move towards that, I get the concern. But, why not want to sign an app?
One reason may be the specific coding structure Apple requires for approval. It’s not just a case of submitting an app for Notarization, the app has to meet a bunch of conditions relating to how it’s written. Depending on how an app was developed, meeting those requirements may involve a lot of work.
Another reason may be that an app does something that Apple will never approve, no matter how it’s coded. MakeMKV comes to mind as a possible example. It converts Blu-Ray discs to MKV files. Apple is probably not going to provide its blessing to an app like that, so Notarization may not be an option.
For myself, I see no problem with that. In my introduction to "app writing" (actually mainframe programming), the emphasis was on maintainability of the app and strict guidelines were set on exactly how it was coded -- then each program went through a multi-level peer review process where it was dissected and analyzed for adherence to those standards. And, any program that was not deemed adherent went back to the humiliated programmer for corrective action or, in some cases, a rewrite. But no program was allowed into the production environment with having passed muster.
To an extent, Apple is doing the same thing here and I as a user appreciate their efforts.
On the flip side -- if you want the anything goes / buyer beware environment, there is always Windows...
Unless Apple has access to your source code, which they do not, they will not be performing the kind of source code inspection that you are describing. At best they will conduct a behavioral analysis of your app, look at what operating system and runtime libraries and APIs you are using (likely to verify you are not using "unsafe" deprecated APIs), check for valid security signatures on all binaries, and ensure your app responds correctly to security authority enforcement actions like revocation.
The general types of application/binary security enforcement processes Apple is putting in place are analogous to those Microsoft has been enforcing in Windows .NET applications for many years. However, with Windows .NET applications, the bulk of the enforcement actions are centrally managed by the .NET runtime which is analogous to a Java VM. Apple doesn't have the same convenience (from a security management perspective) to have a common runtime that serves as a centralized gatekeeper for a whole class of applications that were purposely built with the developers knowing the security rules ahead of time. On the other hand, Windows also allows "unmanaged" applications to run completely outside the managed .NET runtime and it has almost no security control over them. Apple is trying to provide a better and more holistic approach to application security to ensure the entire SYSTEM remains in a robust, stable, and highly available state, not simply putting a corral around an isolated collection of applications that were designed to play by the rules (like MS does with .NET) while allow others to run as hog wild as they wish.
Everything Apple is trying to do makes perfect sense from a system perspective. Apple's application security enforcement mechanisms may not be perfect from the start and may require some tweaking for legacy application support, like manual user overrides. Yes, this will piss off some individual developers, but all systems (of all ilk) should always prioritize the benefits of the many over the benefits of the few. The few that are negatively impacted should not be unfairly singled out and should be given the tools and support to get themselves on the path to compliancy. In the end, the users of the system, all of us, will be the beneficiaries of the actions Apple is taking.
Putting it more bluntly - for a couple of decades the makers of personal computers and the developers writing software for them, including microprocessors, operating systems, and applications, didn't have their shit together when it came to security. Yeah, they didn't know what they didn't know. But at some point they DID know and they still dragged their feet and users suffered. They can't keep ignoring the problem and they have to fix the whole damn system. Someone has to take responsibility for the system and Apple is (and has been) stepping up to the challenge. But the system is now much larger, but at least Apple is trying to do what they can do at the personal computer and device level while protecting their part of the system from the larger (internet, cloud, IoT, etc.) parts of the system that are still growing. If the worst indignity that Apple has to suffer for doing what's right at the levels they control is pissing off a few developers - I'd say they will have done a stellar job, thank you.
dewme said: Putting it more bluntly - for a couple of decades the makers of personal computers and the developers writing software for them, including microprocessors, operating systems, and applications, didn't have their shit together when it came to security. Yeah, they didn't know what they didn't know. But at some point they DID know and they still dragged their feet and users suffered. They can't keep ignoring the problem and they have to fix the whole damn system. Someone has to take responsibility for the system and Apple is (and has been) stepping up to the challenge. But the system is now much larger, but at least Apple is trying to do what they can do at the personal computer and device level while protecting their part of the system from the larger (internet, cloud, IoT, etc.) parts of the system that are still growing. If the worst indignity that Apple has to suffer for doing what's right at the levels they control is pissing off a few developers - I'd say they will have done a stellar job, thank you.
Good explanation, but I think what we're worried about (as end users) is that a few developers who's little apps and utilities we depend on, might just decide to walk away instead of rewriting everything (assuming they hadn't been following those guidelines all along). It might be for the overall good, but will suck if we lose something important to us that we can't find a replacement for. (Again, a great example is MakeMKV... if we lost that, I doubt there is a replacement.)
Will we the users still be able to run anything we like, so long as we go into System Preferences and choose “open anyway”?
These dialogs are annoying enough as they are now let alone with more in Catalina - I want Gatekeeper to be silent unless it detects a malicious binary; not pestering me each time I run something unsigned that's new or updated.
Comments
I can understand that all developers aren't going to want to go through the App Store, so if this is a move towards that, I get the concern. But, why not want to sign an app?
I think today's political situation is a good analogy:
When the sides are split between right vs left or, in this case, control vs freedom, there is no balance. It is an either / or situation --- a zero sum game where every win has an offsetting loser. But, what is generally ignored is that there is a less vocal majority lying in the center of those two extremes that will ultimately prevail with calm reason and logic. But, the two extreme sides will continue to cry foul -- so for them, there is no balance.
Another reason may be that an app does something that Apple will never approve, no matter how it’s coded. MakeMKV comes to mind as a possible example. It converts Blu-Ray discs to MKV files. Apple is probably not going to provide its blessing to an app like that, so Notarization may not be an option.
On the flip side -- if you want the anything goes / buyer beware environment, there is always Windows...
The general types of application/binary security enforcement processes Apple is putting in place are analogous to those Microsoft has been enforcing in Windows .NET applications for many years. However, with Windows .NET applications, the bulk of the enforcement actions are centrally managed by the .NET runtime which is analogous to a Java VM. Apple doesn't have the same convenience (from a security management perspective) to have a common runtime that serves as a centralized gatekeeper for a whole class of applications that were purposely built with the developers knowing the security rules ahead of time. On the other hand, Windows also allows "unmanaged" applications to run completely outside the managed .NET runtime and it has almost no security control over them. Apple is trying to provide a better and more holistic approach to application security to ensure the entire SYSTEM remains in a robust, stable, and highly available state, not simply putting a corral around an isolated collection of applications that were designed to play by the rules (like MS does with .NET) while allow others to run as hog wild as they wish.
Everything Apple is trying to do makes perfect sense from a system perspective. Apple's application security enforcement mechanisms may not be perfect from the start and may require some tweaking for legacy application support, like manual user overrides. Yes, this will piss off some individual developers, but all systems (of all ilk) should always prioritize the benefits of the many over the benefits of the few. The few that are negatively impacted should not be unfairly singled out and should be given the tools and support to get themselves on the path to compliancy. In the end, the users of the system, all of us, will be the beneficiaries of the actions Apple is taking.
Putting it more bluntly - for a couple of decades the makers of personal computers and the developers writing software for them, including microprocessors, operating systems, and applications, didn't have their shit together when it came to security. Yeah, they didn't know what they didn't know. But at some point they DID know and they still dragged their feet and users suffered. They can't keep ignoring the problem and they have to fix the whole damn system. Someone has to take responsibility for the system and Apple is (and has been) stepping up to the challenge. But the system is now much larger, but at least Apple is trying to do what they can do at the personal computer and device level while protecting their part of the system from the larger (internet, cloud, IoT, etc.) parts of the system that are still growing. If the worst indignity that Apple has to suffer for doing what's right at the levels they control is pissing off a few developers - I'd say they will have done a stellar job, thank you.
Yeh, that was pretty much what I said.