I don't. As a user, I don't need Apple arbitrarily allowing big players' apps through their approval process while they hold smaller developers to a stricter standard. That will stifle innovation.
If security is the touted excuse, macOS already has sandboxd[1] which can be used with arbitrary apps that aren't in the App Store.
Linux solved the security problem with Snaps, Flatpaks and AppImages, which all use various layers of containers, kernel namespaces and isolation to provide a sandboxed environment for apps.
[1] https://developer.apple.com/library/archive/documentation/Se...
And sandboxing is completely orthogonal to the fine-grained revocation that notarization allows for. A sandboxed app could still be malicious: say, a weather app that asks for access to your Contacts ostensibly to show weather at your friends' location, but also uploads all the Contacts info to a malicious tracking service. With notarization, this app could have its notarization revoked once it's discovered.
Apple is rejecting anything by developers that don't pay them $100 a year, stifling competition in the process.
Apple has a history of conveniently rejecting apps if the rejection is in their financial interest[1].
[1] https://www.theverge.com/2019/5/31/18647249/wwdc-apple-paren...
I think by "user" it was meant the average user which by my estimation is not super technical and mostly sticks to larger apps anyways. Are smaller developers being held to a stricter standard though than larger developers on notarization?
PCs and the WWW are massively bigger mass markets , not walled, and it's not like PC users are geniuses. Unless you mean that apple specifically caters to even less technical people.
Nope.
I've never had any issue with macOS software acquired outside the MAS and I've never heard of any non-technical user with a problem either.
Notarization is not about security, it's about the iOSification of the Mac.
Do Trojans not exist at all on Mac? Honesty question (I have certainly seen them on PCs; on Linux I worry more about packages).
When Zoom was found to have a serious security issue, Apple stepped in and blocked execution of the older versions of Zoom.
This would not be possible if malware just mutated to avoid detection. For this reason they want to attach a verified developer identity to applications, something backed by an individual's physical address or business records. You pay for this verification, and get a certificate to sign your applications.
New this year, they added a notarization service. This fixes some issues with signatures expiring, but is also built where Apple scans the application for malware before signing.
The scanning is new, but the developer id requirements have been in place since 2012.
If you distribute an unsigned app, the user will by default not be able to open it. You can set an exception as easily as selecting 'open' from the context menu and then saying you will allow the app to run.
You can also disable both the malware list and gatekeeper in general.
Note this is all separate from distributing in the Mac App Store, where you may run into additional policies around requirements for sandboxing, branding, use of private functions and frameworks, etc.
On linux, package signing is typically direct trust. You can manually choose to trust a packager who isn't trusted by your distribution, which is trusted by default.
I don't think linux distributions have anything to deal with malware after-the-fact, however.
I know it's anecdotal, but I doubt there is any objective data out there.
However, you cannot technically implement a JavaScript JIT since they will not give you a security entitlement to create and execute arbitrary code. You would need to either leverage JavaScriptCore, or use a (drastically slower) interpreted mode for JavaScript.
I don't use app stores. Never have. And it's for this reason. I do not favor the control coming. If my computer will not run an executable on command, it really is not my computer. Useless and definitely not something I trust.
Actually I do grab free things off Google play, but I side load as often as I do that.
I think we're gonna see fairly modern systems added to the category of retro computing. It will be a system that just runs programs developed by others. Imagine that!
You don't really - you can use Electron and other frameworks to build it on a different OS, and just package it for macOS.
[1] https://gist.github.com/SchizoDuckie/2a1a1cc71284e6463b9a
At work, I do this for in-house command-line tools. I have automated unit tests and integration tests, and all the compilation is done on a CI server. And if a problem slips through automated testing, well, then somebody will ping me on Slack and I'll fix it.
I only need to take out my MacBook Air to debug something once every year or two.
We may actually need to start a conversation at work about whether we want to continue supporting Macs internally. We could notarize our own CLI tools, but we also rely on lots of open source CLI tools, and I understand that all of those will eventually need to be notarized, too.
I can’t test on a mac, as I don’t have the money for one, so I build the binaries with Travis CI automatically, and never test them myself — I also can’t notarize them, obviously.
this is not hypothetical; I literally just received a GH issue update asking if we can use community funds for the $100 ransom^Wfee.