EagleFiler 1.9.22 is a maintenance release of my Mac file/note organizer and e-mail archiving app. This version works around various bugs in macOS 27, adds capture support for the Thorium Web browser, and improves importing from Mariner Paperless.
macOS 27 broke several things with drag and drop out of Apple Mail. Simply trying to read a URL from the pasteboard will cause a hang while it waits forever for the pasteboard server (FB24803817). The same thing happens when using PasteboardSetPasteLocation() and reading kPasteboardTypeFileURLPromise directly, which I was doing (instead of using newer API) to work around bugs in older versions of macOS. EagleFiler now uses NSFilePromiseReceiver for drags from Mail on macOS 27, which works better, but I also had to work around a bug where Mail would promise superfluous files for which the reader callback was never invoked at all.
macOS 27 also seems to include various regressions when reading PDF and Word files, producing invalid strings containing NUL characters. Also, displaying certain PDF files worked fine on macOS 26 but now crashes.
I also ran into (and worked around) a bug where macOS 27’s NSTextView would get into an infinite layout loop when displaying an attributed string that included images.
Drag and drop from Airmail is still an issue. When using the newer drag APIs, it will often hang Airmail or not produce a file, and this also happens with other apps like Finder as the destination. EagleFiler works around this using older APIs with Airmail and tries to report a helpful error when there’s trouble. Single-message drags work best.
I’ve also been investigating a problem where saving a file with a colored tag in iCloud Drive will, a few seconds later, change the color to gray, but I don’t have a solution for this.
Previously:
Airmail Apple Mail Cocoa EagleFiler Extended Attributes iCloud Drive Mac Mac App macOS 27 Golden Gate Microsoft Word Pasteboard PDF Programming Rosetta Unicode
David Bushell (Mastodon, Hacker News):
I discovered that macOS 15.3 had enabled a feature that was phoning home every 15 minutes with personal data. And that I said “no” and turned it off.
[…]
And today I discovered that Apple had [in macOS 27] removed the “no” switch.
[…]
Digging through macOS 27 settings I turned off Siri (again). Of course, multiple unkillable Siri processes remain, stealing memory and writing data. For what purpose? Who knows. Note that they removed “Apple Intelligence” from this control.
[…]
All of this garbage was enabled after upgrading to macOS 27 despite me having “Apple Intelligence & Siri” turned off already. That was a rather explicit “no”, no?
Previously:
Update (2026-10-02): Coeur (via HN Reader):
Author claims the system setting “Privacy & Security > Apple Intelligence Report > Report Duration” with its 3 options [Off | 15 minutes | 7 days] sends that data to Apple with that frequency. This is wrong - this is a transparency report so that you as a user can see everything that is getting sent to Apple as a part of Apple Intelligence. Nothing additionally is getting sent to apple if you switch this away from “Off”.
To me, the main point of the post was about the missing off switch for Apple Intelligence itself. Bushell was forced into enabling a feature (and storage use) he had specifically turned off, and there is no option to block his data from being sent to Private Cloud Compute. But, yes, the first sentence I quoted from Bushell is wrong. The report feature isn’t periodically sending data to Apple; it’s reporting what was already sent. Turning it off does not add any additional privacy, except from someone snooping the report file directly on your Mac. Apple’s wording explaining the report was confusing but has improved somewhat in recent versions.
Apple Intelligence Dark Patterns Mac macOS 15 Sequoia macOS 27 Golden Gate Privacy Siri
Bob Gendler:
Since macOS 26.4, there’s been an issue with the keychain hiding in plain sight and that issue is it’ll take ANY password. Say what? The story behind CVE-2026–43728.
[…]
Where this is a bit more of a kicker…you can reset the keychain password without even knowing the real one.
[…]
Now did Apple fully fix it, well mostly. Something is different after macOS 26.4 (I believe it’s the new, User Authentication Daemon — userauthd). On macOS 26.3, if you ran security lock-keychain and then security unlock-keychain it HAD to be your keychain password. But now they added this note to the man page.
Unlocking the login keychain might succeed when an incorrect password is presented, if other unlock factors are available.
Previously:
Bug Keychain Mac macOS Tahoe 26 securiy
