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.
"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."
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.
Huh, I didn’t know of this but I did know about the settings and “sudo spctl --master-disable”. It’s probably supposed to be something you come across about as frequently as terminal commands for some then.
If they get rid of option 3, they will make macs unsuitable for a lot of development outside of the Apple ecosystem (they must still be good for development for iOS and macOS apps). Surely that is a large enough part of their userbase that they won't just throw that away
Surely you can turn on option 3 indefinitely for local builds at least. Otherwise Apple kills the ability to develop any software while offline or behind a firewall.
Gatekeeper only applies to software downloaded from the internet. Browsers set the "quarantine" attribute for downloaded files, and then Gatekeeper kicks in on first launch.
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.
I installed Kubuntu 18.10 on my MacBook Pro 2015 13" (12,1) and sleep doesn't work properly because of the USB3 controller. The MacBook will suspend correctly from a cold boot, but every suspend after that the MacBook immediately wakes up as soon as it successfully suspended. This a is a common issue[1].
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.
No one is making any money getting Linux sleep to work on a Macbook Pro 2015. That is why it doesn't work. Sleep can work on Linux, but it is hardware/driver specific. That is why you should only buy hardware where there vendor invests in proper support.
Either the vendor needs to invest in support, or you need the community to come together and build support like with Allwinner chips (which are dirt cheap, hence people building mainline, blobless support). Apple doesn't invest in Linux kernel support, and their userbase isn't motivated to do so either :/
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 too attempted to get Linux working on a modern MacBook. It's terrible. The keyboard and touchpad aren't connected to the USB bus (like on any other sane laptop out there), but instead to the SPI bus. ACPI is terribly broken (it always has been, but not quite this bad) and with the newer Macs with T2 chips, there's a chance you won't even be able to access the nvme drives from Linux at all.
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.
If memory serves the SPI bus thing is down to the UEFI - that is, when you boot into Windows, for example, it uses it via the USB bus. I can't remember the reasoning for this.
I battled this for months and no workaround worked. It sadly forced me back to macOS. I'd reopen the lid later and find the battery drained and lose work if I hadn't saved before closing the lid.
Complaining about it on HN ain't gonna fix your problem. Either wait for someone to fix it, pay someone to fix it now (perhaps along with other funders), fix it yourself (perhaps with a hack/workaround), use MacOS instead, use different hardware, or ignore it.
Stepping back a few feet to get a bit of perspective, it does seem like the OP is using the most common developer machine in history. Devs are historically Mac people, and are afraid of newer ones, so they hoard the 2015 MBP.
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.
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.
My statements still stand. The fact that there are many users of the hardware simply means that there might be many potential funders of a feature like this, or that it is more likely for someone to fix the problem for free in the near future.
Indeed. But it does tend to lend more credence to the point of the person you responded to, which is "nobody is ever going to make Linux work on a computer".
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.)
Why wait? You can do it gradually. I've been using Macs since 1985, and I still have one on my desk at work, but I noticed a few years ago that I'd gravitated toward doing most everything on Linux without really thinking about it. Just get a Thinkpad or something, put Ubuntu or Mint on it, and see how it feels.
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.
I think that is a strange argument to make for preferring macs over Linux. Many of the things you mentioned are inspired by osx counterparts (for example, launchd was the main inspiration for systemd)
I think that is a strange argument to make for preferring macs over Linux. Many of the things you mentioned are inspired by osx counterparts (for example, launchd was the main inspiration for systemd)
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.
You can avoid using systemd[1]. If you don't like the churn of desktop environments, may I suggest Xfce ? It is usable and does not overhaul things that often.
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.
Right, I can do a lot of things with Linux with enough effort. But for a desktop OS I want things to just work. Pretty much any major distro that's supposed to just work is going to be systemd at this point.
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.
Yep, I'm well aware. But as I said the little quirks and whatnot make MacOS feel less unixy. Obviously they're not deal breakers for me, but things like telnet, ftp, and OpenSSL disappearing make it seem like Apple is moving away from SUS (more than it is?). The delta between MacOS and everything else seems to grow with each release. It's probably worth noting that no vendor has tried to get Linux SUS certified and most distributions aren't even LSB compliant.
In fairness, the command-line world of the BSDs of the 1980s is long gone in some respects, and this is not just some Apple/NeXT idiosyncrasy.
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.
Citations needed for the personal attacks. For reference, my bug reports to systemd and the ones filed by my coworkers have been handled quickly and professionally.
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.
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 don't "like" Pottering because I don't know the person in the slightest. I have found systemd to be useful software and interactions on the issue queue have been reasonable.
I was a happy Upstart user before Upstart threw in the towel too.
I can't reply at your depth, but Apple and Google also appear to have won a "pwnie", whatever that is. I think think they still do respectable work in spite of it.
Also, thanks for the citation. I still strongly feel you've shown something that doesn't warrant a personal attack. As someone who gladly uses systemd while having no particular attachment to it, I find the aggressive and personal attacks confusing.
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.
And yet it is that very page where Lennart Poettering says exactly what I quoted. You have an argument with Lennart Poettering, and are trying to argue that xe did not take inspiration from what xe said that xe did.
You can’t just “get a thinkpad or something.” The latest X1 Carbon, for example, requires quite a bit of massaging to work with Linux. (Though that’s more a fault of PC makers than Linux. Because the PC market is so price sensitive, the BOM is constantly changing. So just because one generation of a laptop works well with Linux doesn’t mean the next generation will.)
Do you have any info on the issues with the latest (2019?) X1 Carbon? I was looking at it to replace my Dell XPS, but I'd like to be able to run Linux on it at some point.
This is why I still haven't bought a tablet. I was really excited to get the latest iPad with the A12 bionic, then I started looking into open source software (only really need two: password store and ssh) and realized it essentially doesn't exist.
And with the current state of Android tablets, I guess I just won't be getting one for a while.
For an open source ssh client there is the "Blink Shell", which can be purchased from the App store -or- you can build it yourself from source. I am unsure if the developers directly get any money when you purchase it from the app store, but they do mention the paid app with the source here <https://github.com/blinksh/blink>. It isn't often that I find myself needing to use an iPad/iPhone with SSH, but I've used WebSSH (perhaps no longer under active development) and Coda in the past.
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.
Open Source is what he said doesn't exist. I'm not sure, because it's been a while since I paid attention, but unless a project takes it upon themselves to go through the process of becoming an Apple Developer (do they need to decide on a person, or form a non-profit, or can they somehow register as a non-legally recognized organization?), how doe they distribute a fully open source version with some assurance that what you're running on the device is what's in the open source repo?
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 interpret the "by default" as meaning the exact same thing as "Developer ID is required by default for Mac apps" today. Or in other words, I would assume that getting around a non-notarized app in the future would have the exact same sequence of steps as getting around a non-Developer ID-signed app today.
There's no interaction with Gatekeeper there. An executable you've built yourself will just run normally (assuming it has the x attribute of course).
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.
That's like the "Zone" alternate data stream in Windows/NTFS for the Windows folks. And as in Windows some apps add them, some don't. (Windows ZIP vs 7-zip)
I'd imagine it's another tier for Gatekeeper (the mechanism in macOS that verifies this). Gatekeeper can be outright disabled if desired (appears missing from the System Preferences UI though), allowing all unsigned code to run.
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'd read the 'by default' as it being turned on system-wide and up to the user to override on a per case basis. Of course Apple's ideal model is that they want everything going through them. They're going to enable it 'by default' and if customers don't scream too much, they'll likely make it mandatory a release or two later.
What you describe in your point number 3 is not for apps, but for kexts (Kernel Extensions). Upon installation they won't run by default, but the user is allowed to go to System Preferences > Security and give it permission to run.
You know, I really don't mind the idea of something like this (which is really one of the added benefits of an app store), but I really wish there was a way to add different trusted parties that could sign apps. Sort of like Android where you can add third party apps, but actually go the full distance and allow separate app signing authorities, and while it should be covered in numerous warnings about not adding another signing authority without complete trust and nobody should be walking you through it, it shouldn't be terribly hard to do. If I want to install Amazon App Store apps instead of Android apps (or vice versa), that shouldn't require me disabling security mechanisms on my phone and installing a separate program to manage everything.
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.
Like, oh say, the package repositories on any running Linux system? Yum/Zypper, Apt .. they all allow you to add a 3rd party key and repo address. Gentoo allows overlays. There are teams like Jenkins that maintain their own repos. I maintain one myself (https://repo.bigsense.io).
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.
The technical problem is that to protect system and user security and privacy, third party signed apps would be very limited. This is under the assumption that most users have a limited capacity for understanding the security and privacy ramifications of unfettered access by apps. (Basically - if you can understand this, you already know how to side-load apps onto Android/iOS devices)
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.
It's nothing to do with monopolies. It's just that it's an unworkable idea.
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.
You misunderstood what I was suggesting. I'm not saying existing certificate authorities should sign apps, but that allowing a trusted authority to sign and distribute apps that a user could opt in to would be beneficial. Think yum/apt repo signing keys, and how if you add a third party repo you can require the public key signatures to match, except tied into the OS much closer. I used the CA analogy because vastly more people are familiar with that than the intricacies of open source package management for a few distros.
Even technical users have a limited capacity to properly vet what an authority should be allowed to do. Not to mention, this becomes a very heavy-handed choice to the user (as people already see on android), like "either allow this new app version to now root your phone, or you can't use this service at all"
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?
We already see how slimy so called trusted businesses are like Google and Facebook are by convincing users to install privacy invasive apps using the enterprise developer program.
Who are users suppose to trust?
Back in the day users also trusted SourceForge....
> 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.
That is why you should only do this if you are aware of the consequences.
You put lots of warnings in front, and if after all that they trust the source of the directions, who are we to say otherwise? There's a lot of hubris in assuming we always know better than the user. It may be that in a decade or two people will be a but more knowledgeable about their devices, but I'm afraid we're moving down a path that will make that knowledge mostly useless, since there's now way to express it.
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.
I'm not ignoring it, I just value freedom more. It's easy to make an almost perfectly safe society if we're all willing to give up on fundamental freedoms. I think the best solution preserves some core freedoms while making risky behavior harder. Between desktops and phones we've swung between two wildly different paradigms in the last couple decades. I don't think a bit of moderation on both ends (which is already happening with the OS as we see here) is a bad thing. But so far it seems mostly to be going one direction.
Apple is actually fairly good at making the warnings/process heavy-handed enough that only technical users will follow them.
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.)
It's really simple: It is not our job to prevent smart people from doing dumb things at all cost.
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.
How do you prevent a user who is not aware of the consequences from throwing their a computer into a lake, we better ensure that all computers are Safe-T-Locked into desks so the user cant hurt themselves.
What you described is essentially how Android works today. You whitelist specific apps, like the Amazon App Store or F-Droid, as allowed to install other apps.
The play store and samsung store are able to install and update in the background without the user doing anything. The same is not true of any 3rd party app store you whitelist.
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.
That's interesting. The Android on my phone mus be old enough that it isn't using that, or it's changed since I last bothered with it. Last time I did anything with it was a couple years back with the Humble Bundle app, and I believe you still had to toggle in the settings to allow untrusted sources for that to function. Good to know there's been some progress on this.
99.9% of users are not capable of making an informed decision about whether to approve a third-party app store. That you are is statistically irrelevant to the security of their platform. 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.
> 99.9% of users are not capable of making an informed decision about whether to approve a third-party app store.
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).
Apple offers many ways to self-issue mobile apps, but they all have restrictions that prevent them from being used for malware attacks. 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).
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.
There's a long history of the government preventing abuse when one party in a relationship is not capable of evaluating the other party. We see certifications for various roles from tax preparers to hairdressers, we see limits on what can be sold as food and medicine (unfortunately not enough limits in the US).
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.
> Would you consider such (common) systems to be authoritarian?
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.
"How dare we adopt code licenses like the GPL, allowing a shadowy authoritarian figure known only as ESR to dictate our every move. If we don't start writing our own code licenses this very day, we risk the authoritarian take over of all software by the select few who are able to write them competently. Every time someone uses an off-the-shelf license from a third party they neither know nor trust, our freedom suffers."
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.
This argument doesn't make any sense to me. I'm not implying that you should blindly distrust the app store your device ships with. I'm not claiming that experts aren't experts, or that you specifically are an expert. I don't know where you got these impressions from. I'm particularly puzzled by your choice of software licenses as an analogy, given that they were designed by experts in the field specifically to maximize freedom (whereas app stores were not) and have held up in this regard to sustained scrutiny over many years (the default app stores have failed miserably here).
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.
We disagree on what basic rights _must_ be offered with any hardware-software combination that is sold to us.
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.
I reject your implication that not being allowed to lock you out of your own device would somehow be equivalent to mandating official manufacturer support of arbitrary user modifications. I already provided what I believe to be a reasonable example of such a system. No manufacturer support is required beyond an interface for the user to disable key checks or possibly to replace the manufacturer's key with their own. Once you do so, you are in unsupported territory and everything that follows is entirely on you.
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.
> Apple offers many ways to self-issue mobile apps
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.
And so do I, because without the user being able to carefully select who to trust (and there's no reason Apple is inherently more trustworthy than another company), that's almost the same as removing any vetting process.
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.
> We already know that Apple is more “trustworthy” than Facebook and Google.
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.
No, I’m not referring to Apple’s profits but that is a good gauge of what people find valuable enough to spend money on.
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.
Coming back to the first point "Freedom is for the user do as he wants". I am not even an American but i know how important Freedom is. You can't just give it up for privacy walled garden, corporate profits.
I’m sure most people would give up “freedom” from yet another privacy invasive feature of Facebook thst only happens on Android or yet another piece of spyware that only happens on Android.
That is what freedom all about user own choices not dictated by corporatism.
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.
You mean like all of the companies who bypass the 30% cut now by not allowing in app purchases of subscriptions and media and they distributed their app free on the app store?
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?
This isn't a big surprise, you should expect the tightening of the screws to continue and the pace of it to accelerate. The real issue here is general purpose computing. General purpose computing makes it possible to block ads, to rip your CDs instead of the industry forcing you to buy the same music again, etc. and as a result it is THE major obstacle to unlimited rent seeking and squeezing the last penny out of every user. Expect the industry to keep working in this direction until everything is as locked down as an iPhone.
> General purpose computing makes it possible to block ads, to rip your CDs instead of the industry forcing you to buy the same music again, etc.
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.
> (1) Apple has delivered software which rips CDs with the OS for 18 years now
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.
It doesn’t allow third party ad blockers to record or intercept your browsing history.
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?
Except you can always turn this off, so you can still run the “features” you want.
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.
...and where all software is delivered through them, so they get a cut of any sales. I don't begrudge Apple the ability to make money. I do begrudge them for how they completely monopolize it, and try to present the security argument as if it's a binary choice, and not a spectrum along which there might be a solution different than we have currently which most people might consider better.
That's a false equivalence. An iPad is not a Mac, it has a different security model and a different way of using it. The iPad is more locked-down than the Mac and always will be. Allowing people to disable protections on the Mac has no bearing on whether they should be able to disable them on iPad.
This is just a other step in towards total control of our computing. We are seeing deplatforming, banning, blocking, etc, across large parts of the internet and this will only continue to grow. Britain is now proposing broad powers to regulate the internet to force removal of content they see not fit (not sure why this isn’t larger news on HN, maybe I missed it).
It's probably not larger news because the reporting on this issue here in the UK is quite frankly shocking, especially coming from the BBC.
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.
Don't forget they will always say it's a "security" feature and have a list of all the things people will (usually?) agree with being protected against. What they don't say, however, are all the other things that it will also protect against, some of which you may actually disagree with.
Point stands but maybe the immediate intentions aren’t that nefarious. For 95% of users protecting their devices “from themselves” and potential “dangerous app authors” is a real benefit and something they would pay for.
Seems like we need to relearn the concept of liberty, but again in the digital world.
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"
We have liberty. You have the liberty to use a platform that tries to protect your security at the cost of adding some restrictions. You have the liberty of choosing a different platform (using the same hardware even!) that has no restrictions and is fully open to be modified, at the cost of requiring a lot of technical expertise and putting yourself at risk of malware. You have the liberty of choosing yet another platform (still on the same hardware!) that's not open to modification but less restricted, at the cost of serving you ads on the lock screen and having a history of the worst malware infestation of any computing platform in history. And you have the freedom to write your own platform from scratch if you don't like any of these.
The death of general-purpose computing is well underway.
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.
We need to all fight against this future. Software is the medium of our age—restricting who can create it is not unlike restricting freedom of expression.
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
> 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.
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.
But consider all the legitimate benefits of having these (optional) defaults. I can give a Mac to my grandmother and be reasonably confident she won't download a keylogger that steals her bank password or some such. Meanwhile, I can also give my coworker instructions for running the video downloader Applescript I made.
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.
You can disable secure boot on most modern machines, install Linux, create a cert and sign Grub or your EFI stub kernel, add that cert to your UEFI (delete the stock ones) and then you have a machine that can boot Linux and not Windows.
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.
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.
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.
Part of the point of the OP, as i understand it, is that theres also a cultural war going on, where if corporations end to get their way, by controlling/locking developers and users on their platforms, people will see this as normal.
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.
> A great way to have peer to peer communication, 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.
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.
The point is not necessarily that secure boot will be enforced by the hardware, but that this creeping centralization of control will bleed into the network stack, which would leave you with a useless experience if you did opt out.
Yes, you could do that, but 99% of people are going to have no idea how to do that, or even why they should. As a result, the few companies that own the centralized platforms still get the authority to dictate how computing works, and to block you from distributing software that threatens their interests.
This model needs to evolve from “you must sign with Apple” to “you must sign with one of $TRUSTED_LIST”. There should be a (non-trivial) way to set this, and if I decide all software signed by my best friend is OK then I should have that option. Grandmas should be able to trust software from their IT-expert grandsons and so forth.
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.
Mis-issued certs are common enough that Google et al had to force Symantec out of the cert issuing business. It's a model that only works with a monopolistic cartel gatekeeping the ability to issue certs (which is basically Apple's role in this scenario).
There's been issues with code signing but you can't say it's been pointless. It's a significant hoop to jump for malware writers and out of reach for basic script kiddies.
How does what you are proposing increase trust for consumers?
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.
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.
The linked document, as of when I wrote that anyways, was not a news article at all. It was a developer support document that someone was linking as the primary - and, at that time, only - source of an Apple policy change. Using the original KB link’s title would have pointlessly obscured the relevance of the link to HN readers.
I am concerned about the UI for this that says "Apple has checked it for malicious software and none was found".
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.
How would you rephrase this then? IMHO the words were chosen correctly, because it doesn't blindly say "App is safe, go on". No, it explicitly states that it was checked by Apple and it is considered safe by Apple. It doesn't mean you should fully trust it by default.
> How does Apple check against malicious software?
KB page says "[...] The Apple notary service is an automated system that scans your software for malicious content, checks for code-signing issues [...]"
I see how this can help protect against outright malware. However, what if there's a flaw in the heuristics, and some malware slips through the cracks? Sure, they can fix their malware scanner, but will they take the time to retroactively scan all software with their new and improved scanner? Will they even store every single notarized app on their servers for this to be feasible? Or will they mandate re-notarization every now and then?
So many questions, hopefully Apple answers these soon.
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.
> 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.
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:
I'm talking about the setting to disable requiring notarization for quarantined apps, which doesn't exist yet so I'm simply guessing it will show up there initially.
Without notarization, the signature of the app is tied to the lifetime of the developer id certificates. Thats one of the benefits of notarization (which Microsoft also I believe requires now) - the notary can say 'it was signed while the developer id certificate was still valid', which allows the signature to outlast the certificate.
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.
Without notarization, you can still `codesign --timestamp` to have Apple co-sign your app, which validates that your certificate was valid when you signed the app, even if your certificate later expires.
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"
> Thats one of the benefits of notarization (which Microsoft also I believe requires now)
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.
This is a misleading statement. First, I personally do test Developer ID signed apps locally all the time. Notarization still doesn't come into play because there's no quarantine xattr to trigger Gatekeeper, not because they're signed/unsigned.
Unsigned apps cannot be notarized, and your compiler doesn't sign code (codesign does this unless you have an interesting compiler). In essence, there are two reasons why notarization doesn't have an effect here, the quarantine xattr and the fact that Apple will refuse to notarize an unsigned application; I was merely pointing out the additional, latter reason.
There is only one reason why the Gatekeeper notarization check does not trigger when you run code you compile yourself on-device: the lack of quarantine xattr. We don't need to exhaust the truth table to meaningfully describe the situation.
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.
My perspective was one where I compile software, codesign it, upload it to be notarized and then when it's downloaded the quarantine xattr gets set; if the code doesn't get signed none of the other steps make sense. But I'm pretty sure we both know how this works so I doubt arguing about the order or relevance of certain portions of the process is productive ;)
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.
This is Apple moving one step closer to completely shutting down execution of apps that haven't been signed - a virtual app store so to speak. Because there's no longer a GUI option to allow unsigned apps by default. It was removed from System Preferences some versions ago.
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.
I personally dislike it, but I don't think it's monopolistic behavior. macOS's market share is comparatively pretty low and you can install windows or linux on your mac if you choose to.
"Install another OS" is not an acceptable solution, it smacks of technophile arrogance. Try giving that advice to any senior owning a Mac, wondering why their favorite (unsigned) app doesn't launch after updating their Mac OS.
Apple's entire marketing strategy revolves around customer empathy, but their actions don't
As I said, I dislike apples decision, but involving government agencies and suggesting a monopoly implies that there are no viable alternatives and that’s simply not true. You can just not buy macs anymore and refuse the update.
But you’re okay with giving that same “senior owning Mac” the responsibility of choosing which apps to trust? How has this worked out for the last 30+ years?
It has worked mostly fine for OS X during that period, not so much for Windows though. The blame for thelatter is squarely on Microsoft for having had terrible security defaults and a confusing UI.
Isn’t that exactly what Apple is doing - good default security that won’t affect most users? What software is granny using that isn’t actively supported and not already coming from a trusted developer who isn’t already signing their software to avoid the work around for running unsigned software?
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.
Affects large number of people is not the same thing as those people having no viable alternatives. Utilities are often monopolies, and arguably Microsoft was in the 90s, but a company with like < 50% of desktop market share?
You've put significant effort in defining monoply classification or suggesting workarounds, instead of calling Apple out on unethical behavior. Maybe it's better for Apple's customers for Apple to show some empathy, and not unfairly lock down their hardware. Macs have been secure enough without this new lockdown, so any argument made for security seems like a cover for their true greed
It’s slightly surprising to see people here support this.
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.
I don't mind as long as it's optional. I as a user still have the ability to run unsigned/un-notarized apps, and there's no indication that's changing. I can also turn off SIP and load unsigned drivers if I want (and I do).
iOS, by contrast, doesn't give you any choice in the matter. That's a big difference.
You're right, we have a choice. It's just that when my mom or dad download an app from the browser and it says, app is from an unidentified developer, they're just not gonna no how to turn it off and Apple knows that about a lot of its user base too well.
All I'm reading is Apple is working really hard to avoid calling it an anti-malware/anti-virus scanner and even centralizing it to cover it up (that's one of the notarization process main action).
If notarization is going to be required by default, and Apple wants users to depend on this as a signal of trust, they really need to use something other than light gray text on a gray dialog to inform users that the software they’re opening for the first time is checked and notarized. That dialog that you’re trying to open software from the internet feels like a BE CAREFUL warning—which feels odd when the light gray text says they’ve checked it and found nothing malicious.
Not that I think users shouldn’t be encouraged to be aware ... but it feels rather odd.
Steam is its own client. Only Steam would need to be signed/verified. It doesn't have to set the gatekeeper bit for the software it downloads (like your web browser does), although it could and just allow the same GK process to occur with each game.
With regards to the bit about plugins, will Apple make exceptions for their own software like Logic Pro X? I'm not entirely sure what the hosting/execution model is for AudioUnits and VSTs, what I do know is that many of them will never be updated to meet any new security requirements. I bet we're in for a few more years of terrible advice like "run this command that disables security in the Terminal, then reboot in order to use the product you bought."
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.
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.
The problem is not in they using digital signatures, as this is a trend that is here to stay. The problem is when they are the sole provider of the trust model.
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 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.
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.
Slightly related:
I’m a mac user since almost forever but I’m becoming more and more frustrated by Apple’s decisions concerning their laptops and macOS in general. Recently I’ve been looking at Microsoft Surface Book as a potential alternative if I decide to jump the ship, I also started to move away from Apple applications as I want to be able to switch to an other platform without too much hassle. I still have to find an alternative to Pixelmator and iTerm2 (this one is really more difficult to replace if I consider moving to windows).
Do you have experience to share concerning the Surface Book or moving from macOS to Windows?
Just another reason to build and use a Hackintosh, if you want to be free to choose your own software. Apple is slowly moving towards an iPhone model with macOS.
For a user of your sophistication, why bother with a Hackintosh at all? You could use a truly free Linux based OS and not have to deal with any of this. Is there some killer app that you can only get in Mac OS? Xcode I guess for iPhone dev? And if you have a moral objection to Apple making MacOS like iOS, why would you want to do iOS dev?
Firstly, macOS is a far and away superior experience, given the alternatives, secondly it has better applications, or the Mac versions are better than for other platforms and thirdly it allows development on all platforms with a minimum of fuss.
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.
Hackintosh user here: this has literally no impact on anything.
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.
I mean, if you want SIP, you can leave it fully enabled and load all custom kernel extensions with Clover, as I mentioned.
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.
Does csrutil status not give you the "This is an unsupported configuration, likely to break in the future and leave your machine in an unknown state." warning?
Kernel extension already require a special developer certificate. You should explain to Apple what you need it for, then if your are accepted by Apple you get a new signing certificate including kernel Extensions. After that you can do "anything".
With the notarized every app will be needed to be scan by Apple before. It's something a lot more painful than Microsoft Windows Defender which do the same (first launch of unknown app) for every app and maintained a worldwide database of signature of authorised apps.
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.