One of our Macs kept filling up its SSD even though there isn’t supposed to be anything more stored on it. Photos is set to optimize its storage, and Messages is set to only keep messages for a year. It should be pretty much in a steady state, but we kept getting alerts from Mail that it couldn’t launch because there wasn’t enough free space. It’s an M4 MacBook Air used mostly for Web stuff, but somehow it felt as slow as the Intel one it had replaced.

I deleted unused apps and offloaded photos. Restarting sometimes helped, so I thought maybe it was an issue with Time Machine snapshots not being reclaimed promptly, which has been an issue before. But what data would even be changing so much to create large snapshots?

The problem kept getting worse, so I broke out OmniDiskSweeper. It didn’t find anything unusual, except it showed that the totals for the main folders added up to about 90 GB less than was reportedly used on SSD. Disk Utility showed that there were no snapshots taking up space. There must be real files but not ones that the app could see.

I relaunched OmniDiskSweeper using sudo, and it found a huge amount of stuff hidden in the root account: /private/var/root.

I had thought that wasn’t really used except when running Terminal from macOS Recovery. But apparently various daemons store all kinds of stuff there now. The /private/var/root/Library/Logs folder alone was using 74 GB, and there were also several multi-GB cache folders.

The logs were almost entirely from RTCReporting, and I’m not the only one to run into this.

I deleted the files using OmniDiskSweeper, but that didn’t help. It turns out that by default it moves files to the trash, and I guess since it was running under sudo this meant the invisible trash folder for the root account. It’s better to hold down the Option key to Delete Immediately.

After deleting the files and restarting the Mac, the free space looked right at first but then steadily dropped. Pretty soon there were again 5 GB of RTCReporting logs with the Mac just sitting there. I started using sudo du -h -d 2 /private/var/root/ to track how the sizes were changing. Within a day it was back up to 27 GB.

Activity Monitor showed that rtcreportingd and fileproviderd were each using almost 100% CPU constantly. I immediately suspected Dropbox because it had been working poorly on this Mac for a year or so. It wouldn’t keep files offline and constantly seemed to be syncing even when files weren’t changing. Sure enough, turning off Dropbox stopped the CPU use and the ballooning log files.

This was our last Mac still using Dropbox, so it seemed time to migrate it to iCloud Drive. The syncing problems ended up not being limited to keeping files offline. It couldn’t even reliably download most of them from the cloud to move them out of the Dropbox folder, instead reporting I/O errors for most files. And the files that I did move to the Documents folder never synced that deletion up to the cloud. I ended up just downloading the whole folder from the Web interface. iCloud Drive uploaded everything quickly and then settled into a state of no CPU use.

Previously:

• Sunsetting Maestral
• When Dropbox Spawns a Million Folders
• Tahoe Free Space Problems
• Fixing “Optimize Storage”
• Update on Cloud File Provider Extensions

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:

• macOS 15.7.8 and 14.8.8

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:

• System Settings
• Yosemite Uploads Unsaved Documents and Recent Addresses to iCloud

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).

Marcus Mendes:

Following the rollout of no less than seven Release Candidates, Apple has now finally released macOS Sonoma 14.8.8 and macOS Sequoia 15.7.8 officially.

macOS 15.7.8 (security, full installer):

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

macOS 14.8.8 (security, full installer):

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

Previously:

• macOS 15.7.7 and macOS 14.8.7

Howard Oakley:

Spotlight doesn’t currently appear able to search Time Machine backups reliably, at least not in Sequoia or Tahoe, although this may not be universal.

[…]

If I now step back through my backups to reach one that I know contains that file, I can restore it. But if I type anything into the search field, nothing is found. If I change the scope of the search to that backup, the window title changes but its contents remain blank, and there isn’t even a busy spinner to indicate a search is in progress.

[…]

As I can’t disable Spotlight indexing on that volume without macOS telling me that it’s required to be indexed by Spotlight, neither can I force that volume to be reindexed.

[…]

My conclusion is that using Spotlight to search Time Machine backups no longer works, and the instructions given by Apple are also broken.

That has been my experience, too. As I see it, there are four separate problems:

1. I want to be able to search all my backup snapshots, because I don’t know which one might contain the file I want to restore. Time Machine only lets you search one at a time.
2. Searching an individual snapshot doesn’t actually work.
3. Spotlight indexing is invasive, using lots of CPU time, and with spinning hard drives causes wear and tear and creates lots of noise. If search doesn’t work anyway, I’d like to turn it off, but macOS won’t let me.
4. If the problem is with the index, there’s no way to reset it without deleting your backup.

Howard Oakley:

Unfortunately, all those saved versions in the version database fall outside the scope of Spotlight indexing, and Spotlight search can’t look inside any of the old versions saved in a volume’s version database. Surprisingly, the version browser doesn’t offer any search facilities either, as that’s presumably another feature intended for a future that never came.

[…]

One way around this is to save each document version as a separate file, allow Spotlight to extract their contents and add those to its indexes for that volume, then to search those files. This is quick and simple using my free utility Versatility.

Previously:

• Golden Gate Spotlight
• Time Machine in Tahoe
• Runaway Spotlight With Pages Document on iCloud Drive
• Spotlight Indexing Running Wild
• Invasive Spotlight Indexing
• You Can’t Turn Off Spotlight on Your Time Machine Backup

Joseph Cox (MacRumors, Hacker News):

A vulnerability in Apple’s “Hide My Email” tool lets almost anyone discover a person’s real email address that is supposed to be hidden by the feature, and Apple has failed to fix it for more than a year, according to a security researcher and 404 Media’s own tests.

[…]

“Apple Hide My Email is leaking email addresses that are supposed to be hidden. We reported the issue and replication instructions to Apple over a year ago. We don’t know why it hasn’t been fixed, but we don’t feel comfortable waiting any longer. Hide My Email users deserve to know that it may be possible for attackers to discover their hidden email addresses,” Tyler Murphy, the co-founder of EasyOptOuts, which discovered and reported the issue to Apple, told 404 Media.

“Free, publicly accessible people-search sites make it easy to link an email address to other personal details, so people relying on Hide My Email for safety may be at risk,” Murphy added.

[…]

To test the issue I generated a new Hide My Email address and provided it to Murphy. Around five minutes later, he replied with my real email address linked to my Apple account which was supposed to be hidden.

Ben Lovejoy:

Murphy said that he reported the issue to Apple in June of last year, and the company told him it was looking into it. Apple said it had been fixed in March of this year, but Murphy found that wasn’t the case. He again contacted Apple, with the company saying that it would appreciate him not revealing the existence of the flaw until it had been resolved.

Apple then said it planned to address the issue in June, but since it still hasn’t been fixed[…]

Tyler Murphy:

March 19, 2026: Using the reproduction instructions from our initial report, we determined that the vulnerabilities hadn’t been fixed.

May 22, 2026: We realized that the vulnerabilities may have greater severity and scope than we thought initially and reported this to Apple. Apple never acknowledged the report of increased severity.

June 30, 2026: Apple again reported that the vulnerabilities were fixed and asked us to verify. We determined that the vulnerabilities hadn’t been fixed.

Jeff Johnson:

This is every fucking Feedback I file.

John Gruber:

Not good. Especially the “We reported the issue and replication instructions to Apple over a year ago” part.

This is becoming a pattern. At least Apple still allows third-party e-mail providers.

Nick Heer:

Very few details are available right now. I have seen speculation that the original email address is revealed when someone replies using their hidden email address, but the impression I get from Cox’s reporting is that no user interaction is necessary[…]

[…]

I am also unclear about how, as of May, the EasyOptOuts guys found the “vulnerability may have greater severity and scope” than initially reported. Ominous, though.

Previously:

• Hide My Email Moving to private.icloud.com Domain
• No Bounty for Mysk
• AirTrafficDevice: Ignored, Reluctantly Fixed, No CVE, No Bounty
• Evolution of Apple Security Bounty Program
• The Time to Fix Web Security Bugs

Update (2026-07-13): Jeff Johnson:

I don’t know whether I’ve accidentally stumbled upon that vulnerability, or perhaps in this case the Hide My Email user just messed up in some way, but I’ve definitely discovered a bizarre and troubling Hide My Email bug in Mail app (on macOS Sequoia 15.7.7).

[…]

Bizarrely, however, Mail app displayed an alert that I’ve never seen before, “This message was forwarded to you by Hide My Email,” despite the fact that I have previously received many emails from people using Hide My Email.

[…]

• Why I am seeing two different @icloud.com email addresses, one of which appears to be the sender’s unhidden address?
• Why are the To: and From: fields in my reply disabled?
• Why is my reply not from my @underpassapp.com email address but rather displayed falsely as from the sender’s @icloud.com address and really from my unrelated Apple Account address?

Update (2026-07-16): Joe Rossignol:

Apple this week was sued over a reported “Hide My Email” flaw that could expose a user’s real email address. The proposed class action lawsuit alleges that Apple violated California’s false advertising law and other consumer protection statutes by knowingly offering a feature that does not work as advertised.

This is interesting in that the June 2025 bug report is the evidence that Apple “knew” the feature didn’t work, while “Apple continued to represent to consumers that Hide My Email would actually hide users’ email.” How long are they supposed to get to fix a bug?

Update (2026-07-20): Jeff Johnson:

The misleading user interface elements in Mail app are a bug, but by themselves they’re not a vulnerability. The vulnerability is that when I send a reply to my maliciously crafted email, my Apple account email address is disclosed in the “From” field of the sent reply! In other words, the Mail app interface lies, fails to show the true sent value of the “From” field.

There are a couple of crazy aspects to this information disclosure vulnerability:

1. It does not require that the victim actually use Hide My Email! I never use it. As I mentioned in my previous blog post, I don’t even have an icloud.com email account.
2. It does not matter which of the victim’s email accounts receives the email from the attacker. If your Apple account email address is a@foo.com, but you receive a maliciously crafted email addressed to b@bar.com, Mail app will still send your reply from a@foo.com, thereby disclosing your Apple account address.

Update (2026-07-21): Juli Clover:

Apple addressed a vulnerability in Hide My Email that exposed a user's real email address, reports 404 Media. Apple told the site the issue was fully fixed in a patch released on July 3.

[…]

While the bug has now been addressed, email logs that pre-date the fix could still expose user email addresses.

Update (2026-07-22): See also: Hacker News.

Jeff Johnson:

It appears that the vulnerability I discovered, and which still occurs, is different from the vulnerability reported by others[…]