📰 NewsMonitor

The European Commission, last week:\nToday, the European Commission has issued two sets of binding\nspecification measures to Google under the Digital Markets Act.\nThe aim of the first specification measures is to ensure that\ncompetitors’ Artificial Intelligence (AI) services can compete\nwith Google’s own AI services, such as Gemini, by having equal\naccess to features on Google’s Android devices.\nThe aim of the second specification measures is to rebalance the\nplaying field by giving third-party search engines access to\nsearch data that only Google Search can collect at scale.\nThey provide separate “Q&A” overviews of the guidance for Android AI interoperability and web search sharing, and the full guidance documents are PDFs (Case DMA.100220 for Android AI, Case DMA.100209 for web search). I suggest reading the two Q&A overviews, unless you’re having trouble falling asleep at night, in which case you’ll love the full PDF decisions.\nBoth decisions are interesting. With search, Google is required to share with competitors — search engines and AI chatbots alike — a massive amount of user data from Google Search user interactions. What terms people search for, what they click on in results, what languages and devices they use. It’s all ostensibly anonymized but that’s tricky when it comes to search terms. A lot of the terms people type into web search fields are to some degree personally identifying. The EC seems to be saying it’s Google’s problem to filter out things like passwords and usernames and omit them from the shared datasets. Google can charge money for this access, but only under “fair, reasonable, and non-discriminatory (FRAND)” prices, based on a Commission-defined methodology.\nMore interesting to me, however, is the guidance pertaining to on-device AI on Android devices. What the EC is dictating to Google is just breathtaking in scope. The EC is demanding that Google create APIs that allow third-party AI assistants to do everything Google Gemini does now, including:\nControl hardware buttons (to invoke the assistant).\nCapture anything on screen, from any app.\nSeemingly unfettered access to microphones and cameras and other sensors on the device.\nUnfettered background operation. Third-party AI assistants must be permitted to execute in the background whenever they want, for as long as they want.\nExecute their own audio models on the digital signal processor, so they can listen at all times for their own custom “Hey Dingus” wake phrases/hot words.\nGoogle must allow concurrent access to always-on hot word detection. So if you have Claude and ChatGPT and Grok and Meta AI installed, all of them — in addition to Gemini — must be permitted to have always-on audio detection concurrently. Google is permitted to do some vetting here, but this seems like madness.\nThird-party models get access to Google’s on-device local models.\nAlso, in my reading, the EC is demanding that Google make available to third-party AI assistants all information in Google’s own apps (Gmail, Google Calendar, Google Docs, Google Maps, etc.) that Gemini has access to. There is no opt-out for Google regarding data from their own apps. Nor, I think, does this guidance allow third-party apps from other developers to only support specific system-level AI models. Like, let’s say you’re Slack, and you use the APIs to make the content from within Slack available to Gemini on the device. These guidelines don’t permit Google to allow Slack to say that they trust Gemini but only Gemini. If a third-party app like Slack supports making its data available to any system-level AI provider, it must make its data available to every system-level AI provider.\nThere’s a lot more. Basically, though, the EC is demanding that third-party AI assistants be enabled to become part of the system software, not just apps. I’m sure some people think this is a great idea. It’s the user’s device, they should be allowed to make ChatGPT or Claude or Meta AI part of their OS if they want. It’s up to them. Put users in control.\nThis is how PCs have traditionally worked, but many normal people’s PCs are a mess of third-party software running in the background. That includes the Mac. If you ask a normal person “What third-party software runs in the background on your Mac or PC?” they would have no idea. It’s all just magic to them. If Google supports this guidance, it could turn Android phones in the EU into PCs. Honestly, some of the stuff the EC is requiring is lower-level than what MacOS and Windows allow third-party software to do.\nWhat the EC’s “guidance” describes in this document is an entirely different operating system than the Android that Google has designed. The European Commission obviously thinks it is their place to design operating systems. Maybe you do too. Google obviously disagrees, and so does Apple. And so should most people who have any idea how these devices work. This is a recipe for disaster, if Google were to enact it and third-party AI assistants took advantage of it.\nThat second “if” is a big one. One possible scenario that I consider quite likely is that Google could spend years of engineering time and human resources building out APIs to enable all of this, in the safest and most private ways possible, and no major AI assistant adopts it. That’s the way it’s turned out with a whole slew of DMA compliance for Apple and Google. Apple built an entire complex set of APIs to enable third-party web browser rendering engines, exclusively for compliance with the DMA, and there exist no third-party web browser rendering engines for iOS. Not one. Because while the EU is a big market, it’s not big enough to justify building a custom web browser just for the EU alone.\nWays I can see this playing out, in order of likelihood:\n(A) Google enacts all of this and no major AI assistants support it because it’s only for Android, only in the EU. And it’s not like ChatGPT and Claude are seeing a lack of usage as things stand now. In this scenario Google just wastes massive time and engineering talent building APIs that never get used, and Android users in the EU get hassled with additional annoying choice and permission screens just to use the Gemini features that are built into Android.\n(B) Google enacts all of this and major AI assistants do support it. Unintended results include massive privacy violations where third-party assistants exfiltrate on-device data to the cloud, Meta uses on-device third-party data for the targeting of ads, and users who take advantage of these third-party assistants see significant battery life drain as third-party assistants run without limits in the background and run expensive inference locally to save on their own server costs.\n(C) Google enacts all of this, major AI assistants do support it, and there are no privacy scandals, nor any issues with battery life, because each of the companies that makes these assistants develops them with respect for user privacy and for device resources like CPU and memory consumption. \n(D) Google pulls system-integrated Gemini from Android in the EU, or severely restricts its capabilities. Rather than elevate third-party assistants from apps to system software, demote Gemini to the privileges of a mere app and leave Android users in the EU without a system-integrated AI assistant.\nUnder all scenarios, future feature updates to system-level AI in Android will appear late or never in the EU. No future new features can debut in the EU at the same time as the rest of the world because for DMA compliance, Google will need to add support for third-party assistants to do the same things. And they’re not going to hold new features for the rest of the world waiting for that.\nI’m not even sure (D) is permitted under this Commission guidance, given that Google started shipping Gemini on Android last year. The entire guidance document is written under the presumption that Google will comply by building the APIs that the guidance demands, not by achieving parity by removing Gemini system integration features. It would be awkward and unpopular for Google to ship updates to Android that remove core AI features, but that might be more palatable than the alternative.1 Note that with iOS, to my recollection, Apple hasn’t pulled any existing features from the EU. They’ve only withheld or delayed new features. Google’s on-device Gemini horse is already out of the barn.\nLastly, although this guidance document pertains to Android, not iOS, I see no reason to think the European Commission wouldn’t demand all or most of the same things from Apple. They haven’t given Apple any guidance yet, because it’s European Commission policy to give guidance only after a DMA-designator gatekeeper ships something that is then ruled non-compliant. But it’s hard to imagine Apple accepting most of these terms. Unfettered background processing and access to the microphone, cameras, and sensors? Third-party audio models running on the hardware DSP listening for wake words? Granting third-party assistants unsupervised access to all user data from apps published using App Intents?\nApple unfortunately hasn’t shared any technical details describing its proposal for a “Trusted System Agent” that it shared with the EC last year. But whatever Apple’s vision for the Trusted System Agent is, I don’t see how the EC would deem it compliant with the DMA if they want from Apple anything close to what they are now demanding from Google. There are no checks and balances or oversight that Google is permitted to apply to third-party assistants in this guidance. If Gemini can do something, third-party agents must be able to as well. Because Gemini gets to run in the background as much as Google sees fit, third-party assistants must be permitted to run in the background as much as they see fit. And if those third-party assistant developers — OpenAI, Anthropic, xAI, and Meta — have different opinions than Google on how much CPU usage is appropriate in the background, how much RAM and storage is appropriate to consume, or how respectfully to treat users’ on-device data, well that’s just tough noogies. If the user OK’s it, then it’s OK.\nA month ago, after WWDC, when this guidance pertaining to Android AI was rumored to be forthcoming, I wrote:\nGoogle is learning the lesson Apple learned the hard way with all\nthe existing features of iOS that were deemed noncompliant with\nthe DMA when it went into effect. The “ship it first and ask\nforgiveness / hope it’s deemed compliant” strategy is not a good\none in the EU.\nI genuinely wonder what the European Commission thinks the purpose of Android is. Google created Android for the benefit of its own services. Google was worried about Microsoft, not Apple, at the time, but they wanted to ensure their own services were available on a major mobile platform. I’m really not seeing how it’s more attractive to Google to comply with this guidance than to just pull system-level Gemini in the EU. Either they waste a small fortune building APIs no one will use, or, they spend that small fortune buildings APIs for the benefit of their biggest competitors. I get it that that’s the intended price to pay for being a designated DMA gatekeeper. But what’s the motivation for Google to do this rather than just walk away from system-integrated AI on Android in the EU? It certainly doesn’t look like the competing platform, iOS, is going to offer it in the EU anytime soon either.\nIf you are handed a mandate that everyone must be able to run at the same speed, and you can’t figure out how to make slow people faster, you can comply by forcing the fast to wear weighted boots. This is where utopian egalitarian initiatives often lead. ↩︎

Het is inmiddels duidelijk dat zelfs maar deels Amerikaanse bedrijven met allerhande middelen gedwongen kunnen worden om onze data te overhandigen aan de Amerikaanse overheid. Ook kan de dienstverlening gestaakt worden na een enkel briefje op Whitehouse.gov, wat zonder enige rechterlijke toetsing geplaatst kan worden. Tegen deze beide dingen is met papier niets te doen. Geen speciale afspraak zal je redden uit dit probleem (dit ook volgens de Landsadvocaat). Maar, er is dan soms nog de hoop om de data nog wel privé te houden met speciale encryptie.

I was reading through the fix for a package manager CVE last week and ran into a git flag I’d somehow never noticed: --end-of-options. My first reaction was that some LLM had hallucinated it, but it’s documented in gitcli(7), it was added in git 2.24.0 in November 2019, and it exists because git had already used -- for something else. In most Unix tools -- marks the end of option parsing, so rm -- -f removes a file called -f rather than passing the force flag. Git had repurposed -- early on to separate revisions from pathspecs, because git log foo on its own is ambiguous between a branch named foo and a file named foo and one of the two readings needed a marker: git log main -- README.md means commits on main touching that file. That left the revision position with no terminator, so if a script runs git log "$rev" and $rev starts with a dash, git parses it as an option. From the commit that introduced --end-of-options: But that doesn’t work for the revision parser, because -- is already meaningful there: it separates revisions from pathspecs. So we need some other marker to separate options from revisions. -- and --end-of-options are different things in git, and treating them as interchangeable is a mistake I’ve now seen in several places. Putting -- before a URL in git clone -- "$url" works, because clone follows the POSIX convention. A trailing -- after a ref, as in git checkout "$ref" --, marks $ref as a revision rather than a filename but still lets it be read as an option first. Passing an untrusted revision safely means writing git log --end-of-options "$rev" -- "$path", with both markers doing separate jobs. Support for the new flag arrived per subcommand rather than all at once: git rev-parse only got it in 2.30.0, a year after the initial release, because it has its own hand-rolled argument parser, and git checkout and git reset rejected it until 2.43.1 in February 2024 because they parse -- themselves and the initial implementation left --end-of-options in the argument list where their parsers rejected it. Argument injection Git, hg, and ssh all ship options whose documented purpose is to run a command the caller names. git clone accepts --upload-pack= to specify the server-side binary, and any git invocation accepts -c core.sshCommand= to override how it connects. Mercurial accepts --config=alias.=! on any subcommand, which redefines the subcommand you’re running as an arbitrary shell script. ssh accepts -oProxyCommand=. These are documented features that become attack primitives when a wrapping program passes an untrusted string into the argument list. The failure mode has its own CWE, CWE-88, argument injection, and it’s distinct from command injection because there’s no shell involved: the wrapping program builds an argv array and calls exec directly, exactly as every “don’t use system()” guide recommends, the array reaches git intact, and git then parses one of the arguments as an option because it starts with a dash. CVE-2019-13139 in docker build is a clean example: Go’s os/exec package, an argv array, no shell, and a git-context URL whose #ref:dir fragment reached git fetch origin as --upload-pack=. The pattern was demonstrated across four version control systems on the same day in August 2017, when CVE-2017-1000117 (git), CVE-2017-1000116 (Mercurial), CVE-2017-9800 (Subversion), and CVE-2017-12836 (CVS) were disclosed together. Each passed a URL’s hostname to ssh as an argument, and a hostname starting with -oProxyCommand= became an ssh option. Phabricator’s post-mortem on the disclosure noted that of the three actively maintained tools, only Subversion actually added -- before the hostname in its fix; git and Mercurial validated the hostname format instead, partly because -- isn’t supported by every ssh implementation. The same write-up called the -- mechanism itself “unsafe by default”, since code without it looks correct and works fine right up until an argument starts with a dash. Package managers Package managers routinely take a git URL or ref as data and pass it to a subprocess: gem 'foo', git: '...' in a Gemfile, github:user/repo#ref in a package.json, and equivalents in pyproject.toml, Cargo.toml, mix.exs, Package.swift, pubspec.yaml, conanfile.py, and go.mod. The URL and ref arrive in a manifest, a lockfile, or a transitive dependency’s metadata. Of nineteen package managers I checked1, seventeen fork the git binary as their default or only path. The two that default to a library are Cargo, which uses libgit2 with an opt-in net.git-fetch-with-cli setting to fork instead, and Poetry, which switched to dulwich in 1.2.0 with a system-git-client setting to fall back. Nix uses libgit2 for reading local repositories but forks git for fetches, because libgit2 lacks git-credential helper support. The published CVEs against package managers in this class include CVE-2021-43809 (Bundler), CVE-2021-29472 and CVE-2022-24828 (Composer), CVE-2022-36069 (Poetry), CVE-2023-5752 (pip), CVE-2022-21223 and CVE-2022-24440 (CocoaPods), and CVE-2025-68119 (Go). The Snyk research that produced several of the 2022 entries is written up here, and Sonar maintains a catalogue of the dangerous options per binary. Of the seventeen that fork git, exactly one uses --end-of-options: Go’s cmd/go. It added -- before repository URLs in June 2019 as a general hardening pass. In January 2026 that turned out to be insufficient and --end-of-options was added across the board as the fix for CVE-2025-68119, along with HGPLAIN=+strictflags, which has restricted Mercurial’s early-option parsing since hg 4.4.2 in 2017. The commit message ends: “We should probably follow up with a more structured change to make it harder to accidentally re-introduce these issues in the future, but for now this addresses the issue at hand.” Minimum git versions The other package managers that guard the argument list at all use -- or a leading-dash check on the input, and looking at when each guard was added, most arrived as the fix for a reported vulnerability rather than in the original implementation. The -- before the URL in Bundler’s git clone is the CVE-2021-43809 patch. The leading-dash rejection in cocoapods-downloader landed in three commits over ten days in March 2022, matching the CVE-2022-21223 disclosure. Poetry’s guard arrived in September 2021 with a CVE assigned a year later, and the switch to dulwich followed six months after that. vcpkg is the exception I found where -- was present from the day git registry support was written. Composer’s advisory for CVE-2022-24828 explains why almost none of these tools use --end-of-options: it names the flag as the correct fix and then says Composer supports git versions that predate it, so the patch rejects leading-dash branch names instead. vcpkg’s git integration has a comment stating a floor of git 2.7.4. Homebrew’s HOMEBREW_MINIMUM_GIT_VERSION is 2.7.0 on Linux, set in 2018. Amazon Linux 2, which packaged git 2.14.3, reached end of life last month, so the distributions those floors track are only now ageing out. Ubuntu 18.04 with git 2.17.0 is in extended support until 2028. Ubuntu 20.04, in extended support until 2030, packages 2.25.1, which is new enough to accept --end-of-options on git fetch but old enough to reject it on git rev-parse. Relying on the flag means raising the minimum git to 2.24.0 for most subcommands, 2.30.0 for rev-parse, or 2.43.1 for checkout and reset, and losing anyone still on the distribution-packaged git. Git libraries libgit2, gitoxide, go-git, JGit, and dulwich all implement enough of the git wire protocol to clone and fetch in-process, with no argv boundary and so no argument list to inject into. Jujutsu uses gitoxide for its git interop and has no published CVEs in the argument-injection class; its two advisories to date are a path traversal and a missing SHA-1 collision check inherited from the library. go-git has one, CVE-2025-21613, and it’s specifically on the file:// transport, the one code path in go-git that spawns the git binary. I noted in the package manager CWEs post that this trades one problem for another, since a bundled git implementation has to track every checkout-safety fix upstream git ships, and libgit2 and JGit have both had rounds of those. That’s a real cost, but it’s a stream of specific patches to apply rather than a check that has to be remembered at every call site forever. Writing this prompted me to open a PR against Homebrew raising its minimum git to 2.30.0 and adding --end-of-options before URLs in clone, remote set-url, and ls-remote, and before refs in rev-parse. The checkout and reset calls are left alone, since covering those would need a floor of 2.43.1, released February 2024, and that’s recent enough to still be ahead of several supported distributions. Bundler, Cargo, CocoaPods, Composer, Conan, Go, Helm, Homebrew, Mix, Nix, npm, pip, pnpm, Poetry, Pub, SwiftPM, uv, vcpkg, Yarn. All checked at HEAD in July 2026. ↩

Wherein we chase down a BASIC retrocomputing question that's bugged me for far too long.

Debugging SSO, managing users, adjusting auth policies, configuring branding: every configuration task has lived behind a UI that only a human can drive. The WorkOS MCP server gives agents the same access as your dashboard login. Hundreds of operations, discoverable at runtime. Connect in one command via OAuth, with scoped tokens instead of a master API key. Pass a screenshot of your marketing site and ask your agent to match the login page. If a human had to do it before, an agent can do it now. Connect your agent →  ★

Ben Thompson, on the hype regarding Kimi K3, at Stratechery: This is a point that bears repeating: because U.S. open weight model makers must follow the frontier labs’ terms of service, they (1) are worse than Chinese alternatives and (2) end up distilling the distillation, just with a detour through Chinese labs. Wouldn’t it be better if western open weight model makers could go to the source? To that end, here’s an even more interesting question around distillation: why exactly is it bad? After all, what are large language models but the distillation of all of the knowledge on the open Internet, scraped by the frontier labs and distilled into the models that are themselves being distilled? Who is exactly being wronged here? In fact, this paradox is the solution. I believe that open weight models are good for innovation (and, per the above, I think that labs on the frontier will be fine), but it’s a problem to be dependent on China. The U.S. should pass a law that (1) makes explicit that collecting data for training models is fair use, and (2) bars terms of service that forbid distillation, for U.S. companies at a minimum. Stopping distillation — which is literally just querying the API — is nearly impossible; the U.S. should go the other way and lean into a new copyright policy that both indemnifies the labs and also guarantees that what they learned fuels further innovation for everyone else. To be clear — and Thompson emphasizes this point too — the leading Chinese models like K3 aren’t good only because of distillation. They’re not entirely rip-offs. But distillation is clearly an essential part of the formula they’re using to keep releasing models that are 6–9 months behind the U.S. frontier state of the art. So the Chinese treat all models as “open”, regardless of the terms of service. But anyone in the U.S. or other western countries that respect copyright who wants to distill a good model has to wait for the Chinese to release their models, like K3. And that second paragraph I quote above distills (sorry) exactly why I want to bring out the world’s smallest violin to play a sad song for OpenAI and Anthropic regarding their objections to their frontier models being distilled against their terms of service.  ★

Sinds 2024 run ik OpenTK, met als doel zo goed mogelijk te laten zien wat er in de Tweede Kamer allemaal gebeurt. En, om daar ook nuttige email-notificaties over te versturen. OpenTK is begonnen omdat ik (vanuit de Internetwereld) ineens geconfronteerd werd met een wet die over DNS (mijn hobby) ging en over een paar dagen in stemming zou komen. Dat was heel erg schrikken en ik dacht, dat kan ons nooit meer gebeuren.

9to5Mac: Brazilian users browsing the App Store rankings in categories such as Navigation, Travel, and Weather have noticed a growing number of poorly made games appearing among the top results, many of them featuring AI-generated illustrations of animals as their app icons. As it turns out, these are so-called jacket apps, which are just a front for hidden betting and gambling apps. A 9to5Mac investigation has uncovered more than 60 apps that behave exactly as depicted in their App Store screenshots when accessed from virtually anywhere in the world, except Brazil. When opened from a Brazilian IP address, the same apps instead reveal online betting platforms, as shown in the example below, which is currently the top app in the Weather category. Obviously the main problem is that these apps disguise themselves Trojan Horse-style, and slip through App Store review undetected. I don’t think it’s reasonable to think App Store review could catch every attempt at this sort of thing though — if the horses are disguised well-enough, some of them are going to slip through. That’s actually fine. But the first example 9to5Mac cites isn’t well disguised at all. What sense does it make that “PotatoPlot Puzzle” — a game featuring a rabbit potato farmer — is a weather app? How is that not a red flag right there? Also, this app rose to become not just popular, but the number one weather app in Brazil, a nation with over 200 million citizens. In my yearslong argument that Apple should commission an internal bunco squad dedicated to hunting down scammers in the App Store, I always mention that the point of such a squad shouldn’t be to make the App Store 100 percent scammer-free — which I believe is an impossible goal that would set the team up for failure. The point should be only to make the App Store free of successful scams. Focus on the most popular apps and the most lucrative apps. There’s simply no feasible excuse for PotatoPlot Puzzle to have become the most popular “weather app” in Brazil.  ★

‘It Seems You Have a Different Policy’ Ben Thompson, in a subscriber-only Stratechery update Tuesday: I got a fun email from former Apple executive, Nest founder, and one-time Stratechery Interview subject Tony Fadell in response to yesterday’s Update about Apple suing OpenAI (published with permission): Good article as always… This is Apple’s typical tactic to scare Apple employees — either former or current. I heard this lawsuit was driven by the Apple board. Steve threatened to file a lawsuit against Nest for poaching 80-100 Apple employees. He called me, screamed for a while with lots of accusations. Then I said, “Steve, it’s Apple’s job to retain its talent, not mine.” He stopped his rant and then we went on to talk about our families and vacation plans. We kept hiring… This sounds about right — and in terms of the Steve Jobs angle, John Gruber made a compelling case on Dithering that this lawsuit may very well have been driven by John Ternus channeling his inner Jobs. Fadell, of course, is correct that it’s Apple’s job to retain its talent. Recent reporting from Mark Gurman suggests that John Ternus is keenly aware of this, at least as it pertains to Apple’s industrial design team, which has been ground zero for the Apple-to-OpenAI recruitment pipeline. (And the Dithering episode Thompson references is the one we made free-to-listen this week.) Playing hardball when it comes to poaching is deeply embedded in Apple’s DNA. Steve Jobs hated Apple employees getting poached. In 2005 he sent this email to Adobe CEO Bruce Chizen: From: Steve Jobs Bruce, Adobe is recruiting from Apple. They have hired one person already and are calling lots more. I have a standing policy with our recruiters that we don’t recruit from Adobe. It seems you have a different policy. One of us must change our policy. Please let me know who. Steve After one back-and-forth exchange with Jobs, Chizen agreed Adobe would change its policy. A more contentious example came in August 2007, when Jobs sent an email to Palm CEO Ed Colligan that read: From: Steve Jobs Ed, This is not satisfactory to Apple. It is not just a matter of our employees deciding they want to join Palm. They are being actively recruited using knowledge supplied by Jon Rubenstein [sic] and Fred Anderson, with Jon personally participating in the recruiting process. We must do whatever we can to stop this. I’m sure you realize the asymmetry in the financial resources of our respective companies when you say: “We will both just end up paying a lot of lawyers a lot of money.” Just for the record, when Siemens sold their handset business to BenQ they didn’t sell them their essential patents but rather just gave them a license. The patents they did sell to BenQ are not that great. We looked at them ourselves when they were for sale. I guess you guys felt differently and bought them. We are not concerned about them at all. My advice is to take a look at our patent portfolio before you make a final decision here. Steve That’s a good email. Information dense. My favorite part isn’t the “I’m sure you realize the asymmetry in the financial resources of our respective companies”, although that’s good. It’s the “I guess you guys felt differently and bought them.” Stone cold. Some backstory on the players: Colligan, of course, is Mr. “PC guys are not going to just figure this out. They’re not going to just walk in.” He was a business guy who thought product guys didn’t matter in an industry that was about to be taken over by product guys. Sort of like Steve Ballmer, without the charisma, at a much smaller company. Jon Rubinstein1 was a hardware engineering executive at Apple, overseeing Mac hardware during the comeback years after Steve Jobs returned, then switching to oversee the newly-created iPod division in 2004. (Mac hardware then went under the supervision of a then-little-known operations executive referred to in the announcement as “Timothy Cook”.) Rubinstein left Apple in early 2006, citing exhaustion.2 His departure was announced six months earlier, alongside the promotion of Cook to COO. By 2007 Rubinstein was involved with Palm, by way of Elevation Partners, an investment firm that took a 25 percent stake in Palm. He became CEO of Palm in 2009, tried to turn it around, and then wasted a few years as an executive at HP after HP bought Palm’s carcass thinking it was still alive. Fred Anderson was Apple’s CFO from March 1996 (almost a year before the NeXT reunification) to June 2004 — the nail-biting, at-times-near-bankruptcy turnaround years. Anderson took the fall, perhaps unfairly, for the stock options backdating scandal under Steve Jobs and, after leaving Apple, paid a $3.5 million fine in a settlement with the SEC. Needless to say, in the summer of 2007, there was bad blood between Anderson and Apple. Anderson, post-Apple, was a co-founder of Elevation Partners and had recruited Rubinstein to join. Some bad blood. Some former high-level Apple executives putting a team of ex-Apple engineers and designers together to take on the iPhone. History doesn’t repeat, but it often rhymes. If in addition to thinking that this sounds familiar, you also think these emails sound illegal, you may recall that in 2015, Apple (along with Google, Adobe, Intel, and other companies) paid a collective $415 million penalty to settle a class-action anti-poaching lawsuit. That they settled doesn’t mean they regret playing hardball. Rules are only followed by those who fear the penalties. Jobs liked to fight, and wasn’t afraid to let his temper show. Tim Cook has a fierce temper and steel nerves, but he arguably only once, ever, showed it in public. I do not think he relishes a fight. He’s a diplomat, not a general. I suspect there’s no undiscovered tranche of Jobs-style stone-cold threatening emails from Cook to competing CEOs. Steve Jobs’s oft-cited parting advice to Tim Cook was “Don’t ask what I would do. Just do the right thing.” Cook has largely lived by that mantra. But maybe — maybe — by taking that advice to heart, he has at times deliberately steered the company in ways Jobs would not have, just for the sake of steering it in a different way. I think maybe John Ternus is more of a “Hey, what would Steve have done here?” kind of guy. On the one hand, this lawsuit is a bad look for Apple. It could be perceived that Apple does not think their employees are free to leave and compete against them. On the other hand, Apple could use a booster shot of Steve Jobs’s “us against the world” attitude. It might be wrong to start a war, but it’s never wrong to finish one after being attacked. What would Steve Jobs do with this OpenAI situation? He’d go to war.3 ‘This Is Not Satisfactory to Apple’ The early history of the Macintosh GUI went something like this: When the Macintosh debuted in 1984 it didn’t hit like Apple had hoped it would. (That’s when Steve Jobs was run out of the company.) But by the late 1980s it had caught on, especially in markets like design and desktop publishing. It was the only GUI game in town — command-line DOS PCs were popular, but Windows 1.0 was almost too primitive to believe and Windows 2 wasn’t much better. Apple was certain that the WIMP GUI was the future of computing, and because the Macintosh was the only credible GUI then on the market, Apple owned the future of computing. They were correct about one of those things. Because then came Windows 3, which still sucked — still was ugly, still was terribly designed, still severely limited compared to the Mac in its UI grace and vocabulary of actions — but, it didn’t suck as much. It wasn’t good but it was good enough for the corporate IT market, and the corporate IT market drove the industry at the time. In 1994 John Sculley filed the infamous “look and feel” lawsuit against Microsoft. One year out from the launch of Windows 95 — which at least looked pretty good4 — Apple’s response was to try to argue in court that they owned the copyright and patent rights to the very concepts of the GUI and the desktop metaphor. The court handed Apple its ass. Apple soon found itself 90 days away from bankruptcy and in desperate need of a new modern operating system, which they themselves had proven incapable of creating. Windows 95 launched with such anticipation that customers lined up overnight outside retail stores to buy it the morning it launched. That lawsuit was the low point in the entirety of Apple’s history. It was incoherent and, worse, pathetic. Incoherent because Apple was simultaneously arguing in marketing that the Mac remained vastly superior to Windows (“C:\ONGRTLNS.W95”), while arguing in court that Windows was a feature-for-feature clone. It couldn’t be both. I would argue that the former was true — the Mac remained superior in many ways — but actions speak louder than words and Apple’s action was to sue Microsoft and lose. It was pathetic because you know who loses? Losers. The correct response to the competitive threat of Windows wasn’t to futilely attempt to argue that Windows should not be allowed to exist. It was to make the Macintosh so much better than it already was — to inject so much new innovative insane greatness — that customers would line up overnight to buy Mac software (and watch Apple keynotes). What Microsoft had in 1995 that Apple could not muster was vast customer enthusiasm. That cannot be bought. It cannot be faked. It can only be earned. And you sure as shit cannot stop it with a lawsuit. Earning that sort of consumer enthusiasm — in spades — is exactly how Steve Jobs pulled Apple out of its nosedive. It took the better part of a decade. When Apple announced this new lawsuit last week against OpenAI, I wondered, at first, whether it had a whiff of that 1994 look-and-feel loser desperation. Is it Apple’s position that the only way to stop its talent exodus to OpenAI is in court? Upon consideration, I think not. First, it’s not incoherent. There’s no conflict between what Apple is saying about its products or itself as a company that is at odds with this lawsuit. They’re just saying, “Fuck you, you goddamn traitors. You want to fuck with us? We’ll fuck with you.” When you poke a bear — 400 times — you better be ready for the bear to eventually react. Further, while Apple can only have one CEO at a time, and that CEO remains Tim Cook until September 1, there’s no way that John Ternus doesn’t fully approve of this lawsuit. Cook has gone out of his way to leave Ternus with a clean plate. It would be insane to file this suit six weeks ahead of Ternus taking the helm if Ternus is anything short of fully on board. I’m not saying it’s a good look for Apple. I’m certainly passing no judgment on the merits of the case, which OpenAI hasn’t yet responded to legally. But it is a very different and much more emotional reaction than we’ve seen under Tim Cook. Those anti-poaching emails Steve Jobs sent to Adobe, Palm, and Google weren’t good looks for Apple either. But that doesn’t mean they were bad for Apple. A bad look can be a good thing. Passion is powerful, and in and of itself, inspiring. This is a passion-fueled lawsuit. I saw some commentators speculate that, already hemorrhaging cash on a daily basis, OpenAI will surely spew some of that in the direction of Cupertino and just settle it. But Apple doesn’t need cash. This is a lawsuit that I believe OpenAI cannot settle, because there is no settlement Apple would accept short of a dissolution of their entire hardware division. Apple claims in their complaint that the trade-secret chicanery they’ve already documented “is the tip of the iceberg”. If Apple is wrong, and OpenAI has recruited above the board and hired 400 former Apple employees fair and square (or even just mostly fair and mostly square), they have nothing to fear, and John Ternus will look like a petty little jealous bitch, and a feckless one at that. If Apple is right, however, all bets are off. I said earlier that rules are only followed by those who fear the penalties. But some never consider the penalties in the first place because they believe the rules don’t apply to them. Sometimes they find out otherwise. I’m not saying OpenAI cannot win. I’m saying they can’t get Apple to settle — at least not until Apple is satisfied the whole iceberg has been revealed through discovery. Until then, John Ternus’s offer to Sam Altman is nothing — not even the fee for the gaming license, which he would like Altman to put up. Jobs might be forgiven for misspelling Rubinstein’s surname in his email to Colligan. Everyone called him “Ruby”. Perhaps akin to misspelling Greg Joswiak’s name as “Jozwiak” because everyone just calls him “Joz”. ↩︎ I think it’s more likely that Rubinstein wore out his welcome at Apple. Here, I turn to Walter Isaacson’s Steve Jobs, which has some remarkable reporting on the situation. Quoting from Chapter 35, “Round One” (which chapter title refers to Jobs’s first bout with the cancer that eventually did him in), pp. 459–460 in the print edition: In the fall of 2005, after returning from his medical leave, Jobs tapped Cook to become Apple’s chief operating officer. They were flying together to Japan. Jobs didn’t really ask Cook; he simply turned to him and said, “I’ve decided to make you COO.” Around that time, Jobs’s old friends Jon Rubinstein and Avie Tevanian, the hardware and software lieutenants who had been recruited during the 1997 restoration, decided to leave. In Tevanian’s case, he had made a lot of money and was ready to quit working. “Avie is a brilliant guy and a nice guy, much more grounded than Ruby and doesn’t carry the big ego,” said Jobs. “It was a huge loss for us when Avie left. He’s a one-of-a-kind person — a genius.” Rubinstein’s case was a little more contentious. He was upset by Cook’s ascendency and frazzled after working for nine years under Jobs. Their shouting matches became more frequent. There was also a substantive issue: Rubinstein was repeatedly clashing with Jony Ive, who used to work for him and now reported directly to Jobs. Ive was always pushing the envelope with designs that dazzled but were difficult to engineer. It was Rubinstein’s job to get the hardware built in a practical way, so he often balked. He was by nature cautious. “In the end, Ruby’s from HP,” said Jobs. “And he never delved deep, he wasn’t aggressive.” There was, for example, the case of the screws that held the handles on the Power Mac G4. Ive decided that they should have a certain polish and shape. But Rubinstein thought that would be “astronomically” costly and delay the project for weeks, so he vetoed the idea. His job was to deliver products, which meant making trade-offs. Ive viewed that approach as inimical to innovation, so he would go both above him to Jobs and also around him to the midlevel engineers. “Ruby would say, ‘You can’t do this, it will delay,’ and I would say, ‘I think we can,” Ive recalled. “And I would know, because I had worked behind his back with the product teams.” In this and other cases, Jobs came down on Ive’s side. At times Ive and Rubinstein got into arguments that almost led to blows. Finally Ive told Jobs, “It’s him or me.” Jobs chose Ive. By that point Rubinstein was ready to leave. There’s a strong whiff of “You can’t fire me, I’m retiring” in the air when someone claims they were ready to leave after Jony Ive issued a “him or me” ultimatum. That’s like saying you’re ready to leave the pub after the bartender rings the bell for last call. I’d end this footnote here, but the very next passage is too apt to omit: He and his wife had bought property in Mexico, and he wanted time off to build a home there. He eventually went to work for Palm, which was trying to match Apple’s iPhone. Jobs was so furious that Palm was hiring some of his former employees that he complained to Bono, who was a cofounder of a private equity group, led by the former Apple CFO Fred Anderson, that had bought a controlling stake in Palm. Bono sent Jobs a note back saying, “You should chill out about this. This is like the Beatles ringing up because Herman and the Hermits have taken one of their road crew.” Jobs later admitted that he had overreacted. “The fact that they completely failed salves that wound,” he said. ↩︎︎ One can argue that this whole situation never would have happened if Steve Jobs were still alive, because if he were, Jony Ive, Tang Tan, Evans Hankey, et al. would still be at Apple, and there would be no io. But that’s like saying maybe if someone in the 1910s had given Hitler more encouragement as a painter, none of this would have happened either. I enjoy fictional alternative histories as much as the next guy, but I’m more interested in the question of how Jobs would respond, right now, to the actual current situation. ↩︎︎ A small irony is that the look-and-feel of Windows 95 borrowed much more from NeXTStep than it did from System 7. The look and layout of windows themselves; the use of gray, not white, as the default background color for the UI chrome; the chiseled 3D look — it’s almost inarguable that the Windows 95 look was ripped off from NeXT. Microsoft even copied from NeXT the window-close button going in the top right, not top left, and marking it with an “×” glyph, which the Mac never did. ↩︎︎

Michael Acton, reporting for the Financial Times from San Francisco: About 40 former employees now working at OpenAI have been sent letters directing them to preserve documents and communications and demanding meetings with Apple’s lawyers, according to multiple people familiar with the matter. Apple and OpenAI declined to comment. The decision to hit employees with personal legal letters highlights Apple’s aggressive tactics after it last week launched a blockbuster lawsuit accusing OpenAI and two employees of stealing secret hardware plans.  ★