Currently, you have three options to distribute software on macOS.
1) You register as an Apple Developer (which costs $100 a year) and distribute through the Mac App Store, where Apple will do their review/automated scans/whatever, resign the app with their certificate, and then distribute it.
2) You register as an Apple Developer but don't distribute through the app store, and instead sign your software with the certificate you get through the developer program. It looks like, starting in macOS 10.14.5, you'll have to upload your software to Apple to be "notarized" if you want to distribute this way. It sounds like it's only for new software at first, but eventually old software will stop working unless it's notarized.
3) You don't register as an Apple Developer, and you just build and distribute software however you like. Currently, if a user tries to run your software it simply won't run, and the user has to know to go into system settings and manually give it permission. What isn't clear (at least to me) is weather this option will remain unchanged. This sentence:
> In a future version of macOS, notarization will be required by default for all software.
kind of makes it sound like like all software will have to be notarized, which implies that you have to be an Apple Developer to distribute at all. But saying "by default" makes it seem like there's some kind of option given to the user, so maybe it just means that software that's distributed by a registered Apple Developer but isn't notarized just moves down into the third tier of software that has to be explicitly allowed to run by the user.
It seems like Apple's ideal model is that if a user wants to run software of any kind, it has to go through them (like iOS). I don't think that's what they're announcing for macOS, but it's a little hard to say for sure.
No, you don't need to go into system settings. Just right-click on the app and select "Open" from the context menu. This brings up an are-you-sure dialog that gives you the option to go ahead and run the app. If you choose to run it, Gatekeeper marks it as trusted and won't bother you about it next time.
Don’t be so sure. It’s truly impossible to predict and understand some of decisions Apple's made in the pro market.
Best one can hope for is to get an explanation 10 years from now in a podcast or blog post. If there’s still such a thing
Software that you build locally, or that you install with a package manager, is not affected.
The goal of Gatekeeper is to keep your Mac safe -- not to control what you can do on your Mac.
xattr -d com.apple.quarantine FILE
As long as I still can't trust Linux to successfully deal with suspending without hacks, I'm not gonna move over. It needs to be bulletproof that if I close my laptop, put it in a bag, and then later open that bag my laptop A. wakes up and B. hasn't overheated and drained the battery. macOS gives that peace of mind, and I feel that is paramount for a laptop to be usable. I can't believe this is still not a fixed problem in the Linux world in general, and especially on a 4 year old device.
My Asus Linux supported netbook wasn't properly a flawless experience and those beautiful AMD open source drivers mean I will never get back the same OpenGL feature level and hardware acceleration provided by fxgl, that I had at sale time.
I wrote a post about my experiences here. I got almost everything working except Wi-Fi or ACPI/suspend. It wasn't easy and I would not recommend Apple's non-standard hardware.
It would seem that if a developer OS was going to work correctly on any machine, ever, that would be the one, since an issue there would bug the largest possible group of people who were capable of doing something about it.
But it doesn’t. I think he has a valid point.
No, this is simply untrue. Once you step outside of the US SV and WebDev bubble, there are millions of developers writing code for on Windows and Linux for stuff that you never even heard of. Mostly because it's unsupported on Mac due to the locked down ecosystem. Obscure machine controllers and their drivers, planning software, banking software, regulatory mandated software for certifications, etc.
I did industrial cs, so development was mostly focused on embedded devices and nobody here used a mac for anything.
Wouldn't have worked anyway, since people tend to be tinkerers. That is usually not a group using locked down environments.
You're certainly correct that that's due to a combination of nobody caring enough to pay for that to happen (and the few people who could in fact do something about it simply configuring their own personal machine to work correctly.)
Because I don't want Linux. MacOS largely still just works and Linux is moving away from its strengths as quickly as possible. I don't want systemd. I don't want pulse audio. I don't want Wayland. Linux's strength, for me, has been that it's unixy. If I'm moving to a non-unixy setup, like Linux is becoming, I want it to be as polished and well supported as possible. Linux, simply put, is none of those.
And, quite frankly, I don't want a Thinkpad (and I can't stand that eraser tip pointing thing). I bought a 2015 rMBP late last year and cross shopped offerings from Dell, Lenovo, and one of those Linux laptop companies whose name is escaping me right now. The Mac won out and didn't command a premium over comparably specced alternatives.
I'll spare the ranting about the Gnome 3, new GIMP UI and systemd in general (but these are both major issues for me and symptomatic of a culture I don't want to buy into). I recently tried to set up a Pi Zero with an Audioquest DragonFly DAC. The DAC just works in FreeBSD and MacOS with no hassle. I was able to tweak ALSA to get sound out of it, but shairport-sync can't set the volume (which works just fine on FreeBSD). WiFi was a struggle as well. I forgot what an archaic mess of procfs tunables and bizarre config files Linux on the desktop can be, and I don't want to spend my days debugging my desktop system.
One of my coworkers at megacorp got the officially sanctioned Linux laptop (some Dell thing). Like a good end user he installed updates as they became available. Turns out megacorp bought the Windows version of the laptop and installed Linux on it. Well, my coworker installed some firmware updates that promptly re-enabled secure boot borking his system. He lost a day trying to figure out what happened (Dell wouldn't support Linux on it and corporate IT was entirely indifferent). I don't want to dodge a minefield masquerading as a support matrix.
It seems like it's been the year of the Linux on the desktop for most of my adult life.
Edit: Downvotes don't win over users.
How is it a strange argument? Apple did a good job developing its daemons, and did so for a brand new operating system. Pottering did an abysmal job imitating Apple and is doing a worse job at maintaining his software (e.g. Pottering refusing to open CVEs for known vulnerabilities), and has worked tirelessly to replace working solutions.
If I want non-unix, I go with MacOS. If I want unix-ish, Linux doesn't fit the bill. Much like how I chafe at the GIMP developers chasing non-existent "pro" users with unwieldy UI changes, Linux on the desktop seems to be chasing change for change's sake.
I personally prefer systemd and moved from Ubuntu to ArchLinux a long time ago in order to use it. But I agree with you, the constant overhaul of UI is a problem which is why I have stuck to Xfce for a long time. I however, do not use GIMP, but there may be other options out there.
By the way MacOS is Unix, it is a POSIX compliant OS. Also, you can run Linux on your Mac.
And, sure, MacOS is unix-ish but Apple is ripping more and more of the old NextStep and BSDish things in favor of their own stuff with each version. As long as it just works I'm pretty happy. There are, however, lots of little quirks and gaps with their POSIX layer which is why I'd hesitate to call it a proper UNIX.
Also, you can run Linux on your Mac.
Which would be great if I wanted Linux. I don't. MacOS is working just fine for me.
OpenBSD's ftp command has become a generic multiple-protocol file transfer tool, different to the ftp commands of the other BSDs. (FreeBSD puts this functionality into a tool named fetch, instead.)
The r- commands were eliminated from FreeBSD some time ago, with much the same happening to them as happened with telnet on MacOS. They are no longer in the operating system, but are applications that one can install from packages/ports.
BSD re-vamped its command-line interface to ps in 1990. It has been getopt-based, and documented as such, for 29 years and 7 days.
rc.local was labelled obsolete in FreeBSD in 1995, and deleted from base in 1998.
And so on.
Hence, I doubt the security community requests what is asked for in this issue. And I am pretty sure it's not our job as developers to file CVEs for any bug – regardless how small – we encounter. CVEs are after all not our currency, but the security community's...
I agree this was a bug, but hardly a remote code exploit. The thread is very level headed and someone else filed the CVE. In the OSS community I run in this is normal, in fact I'd say it's very common for the primary developer to have a differing opinion about severity. But security doesn't depend on one bug ticket or one maintainer. There are many entities and teams at play that check and balance.
How so? In your own words:
someone else filed the CVE.
Having someone else override Poettering does not mean "Pottering did not refuse". It simply means saner heads prevailed.
You don't win a pwnie for high quality code, and the vulns they listed (as well as ones discovered subsequent to the award) all smack of low quality code. As the lead of a core piece of technology I expect more than childish whinging about how "CVEs aren't our currency". You like Pottering, great. I don't, and more to the point I don't like the results of his influence on Linux. When posed the question "why not switch to Linux now?" systemd is high on the list of reasons.
I was a happy Upstart user before Upstart threw in the towel too.
Systemd having taken such a different path to solving the startup and service problem, I don't think you can really say that Upstart inspired systemd, perhaps only Upstart's failings.
HN policy is to not gripe or discuss reasons for being downvoted.
Indeed. I made the switch years ago and there's less hassle on the Linux side. The big vendors are just so control-oriented now.
While I work a little faster in the Mac, it feels good running Linux. I don’t think I would be OK with option 3 - agree with you.
EDIT: I am fine with a sandbox for iOS, not macOS.
And with the current state of Android tablets, I guess I just won't be getting one for a while.
I have not done any real research for open source password managers. But a quick search did find <https://opensource.com/article/16/12/password-managers> which lists at least one. Personally I am very happy and frequent user of 1Password (by Agile Bits) across various devices.
I'm much less interested in running someone's custom port of OpenSSH to work with a phone UI than I would be to run some official port by the OpenSSH/OpenBSD developers. How hard is it for someone to harvest private keys, passwords and remote IPs in an app like that? Not very hard at all. Breaking the chain of trust between the repo and what I can build myself (or trust a third party to do, such as a linux distro) makes it much less appealing.
I agree, however I suspect I will still by mac hardware.
So, for me, it's really not a dollar-vote against this behavior ... unfortunately ...
I hate signed apps to be honest. They ruined the software landscape on mobile, and I don't want to see any of this on a machine that is used for work.
Security advantages are marginal, the lock-in isn't.
OK, quick lesson in how Gatekeeper works:
When you download a Mac app from the web, or save it from an email, a bit of metadata called the "quarantine attribute" is attached to it. When you try to run an app with the QA, Gatekeeper checks whether it's allowed to run; by default this will be allowed if it's signed. If it doesn't pass GK, you can still run it anyway by right-clicking on it and choosing "Open". When the app runs, regardless of whether GK passed it or you overrode GK, the QA is removed. After that GK no longer cares about it, and the app will just run normally without further fuss.
Safari and Apple Mail automatically add the QA to anything they download, and most 3rd party browsers and email clients now do the same. But if you download an app using most command line tools (curl, wget, ftp, scp, etc), or if you build it yourself from source, then the QA never gets attached to it in the first place, so GK doesn't care about it and the app just runs normally.
As far as I can tell the new notarization system doesn't change any of this, it just adds another form of code signing.
Currently, if an app isn't signed and you have Gatekeeper set to "Allow apps downloaded from App Store and Identified Developers", you'll get a prompt stating it isn't permitted to run. If you open it using the context menu, you'll get a button in that prompt to "Run Anyway". Alternatively, recently blocked apps by Gatekeeper appear in System Preferences allowing for manual override as well.
I'd imaging the notary service would be included in the "App Store and Identified Developers" section, and the same restrictions apply.
As for your own software, XCode signs it with your Apple ID automatically. Everything else, via terminal is the same as always.
I guess I basically want the web certificate system but much more selective, and don't ship a bunch of trusted ones by default. Of course there's basically zero chance of Apple or Android doing this without outside pressure since it's essentially them giving up the monopoly they have over their ecosystems.
Apple's AppStore and Google Play are bastardizations of the concept of a package repo. Instead of applications and their dependencies, Google/Apple distribute monolithic executable (duplicating shared libraries for every app) and disallow anyone else to have a trusted cert/3rd party repo.
There's F-droid of course on Android.
For instance, you might have a choice to read-only access to the filesystem and user hardware, or be allowed network access.
Without a static policy, the only choice that someone like Apple or Google would have to rampant abuse would be to blacklist the 3rd party key. This might mean blacklisting an entire repo if the repo owner is not properly vetting apps - which would likely be perceived as way more an abuse of power than the current gate-keeper model.
The non-technical reason is that there is zero financial incentive for a company to risk breaking their security model and affect their reputation, just so that other companies have the ability to not do revenue sharing.
The worst a website can do is trick the user into downloading something. The worst an app can do is steal their data, capture video from their mic/camera, wipe their computer, turn it into a DDOS bot etc. It's night and day.
And so trusting third party certificate issuers who currently don't verify websites or their owners and having them now certify apps is a pretty big leap.
The reason we can trust the CA certificates loaded in our browsers have proper processes and operate transparently is that the browser makers leverage those certificates being preloaded as bargaining power.
Would we have the opportunity to retain that sort of power in this decentralized world? Or do we start seeing the "essential" apps move out of the store and doing things like background monitoring of the user?
Who are users suppose to trust?
Back in the day users also trusted SourceForge....
That is why you should only do this if you are aware of the consequences.
We're at an inflection where in the future we will either retain some control over our devices, or almost none. I'm done arguing for complete control, that's boat seems to have sailed. I'm just trying to influence people to not throw away all their control at this point.
Which is that even incredibly smart, incredibly technical users will still click on random dialog boxes and open phishing emails.
I understand where you're coming from but I wouldn't bet on a future where users are going to be somehow smarter about this sort of thing.
For instance, the /System folder is not writable unless you reboot into single user or recovery mode, then run commands in a shell.
Several app developers (including Mojang with Minecraft) recommended turning off Gatekeeper to run their apps rather than dealing with developer signing or because they did not want to purchase a signing certificate. Apple eventually removed the option to disable gatekeeper from the UI (but retained it as a shell command).
The 'advanced user' override to run these apps has always been to select 'open' from the finder/context menu - but simply double-clicking on an app will give a failure screen, not an override/consent screen. (Yes - rather than telling users to right-click on their app, third parties told the users to disable app verification and quarantine for the whole system.)
I find it surprising how lots of people who live in democratic, free societies, still have this urge for authoritarian solutions to every problem.
The history of the judicial system has shown that even incredibly smart people will sign contracts that are clearly to their detriment. Does that mean the appropriate solution is to only allow contracts that have been vetted by MicroLaw incorporated?
Overall, history is full of smart people doing dumb shit. The only way to completely prevent that is draconian authoritarianism. I would think humanity should have understood by now that that doesn't end well.
It's not so difficult if your MacBook trusts Apple, Google, Amazon, and Microsoft out of the box.
Explicit consent is required for every apk install or update. Which is a bummer if you want to compete with the baked in store apps that "just work" and keep things up to date.
EDIT: Users, given a way to sideload, will always be taken advantage of. At least the enterprise program lets them be cured quickly. https://www.wired.com/story/exodus-spyware-ios/
There's a difference between "people are stupid so let's prevent them from doing stuff that might cause problems, even if sometimes it's useful" and "people are stupid so let's discourage them from doing stuff that might cause problems."
> Fortunately, Apple has to date and clearly intends to continue offering a way to disable this functionality for the "statistically irrelevant" subset of their users that have good reasons to.
For their OS, yes. But the trend of locking the desktop/notebook offerings down to be more like their phone offerings is clear. Maybe there's also drift from their phones/tablets to be more open like their offerings and I'm missing it, but if not, I'm pretty sure I can see where this will eventually end (if Apple gets their way).
The scenario you describe, where my pocket brain can be enrolled in a third-party App Store, is hostile to my security requirements for my pocket device and I’m glad Apple prohibits it.
Nonetheless, it is essential to your liberty and freedom.
I have the ability to recklessly spend the entire contents of my bank account on Amazon purchases if I so choose. I'm certainly not faulting the bank for "allowing" that though! Truly, I will never understand why some are so eager to have their behavior dictated by others.
Would you consider such (common) systems to be authoritarian?
It is unfortunate that technology evolves so much faster than the average person's understanding of it. It both places a huge need on such intermediaries being present, but puts the running of such an intermediary outside of an entity supposedly operating in the public good (like the government) and into the hands of a corporation that may in one way or another be motivated to abuse such a role - and even if they try not to, being a for-profit gate-keeper guarantees they will be perceived as abusing such a role.
That question can only be meaningfully answered on a case by case basis. Many of them do cross the line as currently implemented in my opinion; to what extent varies. Oftentimes there is a perfectly reasonable explanation for their design rooted in history (ex being created prior to the internet or some other technology). On the whole most of them seem to work well enough.
I would note that the presence of one flawed system does not serve as justification for others to exist as well. The world is certainly imperfect, but that is not a valid argument against improving it.
> places a huge need on such intermediaries being present
I don't dispute this - what I take issue with is the inability to opt out.
> being a for-profit gate-keeper guarantees they will be perceived as abusing such a role
Regarding app stores, the manufacturers could have trivially set them up such that it wasn't possible to abuse them. Functioning examples of such systems already exist. They specifically chose not to do this, so I do not think it is unreasonable to assume the worst about their intentions.
So, your argument doesn't pan out, I think. At some point experts are expert and you are not. I am not an expert at app stores. I defer my app store choices to the people who make my phone, because they have a track record of choices I usually approve of, and their missteps are never in service of "exploit me" (like Facebook's). There are many competing hardware platforms to choose from with many fewer restrictions. I choose the more-restricted and my free time available to focus on actual benefits to the world increases. I don't believe I would benefit the world by using a third-party app store, and I don't have time for the drama it involves. YMMV.
What I am claiming is that you don't have freedom if you can't make these choices for yourself. Sane defaults are fine. Shipping with a prepackaged app store is fine. Even having to reboot the device into a separate mode and enter a password in order to change sensitive system settings is fine. But if I want to add F-Droid, I need to be able to do that and it needs to be a first class citizen. I need to be able to remove Google Play if that's what I want to do. On iOS, there is not and can never be a third party app store under current policy. That is most definitely a restriction on your freedom as a user; I do not believe that any cohesive argument can be made against that statement.
Just because you have the option to opt-out of vendor restrictions doesn't mean that you have to do so. For example, my mobile device won't allow me to disable secure boot or to install my own keys, and it is incredibly difficult to locate one for sale that will. In contrast, my laptop will allow me to do both of those things if I so choose. Doing so requires rebooting into the UEFI shell, which I have the option of password protecting. None of this can be done by a malicious program from user space barring a truly massive security hole. As such, I do not believe that this freedom negatively impacts my security in any way.
I demand the right to take apart my hardware and software as I see fit.
I do not demand the right to receive active support for doing so from the manufacturer.
If they can lock me out with their technology, that is their right as author of the technology. If I can circumvent their lockout with my technology, that is my right as purchased of the technology.
Apple does this so well that most of us aren’t capable of hacking their technology. Good job.
A certain large American tractor company tries to take away your right to attempt to hack their device, rather than simply making it difficult. I disapprove of this with every fiber of my being. As purchaser of the tractor, I may do whatever I wish with what I chose to purchase.
When I buy an iPhone, I knowingly choose to purchase a device that keeps me out so effectively that there are no known ways to hack into it if it’s up to date. Apple has the right to make it so, and it’s very useful to me that they do. I then continue to update it to maintain that line of defense. Folks who root their phone choose otherwise on both counts. That’s their right, too.
If you wish to remove Apple’s freedom to build devices that defend against non-Apple software intrusion, you’re welcome to campaign for that, but I support their freedom to build security countermeasures to the same degree that I support my freedom to purchase a device with those countermeasures enabled. My freedom need not come at the cost of theirs, as the plethora of Android options clearly evidences.
Perhaps an analogy would help here. For example, suppose auto manufacturers started welding the hoods of new vehicles shut. Suppose that legislation was subsequently passed which banned this practice and asserted that you have a legal right to access, inspect, manipulate, and replace the internals of a vehicle you own. This would not be equivalent to requiring the manufacturer to actively support such activity! It would only prevent specific undesirable behavior on their part.
> I support their freedom to build security countermeasures
This is a false implication about my position, and my previous post very clearly addressed this exact point. Providing the user with the means to optionally unlock things does not require that security be diminished. Functioning examples of this already exist in the wild.
> If they can lock me out with their technology, that is their right as author of the technology.
Currently, yes - from a legal perspective. For the public good, that needs to change. We have ample evidence at this point that we cannot rely on the market to make choices in its own best interests in this case. The market consistently chooses the cheapest devices and the largest ecosystems; it does not appear to select based on the openness of the ecosystem. Meanwhile, manufacturers are actively walling off their ecosystems wherever they can get away with it. They often point to security when questioned, but I find these claims dubious at best. Meanwhile, their behavior demonstrably protects their profits while actively pushing our society towards a state that is very easily abused in a great many ways.
To my mind, such regulation is conceptually analogous to the ADA compliance requirements for certain types of buildings in the US. Without the ADA regulation, the market would almost certainly not choose to conform on its own. Nevertheless, it is clearly in the public's best interest for it to do so.
Editing to add: Your belief that there are no known ways to break into an iPhone if it is up to date is almost certainly incorrect. This article (https://motherboard.vice.com/en_us/article/qvakb3/inside-nso...) from ~6 months ago was on HN at some point. From the article:
> He gave NSO that phone number and put the phone on the desk. After “five or seven minutes,” the contents of his phone’s screen appeared on a large display that was set up in the meeting room, all without him even clicking on a malicious link, he said.
I have no doubt it's related to the recent rise in authoritarianism too.
Do any of them allow a third party to certify a general purpose application from another developer as safe?
> That’s how they were able to globally kill that Facebook VPN scam app that used Enterprise Certificates, and that’s why all non-enterprise app distribution methods carry an expiry: either you’re a free sideload developer (one week), a TestFlight user (twelve weeks), or an enterprise user (no expiration unless your enterprise earn a revoke for distribution to the public).
To me, that sounds like they're happy to provide various levels of workarounds as long as there's absolutely no way it can compete with their app store. I suspect an enterprise signature used to sign various third party apps for distribution would not be looked upon kindly by them. What's more, I don't believe they should have final call over what software should be allowed on the phone, so even if they did allow a more general signing capability, what ecosystem is going to develop there when the metaphorical Sword of Damocles or Apple's arbitrary whims as to what is acceptable or not are continually reassessed (and possibly checked for conflict with Apple's future business ventures)?
> The scenario you describe, where my pocket brain can be enrolled in a third-party App Store, is hostile to my security requirements for my pocket device and I’m glad Apple prohibits it.
Possibility is not the same as certainty. It's only hostile to your security if utilized. If the ability to do so was gated by a settings toggle, you would be no worse off than you are if you did not enable it.
I certainly hope not.
As a simple example, might you be willing to trust Mozilla to offer a service where they review and certify all submissions that pass review for apps that are willing to pay for the process (allowing Mozilla to use some of their credibility and engineering expertise to raise funds)? I would. It wouldn't be perfect, but it would allow for a company with different principles and motives than Apple to be used, and my sensibilities lie closer to Mozilla's than they do Apple's or Google's.
It's in Apple's interest now to position themselves for privacy, because that differentiates them from the major alternative. That said, it's irrelevant who is more trustworthy now. That may change over time, and just because Apple is trustworthy now doesn't mean their business can't change over the next decade. Should we allow a precedent that just because a company has been trustworthy so far that we allow them to ensconce themselves as thew arbiters of trust thereafter?
People thought Google was very trustworthy in the past. I think Google was trustworthy in the past, but little by little they've been incentivized by their business model towards decisions and stances that are not as aligned with what I want anymore.
Companies change, quite a bit and quite often actually. All it takes is different management and/or a different board for a public one. Allowing people to actually assign who they trust at a more granular level than "Apple or Google" is essential if we want a say in our future.
Google was about tracking and ads as their business model once they found one. As was Facebook.
If the lack of “freedom” is killing innovation, where are all of the profitable businesses that take advantage of Android’s “openness”?
If Apple’s “walled garden” is holding back innovation, there should be a lot of innovative, successful third party products that are available for Android that aren’t available for iOS.
Those are the only two platforms we can compare right now when it comes to the “open” vs “closed” debate.
If there are not much innovations happening on other platforms then why are Apple afraid to allow side loading?
Your original point about profits and freedom makes sense now. If Apple allowed side loading or other stores then its profits would decrease. There would companies who would like to bypass that 30% cut. So yes your point is correct its all about profit rather then privacy or freedom.
The only companies that are forced to pay the 30% cut are the game developers for loot boxes and magic diamonds.
So Android users knew they were making a choice to install privacy invading apps? Not to mention all of the spyware that you can install on someone else's phone?
I understand the point you're trying to make, but (1) Apple has delivered software which rips CDs with the OS for 18 years now, and (2) this feature not only doesn't block any number of ways to block ads, but Apple provides an API for blocking content (including ads) with both macOS and iOS.
I would be surprised if iTunes survives this one.
> (2) this feature not only doesn't block any number of ways to block ads, but Apple provides an API for blocking content (including ads) with both macOS and iOS.
Apple's content blocking API is less flexible and useful than the more powerful general purpose API it replaced in the Safari 12 lockdown, which proves the parent's point.
And seeing that all music sold by Apple has been DRM free for a decade, are you thinking they are not only going to reenable DRM, they are going to make it more restrictive in 2020 than it was in 2003?
So while you’re assuming evil intensions, occam’s razor would suggest that instead this is actually about preventing ever increasing malware even for software that don’t originate from the App Store. It’s about creating a record that traces executables back to their authors.
They have been presenting it as a simple choice between letting big corporations kill our kids for profit and a safe internet where companies take responsibility.
There is very little debate beyond that. No criticism. No questioning of causality. No journalism. No science. It's pure propaganda.
Not even even the breathtaking logic of banning "harmful but not illegal content" is raising eyebrows.
Yes, liberty is sometimes difficult, and it allows people to make bad choices. Liberty is hard.
We've seen this story play out enough times to know that it isn't a slippery slope. It starts of as a play to "protect the users" or "avoid the bad guys", or as we have seen in the security theater of other domains, namely the aviation industry, "for your safety and security"
You can always buy a different platform. Seems like that's plenty of liberty.
Just imagine the world in a decade or two: it'll be one of mandatory secure boot, remote attestation, and centralized app store distribution. Regular people just installing software? That's unthinkable. It'll put themselves and others at risk. Even browser extensions will be tightly restricted. If you want to write software, you'll have to get a developer's license and accreditation from an industry-wide professional association, who can remove your accreditation (and ability to get a run-your-own-code certificate) for any reason. Sure, you can find some 2019 laptop and run Linux on it, but your ISP won't forward your packets if they're not signed by a trusted kernel. Good luck running some tin-pot mesh network in whatever tiny sliver of unlicensed spectrum remains.
Think this scenario is unlikely? I wouldn't be so sure. All the bits of technical infrastructure we need for this dystopia already exist in one form or another. There's also significant social and political pressure to rein in the internet --- pick your favorite pretext --- and it's inevitable that platform vendors will respond to this pressure. I've heard a disturbing amount of talk lately of the need for centralized control in order to combat "disinformation", for example. Already, we've lost an amazing amount of ground on software freedom relative to what we had ten or fifteen years ago. Most people already use a primary computer that they can neither control nor inspect --- and they like it.
Mark my words: in ten or twenty years, policymakers and very serious establishment types will regard letting regular people just make their own software and connecting it to the public internet as unnecessary, dangerous, and suggestive of some kind of moral fault. It's starting already.
But, fighting optional code signing the wrong battle. As long as the requirement can be disabled, there's nothing wrong here. Safe, but optional defaults are a good, practical compromise.
What I do find disturbing is when people praise Apple's locked down iOS model, as a means of enforcing privacy standards on developers or some such. People have argued this point on Hacker News: https://news.ycombinator.com/item?id=19051678
I'm not convinced this is true. Over time, voluntary adoption of this will steadily increase. Then when it reaches a certain level of ubiquity, Apple can flip the switch to make it mandatory and since 99% of users won't have their day-to-day impacted the blowback will be tolerable to Apple.
This has to be fought now, while it still is optional. Otherwise we're already sunk.
The problem with "slippery slope" arguments is that in many aspects of life, the optimal solution is a balance between two extremes. You can't reach that midpoint unless you're willing to venture down the slope partway.
Here's another way to prevent this eventuality—teach everyone how to disable these checks, when they have a legitimate reason to do so. I feel like I keep getting blowback for saying this, but I'm pretty frustrated at how strongly much of the Apple community advises against disabling Gatekeeper and SIP. If you want to theme your Mac's UI or modify UI sounds or some such, and you're savvy enough to boot into recovery mode, go ahead and turn SIP off, and don't feel like you're constantly putting your data at risk, because it's really not that big a deal.
Of course the major distros like Ubuntu can boot with the default secure boot keys.
I have a feeling x86 manufactures would face considerable backlash if they tried to lock down SecureBoot in a manner where it's impossible to disable. (and yes, I do know there are some Microsoft devices that are already setup this way, but the majority of manufactures do allow control over SecureBoot). Then again we have Intel ME on all our machines and that's somehow still okay, so maybe you're right.
There was "considerable backlash", to say the least, to every little step along the way to the current, ridiculous reality you describe.
No one cared about our objections. The voices of those that care about free general purpose computing are not important to those who make the decisions.
We are frogs and we are being boiled.
This happened before with radio and TV signals. A great way to have peer to peer comunication, with local TV's and radios, ended up being regulated.. and in our culture, its normal to sit in front of a TV, and have a few monopolies to choose what we will watch.
And right now its unthinkable to revolt to those kinds of laws that forbid us to transmit content, as we accepted as normal (where's the cultural aspect of it, shaping our behaviour).
The same will happen to the next generations if we dont take a stand against this. Normal users wont understand the social, cultural and political implications of this. Companies like Apple defining what you can or cannot use, listen, see or install in your own device.
I don't think this is comparable. Radio and OTA TV needs to be regulated by a central authority or it won't work for anyone beyond a certain level of technological penetration. There's a set amount of data that can fit in the amount of spectrum available, and a radio station is transmitted to everyone whether they request it or not.
You've always been free to create and distribute VHS and cassette tapes because those don't eat into the amount of spectrum available to everyone.
It isn't like the big software houses would fight against the idea.
There is value in requiring all software to be validated by somebody but it’s a slippery slope to have ONE. The main reason is, even if I trust “Apple” now, what is “Apple” in 10 years? (Heck I thought I “trusted” them to always make desirable hardware, got burned on that one.) Things change. I want another signatory.
This model can work. It's just that microsoft is being sloppy.
Malware is very common on the Play store as well, signed software by one gatekeeper does not guarantee anything.
I think that when you look at how things went for the certificate business, you will find this model pretty quickly turns into a pretty scammy breed of companies offering "notary" services without a lot of benefit to consumers. Consumers would have to know which authorities were trustworthy, and since most won't care/know, it results in lower security overall.
Now if the App Store were decentralized, I think things would be a lot different. But Apple already owns things end-to-end, so they may as well be the certificate authority as well.
Beginning in macOS 10.14.5, all new or updated kernel extensions and all software from developers new to distributing with Developer ID must be notarized in order to run. In a future version of macOS, notarization will be required by default for all software.
Apple recommends that you notarize all of the software that you’ve distributed, including older releases, and even software that doesn’t meet all of these requirements or that is unsigned.
It’s very vague as usual.
I guess the current work arounds will still apply (right click open, for instance)
But we'll probably have to wait for WWDC for a definitive answer
Developer ID signing will eventually be replaced with notarized Developer ID signing, on some suitably long roadmap that can be assumed to first involve a change in new app signing, then developer warnings of impending change of default on new OS version, that new OS version having user visible warnings, finally having the old developer id signatures ignored (making apps behave as unsigned, requiring the same right-click opening/exempting as today)
For those who are looking for my entry into the pool - the OS changeover for user-visible warnings will be this time next year, with it made obvious (at WWDC 2020) that the September 2020 macOS major release will make the final change to ignore old non-notarized signatures.
How does Apple check against malicious software? What is even considered "malicious" software? Software that someone might consider benign might be considered malicious by someone else - it isn't a black and white thing.
The UI just provides a false sense of security. I assume they check it for known malware, but it wouldn't do anything against a targeted attack where the malware is custom made and only ever used once. In fact, it would facilitate the attack by giving the user a false sense of security that everything is OK.
KB page says "[...] The Apple notary service is an automated system that scans your software for malicious content, checks for code-signing issues [...]"
It's an automated check that Apple has not disclosed.
So many questions, hopefully Apple answers these soon.
I have to assume that it will still be possible to compile some code and run the executable without first passing it through Apple’s servers.
To notarize an app, you upload it to Apple. They'll run malware scans on it and such.
This only applies to people distributing apps outside the app store with the $100/year Developer ID certificate. If you're not signing your apps, I believe the behavior will be unchanged, because your app would already be blocked from running by default.
When you download an app from the internet using a browser or other quarantine-aware tool, it receives a "quarantine" bit and metadata recording the download URL. When you try to run the app for the first time, a window pops up saying "You got this app from shadywebsite.com, are you sure you want to open it?". Right now, the app's code signature is checked, and you get a message saying "this app can't be trusted" if the code signature check fails or the app isn't signed. Once notarization is required, signed apps that are not notarized will be prevented from launching in the same way as unsigned apps.
1. This will probably be a setting under "Allow apps downloaded from:" in System Preferences -> Security & Privacy you can revert if it breaks your workflow.
2. If the notarization check reuses the current mechanism, it will only apply to quarantined apps. If you're compiling something yourself, the compiler won't put a quarantine bit on it and it will execute fine. Same with homebrew/friends.
There's no longer a GUI option to allow unsigned apps by default. It was removed from System Preferences some versions ago.
But, you can do it via a one-line terminal command:
sudo spctl --master-disable
I would expect Developer ID certificates to all expire by the changeover, with the only point for continuing to ship Developer ID certificates would be so that new app builds can work on pre-Mojave OS releases. Or I suppose skipping any Apple-run scans of your software.
Notarization is an advanced version of this where Apple adds to the signature "we have scanned the app for vulnerabilities and will continue to do so"
How does code signing work in Windows (for normal win32 programs)? I know I don't have any problems running 15 year old programs, which I have to assume predate any type of code signing.
If you're going to be pedantic, you've reversed cause/effect by saying "notarization won't come into play because you can't notarize an unsigned app". You can still upload it to the notarization API if you like and watch it fail the tests, as this is a separate step from codesign. Whether you choose to do that has nothing to do with whether you've signed it.
1. Run only apps from the App Store
2. Run apps from the App Store or signed by a Developer ID
3. Run all apps (a hidden setting)
The default is 2 and you can achieve 3 (even when 2 is selected) by right-clicking and selecting Open on first-launch.
This change relates only to 2. "signed by a Developer ID" is being replaced by "signed and notarized by a Developer ID". This change applies immediately to developers who have never released a Developer ID app and will apply to all Developer ID apps in a future release of macOS.
From a user's perspective, this is a technical change that makes no difference. From a developer's perspective, it's a new, mandatory step in your deployment pipeline but otherwise not a major issue.
Apple knows and relies on the fact that a regular Mac user would be intimidated by requiring a terminal command: `sudo spctl --master-disable` to enable un-trusted apps!
EU, FTC, et. al. need to look into this monopolistic behavior, where Apple constantly cock blocks anything it hasn't blessed, the fee for the blessing - a cool $100/year, assuming they don't start arbitrarily rejecting the said blessing, as is the case with their iOS app store.
Apple's entire marketing strategy revolves around customer empathy, but their actions don't
But, no security defaults with either Mac, Linux, or Windows stops an app that has user level access from having access to all of the user’s documents - except for apps that are either in the App Store or voluntarily sandbox themselves.
It's interesting that Apple has created two similar protecting technologies. Here's a good article explaining the similarity / differences: https://lapcatsoftware.com/articles/hardened-runtime-sandbox...
I own my Mac, I’m responsible enough to decide what app to use and not to, I don’t need apple’s help. This transition of OSX to be more like iOS is definitely gonna result in me switching to Linux for good.
This, plus things like advertising on the App Store are really gonna make me switch all my devices.
Thanks Apple, but no thanks.
iOS, by contrast, doesn't give you any choice in the matter. That's a big difference.
Not that I think users shouldn’t be encouraged to be aware ... but it feels rather odd.
From what I see around me, the vast majority of Mac users spend the vast majority of their time in mainstream apps (Chrome, Adobe, Office, Safari, Xcode, Final Cut, Logic, Ableton Live, etc). I don't think this will impact the majority of mac users negatively.
This will only really impact macOS developers without an Apple Developer account, which I guess are a minority. Probably in that minority most are compiling to macOS from Windows or Linux.
You are not being the devil's advocate here.
Whatever MS, Google or Facebook do its the end of the world (as it should), but apparently for the HN crowd, Apple can do whatever they want.
This monopoly over our digital life will have severe consequences in the future. People here are so smart, but when its about Apple, their sentimental reasoning start triggering.
Actions like this one, as many others, are some of the reasons why i never use anything from Apple. Its like a car factory being able to decide where you cannot go with "their" car (Its yours). Or the clothing company choosing the places i can use "their" clothes.
The hacker spirit here ends when is anything related to Apple, when in doubt just read the top comments here in this thread. Its not a 'benevolent ditactor hacker' sort of social contract.. its a company which need to raise their profits so their shares keep being valuable to the stock market. If consumers and developers let them, they will own our digital life, and lock us with them.
We have no legal framework, and no State to intervene in our interests as it should be.. States and democracies are a dying species, and we are the ones to blame.. we, as in the general population, just want the next shiny gadget.
But i bet we will miss the things we have, but dont give much value now. Lets not forget the share of our lives that are constantly being transfered to the digital dimension, and how important they are now.
> But i bet we will miss the things we have, but dont give much value now.
For a minority. A vast portion of users are happy with the iOS model.
I don't think the majority of Mac users share your ideology.
As others have pointed out, at least they should allow third-parties in where users could let trusted parties (from his point of view) provide him software for a machine he owns.
People are being näive thinking this is really about security, when in fact, its about control, power and profits. And when (some) people wake up to this fact, it will probably be too late to take any action. And i bet the majority wont even know what they have lost.
Its clear they are not thinking in their users insterests first with this move, because they are giving security with one hand, and taking freedom with the other hand.
For instance, if some app compete with them in things they think is strategic, with the control they have, they can make the app vanish and not be a problem at all for them.
We see this happening with Google everyday in search results for instance. We saw this with Windows before, but this time i think it will be much worse..
Hackers will find a way to unlock the kernel, but im sure by that time, those companies would be so powerful, they would have a legislation for that, so those kind of actions could be punished with fines or even prison.
I know im exagerating in this last scenario, but it is all possible, and with time it get more and more likely to happen.
This shouldn't change the behavior for these apps - for several years, these apps have been blocked by default, requiring the user to open them from a menu (rather than by double-clicking) to get the option to allow them to run.
The change is in the process for macOS developers with apple accounts - in addition to signing locally with their developer id, the build is uploaded to apple to scan for issues then notarize.
This does give different properties to the app - builds can be individually revoked, and the signature can outlast the developer certificate. It may mean eventually that macOS apps using private API can no longer be signed - that depends on what apple checks/does with the builds before notarizing.
Do you have experience to share concerning the Surface Book or moving from macOS to Windows?
Just change the setting if the default doesn’t suit you.
That is my point.
Overall it's just more productive and pleasant. If there were a practical alternative I'd jump in a second.
Developing for all platforms is a commercial reality, regardless of what I think, but wanting freedom to develop software for any platform without a corporate's approval is not unreasonable. The complaint applies to Google and Microsoft to some degree as well.
If you turn off SIP, you can run unsigned kernel extensions without issue, both on a Hackintosh and on a real Mac†.
If you're a Hackintosh user, but for some strange reason you want to leave SIP enabled, you can inject unsigned kernel extensions via the Clover bootloader. (I think you may need to temporarily disable SIP during setup or something like that, I don't fully remember. I just turn SIP off.)
† I actually find this much easier than Windows, which is a royal pain in the neck if you want to install unsigned drivers.
As I see it, if you're the kind of user who's installing Hackintosh, you're also probably savvy enough to not grant root permission to just any software. I want to have full control over my computer.