IT

Moving away from Apple platforms, a living diary

TL:DR A living diary of how I am slowly moving away from Apple

The first computer I purchased with my own money was a Mac Plus, circa 1990. Then I discovered Linux in 1991 and switched. When Apple introduced Mac OS X, I purchased an iMac G4, and over time transitioned fully to the new UNIX-based Mac. I also got the first iPod, iPhone and iPads, so I could fairly be accused of being an Apple fanboi, even if I have never been blind to the platform’s limitation and Apple’s questionable business practices.

Over the last year and more, I have been souring over Apple as a platform and a company:

  • Their software quality, never particularly high (even if Microsoft made them look good in comparison), has tanked since they fired Scott Forstall. I am not even sure whether they are any better than Microsoft at this point.
  • Their need to eke out growth from a maturing smartphone and PC business means they are incredibly rapacious with the App Store tax, and pushing developers towards user-hostile business models like subscription pricing.
  • Their claim to privacy leadership was always more marketing than reality, but is now in tatters, see my previous article on how to circumvent their tracking (not always possible, e.g. notarization).
  • Their extortionate pricing on RAM and storage has grown impossible to ignore.

So what is to be done? I am working to switch to Ubuntu Linux on the desktop and laptops (I still use Alpine Linux on servers), and to GrapheneOS, a degoogled and highly secure fork of Android. To this end, I purchased a few laptops to run Linux as a daily driver (Asus Vivobook S and Lenovo Thinkpad E16 G3), a Google Pixel 8 Pro and Google Pixel Tablet. I also have a Beelink GTR9 Pro on order (running the AMD Strix Halo Ryzen AI Max+ 395 processor) to be the twin and successor to my Mac Studio.

I carry both my iPhone 16+ and the Pixel with me at all times, and force myself to use the GrapheneOS device first, and only fall back to the iPhone if all else fails, which indicates which functionality I need to migrate next.

The rest of this article is a living diary of the migration and what software I am using as a replacement, and I will update it as I progress.

iOS and iPadOS to GrapheneOS

Of course, many apps are cross-platform and migrating is straightforward.

It’s annoying that Signal and WhatsApp don’t allow you to run the same account concurrently on two phones, a vestige of their original sin, i.e. basing identity on the rotten foundation of the Public Switched Telephone Network.

Upcoming:

  • Things (to do list manager): undecided, but probably Emacs Org-mode.
  • Apple Pay: there are reports Curve Pay works on GrapheneOS.
  • Backups: I set up nginx as a WebDAV server for Seedvault, but it is not yet reliable.

macOS to Linux

  • Email: Emacs with mu4e, mbsync and smtpmail.
  • Browser: Vivaldi.
  • Password Manager: KeepassXC. Apple Passwords gained the ability to export all passwords to CSV, but there is no way to automate this.
  • eBooks: Foliate.
  • AirDrop: LocalSend.
  • PDF Library and Spotlight: Paperless-ngx.

Upcoming:

  • Photo editor and DAM: undecided. My monitor has hardware color-calibration, so at least I won’t have to worry about Linux color management.

Apple privacy checklist

TL:DR Apple’s claims to being privacy-first are a marketing sham

Apple claims to hold privacy at its core, but it has been an advertising company for at least a decade, and now that smartphone and computer sales are plateauing and new products like the Apple Vision Pro have failed to set the world on fire, Services revenue (an euphemism for the 30% App Store tax on developers and advertising) is critical to maintaining the company’s stock price.

Recent behavior from Apple has confirmed Google or Meta’s take that Apple’s privacy claims are just that, clever marketing to obscure the fact the privacy measures they do have are mainly there to stymie its competitors:

  • Apple forces app developers to ask permission to access the advertising tracking ID (IDFA), but exempts itself from that requirement by a truly Clintonesque redefinition of tracking as “sharing data with other companies, not with ourselves”—one rule for thee but not for me

  • Apple’s notarizarion feature leaks information to Apple on what apps you have installed on your device. What’s worse, this is sent unencrypted so anyone with network access can also grab this info. Apple promised to give a way to disable this misfeature (which also has a noticeable performance impact for developers) but quietly reneged on this.

  • Apple would upload recordings of Siri queries without your consent, and Apple employees and contractors had access to them

  • Apple implemented a CSAM scanning feature, whereby your iPhone would rat you out before the government even asked them to do so. Even though they reversed themselves, they set a precedent authoritarian governments will certainly avail themselves of.

  • When they introduced the Journal app, they gave them wide-ranging access to other apps’ data without consent.

  • Apple silently opted you into “Privacy Preserving Ad Measurement”. This an Orwellian misrepresentation, as your browser is tracking you on behalf of advertisers, just as Google Chrome is doing with its Topics API. Firefox is equally guilty of this (PDF) and unrepentant. Even Google, the most voyeuristic of the surveillance-industrial complex, asked for permission before enabling this in Chrome, albeit with wildly misleading wording because no one does dark patterns quite as smugly as don’t do be evil Google.

  • Apple silently opted you in to “Enhanced Visual Search”, where it uploads fingerprints of landmarks in your photos to its server. It claims to use differential privacy and homomorphic encryption to make this privacy compliant, but this still leaks information, even if Apple’s implementation were perfectly bug-free (given the abysmal track record of Apple QA of late, this would require heroic levels of credulity).

  • They did it also for “Improve Search"—Seeing a pattern here yet?

Here are the settings you need to review and change from their privacy-invading defaults, in chronological order of when they were introduced. Apple also has the nasty habit of silently turning them back on, so you will need to check this list regularly. You will also need to set these on each device separately.

iOS and iPadOS

  • Disable the IDFA altogether and do not allow apps to ask for it:
    • Settings / Privacy & Security / Tracking / Allow Apps to Request to Track / (turn off)
  • Disable Apple’s own Ad network tracking:
    • Settings / Privacy & Security / Apple Advertising / Personalized Ads / (turn off)
  • Disable Sharing of information with Apple, including Siri recordings:
    • Settings / Analytics & Improcements / (disable all of them)
  • Private Click Measurement:
    • Settings / Apps / Safari / Advanced / Privacy Preserving Ad Measurement / (turn off)
  • Improve Search:
    • Settings / Search / Help Apple Improve Search
    • Settings / Apps / Safari / Search / Search Engine Suggestions / (turn off)
    • Settings / Apps / Safari / Search / Safari Suggestions / (turn off)
  • Visual Search:
    • Settings / Apps / Photos / Enhanced Visual Search / (turn off)
  • Journal App:
    • Settings / Privacy & Security / Journaling Suggestions / (turn them all off)

macOS

  • Disable analytics:
    • System Settings / Privacy & Security / Analytics & Improvements / (turn them all off)
    • Sign in to account.apple.com, then Privacy / iCloud Analytics / Share iCloud analytics / (turn off)
    • This might also be a good time to request export of all the data Apple holds on you
  • Disable Apple’s Ad tracking:
    • System Settings / Privacy & Security / Apple Advertising / Personalized Ads / (turn off)
  • Disable Siri:
    • System Settings / Apple Intelligence & Siri / Siri / (turn off)
    • System Settings / Apple Intelligence & Siri / Siri history / Delete Siri & Dictation History / (click on the button)
  • Private Click Measurement:
    • Safari / Settings / Advanced / Allow privacy-preserving measurement of ad effectiveness / (turn off)
  • Improve Search:
    • System Settings / Accessibility / Motor / Voice Control / Improve assistive voice features / (turn off)
    • System Settings / Spotlight / Siri Suggestions / (turn off)
    • System Settings / Spotlight / Help Apple Improve Search / (turn off)

Further actions

Ideally, change your default browser to something better, like Vivaldi or LibreWolf.

Stop iMessage from using insecure unencrypted SMS as a fallback (warning: this setting is buggy and often ignored):

  • on iOS: Setting / Apps / Messages / Send as Text Message / (turn off)

Better yet, ditch both SMS and iMessage for Signal or WhatsApp, who do not have an unencrypted option to snare you. See also this Signal hardening checklist.

Install Little Snitch, an outbound firewall you can use to control what sites apps can connect to.

Disable Apple Intelligence.

Ultimately, switch to Linux and GrapheneOS or LineageOS.

PSA: LinkedIn single-sign-on dangers

I have a work-issued computer that I keep rigorously separate from my personal stuff. It belongs to my employer and thus I do not keep personal files on it, or access personal email and certainly don’t save personal passwords on it. I even have it on a separate VLAN on my home network.

This is why I was horrified when I went to the LinkedIn website on my work computer (to look at a colleague’s posting) and it automatically started a single sign-on with my company’s GMail (my work address is of course linked to my LinkedIn profile).

This means a company with Google Apps can potentially access your LinkedIn account without your permission. Considering LinkedIn’s past record of egregious security failures1, it shouldn’t be too surprising, but still…

I couldn’t find any setting to disable SSO, and it seems the only way to prevent this is to turn on two-factor authentication (where the only options are the grossly insecure phone SMS text message method or the equally phishable TOTP Authenticator app codes, not the actually secure Webauthn/FIDO U2F USB keys).


  1. A colleague had built a GPU mining rig for fun and profit, and run the LinkedIn hashed password dump through it using hashcat. He found Donald Trump’s was a variation on “You’re fired!”… ↩︎

Funding the vetting of the Software Supply-Chain

TL:DR A way out of our software supply-chain security mess

As memorably illustrated by XKCD, the way most software is built today is by bolting together reusable software packages (dependencies) with a thin layer of app-specific integration code that glues it all together. Others have described more eloquently than I can the mess we are in, and the technical issues.

XKCD

Crises like the log4j fiasco or the Solarwinds debacle are forcing the community to wake up to something security experts have been warning about for decades: this culture of promiscuous and undiscriminating code reuse is unsustainable. On the other hand, for most software developers without the resources of a Google or Apple behind them, being able to leverage third-parties for 80% of their code is too big an advantage to abandon.

This is fundamentally an economic problem:

  • To secure a software project to commercial standards (i.e. not the standards required for software that operates a nuclear power plant or the NSA’s classified systems, or that requires validation by formal methods like TLA+), some form of vetting and code reviews of each software dependency (and its own dependencies, and the transitive closure thereof) needs to happen.
  • Those code reviews are necessary, difficult, boring, labor-intensive, require expertise and somebody needs to pay for that hard work.
  • We cannot rely entirely on charitable contributions like Google’s Project Zero or volunteer efforts.
  • Each version of a dependency needs to be reviewed. Just because version 11 of foo is secure doesn’t mean a bug or backdoor wasn’t introduced in version 12. On the other hand, reviewing changes takes less effort than the initial review.
  • It makes no sense for every project that consumes a dependency to conduct its own duplicative independent code review.
  • Securing software is a public good, but there is a free-rider problem.
  • Because security is involved, there will be bad actors trying to actively subvert the system, and any solution needs to be robust to this.
  • This is too important to allow a private company to monopolize.
  • It is not just the Software Bill of Materials that needs to be vetted, but also the process. Solarwinds was probably breached because state-sponsored hackers compromised their Continuous Integration infrastructure, and there is Ken Thompson’s classic paper on the risks of Trusting Trust (original ACM article as a PDF).
  • Trust depends on the consumer and the context. I may trust Google on security, but I certainly don’t on privacy.

I believe the solution will come out of insurance, because that is the way modern societies handle diffuse risks. Cybersecurity insurance suffers from the same adverse-selection risk that health insurance does, which is why premiums are rising and coverage shrinking.

If insurers require companies to provide evidence that their software is reasonably secure, that creates a market-based mechanism to fund the vetting. This is how product safety is handled in the real world, with independent organizations like Underwriters Laboratories or the German TÜVs emerging to provide testing services.

Governments can ditch their current hand-wavy and unfocused efforts and push for the emergence these solutions, notably by long-overdue legislation on software liability, and at a minimum use their purchasing power to make them table stakes for government contracts (without penalizing open-source solutions, of course).

What we need is, at a minimum:

  • Standards that will allow organizations like UL or individuals like Tavis Ormandy to make attestations about specific versions of dependencies.
  • These attestations need to have licensing terms associated with them, so the hard work is compensated. Possibly something like copyright or Creative Commons so open-source projects can use them for free but commercial enterprises have to pay.
  • Providers of trust metrics to assess review providers. Ideally this would be integrated with SBOM standards like CycloneDX, SPDX or SWID.
  • A marketplace that allows consumers of dependencies to request audits of a version that isn’t already covered.
  • A collusion-resistant way to ensure there are multiple independent reviews for critical components.
  • Automated tools to perform code reviews at lower cost, possibly using Machine Learning heuristics, even if the general problem can be proven the be computationally untractable.

The fetish for uptime

At one of my previous jobs, the engineers on my team had an informal competition as to who could rack up the longest uptime on their workstation (they all had Sun Solaris or Linux, of course). When the company moved to a new office, one crafty engineer managed to beat all the others by putting his Sun into the seldom-used hibernation mode to preserve his uptime when everyone else was forced to reboot.

I posit that uptime is actually a bad thing. All software has bugs, and a regular maintenance schedule to apply patches, at the very least once a month, should be part of the plan and designed into the architecture. By that token, an uptime greater than 31 days is a “code smell” for infrastructure.