macOS Security and Privacy Guide | Hacker News Reader

macOS Security and Privacy Guide

github.com

323 pointsNginx48789 comments

This has popped up a bunch of times before:

https://hn.algolia.com/?query=macOS%20Security%20and%20Priva...

It's not good. See:

https://news.ycombinator.com/item?id=17904304

tptacek's criticisms are quite valid. However, "it's not good" seems oversimplified to me? I found lots of interesting information in this.

For example: information about the activation process for Macs, importance of setting a firmware password, disable some of the Spotlight services, and binary whitelisting through Santa. The repo also has the most comprehensive discussion I've seen about evicting FileVault keys from RAM on sleep: https://github.com/drduh/macOS-Security-and-Privacy-Guide/is...

Also, I'm not sure if this has been changed more recently than the comment you linked, but it seems like they actually don't recommend AV software anymore: "Therefore, the best anti-virus is Common Sense 2020. See discussion in issue #44."

I grant you that having someone follow this top to bottom might be bad, but to say "it's not good" seems to both lack nuance and also to discard some useful, hard work done in good faith.

A guide that can't be used safely by non-specialists while being aimed at them is not a good guide. It is a very simple conclusion with the added benefit of also being almost tautologically true.

The thing probably does contain a bunch of interesting information but it's not good at its stated purpose.

I love how this is offered fully in Chinese, and that reminds me of something. Every operating system like macOS has its place, no matter what one's threat model is. Don't just say 'move to Linux if you're really worried about security or privacy'.

Maybe someone in China or another authoritarian regime needs to look less suspicious on the outside by using macOS instead of Linux. For those people, this information is gold.

BTW, this is indeed the famous Github guide many of us have known for years, just now renamed and updated.

2016 HN discussion of it with the old title, 'A practical guide to securing macOS': https://news.ycombinator.com/item?id=13023823

> Maybe someone in China or another authoritarian regime needs to look less suspicious on the outside by using macOS instead of Linux.

There's even an official Chinese Ubuntu spin. You're probably more suspicious with macOS, since these tend to be in the hands of high-profile businessmen and such.

In an authoritarian regime everyone with a computer looks suspicious.

quite the opposite, in a mass surveillance state anyone without virtual personality fingerprint and tracking data is suspicious

How about:

In an authoritarian regime/mass surveillance state everyone is suspicious?

In an authoritarian regime everyone looks suspicious because by definition the government trusts no one except themselves and even then it's not very true.

> Don't just say 'move to Linux if you're really worried about security or privacy'.

In China Linux rocks exactly in security & privacy like "lone star". Windows - shitload of telemetry by design; macOS & iOS - there's no secret anymore about Chinese iCloud & Chinese government.

If I were in China doing anything even slightly over the line, windows telemetry would be the least of my worries, keeping my vital organs and freedom would be at the top.

I'm somewhat surprised that this guide recommends Homebrew. I agree that using a package manager is a good way to keep software updated from a central, trusted repository--always a good thing--but Homebrew makes a number of trade-offs for convenience instead of security. MacPorts has most of the same common packages and doesn't mess up filesystem permissions like Homebrew does. If I remember correctly, the all-inside-the-home-directory technique used in this guide is unsupported by the Homebrew developers as well.

See https://saagarjha.com/blog/2019/04/26/thoughts-on-macos-pack... for a more nuanced take on this.

> MacPorts has most of the same common packages and doesn't mess up filesystem permissions like Homebrew does.

This is more a convenience than security question. I understand that Homebrew can install not only open source command-line tools, but also third-party binaries (via `cask`) and Mac App Store apps (via `mas`), and that all three types of software can be installed, updated, or removed via the same `brew` command or synced `Brewfile`.

Does MacPorts offer something similar? In that case, how is its coverage compared to the systems above?

(Context: I’m a long-time Linux user in the process of migrating to macOS.)

As I understand it, MacPorts is a fair bit more limited in that regard. For my purposes, I haven't found a need for the ability to install third-party binaries and Mac App Store apps through my package manager, since every third-party binary I have installed includes its own updater and the Mac App Store updates apps as well. I can see how setting up everything in one place could be useful, but I haven't run into a situation where it has been useful in my macOS usage quite yet.

Homebrew and MacPorts are philosophically pretty different from each other and neither can be directly compared to Linux package managers. I think you'll find the solution of MacPorts for OSS command-line tools + Mac App Store for Xcode and other random stuff + third-party installers for things like Sublime Text and Microsoft Office works pretty well in practice, although it's not quite as clean as using one package manager for everything.

Thank you for sharing your experience on this :).

> I can see how setting up everything in one place could be useful, but I haven't run into a situation where it has been useful in my macOS usage quite yet.

What appeals to me personally is having a list of apps (the “Brewfile”), that I can sync between my work and personal computer via my dotfiles, and let the system mirror what apps are installed on both devices (“brew bundle” installs or uninstalls apps based on that app list). And that if I need to replace my machine, I can just sync my dotfiles to new machine and let Homebrew autorestore apps, including third-party apps and things from App Store.

I’ve tried some “declarative package managers“ before and enjoyed that, so when articles like this [1] said Homebrew can apparently do the same across open-source software, Mac App Store apps, and third-party apps, via a single synced Brewfile, that seemed interesting. The same Brewfile also appears to be usable on Linux for open-source apps (via Linuxbrew).

But I don’t yet have any experience with it, so I have no idea how well it works or whether it’s worth it. If we disregard third-party apps, do you know if MacPorts has an equivalent to Brewfile?

[1]: https://openfolder.sh/macos-migrations-with-brewfile

Somewhat, it does have a way of recreating your current setup (generally intended to be used across OS upgrades, but doesn't have to be limited to that usecase): https://trac.macports.org/wiki/Migration

Cask doesn't just handle packaged GUI apps, but also binary distributions of command-line apps that are hard to compile from source; or are proprietary/closed-source; or are actually sandboxed point-release distributions of {software written in a scripting language + its vendored deps + its runtime}. None of these will have any sort of updater built into them, but they'll all be updated through `brew cask upgrade`. (Any random Golang binary you might download off of Github? Before I even Google it, I type `brew search $whatever` into my terminal. Way easier to keep updated than even the `go get`-installed version, and also doesn't require that you have go installed.)

As well, even for GUI software that has Sparkle-like update support built in, if you don't use it very often, it won't get updated until the next time you launch it, and even then will only get updated if you're online at the time you launch it. This leaves you vulnerable in the specific case that the software is offline but opening an untrusted document (e.g. one you originally downloaded from the network.) The vulnerability in the app will likely be exploited immediately upon launch of the app, before the app gets to update itself. Doing a periodic `brew cask upgrade` also takes care of these (at the annoying expense of constantly upgrading apps that put out a new release every few days. Looking at you, Etcher.)

Also, besides upgrading, brew is useful just for grabbing all this third-party software without having to run hither and thither to find it. Sometimes the only web route to downloading a piece of software involves one of those skeezy download-hosting sites that redirects you through several ad walls, or requires that you make an account to download. With brew, you skip all that — just e.g. `brew cask install megasync` or `brew cask install plex-media-server`.

Also, brew suppresses any interactive GUI elements of the install/update process, if it possibly can. `brew cask install java`, besides skipping navigating through ten pages of links to links to TOS agreements to links on Oracle's website, also does not summon forth the Java installer GUI, but rather does everything in the command-line. (As far as I can tell, it doesn't install the Java updater, either; brew takes over responsibility for upgrading Java, so there's no need for an independent update checker.)

And there's also `brew cask zap`, which is an uninstaller that actually cleans up after the program, removing not only the application itself, but also all the stuff the app either installed, or later created at runtime, under /Library. This takes advantage of Apple .pkg BOM manifests if it can; but also has a manually-specified section in brew formulae, to allow it to zap away the cruft of apps that don't bother to keep track of themselves (e.g. Zoom, zerotier, usboverdrive, switchresx, etc.)

There's also `brew services` — brew packages (and I think brew casks, too) can install launchd unit-file templates; and you can then enable/disable these (i.e. [un]link them in ~/Library/LaunchDaemons), and manage the lifecycle of (start/stop/status) these (i.e. call into launchctl), through `brew services`.

(My own `brew services` currently contains: docker-machine, ifs, postgresql, reds, ssh-askpass, unbound. I use it quite a lot! Much less arcane than launchctl itself.)

-----

Oh, and disregarding all that, and addressing the assumption underlying your arguments (that homebrew "messes with the filesystem"): you can keep a brew installation that doesn't mess with the filesystem at all (see https://docs.brew.sh/Installation#untar-anywhere).

It's just that doing so will confuse exactly the type of pre-compiled CLI (or POSIX-y GUI) tools that `brew cask` is meant to help you install. These would be the ones where important paths (e.g. $PREFIX/etc, $PREFIX/share) are burned into the compiled binary, and so by necessity one fixed prefix has to be selected to burn in at compile time. Usually the fixed prefix chosen is `/usr/local`.

People install Homebrew to /usr/local (or rather, allow Homebrew to link casks into /usr/local) because it's better than the alternative — where that alternative isn't "all that stuff gets installed in a clean way instead" but rather "all that stuff makes a mess of /usr/local on its own, but now there's nothing watching it do it, so your /usr/local is now a permanent, opaque mess rather than a set of managed overlays." (Ever install LaTeX on macOS from its upstream download? Or how about calibre? PostGIS? R? They all make exactly these kinds of messes in /usr/local. At least, by letting brew install them, you can now upgrade or remove them; and it'll notice if one package's files are trampling over another's.)

Thanks for your thorough discussion of this; as someone currently migrating to macOS, I found it very helpful :).

mas is independent of Homebrew and available on MacPorts: https://github.com/macports/macports-ports/blob/master/sysut.... There's discussion on the mailing list on whether MacPorts should have a sort of "caskroom" type thing–currently it tries to avoid this except in cases where it's impractical to build from source (e.g. Java).

FWIW I use Homebrew Casks to install binary stuff, which MacPorts doesn't offer, and MacPorts to install everything else. (Oops, other than stuff that is only available on the Mac App Store, for which I use mas, which will probably fatally break some day.)

I can't say I've needed to use anything outside the appstore and macports, I'm very satisfied with them. For macports you have to install the CLI tools for Xcode.

MacPorts is an implementation of BSD family ports package managers. I don't know much about modern ports, but when I was an active FreeBSD user, it did not install binaries, compiling the package with all dependencies instead - that is why it offers only open-source packages by definition. Darwin itself a BSD family, so I guess MacPorts were the first package manager implementation. However, proprietary applications is a common thing on Mac, unlike Linux/BSD systems, that is why Homebrew offers much wider choice of packages.

MacPorts offers prebuilt binaries for many packages these days, although you can generally install them from source if you so wish (and it will do so if you are on a release for which the package is not built).

Thank you for this comment, and thanks to saagarjha for the blog post. I’ve had the feeling over the past year or so, that Homebrew is getting in the way of other steps that I’d like to take to secure my system.

(And I’ve been confused by the policy of “absolutely no root until something goes wrong; then we tell you to use sudo to run terrifyingly broad commands.”)

Additionally, Homebrew is spyware and the authors refuse to remove this functionality.

Have anymore detail on that statement?

Really? Please tell me more.

Homebrew silently reports your IP address (and thus coarse location), a unique identifier (that allows your location to be tracked over time), as well as any packages you install, to Google (and by extension the US military intelligence community), each time you use it.

I switched to Nix.

HOMEBREW_NO_ANALYTICS=1 / brew analytics off doesn't prevent that?

Analytics connections are also trivial to block on a DNS level. Homebrew isn’t malware; it’s not going to circumvent a simple DNS block for analytics.

that should be the default and google analytics should be opt-in at best

It does, but software that is spyware unless you twiddle the hidden knob to make it not spy is still spyware.

When are we going to see the unix filesystem reflect a threat model other than protecting users from each other? The filesystem permissions you're referring to being messed up work off threat model assumptions that pre-date unix.

I mean maybe if Apple provided a decent way to sandbox processes or restrict them outside the traditional unix user-owned-process model, but all their efforts here seem designed to pimp their app store.

/usr/local is just one place where this friction arises. SIP does not point to improvements here in the near future.

Interestingly, both MacPorts and Homebrew use the facilities Apple has already provided to sandbox processes.

Does nix?

Hmm, I am not sure we are using the term the same way. The processes built still run with my user id with full access to everything that entails.

In any case, the App Store sandboxing is pretty useless at enabling end-users to control what the process does. I mean little snitch should be built in to the OS by now and given user experience considerations outside the control or snitch—say, shipping apps with explicit whitelisted routes to the internet you can view before launching one.

/usr/local is a remnant of a time that makes no sense anymore for most developers in a time of dedicated workstations and I can hardly blame homebrew for pushing back against any of the cruft that's built up over the years but is now difficult to justify.

Sandboxing is usually applied during build time and not at runtime, which was probably different than what you were thinking.

I was looking at Yabai [1] as a window manager and it requires SIP[2] to be disabled for advanced features... Is SIP really needed ? I see that it didn't even exist since "since OS X 10.11 "El Capitan".".

[1] https://github.com/koekeishiya/yabai/wiki

[2] https://github.com/drduh/macOS-Security-and-Privacy-Guide#sy...

Here’s an instance of SIP preventing a Chrome update from bricking computers.

https://arstechnica.com/information-technology/2019/09/no-it...

Bricking means that the computer is no more useful for computing than a brick (or that you might as well use it as a brick). Don't use it for stuff that can be fixed with software.

Where do you draw the line, though? Something that might be a brick to a web developer would probably be perfectly serviceable to me as a firmware engineer

Meanwhile, something that's a brick to me is often perfectly serviceable to someone who can operate a soldering iron

Something that's a brick to a competent hardware tech might still be serviceable to a 3 letter agency

If you can still boot a Mac from the recovery partition or an external drive, it’s not bricked.

It IS bricked if you're a semi-technical Chrome user whose mac is stuck at the question mark screen, though

Sure, the line is porous, but if it can be fixed by doing something with software that is documented by the manufacturer then I think it's definitely not bricked. In this case booting from recovery.

This debate showed up in the original HN discussion too, which also used the term. I think it’s more appropriate to draw the line at “as useful as a brick without taking actions not exposed as part of the normal user interface”. Drawing the line between hardware and software yields false negatives (corrupted read-only firmware is indeed bricked), false positives (discharged battery is not bricked), and messy grey areas (if it’s non-functional but fixable with a trivial chip replacement, is it bricked?), and moreover is frustratingly antagonistic to non-programmers, who have a computer that is as useful as a brick to them until they take it to a professional, yet you tell them not to say so just because you also have the skills necessary for this particular repair.

Yabai is awesome. You can partially disable SIP, which I believe is required since the scripting extension needs it to interact with the dock. But you don't need to completely disable it.

[1] https://github.com/koekeishiya/yabai/wiki/Disabling-System-I...

I should note that if you care about security, partially disabling SIP is as good as fully disabling it. Especially for those specific flags.

As a side note: isn't ChromeOS a safer alternative to macOS in 2020[1]?

[1] https://www.chromium.org/chromium-os/chromiumos-design-docs/...

Afaik ChromeOS phones home to Google, so if Google is among your threat model (privacy) it's not good.

Las time I checked, installing ChromiumOS wasn't easy and i'm not even sure there's a "ungoogled" version like there is for the Chromium web browser.

I meant, ChromeOS migth be a more secure, not necessarily a more private option.

If macOS had a way higher likehood of zero-day attacks, ChromeOS phoning home wouldn't be the biggest concern to most users.

Because in the first case the threat would be the entire world, and in the second case – only the US government.

> and in the second case – only the US government.

And some percentage of Google employees. Probably not really a big deal, but still there.

Secure is a very vague word, I think you're looking for "less hackable by hostile actors" then definitely chromeOS has a smaller footprint.

I don’t know how ungoogled it is but it’s pretty damn easy to install CloudReady from Neverware.

It didn't work with my Ryzen laptop the last time I tried sadly

Neverware provides a list of officially supported devices[1], and AMD Ryzen support could arrive with Pixelbook 2[2].

[1] https://guide.neverware.com/supported-devices/

[2] https://www.notebookcheck.net/More-evidence-that-Google-is-d...

macOS now presently phones home to Apple on every novel binary execution, too, as I understand it.

It is also super chatty to the mothership even with iCloud and all updates disabled.

> Las time I checked, installing ChromiumOS wasn't easy

Honestly, compared to installing MacOS, neither is easy

In some ways, yes, but they’re about equal if administered/managed properly.

Probably from a pure safety perspective, however since a lot of your life is uploaded to google I'd rather deal with apple. I've used them for years with zero problems other than 1 HD crash, but I always back up my data so that's never an issue. If you're really worried install dockers and use limited user accounts to run apps. There's always a way.

This guide is great. It's a pity there is no easy to use (maybe GUI) tool for the average user go be able to implement a lot of the things mentioned here. There used to a few scripts around but most seem outdated. I'm thinking along the lines of Harden Tools for Windows. Great open source project for someone.

https://securitywithoutborders.org/tools/hardentools.html

https://objective-see.com have pretty good security related GUI tools for macOS. Things like ransomware protection, firewalls, task explorers. They also do malware analysis for macOS, definitely an interesting website.

Totally I'm a huge fan of the stuff on there

Ironically, it's way more difficult to harden OS X compared to hardening W10, due to the lack of community. Although OS X is more secure by default, there are pretty glaring security holes that aren't easy to fix without tools.

The thing about PRNG "entropy" and when to enable Filevault is almost certainly false, and based on a misconception of how PRNGs work.

Also, recommending libpurple-based IM clients as a security/privacy measure, so you can run OTR over them, is probably a bad idea.

And it recommends Mac antivirus! Do not install antivirus on your Mac.

The guide seems to say, "the best anti-virus is Common Sense 2020. See discussion in issue #44." I take this to mean that they recommend common sense instead of anti-virus software.

It does also say, "Anti-virus programs are [...] possibly useful for catching 'garden variety' malware on novice users' Macs", so maybe that's what you disagree with, which is reasonable.

I just wanted to point out that their main recommendation does not, to my reading, suggest to use AV.

Nice guide. I didn't realize the security implications of iOS devices and the Touch Bar (being practically an iOS device itself).

I'd be interested to see an equivalent guide for Android devices. My current suspicion is that I'd be far more alarmed by Android than iOS but it would be nice to verify this.

You can pretty much do anything with Android, the same cannot be said about Apple's dictatorship.

I am not even sure about stock installs given Apple's poor security record.

> You can pretty much do anything with Android, the same cannot be said about Apple's dictatorship.

The problem is that app developers can also do anything with Android, often against the users‘ will.

Before I switched to iPhone, my choices for location access on Android apps were basically “access location 24/7”, or “no location support at all”; and even that was an improvement upon the earlier “the app will get these permissions, don’t install it if you disagree” model. iPhone, in contrast, had a sensible “only access location when the app is open” option. Similarly, uploading a single photo to Facebook on Android required the app to get full access to your whole SD card; on iPhone, I can send a photo without the app getting access to my storage at all (that single photo is copied into the Facebook sandbox by the OS). Perhaps Android has improved since, but so has iOS (see e.g. the feature list for iOS 14).

For some of us, controlling our data without turning the phone into a full-time hobby is more important than having full system access.

> I am not even sure about stock installs given Apple's poor security record.

Do you have a link supporting that Apple’s security record is worse than other systems, relative to market share?

As far as I know, the macOS permission system provides better sandboxing than either Windows or Linux by default. (Though if you work for it, you can harden Linux more.)

And although there is a lot of malware for macOS, last I checked nearly all of it was in the form of Trojans and similar vectors, where a user has to download and execute untrusted code. That is an issue on any platform; a user running a malicious bash-script with sudo shouldn’t count the same as remote exploits in my opinion.

You're correct, both Android and iOS have improved. Both have the features you described today, neither had them several years ago.

It’s good to hear that Android supports this as well now, but I think you understate the difference in when these features arrived. From a quick search, the location example was fixed in iOS 8 in 2014 [1], and in Android 10 in 2019 [2], putting Apple 5 years ahead of Google on privacy features. Based on the list of privacy features being introduced in iOS 14, my impression is that this is still the case?

[1]: https://9to5mac.com/2014/06/04/apple-improves-location-servi...

[2]: https://en.m.wikipedia.org/wiki/Android_10

Thanks for looking up the timeline, I was not sure. Also full disk encryption on phones is another thing Apple did way earlier.

I agree it's not exactly apples to Apples. Does Apple still have special permissions for their own apps which allows them to run unobstructed, but other apps need to jump hoops with callbacks and other workarounds?

Are we expecting for Apple to always be 5 years ahead of Google on privacy features? Or did Google shift priorities with Android 10?

Honestly if we're talking about buying an iOS device or an Android device in 2014, I'd lean towards iOS for sure. I don't feel the same way about it today.

> Are we expecting for Apple to always be 5 years ahead of Google on privacy features? Or did Google shift priorities with Android 10?

Good question! My personal impression is that Google, being primarily a tracking company, reluctantly added just enough privacy features for people not to flock to Apple. (I think people have grown more privacy-conscious over the past few years, and Apple has marketed their privacy features heavily.) Links like this [1], listing the iOS 14 privacy features that will arrive in late 2020, appear to still be ahead of what Google has done yet – and e.g. Facebook’s reaction to the cross-app tracking block appear to indicate that this isn’t something they’ve encountered from Google.

But being an iPhone user now, I of course notice more easily what’s happening in the Apple world than Google world. If you have an overview of new privacy features in Android, which aren’t in iOS, I’d be very happy to be proven wrong. I’d love to see a full arms race between Google and Apple on privacy, with both parties introducing novel features.

[1]: https://www.macrumors.com/guide/ios-14-privacy/

> Does Apple still have special permissions for their own apps which allows them to run unobstructed, but other apps need to jump hoops with callbacks and other workarounds?

Unfortunately, yes. There is e.g. no way to get as reliable background sync with things like Nextcloud and Resilio as you do with iCloud, since there’s no “run in the background” permission. Not sure about this, but I don’t think any other app can take over the lock screen in the same way as Apple Maps. You can’t set a default browser than Safari, but I believe this is changing in iOS 14.

While I respect Apple for their stance on privacy and therefore use an iPhone, I do disagree with some of these missing permissions, and hope that a new round of anti-trust investigations may force them to open up on this.

> I'd be interested to see an equivalent guide for Android devices.

Recently shared: https://news.ycombinator.com/item?id=24091709

That part about iOS is confused. The focus on activation is weirdly myopic. If Apple wants to track your identity, location, and activities and send it to the Chinese government, they are going to be able to do that with or without that specific activation mechanism. They can do this in iOS or in macOS.

The fear of the potential iOS-ification of macOS due to the use of Apple silicon in macs also has some logic holes. Apple can iOS-ify macOS with or without Apple silicon, and vice-versa. This is conflating hardware with the software it runs.

Does anyone knows of a similar collection of tweaks, but for getting performance out of macOS?

Things like disabling Spotlight so it's not indexing node_modules and other folders, or adding tools to the Developer Tools to disable network checks with apple servers when you want to run a binary

You can already exclude things from Spotlight’s index in System Preferences.

I know, i'm doing it. I was saying I would love for a list of tweaks of that nature. Things I don't know about that I could do to improve performance

i've increasingly been having issues with hands off![0] on my machine (intermittent high cpu usage, regular kernel panics), and was actually looking at this guide a while back to decide whether i should switch to pf instead[1].

but pf seems to require much more configuration and management. anyone have experience/pointers in this regard?

[0] i used to use little snitch many years ago, but ran into similar issues with it over time (maybe it's better now).

[1] https://github.com/drduh/macOS-Security-and-Privacy-Guide#ke...

I use Murus to manage pf on a couple of Macs. They also have an application-layer firewall named Vallum. https://www.murusfirewall.com

> Is your adversary a three letter agency (if so, you may want to consider using OpenBSD instead);

A 3 letter agency won't be stopped by OpenBSD or any other OS.

There is so much security holes in the hardware itself and ultimately they can always "convince" you to release your data.

No, you can’t stop “an agency” but you can make their job harder and slow them down. Using a hardened O/S is part of the mix but not connecting to the net if you can avoid it is another. A good overview of how to configure you computer for privacy can also be found on episode 177 of Michael Bazzel’s “Privacy, Security, and OSINT Podcast”:

https://overcast.fm/+Hbyfl32i0

If your adversary is a three letter agency, you might want to consider a Qubes/Whonix combo. It's the closest you're gonna get.

It's enough to make one want to switch to OpenBSD or Linux.

I think most of that guide would require roughly the same amount of work on Linux though (e.g. setting up firewalls, DNS, VPN, and FDE).

Are you kidding? You still have to do work, but a third party doesn't get to decide if you can boot and what image you boot.

> What is particularly worrying about this process is that it is a network-linked secure boot process where centralized external servers have the power to dictate what the device should boot.

This is an abomination.

Firstly, your quote is about iOS not macOS as far as I can tell, so the competitor here would be Android not OpenBSD.

Secondly, I interpreted your comment as “that list is long enough to make one want to switch to Linux”. I then stand by my comment that most of the suggestions on the list require at least the same amount of work on Linux. (Source: I’m a Linux user that has setup things like fscrypt, ufw, openvpn on my devices.)

This is great! Thanks for sharing it. Obviously a labor of love.

Should add an explanation for what "sepOS" is.

This fails to make much sense overall. My macs only talk to apple when I let them and it was way simpler than this.

Reply on news.ycombinator.com