Archive for August 2026

Tuesday, August 18, 2026

New EU App Store Terms to Comply With DMA

Apple (developer, details, Hacker News, TechCrunch, The Verge, 9To5Mac):

These changes resolve Apple’s disagreements with the Commission over business terms and alternative distribution. They also reduce complexity by moving every developer that distributes apps in the EU to a single set of business terms.

[…]

The Core Technology Fee, a per-install fee for developers that achieve extraordinary scale, will be replaced by the Core Technology Commission, a simple 5 percent commission on digital transactions in apps distributed outside the App Store. The new terms also eliminate the initial acquisition fee and store services fee.

[…]

Under the updated terms, developers can now offer Apple In-App Purchase alongside alternative payment options, which had not previously been permitted in the EU.

[…]

Apple is also expanding who is eligible to operate an alternative app marketplace or distribute apps via the web in the EU.

[…]

Apple will continue to require every alternatively distributed app to go through Notarization[…]

Juli Clover:

Apple will charge a 26% fee for apps distributed through the App Store that use in-app purchase.

[…]

Apps in the App Store that use in-app alternative payment processing will pay 20%.

[…]

Apps that link to a website purchase option will pay 15%.

Apps using Web Distribution or App Marketplaces would pay the 5% CTC (and report transactions). I like that the new terms are simpler and that the fees are slightly lower, but it seems like the EU got tricked or surrendered here.

EMIRELADERO:

This is bonkers, I can’t believe the EU Commission agreed to it. The main issue that the DMA was about still remains: Apple retains ultimate control over app developers’ dealings with users.

The status quo that the EU should have pushed for, and which Article 6(7) of the DMA requires, is one where a developer can distribute iOS apps to users without ever entering into any contractual relationship with Apple.

mjorgers:

All in all, still extremely anti-consumer. If I can download and run arbitrary code on my Mac--even if I have to jump through scary warnings--why should I not be able to do so on my phone? Why would one computing platform be different from the other?

Ben Lovejoy:

However, while Apple hopes it will be allowed to charge these lower commissions, it has admitted in a new regulatory filing that it may not be allowed to charge any commission at all on purchases made through third-party app stores and other external platforms.

Tim Hardwick:

The commission Apple earns from the App Store is shrinking in markets where it has been forced to relax its grip on in-app purchases, based on new analytics data.

Previously:

macOS 26.6.2

Joe Rossignol (release notes, security, no enterprise, no developer, full installer, IPSW):

macOS 26.6.2 delivers security fixes that were first made available in the macOS Golden Gate 27 beta.

Howard Oakley:

There don’t appear to any matching security updates to Sequoia or Sonoma, though.

See also: Mr. Macintosh.

Previously:

iOS 26.6.1 and iPadOS 26.6.1

Joe Rossignol (iOS/iPadOS release notes, security, no enterprise, no developer):

Apple today released iOS 26.6.1, iPadOS 26.6.1, visionOS 26.6.1, and macOS 26.6.2, with all of the updates containing security fixes.

Apple also released iOS 18.7.10 and iPadOS 18.7.10 with security fixes.

The version numbers are now out of sync with macOS because macOS 26.6.1 fixed an important screen sharing vulnerability a few weeks ago.

Juli Clover:

There are fixes for an audio vulnerability that could allow an app to leak sensitive user information, an image vulnerability that could allow for arbitrary code execution, a trio of kernel vulnerabilities, and several WebKit bugs that could cause memory corruption or Safari crashes. Of the 29 CVEs outlined in the document, 21 are WebKit-related, and nine are credited to OpenAI Codex Security.

On iOS, Apple also fixed a telephony bug that could allow an attacker in a privileged network position to bypass IPSec authentication and intercept network traffic.

Previously:

Monday, August 17, 2026

Apple Proposes 15% External Purchase Fee

Juli Clover (AppleInsider):

Apple has again failed to earn a stay for fee calculations in its ongoing legal fight with Epic Games. Apple's case will be heard by the Supreme Court in the term that begins in October, and Apple asked the U.S. District Court for the Northern District of California to pause proceedings until then, but the court said no [PDF].

Juli Clover:

U.S. Supreme Court Justice Elena Kagan today granted Apple a one-day stay in its legal fight with Epic Games, giving Apple more time to outline the fees it wants to charge developers for linking out to purchase options on the web.

M.G. Siegler:

Apple tried to freeze the entire thing while they appealed to the Supreme Court – and the Supreme Court denied the freeze. But they didn’t deny hearing the case – yet. That’s why they’re pausing the proceedings for now (after Judge Gonzalez Rogers denied the same request), while they weigh Apple’s appeal. But before they do that, they’re basically likely to decide today – again, it was just a 24-hour delay – whether they should grant a longer stay. Presumably if the court thinks they’re unlikely to hear Apple’s appeal, they may not grant that longer stay. Or if they think Apple filing their number won’t harm their business, they’ll let it proceed. But Apple will argue that if the longer stay isn’t granted, it will cause major harm to their business because again, it will effectively end the App Store cut as we know it.

Juli Clover (Engadget, The Verge):

Apple today submitted a court-ordered proposal outlining the commission it believes is reasonable to collect from U.S. apps that link to purchase options outside of the App Store.

Apple is asking for half of its commission on standard apps, so apps that would pay 30 percent for an in-app purchase would pay 15 percent when linking to a web purchase option. Small Business Program participants that would normally pay 15 percent would pay 5 percent.

[…]

The appeals court suggested the commission could be limited to the direct costs of facilitating link-outs, and under that approach, the fee would be zero. Apple says a zero commission would not reflect the value that it provides developers, and its suggested commission gives it fair compensation for the App Store platform.

[…]

The district court will now evaluate Apple’s fee proposal and hear a response from Epic Games , and Apple will need to implement the fee the court sets.

Apple:

Unlike cost-only based commissions, Apple’s revenue-based commissions incentivize continued investment. Apple charges developers a $99 annual fee for the Apple Developer Program. May 17, 2021 Trial Tr. at 2762:21–2763:13. This modest fee—designed to prevent fraud and expressly not intended to compensate Apple for the use of its IP-protected tools, technologies, and services (id.)—allows developers to build apps using Apple’s offerings and deliver experiences to iOS and iPadOS users worldwide.

The annual developer fee is nominal. Apple relies on percentage-based commissions to recoup and profit from its investments. See id. ¶¶ 87–93. Apple is incentivized to invest in IP- protected tools, technologies, and services that generate revenue for developers (and benefit users).

[…]

Dr. Carlton explains that “reduc[ing] Apple’s incentive to invest and provide the technology and services that benefit users and developers” would harm users and developers, as well as Apple.

I like the part where Apple’s expert argues that its normal commission rates are so high that it would still be profitable for developers to pay the proposed linking commissions on top of what they would pay to Stripe or Paddle. In other words, paying Apple for “IP” almost twice what it admits the other companies charge for “full-service, turnkey payment processing.”

Jeff Johnson:

If the point [of the $99] is just to prevent fraud, why do we need to keep paying $99 yearly FOREVER? Is 10 years not enough to prove I’m not a fraud?!?

If the fee doesn’t help pay for Apple IP, then it’s even more blatantly unfair that a minority of apps have to pay for ALL apps to access Apple IP. Free apps, no matter how big or how much $ they make via ads, get access to Apple IP from OUR REVENUE CUT, and not even their $99 counts.

Matt Garber:

That’s what that enormous hardware margin from customers is already supposed to be paying for — Apple IP! In the early 00’s, I gladly paid the “Apple tax” (PowerBook G4) to get access to the Mac OS X software/ecosystem, including all the Unix and dev tools. I’m not sure why anyone thinks that double-dipping is fine on all the non-Mac platforms, App Store or not.

Jeff Johnson (2):

Schiller’s [previous] testimony about the previous program is extremely misleading, because the new program began in 2008 at the same time as the App Store, so there was no previous iOS developer program, and Mac Developer ID did not begin until 2012, so Apple Developer Program membership was not actually required to distribute Mac apps!

Jeff Johnson:

Fourth, it appears that Steve Jobs was wrong: the $99 fee didn’t prevent developers from flooding the App Store with a lot of junk.

I want to quote another remarkable passage from Schiller’s testimony, again with questions from Apple’s own lawyer.

Q. And Mr. Jobs says, “And also just to make it a little clearer, we don’t intend to make money off the App Store. I mean, we don’t make a lot of money off iTunes, and the split with the music companies is about the same, so in the case of the iTunes Music Store, we give all the money to the content owners, and we are basically giving all the money to the developers here. And if that 30 percent of it pays for running the store, well, that will be great, but we just want to create a very efficient channel for these developers to reach every single iPhone user.” Is that a statement that Mr. Jobs made back in March 2008?

A. He did.

[…]

I won’t quote the following passage in which Schiller testifies about his internal email suggesting that Apple limit itself to $1 billion per year in profit from the App Store, hand-waving away the suggestion as merely “spurring conversation.” Of course the email also seems to contradict Schiller’s (absurd) testimony that Apple does not specifically calculate profit from the App Store, only company-wide profit. Apple’s public financial statements also appear to contradict Schiller’s claims.

Previously:

Zoom Screen Sharing Attack

Lily Hay Newman (via Ben Lovejoy):

As AI models gain advanced capabilities to find vulnerabilities in software, develop ways to exploit them, and even carry out autonomous hacking sprees, researchers offered a sobering new example on Tuesday, disclosing vulnerabilities in the video conferencing platform Zoom that could have been exploited to take over targets’ devices. Anyone on a call that involved screen sharing, whether participants or the host, would have been vulnerable to a silent attack that could be carried out with no indication and no interaction from the victim.

Researchers from the digital defense firm A Security say the bug was discovered in early June using publicly available AI models, and that it took fewer than 20 prompts to uncover the vulnerabilities and create a working attack. Zoom issued a security advisory on Tuesday, including details about fixes the company has already begun rolling out to address the flaws, which affected devices running all operating systems that Zoom supports—Windows, macOS, Linux, iOS, and Android.

[…]

The vulnerabilities were specifically in the protocol used to facilitate real-time annotation during screen sharing.

I don’t understand how it could take over an iOS device when Zoom’s iOS screen sharing feature only allows observation, not control.

Previously:

Friday, August 14, 2026

TabControl Scam and the App Review Queue

Jeff Johnson:

Despite my history of uncovering App Store frauds, I rarely go looking for these things intentionally! They’re just so pervasive and obvious, they jump out at me. In this case, I was looking at the list of top paid Safari extensions in the Mac App Store, because two of my own extensions are currently on the list, when I noticed the TabControl Extension.

[…]

The Mac App Store “screenshot” for the app is not actually a screenshot at all. If you look closely, that’s not the real Safari: the toolbar elements are wrong. I suspect that the image was AI-generated.

[…]

Another thing you should note in the fake screenshot is the “4.9 out of 5” stars, giving the impression that this is the App Store user rating of the app.

[…]

These purported reviews, all but one of which is 5 stars, are all in English. Yet none of them is in the US App Store. […] If you’ve ever looked through App Store user reviews, it’s unusual to find this naming format. […] the dates on the reviews, such as “Mar 12,” predate the release of TabControl Extension in the App Store!

John Gruber:

God only knows what this obvious AI slop scam is doing with the data from users’ Safari tabs. It’s currently the 12th or 13th most popular Safari extension in the App Store.

Jeff Johnson:

Coincidentally, on the same day well-known developer Marco Arment complained on social media that his new, unreleased Mac App Store app had been waiting 12 days for review by Apple.

Arment ended up waiting on hold—listening to an odd choice of music—to talk to App Review, which I didn’t realize was an option. His Unforgetful app is now approved.

Johnson continued browsing Safari extensions in the store:

The apps’s privacy policy is again on Google Drive, but the developer website link goes to https://aee5e5015.app-ads-txt.com, a suspicious URL. This website is barren and simply redirects back to the App Store[…] Did App Store review ever bother to click the developer website link?

[…]

In addition to the 41 apps, each of which required at least one submission to App Store review, I count across those 41 apps at least 327 updates, almost all of which have the same generic description for what’s new in the update: "Bug fixes and performance improvements." So that’s at least 368 submissions to App Store review, most within the past 12 months, from a single developer. In other words, the developer is averaging almost one submission per day. We can count only approved submissions; we have no idea how many submissions by the developer were privately rejected by App Store review.

I get the impression that Apple is asleep at the wheel. Is anyone at Apple counting submissions per developer? How many is too many? How many resources is one developer allowed to consume?

[…]

You may view it as a noble, democratic ideal to treat every app developer the same, but in reality this is the path to the crApp Store, full of scams and slop.

John Voorhees:

There’s no doubt that there is spam on the App Store, but the way to remove it is to target the spammers, not new developers, students, and hobbyists looking to build their ideas. I know that being an indie developer isn’t an easy way to make a living, but erecting barriers to submitting apps is the surest way to starve Apple platforms of fresh, innovative ideas.

John Voorhees:

I’d like to see App Store spam cleaned up as much as anyone, but the way to do it isn’t preferring well-known developers and those who can afford to pay more for special treatment.

Marc Palmer:

I don’t agree with paid tiers either. However it feels like there should be a natural brake applied to new developers and new apps. It’s no big deal if your first app takes a week or two to review (often did 10y ago), and as it matures & receives meaningful updates in the store, turnaround increases as trust and “value” (active users?) builds up. Like “tarpitting” new accounts. I think limiting the # of new apps you can add per month to say 1 or 2 would also help…

Jeff Johnson:

I was a new App Store developer myself ten years ago. My previous article didn’t propose any new barriers for those groups. To be clear, I did imply that no developer, whether new or not, should have more than 40 apps and average a new App Store submission every day of the year. I’m not aware of any prominent developer who has that many. Apparently, checking just now, Microsoft by my count has 38 App Store apps between iOS and Mac, which is a lot but still less than the 41 apps of the developer I discussed in my previous article who is definitely not one of the largest software developers in the world along with Microsoft. I do think it’s reasonable for Microsoft to pay a significantly higher developer fee to have those 38 apps reviewed than a smaller developer pays to have one app reviewed by Apple.

[…]

My contention is that Apple is actually wasting its own resources treating every developer like a potential spammer or scammer, even the developers who are known to be trustworthy, and this wasting of resources makes it harder on everyone, including new developers, students, and hobbyists. App review is grossly inefficient, and it’s clearly failing to scale to the increase in App Store submissions. What I propose is not raising the gates but rather lowering the gates for developers who have already proven trustworthy, so that Apple can focus its review efforts where they’re most needed.

I’m not sure that paying more would help anything. If scams are profitable, surely it would be worth them paying more, and then we’re back to square one. And I don’t want to create another situation like App Store Search Ads where providing poor service makes the revenue numbers go up. But I like the general idea of considering the account’s history, e.g. the way the Discourse forum gradually increases trust over time. It should count for something if you have a long history of following the rules and submitting updates to a small number of apps on a reasonable schedule vs. frequent spamming of submissions that don’t even have real release notes. It would not be fair for Microsoft to be able to cut in line, but giving spammers equal access to the review queue means they’ll use more than their share of Apple’s resources. That also seems unfair. The current system encourages frequent submissions, which also increases the overall load on the reviewers. I think the incentives need to be changed somehow. Maybe each account should get a certain number of “fast” submissions per month or year, after which you can still submit but it goes into a lower priority queue.

William Gallagher:

Even among more legitimate-seeming apps, though, Apple is ignoring clear problems. In AppleInsider research, for instance, we found that many price tiers listed for the “Simply Piano” app bore no relation to what the developer actually charges.

[…]

You shouldn’t have to be the one to investigate apps you want to try. That is the future of third-party App Stores, and that is a future to be fought.

But that future is here with the first-party App Store we already have. And this inability to trust an App Store is here, right now, because Apple will not do what it keeps saying it is doing and what it is charging developers to do.

Previously:

SQLite WAL-Reset Bug

Alex Chan (Hacker News):

Many of these outages were caused by a single bug, deep in SQLite. It took months of intense forensics to track it down.

[…]

This lack of reliable trigger conditions meant we couldn’t reproduce the bug synthetically. Instead, we had to rely on deploying passive, forensic telemetry in our live environment to catch the corruption red-handed. Gathering live diagnostics for a database issue is the last thing we wanted to do, but we had no choice.

[…]

As an additional complication, the corruption didn’t occur on a regular schedule. Sometimes incidents would be hours apart, other times weeks. This made it difficult to predict progress or plan further work, because we were never sure when we’d get our next diagnostic dump. We had a six-week period between October and December when there were no corruption incidents, before they returned as an unwelcome Christmas present.

[…]

In two incidents, our transaction logs failed to replay cleanly. Upon closer inspection, we discovered that data written and committed by one transaction was inexplicably invisible to later transactions. A write had vanished into thin air without raising an error.

SQLite:

The bug is likely present in all version of SQLite from 3.7.0 (2010-07-21) through 3.51.2 (2026-01-09). It is fixed in version 3.51.3 (2026-03-13) and later. Backports of the fix are available for some earlier releases: 3.44.6 and 3.50.7.

The bug only affects databases in WAL mode when there are two or more database connections open on the same file, in separate threads or processes, and when those two connections attempt to write or checkpoint at the same instant.

Alex Chan:

This investigation is a useful reminder: running boring technology in a non-standard way is a risk. The common paths and standard configurations are incredibly well-tested and reliable. Most people use SQLite in a standard configuration and never face this sort of issue. Everything we were doing was a public, documented, supported configuration—but by taking manual control of the checkpointing process and running at our own aggressive pace, we stepped off the well-trodden operational path.

Scott Perry:

I spent the last two years of my time working on SQLite trying to chase this bug down. It was so rare that I never got an internal report; my assessment of the number of customers affected was “about a county’s worth”, some of whom were generous enough to allow their local Genius Bar to send me backups of the affected databases. I spent so many hours in a hex editor staring at the wreckage.

Top three data corruption bug of my career for sure, and the other two weren’t bugs in SQLite.

A former Tailscale employee got in touch and shared that they were checkpointing these databases every 250ms. Multiplied across a fleet of servers that is a fantastic way to surface a super rare bug—they basically built our test rack as a product, but two orders of magnitude more effective (partially due to scale, but mostly because our rack also panics devices at random in order to test the filesystem, NAND controller, etc. and rebooting takes a while)

[…]

13/10 fantastic bug. proof that 100% test coverage is a good start, and that formal methods are needed for critical applications.

Carl Sverre (Hacker News):

I whipped out my phone, and asked Claude to get to work. I had it get SQL 3.51.2 – still buggy – set up in Antithesis, and then instrument the code with a bunch of Antithesis assertions. You can see the instrumented version here.

Then I asked it to write a simple workload which exercised the WAL insert and checkpoint code. Notably, this is a completely generic workload. It just runs writes and checkpoints concurrently – things you’d expect to actually happen in production, all the time. The assertions are also generic to the bug, they’re all standard assertions you’d add to any database, things like “no lost committed writes” and “database is not corrupt” (called integrity check in sqlite).

On my first run, Antithesis caught the bug in 15 mins. Here’s the report.

Of course, it helps that he knew to look in the checkpoint code, but you could imagine using tools like this to quickly investigate hypotheses when you don’t already know the answer.

Thursday, August 13, 2026

SuperDuper 4

Dave Nanian:

The new version of SuperDuper is a ground-up rewrite, a tip-to-tail reinvention of what SuperDuper looks like, how it works, what it can do, and where I can take it in the future.

[…]

Documents have been retired and replaced with Copy Jobs, which are stored internally and organized by source. If you want to copy Macintosh HD, that’s where you start. Click, and you’re presented with one or more template copy operations, or you can start from scratch.

Configuration is done right inline by clicking bold, underlined link elements and selecting options from pop-ups. The effect of your choices is immediately reflected in What’s going to happen?, ensuring you know what to expect when you click Copy Now.

SuperDuper has been around for 22 years, and I’ve been using it since version 2 in 2006. Shirt Pocket had always been great about keeping the copy engine up-to-date with all the changes in macOS and its increasingly baroque file system structures. But the outward appearance of the app hadn’t changed much, aside from losing the brushed metal, and neither had the feature set. I know all too well how much work it can be as a solo developer just to keep an app working. Ironically, the better you are at adapting to the changing OS, hiding the complexity, and presenting a simple interface, the more it looks like you aren’t doing much. Actually, if you follow Nanian’s blog, you can see a fraction of all the stuff going on under the hood—tricky edge cases, macOS bugs, and undocumented behaviors that must be handled so that you can essentially just press a button and get a proper bootable backup.

Eventually, he found the time to rewrite the app, both the engine (which is faster and more robust) and the user interface (which is greatly expanded). My first reaction was: this is SwiftUI, isn’t it? And it is. You can just tell by the way the text reflows, all the different colored buttons and blobs, the hover effects, and how the design heavily emphasizes scrolling. (Like System Settings, it doesn’t remember scroll positions. Nor does it remember which disclosure triangles are expanded.) The keyboard navigation and focus behavior are off in places. For reasons I don’t understand, SwiftUI gets a lot of this wrong out of the box. In some cases, like the outline view for creating a copy rule, keyboard support was manually added and works as expected. But there are other places where arrow keys and type-selection don’t work. Sometimes I need extra clicks to get the proper focus. Sometimes the arrow keys scroll the window instead of changing the selection.

That said, this is one of the best SwiftUI interfaces I’ve seen. I think it successfully preserves the spirit of the app, making it really easy to configure things and see what’s going to happen, while streamlining the way documents/jobs are managed and expanding what you can do. It’s still essentially one window (plus a Settings with one checkbox), and you can still use it in the old way, but now you can also run multiple jobs at once and inspect their histories.

Click the Preview button and SuperDuper will run the copy without making changes and present you with a report that shows exactly what would have been updated, added, deleted, etc., had this been a real run.

This is great to have. If there are particular folders or files you want to check, you can browse the source tab of the preview to see what’s excluded or find them in the destination tab to see whether they would be added, updated, removed, or kept. The interface to browse this is a sort of columns view with only one column. It’s fast and easy enough to use, but keyboard navigation doesn’t work properly. I longed for it to be an outline view so that I could quickly expand an entire subtree and see at a glance which files would be changed. I also wished that it would show how much data would be copied.

SuperDuper 4 is much faster than before. And I’m not just talking 20% or 30% faster. Smart Updates are between 2x and, with the new Turbo feature, an order of magnitude faster.

It’s hard to benchmark such things, but my general impression is that this is true. The longstanding Smart Update feature copies only the files that have changed. This seems quite a bit faster than before and slightly faster than Carbon Copy Cloner. The new Turbo feature uses the FSEvents log to optimize finding such files. If macOS knows which folders might contain changes, SuperDuper can focus on those and not waste time scanning ones that are identical. When this works, it feels almost impossibly fast. SSD-to-SSD backups of my Mac’s boot drive will take 1–3 minutes instead of more like 20 minutes. This also seems to be faster than Carbon Copy Cloner’s similar Quick Update feature.

Unfortunately, for reasons seemingly out of the app’s control, sometimes Turbo isn’t possible. This can happen if you’ve modified the copy job or if there’s been a huge amount of file system activity since the last backup so that FSEvents doesn’t contain the necessary information. In such cases, SuperDuper will fall back on doing an old-school Smart Update. I found that excluding my destination drive from Spotlight made it much more likely that Turbo would work.

As much as I like Turbo, I don’t end up using it except for the daily scheduled backup of my boot drive to an always-connected SSD. For my other backups, I have multiple destination drives for each source, and I find that the user interface doesn’t scale so well to configuring a separate job for each. That leads to lots of scrolling. So, instead, I use just one job per source and select the destination I want before starting each backup. This counts as editing the job, so it won’t be able to Turbo, but I find that backups to slow spinning hard drives take a long time either way and are dominated by the copying speed rather than the scanning speed.

Successful and failed runs are shown at the bottom of the copy job, with color-coded dots that can be clicked to display details.

This is my favorite bit of interface design in the new version. It very compactly shows you the recent history for that copy job using the same format that’s used for showing the completion status of the most recent run. I can quickly see all the information I usually care about, and you can click a button to see more detailed information if necessary. The downside is that you can’t see as much information at once—or across multiple jobs—as if there were a dedicated log window, and it only shows the most recent 7 runs. But I think this tradeoff is well in keeping with the app’s spirit of making things simple and clear rather than offering every possible option.

The most baffling part of the interface is that after each backup completes or fails it shows an “Apple Intelligence Summary”. Much space is devoted to labeling this and to assuring you that none of your data went into the cloud. I just don’t see what the point of this is. 99+% of the time, my backup either succeeded or failed for a very predictable reason like running out of space. Why do we need AI for this? I trust the AI summary less than I would a hard-coded string from the developer. Perhaps in an obscure situation that the developer didn’t anticipate Apple Intelligence would be able to offer a useful interpretation, but I have yet to see that.

At a technical level, SuperDuper has been split into a “helper” or “server”, which runs the copy, and an interface, which is the part you interact with. That means that, once registered, you can quit the SuperDuper application and your backups will still run. They’ll even run if you log out!

It doesn’t much matter to me that it can back up without launching the app—I like to see its progress—but I appreciate the new architecture for scheduled copies. Schedules are now much better integrated into the app proper rather than being driven through AppleScript.

You can run any number of copies at the same time. If you have four backups you need to do, just click Copy Now for each, and they’ll all run simultaneously.

This is the most important new feature for me. I used to do all my clone backups with SuperDuper. But, over years, my backup needs grew. I now have five main source drives to back up. They are much larger than before, and APFS on spinning hard drives is really slow. Thus, the backups, even with Smart Update, can take a long time. That was a lot to manage with old versions of SuperDuper. Carbon Copy Cloner has long supported multiple simultaneous backups so that I could connect a bunch of destination drives, tell it to start, and when I came back they’d all be done. I didn’t have to be there to wait for each backup to finish and then start the next.

It was just so much easier, so I started using Carbon Copy Cloner for most of my backups. But I still liked SuperDuper and trusted its copy engine, so I continued to use it to do some of the backups of my most important drive (the internal SSD). I think it’s good backup practice to have redundancies, not just in terms of multiple physical drives and storage locations but also for the software creating the backups. Both are quality apps, but it’s possible that there’s a bug or a misconfiguration on my part that might prevent the copying of a file that I need. Why put all my eggs in one basket? Now that SuperDuper also supports multiple simultaneous backups, I’m using it for half the backups of all my drives. On one backup day I’ll do all SuperDuper backups, then the next time I’ll do all Carbon Copy Cloner backups. (I continue to use Time Machine and Arq for additional redundancy.)

If you try this, I strongly recommend writing down which app you used for each destination drive and then doing all future backups to that drive using that same app. And it works better to do the first SuperDuper backup with Erase and Copy rather than trying to Smart Update a Carbon Copy Cloner backup.

There are a variety of reasons for this, but the main one is the different ways that the apps deal with APFS snapshots. Both use snapshots on the source to ensure they’re copying from a consistent state. And both mark completed copies with snapshots on the destination. But the retention of the destination snapshots is very different.

Carbon Copy Cloner can keep them around essentially as long as you have enough free space. It can also prune them out of order, so that you have daily snapshots for the last month and weekly ones going back further. This is managed by the app, though you can also manually delete snapshots yourself using Disk Utility.

SuperDuper’s snapshots are automatically managed by the macOS. I’m personally less fond of this design because in practice the system will choose to clean up old snapshots almost right away. I can’t count on being able to restore from any backup but the most recent. To me, this is a shame because APFS supports multiple snapshots, and there’s plenty of space on the drive to store them, but I can’t use them. It’s just not a design goal of the app.

Again, this ties back to how SuperDuper values simplicity. If it made longer-lived snapshots that weren’t cleaned up automatically, you might get into a situation where you (or another app) wanted to add files to a drive and couldn’t because it seemed to be full. You’d have to understand snapshots or have an app that could delete the SuperDuper snapshots to free up space. Third-party apps aren’t supposed to delete snapshots belonging to other apps, which is why you don’t want to mix SuperDuper and Carbon Copy Cloner on the same destination. If the former needs more space to complete a backup, it won’t be able to purge snapshots created by the latter.

The status information for the backups that are in progress is shown right in the Sources section of the main window. You can see at a glance which drives are being copied and when they’re all estimated to finish. I haven’t found the estimates very accurate, so I’d prefer to see the start time and the percent complete. Flipping between multiple active jobs to check their detailed progress is kind of a chore, but if all you need is the summary information you can close the app and monitor it from the new menu bar icon.

SuperDuper 4 now supports copying to and from any file system the Mac supports. Using a “Photos” drive with both Windows and Mac that’s formatted as exFAT? No problem: you can copy it.

It can also copy individual folders rather than just entire volumes, if you drag them into the sidebar.

I’ve added Shortcuts support, so you can create a shortcut that runs before or after a copy, on success, or on error. Want to send an email on success or failure? Beep when copies are done?

[…]

Not only does SuperDuper let you call a shortcut from a copy—you can create, run, and check on a copy job from a shortcut!

There’s a lot of potential here, and the completion shortcut receives a bunch of JSON describing what happened so that it can make decisions about what to do. On the other hand, I would rather see AppleScript support, as I find Shortcuts confusing and inconvenient. I wish that common completion actions like sending e-mails were built into the app so that they were easier to set up. (You can choose to eject the drive, post a notification, or sleep the Mac without having to write a shortcut.)

In all the years SuperDuper has been on the market, we’ve never charged for updates and never even raised the price. That’s 22 years of free updates.

The Apple Silicon version was a paid upgrade, but you could run SuperDuper 3 in Rosetta with an old license and still get all the features.

Version 4 costs $43.95, with various upgrade discounts based on the purchase date. There’s no discount if you purchased before July 2020, but us old timers got so many years of free updates it was one of the best deals ever in Mac software. Regardless, it’s not a high price for peace of mind. The new version is, I think, a massive improvement, maintaining the spirit of the original while modernizing and expanding it.

I’ve already said that I use both SuperDuper and Carbon Copy Cloner. I think both are excellent—great apps with great customer support. With SuperDuper 4 they’re more similar than in the past, but they remain very different. If you must pick one, I would say that Carbon Copy Cloner is better if you want lots of options and control; if you want persistent snapshots, verification, copying of cloud-only files, or detailed logging; or if you have a very large number of backups. (It does have a Simple Mode, but it’s arguably too simple and limiting.)

SuperDuper is better if you care about bootable backups or want something simple but not too simple. There’s documentation, but you probably won’t need it because so much is explained within the app’s interface. It’s just really easy to set up a backup, see what it’s going to do, see what it’s currently doing, and see what it did before. Pretty much everything happens in a single window, without tabs or separate modes. SuperDuper is all about striking a good balance for most people, doing the right thing with a minimum of fuss.

See also: Adam Engst and Accidental Tech Podcast.

Previously:

Update (2026-08-14): The developer wrote in to say that SuperDuper does try to remember the scroll position in the main window, just not across launches. With the current version, 4.0.2, I find that this mostly works but that it gets thrown off if I’ve expanded any of the triangles to see more details about the currently running job. Then my carefully positioned view will be shifted a bit when I come back to it. It’s hard to get this exactly right.

He also had a great tip about a hidden feature that can relieve some of the scrolling issues I encountered: you can click multiple times on a drive in the list of sources to have it jump to the next active job for that drive, scrolling it to exactly the right spot. When the sidebar has keyboard focus, you can also do this by pressing the Spacebar.

See also: Dan Moren.

Tuesday, August 11, 2026

How Claude Marks AI-Generated Content

Thomas Claburn:

Anthropic will embed watermarks in the text and files generated by future models it launches in the EU, as part of its effort to comply with content and transparency rules in the bloc’s AI Act.

[…]

The move may further amplify the appeal of open weight models and alienate Claude customers, who don’t necessarily want consumers of their AI-generated content to know its provenance.

[…]

Anthropic itself is already hedging about the utility of its marking method, noting that detected marks are not conclusive evidence that Claude produced the content and that the absence of marks cannot guarantee that AI wasn’t involved in the creation of a particular piece of content.

Anthropic (Hacker News):

Claude models launched in the EU on or after August 2, 2026 will support machine-readable marking at launch. Generated text will carry embedded watermarks, and generated files will include digitally signed provenance metadata where supported.

[…]

Marks will apply to output from supported Claude models across Claude Platform (API), Claude, Claude Code, Claude Cowork, and Claude Tag, and wherever Claude is offered, worldwide. Some platforms or features may not support certain marking types.

[…]

We’ll support users and other third parties to detect Claude’s marks, as the Code requires, and we’ll share details in forthcoming documentation.

John Gruber:

Anthropic is claiming this is for compliance with an EU law but that “Marking will apply to output from supported models wherever Claude is offered, worldwide.”

This is infuriatingly opaque. I won’t speak to the “signed provenance metadata” they say they’ll be embedding in generated files like PDFs, SVGs, PNGs, and JPEGs. That’s important but it’s complex. Plain text is simple. A string of text is just one character followed by another. I presume that Claude is going to start “embedding” invisible characters/byte sequences between visible characters? What they’re claiming to do here seems impossible, frankly, and anything they attempt to embed invisibly is going to cause immediate problems.

[…]

If the “watermark” is not comprised of invisible characters but rather visible ones, how in the world does this jibe with their claim that it’s “imperceptible”? (This Reddit thread claims that’s how it will work — “It’s a form of steganography where the model subtly biases its word choice to create a statistical pattern that can be detected later.” How in the world can that be squared with “it doesn’t change the meaning, quality, or readability”?) And any sort of semantic detection like this is going to cause false-positive problems.

Previously:

Update (2026-08-17): Anthropic provides more details:

Watermarking won’t be specific to Claude. As of August 2, the EU requires AI providers serving its market to mark AI-generated content. Other major model developers have signed the same Code of Practice and will be implementing their own watermarks.

[…]

In internal testing, we’ve seen no impact of watermarking on the content, level of creativity, or readability of Claude’s text. In the SynthID-Text paper, which introduced the technique we use, Google DeepMind tested this impact by serving a model that used watermarking to a portion of their Gemini traffic and comparing thumbs-up and thumbs-down ratings. They found no statistically significant differences from the unwatermarked model. And in a controlled study, human raters comparing watermarked and unwatermarked answers side-by-side saw no difference in quality.

[…]

There are limitations to the effectiveness of watermarking. Using our key, one can only answer the question “What is the likelihood this was partly written by Claude?” It doesn’t confirm whether the text was human-written, and it can’t tell whether the text was written by a different AI (even if that other AI uses watermarking, it would have a different key; it might also use a different watermarking method altogether). Detecting a watermark also doesn’t work well on small samples, where there are fewer word choices and thus less information to go on. As a passage increases in length, confidence about Claude’s involvement increases too.

Watermarking is sparser on factual passages where there are fewer choices that can be made without decreasing the accuracy of the text. […] For the same reason, code—which in very many cases has to be exact—has generally less watermarking than some other forms of text.

John Gruber (Mastodon, Bluesky, Hacker News):

I initially guessed “invisible characters” not because I didn’t think of the semantic word-choice technique, but because I was a fool who took Anthropic at its word in their description of what they would do.

[…]

They say “imperceptible” and “doesn’t change the meaning, quality, or readability”. Their words. Not almost imperceptible. Not slightly changes the meaning, quality, or readability.

There seems to be a slight of hand here, where Google studied whether humans saw a difference in quality but then Anthropic claimed that there was no difference in meaning. Changing words will almost always change the meaning. Perhaps not in an important way, but a change is a change. Pretending otherwise is offensive to a writer. The response to this line of argument seems to be that LLMs already have randomness and that the marking changes will be within the level noise that’s already there. To me, this presents a pessimistic view of the capabilities of LLMs, contrary to Anthropic’s normal claims. The Google study was published in 2024 and didn’t test Claude. The models have changed a lot since then, but they are assuming that the precision hasn’t advanced enough to be affected, nor will it in the future. Or that when there is a tension between watermarking and quality they will pick the former. And perhaps you won’t be able to tell because everyone else will be watermarking, too.

But the very best description of the general idea behind the technique is an interactive essay by James Padolsey, “How AI Text Watermarking Works”.

[…]

This isn’t just about text one might generate with the intention of passing it off as their own natural work. This isn’t even about LLM proofreading of work written by hand. Anthropic is saying that all new Claude models are going to adulterate every single bit of text longer than 200 tokens (~150 words) they generate, including everything it presents to its users to read. So even in a private conversation between a user and Claude, which will never be read by anyone other than the user, Claude will begin making word choices in the name of marking its output in statistically predictable ways rather than maximizing clarity and precision.

[…]

Taken literally, compliant LLM terms of service must forbid users from rephrasing the output from models that comply with this regulation, because the word choices are the marks. But it’s not the European Union that is trying to impose their absurd, impractical, witch-hunt-fueling regulation on the entire world. That falls on Anthropic.

Complying with this, particularly with regard to text, is only going to create problems for honest users. Dishonest users attempting to pass off AI-generated text as their own writing (students, employees, whoever) will simply circumvent detection through non-compliant AI paraphrasing tools.

I don’t love that checking for a watermark requires submitting the text to the AI provider, and all you get back is an opaque result with no way to verify it.

James Padolsey (via John Gruber):

The move is Anthropic’s response to Article 50(2) of the EU AI Act, which requires providers to ensure that outputs are “marked in a machine-readable format and detectable as artificially generated or manipulated”.

[…]

The Act exempts standard editing, but many legitimate assistive uses require more substantial rewriting while leaving the ideas, judgment and responsibility with the human. The same thought that led to this law could have applied to calculators at the time of their inception, had their outputs revealed themselves through artefacts. Thankfully, a sum borne of the brain is treated no differently from one produced by a calculator. Likewise with spellcheckers. To make assistance suspect only once the tool becomes capable enough to compose a whole sentence is not a principled boundary. It is a moral premium placed on difficulty itself.

Anthropic has nevertheless chosen a blanket, model-level implementation that appears broader than the law’s minimum requirement. That may be convenient compliance engineering, but it discards distinctions the law expressly attempted to preserve. The result is a signal broad enough to implicate harmless and assistive use, yet fragile enough to be removed by a motivated person through substantial recomposition. It risks concentrating suspicion on ordinary and assistive users while remaining weakest against deliberate deception.

Xbox Outage Affected Discs

Jay Peters:

An extended Xbox outage that began Sunday evening didn’t just cause issues for people trying to play digital games — it blocked people from playing their disc-based games, too.

Xbox’s status page initially reported the outage on Sunday at about 11PM ET, and it also prevented people from logging in, launching apps, or finding games on the Xbox store. This morning, the page also noted that users “may have problems” playing their digital and disc games, which posts on social media confirmed. During that time, my colleague Richard Lawler was able to launch digital games he owned, but trying to boot up games tied to Game Pass popped up error code 0x87e107df, indicating the license couldn’t be verified.

Matt Birchler (Hacker News):

When Sony announced that they were discontinuing physical discs for PlayStation, I was less outraged than many. The reason I felt this way wasn’t because I loved what Sony was doing. I think it came from an understanding that physical media ain’t what it used to be.

[…]

It’s still just a license, and Microsoft, Sony, and Nintendo can either intentionally or, in this case, unintentionally prevent you from playing that game, even if you own the physical copy. This isn’t even to mention the fact that when you pop the disc in your drive, you’re not playing from the disc. It’s installing it to your internal hard drive and is probably installing a bunch of updates that are required to make the game actually work at all.

Kyle Orland:

For years now, the testers at DoesItPlay have been documenting this trend, testing thousands of physical game releases to see which ones live up to the promise of full “plug and play” functionality without an Internet connection. Thus far, a full 27 percent of the physical releases they’ve tested require some sort of download to fix game-breaking bugs or obtain core game content that is not stored on the physical release itself. That ratio balloons to 34 percent for tested PS5 games and 50 percent for those on the Xbox Series X.

Previously:

Sony Removing Purchased Content

Cindy Harper (Hacker News, ArsTechnica):

Sony plans to wipe 551 movies and TV shows from the PlayStation Store libraries of customers who paid full price for them. The deletion is coming on September 1 and so far the company has said nothing about giving anyone their money back.

[…]

Anyone who hit “buy” on one of them will open their library that morning and find a hole where it used to be. PlayStation’s notice states it without apology: “You will no longer be able to access your previously purchased content from Studio Canal, and it will be removed from your video library.”

The justification Sony offers runs to six words, “due to our content licensing agreements.”

You might try to avoid this problem by purchasing physical discs, but movies and TV shows no longer always make it to that medium. And the same will be true for games.

Sid Shuman (via Nick Heer):

As consumer preferences and the broader entertainment industry continue to shift away from physical discs to digital, physical game disc production for all new games releasing on PlayStation consoles will be discontinued starting January 2028. Following this date, new games will be available on PlayStation Store and at retailers in digital formats only.

Timothy Geigner (Hacker News):

In all of our discussions about how the digital revolution has created a system in which people don’t actually own the things they think they’re buying, I get particularly frustrated by the lack of change in it all. We’ve spilled much ink complaining that this clearly anti-consumer practice needs to be done away with, where an unsuspecting public thinks they’re buying “a thing” only to learn months or years later that “the thing” they bought was actually a license to use/view/listen to another “thing”, and that license exists at the pleasure of the company that collected the money for it.

[…]

As Kotaku notes later in their post, part of what is striking in all of this is the sheer mundanity of the announcement. Because there have been no consequences, or any action at all from the public or government, Sony treats this all as if it’s perfectly normal and no big deal. You can tell me all you want about how the Ts and Cs in these purchases do in fact note that the nature of the purchase is a temporary licensing of the content for an undetermined time period… but I can promise you that the public in general doesn’t understand that. They think they’re buying a thing, not a license.

And that’s because of the purposeful obfuscation of that fact.

Kyle Orland:

Sony’s recent decision to stop producing physical PlayStation games in the near future has naturally led to a renewed focus and appreciation for physical games that can be played just by sticking a cartridge or disc in a console. But an increasing number of those “physical” games these days still require additional downloads from a centralized server to function as intended.

Previously:

Microsoft Account With Files, Photos, and Games Almost Lost

Joshua Khane (Hacker News):

Microsoft DELETED my account AND OneDrive!!?? After ACKNOWLEDGING that I’m the owner of the account and that it was compromised???

25 fucking years of data, thousands of euros spended on games?? My son’s baby pictures? GONE!

Scott:

This is EXACTLY why cloud providers should be building (and might need to FORCED to, via consumer protection regulation) access for other online backup services into their solutions INHERENTLY. Apple… are you paying attention?

That One Guy:

Honestly they could recover it, they choose not to because they dont give a shit about their user base.

XBOX Support:

We’re sorry this happened, it’s not the experience we want anyone to have when their account is compromised. We have been working to restore access to your purchases and reached out with the next steps.

Running to the press works.

Previously:

Monday, August 10, 2026

WebKit IP and DNS Leaks Affecting Proxies and Private Relay

Talal Haj Bakry and Tommy Mysk (Mastodon, Hacker News, MacRumors, Mac Power Users):

WebKit-based browsers on iOS and macOS can be configured to route all web traffic through proxy servers, which is how Tor browsers on iOS and our own Psylo work. We found three WebKit features — DNS prefetching, WebAuthn Related Origin Requests, and WebTransport — that bypass the configured proxy and send traffic directly from the device, which exposes the user’s real network. The same leaks also affect Apple’s iCloud Private Relay.

[…]

It must be noted that VPNs are not affected, since they tunnel the device’s entire network traffic at the system level.

[…]

We’ve addressed all three leaks in Psylo 1.3.1[…] Passkeys and WebTransport have legitimate uses, so both can be re-enabled at any time through per-silo toggles. This keeps Psylo leak-free out of the box, while users who need one of these features on a given site can opt in explicitly, with a clear understanding of the trade-off.

Psylo:

In an ideal world, we’d report the issues to Apple, they acknowledge the issue, and ship a fix in a timely manner. Unfortunately, our past experience with Apple tells us that reporting this issue would involve months of delays, inconsistent communication, and in some cases, denying the issue’s impact entirely.

We weren’t willing to wait months, or upwards of a year, sitting on bugs that undermine the core privacy guarantees of Psylo and iOS Tor browsers while saying or doing nothing.

[…]

Should we knowingly leave our users exposed while waiting for a system-level fix? We didn’t think that was acceptable or fair to our users. Or should we quietly ship our own mitigations without telling anyone? We didn’t think that was acceptable either. Security fixes deserve transparency, especially when they involve tradeoffs.

Psylo:

Soon after we published the blog, we sent a link to the blog and demo website to Apple in a security report to make them aware of it. Now the report is already in the status “We’re planning to address the issue you reported.” and a fix is planned for Fall 2026 🤯🤯🤯

Mysk:

It used to take months and months to reach this status. We got there in less than 24h

Running to the press always helps…

Previously:

Update (2026-08-11): Ben Lovejoy (MacRumors):

A class action lawsuit accusing Apple of false advertising, misrepresentation, and fraud has now been filed by Clarkson Law Firm – the same lawyers who previously obtained a $250M settlement over the delayed launch of Siri AI.

Hughesnet Bankruptcy

Michael Kan:

US satellite internet provider Hughesnet has filed for Chapter 11 bankruptcy after running low on cash and losing subscribers to Starlink.

Hughes Network Systems filed in a US bankruptcy court on Sunday, but the company notes it’ll continue serving its satellite internet customers during the restructuring period.

I used Hughesnet before DSL was available. The company was really annoying to deal with, and the dish was finicky, but the service was much better than using a dial-up modem.

Previously:

Friday, August 7, 2026

Dark Hours Rejected From the App Store

[Update: See the retraction below.]

Terry Godier:

On the web, if I build something that works within the standards, it works. Whether people use it is up to them. On iOS, there is another question entirely: whether Apple decides it should exist.

[…]

In the past couple of years I’ve built three apps that were rejected from the App Store on various grounds.

[…]

A while ago I tried to submit an iOS app for Dark Hours, my astronomy website for normal people. It was rejected on the grounds that it was astrology.

[…]

I see countless ChatGPT wrappers with nearly identical icons and eye-watering subscriptions. I see astronomy apps requesting permissions that have nothing to do with looking at the night sky. My kids download games that interrupt play every few minutes to advertise the developer’s other subscription apps, each with their own $20–50 yearly plans.

Via John Gruber (Mastodon, Hacker News):

But if you actually look at Godier’s Dark Hours, for even just a few seconds, it is instantly obvious that it pertains to the science of astronomy and has absolutely nothing — zero, zilch, nada — to do with astrology.

[…]

Godier proceeded through a series of escalations up to the App Review Board and the Review Board responded that they determined the original rejection was valid because, I shit you not, “We understand that the app includes a live tarot reading feature.” Which isn’t even about astrology. It’s straight out of Kafka.

[…]

This isn’t just contrary to the benefit of developers, like Godier. It’s obviously contrary to the benefit of Apple itself, which should not just accept an app like Dark Hours, but celebrate it as an exemplar of the platform.

Mistakes happen. But in a functioning system mistakes get corrected, and mistakes as obvious as this one get corrected almost instantly and include a quick apology for the conflation. The App Store is not a functioning system.

Previously:

Update (2026-08-10): John Gruber:

To the best of my recollection, this is the first post I’ve retracted in the 24 years I’ve been writing Daring Fireball. I hope it’s the last. I was misled, both overtly and through omissions[…]

[…]

The truth is, the app, as originally submitted by Godier to the App Store (under the name “Asterly”, not “Dark Hours”), was entirely dedicated to astrology, not astronomy, and did in fact include a “Tarot card of the day” feature amongst other occultist horseshit.

[…]

I wrongly took Godier at his word, both in his public blog post and in private iMessage correspondence yesterday, that the rejection wasn’t just merely debatable, but completely and rather preposterously ungrounded. Whether Godier ever submitted a build of “Asterly” to the App Store that contained no occult horseshit and only the hard-science astronomy features that were present in his “Dark Hours” website that was available for the last week, I don’t know. But I have no reason to believe that he did.

[…]

In an uncomfortable exchange between Beher and Godier on Bluesky, Beher pointed out that Godier’s Dark Hours had the same bug as Beher’s that routed people to “random fields in Mexico”. Earlier today, Godier took his web app down and redirected his darkhours.io domain to Beher’s darkhours.app.

I’m really unhappy about this, both for my role in spreading a false story and because I think it will hurt the cause of reforming App Review. I know there are many crazy rejections and have experienced some first-hand. This story was believable because of that well-known history and because Godier didn’t seem like a nobody trying to get attention—he was the developer of another highly regarded app. But now people are going to point to true developer stories and accuse them of being fakes, too.

Jeff Johnson:

Terry Godier has just published a so-called “Mea Culpa” blaming Claude for cloning an open source app and denying foreknowledge.

There’s no mention of or apology for how Godier deceived Gruber and the world about the astronomy/astrology App Store submission/rejection.

The blog post essentially confirms that this person cannot be trusted.

Update (2026-08-11): Colin Cornaby:

BOTH projects were generated using Claude. So you have two people - both generating the same app from the same training data - having a public throw down over who copied who.

[…]

The “original” developer does claim to know how to code - which wasn’t clear from my research. That still doesn’t necessarily mean the original app was the source of the training data. They both may be a result of the same training data.

Nick Lockwood:

Holy shit, so the “Claude plagiarised an app” story is actually “Claude produced the same app twice when prompted to do so by two separate developers” 😅

It’s not clear to me exactly how much each developer relied on Claude or which training data was used, but I wanted to note this angle of the story.

Update (2026-08-14): Rosyna Keller:

With all this talk of an astrology app being rejected by App Store review I’m reminded there’s still a flat Earth/astrology app on the App Store that actively leaks the location of all of its users.

macOS 26.6.1

Juli Clover (release notes, security, no enterprise, no developer, full installer, IPSW):

macOS Tahoe 26.6.1 fixes a vulnerability that could allow an attacker to authenticate to Screen Sharing without valid credentials.

See also: Adam Engst and Mr. Macintosh.

Previously:

Update (2026-08-14): Bill Toulas:

In an update to the initial advisory, the Dutch agency said it received a report indicating that the vulnerability is being exploited in the wild in attacks where port 5900 is exposed to the internet.

According to the NCSC, the attacker obtained root access to the system and deployed a Monero cryptocurrency miner.

macOS 15.7.9 and 14.8.9

macOS 15.7.9 (security, full installer):

This update provides important security fixes and is recommended for all users.

macOS 14.8.9 (security, full installer):

This update provides important security fixes and is recommended for all users.

These seem to fix the same screen sharing bug as the macOS 26.6.1 update.

See also: Howard Oakley.

Previously:

Thursday, August 6, 2026

Snow Leopard Lore

Ruben Schade (Hacker News):

This idea is so powerful—and so longed for—that it’s escaped containment among the Apple crowd. I’ve seen everything from Linux distro to phone updates referred to as Snow Leopard releases, when their vendors cite stability and bug fixes over new features. Likewise, people plead with their vendors for a Snow Leopard release when they feel quality has slipped.

The reality was a bit different. As I wrote at the time[…]

People conflate a bunch of different ideas when talking about Snow Leopard:

LegNeato:

Snow Leopard’s stated goal internally was reducing bugs and increasing quality. That is a fact, not marketing. I am not sure why people on the internet don’t believe that, but I was there. If you wanted to ship a feature you had to get explicit approval from leadership and the bar was high. In normal feature releases it operated bottom up “here is what we are planning to ship” and in Snow Leopard it was top down “can we ship this?”.

AFAIK Snow Leopard was the first release of this kind (the first release I worked on was Jaguar or Puma), and was a direct response to taking 8 software updates to stabilize 10.5 and the severity of the bugs found during that cycle and the resulting bad press. Leopard was a HUGE feature release and with it came tons of (bad) bugs.

[…]

Testing was basically engineers, internal QA, some strategic partners like Adobe and MS, and the Apple Seed program (which was tiny). There was very little automated testing. Apple employees are not representative of the population and QA coverage is never very complete. And we sometimes held back features from seed releases when we were worried about leaks, so it wasn’t even the complete OS that was being tested.

Software updates are always needed, though the issues they fix became less severe over time due to larger seeds (aka betas), recovery partitions, and better / more modern development practices. But I can tell you FOR A FACT that Snow Leopard had fewer major bugs over its lifetime, coalesced very quickly, and was extremely solid when Lion was released.

Ken Ferry:

I agree with you that Snow Leopard was billed as no USER VISIBLE features. But people did NOT just fix niggling bugs, it was an architecturally huge release. E.g., it introduced GCD. And unless I’m confusing the year, it rewrote the Mail backend to use it and mail hasn’t had reliable search since.

My memory is that quality was so low that we pushed back the release. With the extra time we did manage to fix enough bugs that it was well received. But internally it was more destabilizing than most releases due to the amount of architectural churn.

giantrobot:

Yeah as someone else that worked on Snow Leopard I found this article and ones like it a bit silly. They’re a lot like the old “debug code” posts on Mac forums back in the day trying to explain why Puma was slow (no, you’ve got a G3 and an unaccelerated video card).

Tiger and Leopard were sprawling releases. Tiger covered 32-bit and 64-bit PowerPC, then 32-bit x86, then 64-bit x86 Macs. Tiger was also what I guess I’d say is the first “modern” OSX release, with subsystems like launchd and a more mature OpenDirectory replacing older NeXT subsystems. Leopard in my experience was a train wreck. It shipped a lot of new features, both user facing and back end frameworks, but the development was seriously impacted from teams losing engineers to iOS. Leopard had features planned assuming 100% availability of SWE’s resources but ended up with 40-50% of SWE’s resources (made up numbers based on my feels at the time). Many new frameworks in Leopard did not land or get stable until very late in the development cycle which meant everything downstream had to scramble right before GM. It was 100% the case that Leopard was not really stable until 10.5.8 and still sucked IMHO.

There was a lot of clean-up needed in MacOS and that was Snow Leopard. It was not a perfect release but 10.6.3 (the second disc pressing IIRC) and onward were very stable. Dropping PowerPC support really helped focus QA since they didn’t need the massive array of test hardware Tiger and Leopard required. You also didn’t need to wrangle builds for four architectures, including multiple compilers as a few libraries (if not whole frameworks) were compiled with ICC on x86 for performance reasons. The “Snow Leopard wasn’t that great” meme is weird. I’m sure it had its problems like every OSX release did. Unfortunately most OSX releases broke someone’s workflow. Snow Leopard ware no different. But it was always billed internally as a “no new features” release and those features that it did ship faced a very high bar to get in the release. I definitely look back on Snow Leopard as a high water mark for macOS quality in terms of a release.

Previously:

Update (2026-08-10): Mooch:

If you weren’t there then you don’t know why I considered getting a “10.6.8” tattoo at one point. Boot Camp was no longer siloed, zero-drama Exchange support was baked in, Quicktime X hauled ass, and It was the definitive answer to the smoldering wreckage of Vista.

Mario Palomera:

Snow Leopard has always remained the best Apple OS in my memory. For me Mail search was perfect all the time, once spotlight finished indexing it was incredible, iTunes, finder, everything just worked. The consistency was felt everywhere…

macintog:

[But] there’s one other missing piece: time

everyone forgets the annual release cycle is a modern novelty. plot 10.x.0’s and 10.x.y final builds on a timeline and it becomes clear

Apple to Build Universal Clipboard for Windows

Juli Clover:

Apple is working on a new feature that will support cross-device copy and paste between iOS devices and Windows PCs.

Microsoft asked for the feature using Apple’s EU interoperability request system for developers, which Apple implemented to comply with the Digital Markets Act. Apple began evaluating the request in March, and on June 26, proposed a project plan.

[…]

Apple proposed a solution that would let an iPhone share and import items from the pasteboard to a paired accessory, like a Windows PC. Apple plans to use a solution similar to the Accessory Notifications option it added for third-party wearables in the EU in iOS 26.5. Users would need to give a paired device one-time permission to paste content from an iPhone.

[…]

Apple says introducing cross-device copy and paste is a significant engineering effort, with work expected to be complete by fall 2027.

I wonder whether Apple will restrict this to the EU.

Previously:

Illinois Photos.app People Album Lawsuit

Anurag Chawake:

Apple faces a $32.5 billion lawsuit over how its Photos app scans and stores faces. A federal judge cleared the case to proceed as a class action late last month, allowing millions of Illinois iPhone owners to join.

The case has been years in the making, and Apple has fought to shut it down at nearly every turn. Now it heads back to the court, with the company’s privacy practices on trial.

[…]

Court records have shown that the update applies to users with iCloud Photos turned on. Those accounts also need to use at least 10GB of storage and contain at least 5,000 photos and videos. Plaintiffs say all this amounts to collecting biometric data without consent, putting Apple squarely at odds with Illinois law.

Again, I find it odd that features are apparently gated based on the capacity of your iCloud account rather than the available storage.

Malcolm Owen:

The lawsuit accuses Apple of collecting biometric data without user consent in the Photos app, reports The Times. It is alleged that Photos uses facial recognition technology to scan individuals who appear in images, creating a “faceprint” for each person in the photo library.

After collecting enough samples, an algorithm is allegedly used to identify the iPhone user. That data is then stored on the iPhone within the Photos app.

I don’t see what the issue is here. My understanding is that it only uploads vectors after you’ve opted in by enabling iCloud Photos and manually assigning names. Also, the vectors don’t seem like the sort of biometric information that the law was meant to protect.

Brian Webster:

Assuming things are working properly, what should happen is that the people you have specifically named and the photos you have specifically verified sync their info via iCloud. However, the actual face detection for the rest of the photos is done on a per device basis and is not synced via iCloud, primarily for security/privacy reasons.

So, when you first set up a new device, it will pull down the names and info for the photos where you have identified a particular person, but then it still needs to go through the entire library on-device, identify the faces in each photo, and compare them to the synced information to tell which person is in which photo. So once it’s done, you should end up with mostly the same photos identified as each person, but each device still needs to do its own face detection locally.

Wednesday, August 5, 2026

Fitbit Now Syncs With Apple Health

Juli Clover:

Google Health (previously the Fitbit app) collects fitness, sleep, and wellness data from a connected wearable device. Steps, distance traveled, heart rate, sleep, and more can now be added to Apple Health. As noted on Reddit, some data such as HRV doesn't transfer over.

[…]

Syncing can be enabled after downloading the update by selecting Connections, choosing Apps and services, and then adding Apple Health.

My wife is a longtime Fitbit user. A few weeks ago, some family and friends started a friendly competition to see who could get the most steps. They’re all Fitbit users, too. Then she wanted to start comparing step counts with me, but I have an Apple Watch. I thought this would be no problem because the Health app has a sharing feature, and Fitbit and HealthKit have both been around forever. I was shocked to learn that there has never been any syncing. I don’t really understand the reason for this, as it seems like it would make the Fitbit more valuable.

It looks like the syncing part is now solved, but we still can’t automatically compare our steps. We’ve both tried inviting each other to share step counts and some other metrics multiple times over the last several weeks, and it has never worked. Either the invitation doesn’t arrive or the app just spins forever when trying to accept it.

Previously:

Mail Attempting to Sync Previous Recipients Despite Setting

Jeff Johnson (Hacker News):

Nonetheless, when I send an email in Mail app, from a non-iCloud account to an non-iCloud account, Mail immediately triggers an iCloud connection, as revealed by Little Snitch.

[…]

What could Mail be querying and saving in CloudKit when I’ve disabled Mail in iCloud?

[…]

As you can see in my screenshot at the beginning of this blog post, I have Contacts turned off in iCloud settings, so my Previous Recipients list should not be synced to iCloud. Nonetheless, I followed the commenter’s suggestion of logging in Terminal. I saw log messages that referred to com.apple.mail.recents, which might indicate Previous Recipients and would certainly explain why this happens when I send an email.

[…]

I do object to notifying Apple that I’ve just sent an email. That in itself seems like a violation of my privacy.

The settings are confusing, even more so than with System Preferences. If you go to System Settings ‣ Apple Account, it shows a round rect that says Mail and shows the Mail icon. If you click this, it lets you uncheck Sync this Mac for iCloud Mail. This mirrors the iCloud Mail checkbox that you get when you click See All to see the full list of apps. I don’t like how the top-level name and icon suggest that you’re going to a settings sheet for the Mail app, but then it actually gives you iCloud settings.

Importantly, there’s also another Mail checkbox in that list. It’s easy to miss because, first, why would you expect to see two Mail checkboxes?

And, second, it’s not obvious that there are actually three lists: a bunch of “favorite” system apps, in non-alphabetical order, for some reason including lesser ones like Freeform and Image Playground; followed by a second list of system apps in alphabetical order; and then a third list of alphabetical third-party apps.

Mail is in the second list, along with (to me) other top-tier apps like Books and Maps. Anyway, this second Mail checkbox controls the syncing of non-mail Mail data such as rules and smart mailboxes. But not, apparently, according to Apple, the previous recipients.

Previously:

Telegram Temporarily Removed for CSAM

Hartley Charlton (The Verge):

Apple briefly removed Telegram from the App Store on Monday night after a review found content that violated its guidelines against child sexual abuse material (CSAM), but restored the app a short while later, according to Reuters.

It seems like this was a symbolic gesture. Removing the app didn’t affect any of the customers who had already downloaded it. Probably none of them saw the image. And restoring the app doesn’t mean that it’s completely free from CSAM—probably none of the major platforms is. It just means that Telegram did the obvious thing after the violation was reported, which presumably they would have done, anyway.

Jeff Johnson:

They removed an entire app for ONE app user???

And before even contacting the developer? Telegram banning the account is what actually prevented users from potentially seeing the CSAM. Apple’s action seems like either a mistake or trying to send them a message.

I would note, by the way, that the Telegram app was apparently never removed from the Mac App Store. Which goes to show how little Apple cares about the Mac App Store.

Telegram:

I’m sure this stance will be applied equally to all other apps in the store, in the future right? @Apple

Pavel Durov (Telegram, MacRumors):

Because Telegram quickly removes illegal content from public groups using all kinds of moderation tools, the attacker had to resort to a technical trick. He inserted AI-modified illegal content by editing an old message in an active group chat. As a result the content was effectively hidden from the group’s members, preventing them from seeing/reporting it.

The attacker was a takedown extortionist: someone who demands ransom from group owners in exchange for not targeting their communities. These extortionists use automated accounts to plant illegal content in public groups and then report it directly to Apple, attempting to trigger the removal of legitimate communities whose owners refused to pay them.

[…]

Extortionists have found a way to manipulate Apple into overreacting. Apple removed Telegram from the App Store before contacting us. This creates a potential systemic risk for every mobile app that hosts user-generated content. If an app used by more than a billion people can be removed from the App Store without prior warning, any app can be.

Marcus Mendes:

During the time the app was unavailable, many speculated that the move was politically motivated, or perhaps in response to the recent discovery that Telegram has allegedly been using an obfuscated private UIKit API to animate its emoji picker.

It’s sad but kind of hilarious that both of these so disparate theories were considered possible. Durov really does have political enemies, and Apple really does seem to have it out for Telegram. But, also, using private API to animate emojis totally seems like something that Telegram would do and that Apple would overreact to.

Previously:

Update (2026-08-06): Matt Burgess (Hacker News):

Over the last nine months, Mark Zuckerberg’s Meta has run dozens of paid ads that include explicit AI-generated child sexual abuse material (CSAM) and images of minors alongside sexually suggestive statements, according to details of the ads shared with WIRED. The ads, which in some cases reached several thousand accounts, were targeted at people living in the United States, United Kingdom, and more than a dozen European countries.

This is much worse than what happened with Telegram, yet Apple didn’t overreact.

There’s also the Twitter/Grok case.

Previously:

Tuesday, August 4, 2026

OpenAI Open Letter Responds to Apple Lawsuit

Sarah Perez (Hacker News):

Apple is now seeking a preliminary injunction in its trade secrets case against OpenAI, which aims to stop the AI model maker from moving forward with developing an AI device or other products based on Apple’s technology. […] In a new filing, Apple is requesting expedited discovery from the accused OpenAI employees, senior systems engineer Chang Liu and Chief Hardware Officer Tang Yew Tan; OpenAI, and its foundation; and io, the device startup co-founded by Apple’s former lead designer Jony Ive.

OpenAI (Hacker News, ArsTechnica, The Verge, MacRumors, 9To5Mac):

Apple had claimed that they contacted OpenAI in February and that we didn’t respond. They now admit that their outside lawyers emailed the wrong person after confusing two Asian last names—only after we brought this to their attention. Apple also claimed they had a discussion with our General Counsel, which they now concede never happened. But they again hide the fact that they never raised the specific allegations in this lawsuit at that time, and that they in fact told us that they were “resolving any issues”. We then heard nothing for five months until they sued. In their latest filing, Apple tries hard to spin this sequence of events, but you can just read the emails for yourself here.

Apple accuses Chang Liu of accessing Apple confidential information after leaving the company, but only now admits that Apple employees reached out to him and asked for his help to locate this information (you can read the messages here). Apple now tries to shift the blame to “residual access”, but they also don’t disclose that this is a common issue with Apple which is caused by them failing to properly manage system access when people leave. What that means in practice is that former employees who are trying to do the right thing when they leave still have access to Apple files—despite not wanting them or even being aware of them.

William Gallagher:

What it does not even touch is the accusation that Chang Liu retained his Apple laptop, which seems to be proven by what OpenAI posted. Apple further says that Liu entered shared network folders after leaving the company, and did so to download dozens of confidential files.

Then, too, OpenAI ignores the specific further accusation that ex-Apple employee Tang Tan both emailed documents to himself and sought trade secrets from employees he was recruiting for the ChatGPT company.

asimpletune:

What really matters is the claim that Apple never raised those issues in the lawsuit with them. OpenAI claims the emails prove this, but to me all the emails prove is Apple sent an email that said “please see the attached letters”. We don’t know what is in the attachments but I imagine those were the relevant issues they raised.

[…]

The fact that the lawyer emailed the wrong person is moot if they caught it and resolved it days later.

Previously:

Update (2026-08-05): John Gruber:

In OpenAI’s phrasing, it sounds like Apple’s attorney sent the entire initial letter of concern to the wrong person, and that’s why OpenAI never responded — because it wasn’t sent to the correct person (OpenAI general counsel Che Chang). That’s not what happened. The initial blockbuster “hey we think you guys are stealing our trade secrets and we want to talk to you about it” letter was sent to Che Chang. And Che Chang never did respond to Apple’s lawyers. That a mistaken email thanking Che Chang for a phone call that never happened (because that email was intended for another OpenAI employee) was also sent is irrelevant. I don’t understand why OpenAI is continuing to focus on this inconsequential mistake.

[…]

The iMessage transcripts that OpenAI provides at the bottom of their post do not contradict Apple’s claims at all. […] Apple also claims that Liu accessed confidential information, presumably in Box and definitely not in iCloud Drive, on five different occasions, up until 27 April 2026, over three months after he left Apple. These chat transcripts offer no explanation for that.

[…]

To me, the most interesting response from OpenAI wasn’t their blog post, and was in fact released by Apple, as “Exhibit F” to one of their expert declarations submitted to the court last night.

Confidential Apple Files in iCloud

Juli Clover:

The way Apple combines work and personal iCloud accounts left some employees able to access confidential documents after departing the company, reports The Information. The site spoke to more than half a dozen former Apple employees who were unknowingly left with access to sensitive content.

[…]

Apple told The Information that the OpenAI lawsuit is unrelated to any files left available on iCloud and that it does not pursue legal claims against former employees who accidentally have Apple documents in their personal iCloud accounts.

[…]

In a now-settled legal dispute, chip company Rivos claimed Apple intentionally lets former employees retain access to files “as part of a planned effort to generate a pretextual basis to sue the employees and their new employer for ‘stealing’ Apple material.” In the Rivos case, an employee was targeted for keeping work files in his personal iCloud account.

Andrew Orr:

The documents included confidential material such as plans for product launch events. The former employees said they made no effort to retain access and unexpectedly found the files mixed with their personal iCloud data.

The problem reportedly grew from Apple’s practice of encouraging employees to connect their personal Apple IDs to company-funded iCloud storage.

[…]

Apple also relied heavily on iMessage for workplace conversations and file sharing before rolling out Slack around 2019. Former employees could retain old iMessage conversations and attachments, while Apple could terminate their Slack access when they left.

John Gruber (Mastodon):

If you use your personal Apple ID, you get a magic “Apple Work” folder in iCloud Drive. When you leave Apple, that “Apple Work” folder disappears. But any other files or folders that were shared with you that were outside that magic folder are still in your iCloud Drive, because it’s still your personal iCloud account.

[…]

You still have the same Apple ID account, even though you no longer have an employee @apple.com email account. Overall, this is a humane way of dealing with digital identity. Your Apple ID account is you, the person, not “example@icloud.com”, one specific unique email address. And you, the person, may well have multiple email addresses — all of which can be associated with your one Apple ID account. That makes Apple IDs more nuanced and complicated than a simple mapping of one email address = one account. And it obviously makes access restrictions more complicated.

Yesterday, OpenAI released messages to show that Apple employees (with permission) retained access to the departing employee’s personal iCloud account so that they could access work files that were stored there. It’s just a mess that both the software and corporate policy encourage mixing everything in one account.

Eric Schwarz:

As many things I know about Apple, this whole thing both makes perfect sense and feels absolutely bonkers.

Previously:

Apple Fires Engineer Who Kept Customer Device IDs Private

Ryan Merket (Hacker News, PDF):

The company said his performance was the reason, according to a lawsuit Boardman filed in San Francisco Superior Court. Boardman says that explanation was a pretext. His version of the story begins three years earlier, inside Apple’s technical relationship with the largest wireless carriers in the United States, with a category of data capable of identifying nearly every phone on the network.

[…]

Apple considered serial numbers and IMEIs personally identifiable information under its internal policies, Boardman alleges. Representatives working with carriers other than AT&T required the carrier to obtain a customer release before Apple supplied the data. The Apple representative assigned to AT&T did not enforce that requirement, according to the complaint. Boardman says the identifiers were then transmitted through “unsecured email communications.”

He reported the practice to his manager and sought guidance from Apple’s legal department. He alleges that the company never gave him a written response.

I don’t think he has much of a legal case. Apple was probably within its rights to fire him if what he refused to do was against company policy but not illegal. It doesn’t sound like Apple is disputing that, at least not yet.

However, I think this is interesting because:

Previously:

Monday, August 3, 2026

Pasting Quoted Paths and Escaped Terminal Text

Anthony Reimer:

When you are shell scripting or working in Terminal, sometimes you want a quicker way to enter the path to a file or folder, particularly if you have already navigated to it in the Finder. One way that works in Terminal is to drag the file or folder from the Finder onto the Terminal window, which then types the path into the current command. However, another method was introduced in El Capitan (OS X 10.11) that allows you to copy the full path onto the clipboard.

In Finder, you can hold down Option and choose Edit ‣ Copy Pathname.

Starting in macOS Sequoia, copying the path to the clipboard using the method described generates a path that can be directly pasted into the Terminal or a script and be interpreted as that path without further manipulation.

It adds single quotes and or escapes characters, but only if necessary.

There are certainly some people who are unhappy with this change in behaviour but most Mac Admins will not be among them.

You can get the unescaped path via AppleScript.

Anthony Reimer (via Miles Wolbe):

Graham Pugh pointed out that if you have text on the clipboard, you have the option of pasting that text “escaped” in Terminal. Simply copy the text from whatever source you choose (e.g., the output of an AutoPkg run, where paths are not escaped), then in Terminal choose Edit > Pasted Escaped Text or use the shortcut Command-Control-V.

[…]

As a bonus, this concept can be applied to a tip I learned from Armin Briegel a few years ago, namely that if you select something in Terminal that you want to then paste into the current shell command, you can skip the copy-paste dance and instead just press Command-Shift-V to do it in one step (or if you prefer menus, Edit > Paste Selection). If you add the Control key to that sequence, the text pasted is escaped (Edit > Paste Escaped Selection or Command-Control-Shift-V).

NSPasteboard Crashes When Handling File Promises

Wade Tregaskis:

NSPasteboard mutates itself simultaneously from the main thread and the global concurrent Dispatch pool, w.r.t. to its internal type cache. This is surprisingly trivial to reproduce (sample code below) by just dropping, e.g. a file promise (such as by opening a PNG in Preview, revealing the thumbnails sidebar, and then dragging the thumbnail onto the sample project’s window).

[…]

Since this bug causes semi-random memory corruption, it manifests in a large number of ways – not all of which are all that helpful.

[…]

SwiftUI’s onDrop(of:isTargeted:perform:) method makes no claims or promises as to what thread / queue it executes the closure on, and in fact according to the anonymous Apple engineer it never executes the closure on the main thread.

Now, while that may be the intent, the reality of that is wrong – in my experience it always executes the closure on the main thread (which makes a lot of sense to me as drag-and-drop event handling in AppKit has always been on the main thread in practice).

Apple also told him that NSPasteboard is not safe to use outside the main thread, even though that’s not documented, it’s not @MainActor, and Apple’s own code does do that.

Copyright © 2000–2026 Michael Tsai.