Hacker News Reader

Comment by GeekyBear | Hacker News Reader

> It accessed Messages without full disk access

>This whole story never made sense or was substantiated

This story makes perfect sense, and Meta has a long history of not respecting user privacy controls.

> tech columnist Jason Aten said that Meta’s new general-purpose AI agent Muse sent him an unsolicited notification referencing a thread between him and a co-worker over Apple Messages. Aten said he never granted Muse permissions to read his messages and had assumed they were off-limits

https://arstechnica.com/security/2026/10/apple-changes-full-...

View on HN

The reason that story didn’t make sense to me was that the tech columnist never showed the Apple system settings on whether full disk access was enabled or not. If you trusted the tech columnist that full disk access was not enabled, then Meta’s Muse AI seemed to have discovered a zero-day vulnerability in Apple software, specifically a TCC bypass.

First I doubt Muse is that good of an AI. Second, even if that’s the case, why wouldn’t someone report it to Apple to get thousands of dollars in bug bounty rewards?

Apple's statement makes their position on the matter clear.

> Some developers are using Full Disk Access in ways that could put users at risk, exposing everything on their systems—including files, mail, messages, and even browsing history—without users’ full knowledge and understanding. For communication apps, this can also compromise the privacy of the people users are communicating with.

That Apple statement assumes that the user has granted full disk access but the user said he did not. So I conclude that Apple thinks the user is either lying or had forgotten he had enabled full disk access.

I’ll be charitable and say the user isn’t lying. Okay he has made a mistake in the initial granting of permissions. Then why didn’t he correct or retract the article?

Because Muse has a setting in the app that you are supposedly required to turn on before it can read your message?

One that the journalist in question did not turn on.

The app-level setting is irrelevant if the app does not have Full Disk Access.

Muse cannot bypass built-in macOS protections. TCC does not work on "the honor system", any more than UNIX permissions. It doesn't matter how nefarious Meta happens to be. Operating system security is designed to be resistant to malware.

> The app-level setting is irrelevant if the app does not have Full Disk Access.

I'm just going to have to ignore you on this issue.

> Meta CTO David Singleton joined the fray with a rebuttal that appeared solid. For Muse to access Apple Messages, a user must manually give it two privileges.

One one of those privileges actually stops them from accessing the filesystem. Any agent, Meta or otherwise, can access iMessages without the connector in that configuration.

> I'm just going to have to ignore you on this issue.

Sure, what do I know? After all, I'm only [checks notes] a 20 year veteran of Mac software development with multiple Apple-issued CVEs to my credit. ¯\_(ツ)_/¯

> > Meta CTO David Singleton joined the fray with a rebuttal that appeared solid. For Muse to access Apple Messages, a user must manually give it two privileges.

Yes. Those two:

1. Full Disk Access

2. The Messages Setting in Muse

As I said, without the first, the second alone won't allow Muse to read your Messages db. Do you not understand why Singleton said that Muse needs both?

The entire story here is that Meta claimed that Muse would not access your messages without you granting it the second permission, even after your granted it the first.

Hence Apple's statement that the first permission was being abused to destroy any promises of user privacy.

> even after your granted it the first.

The problem here is that Aten claimed he did not grant the first, and moreover, you have been defending that claim of Aten's in these comments.

As soon as you admit that Aten did indeed grant the one permission, it's not much of a stretch to conclude that he also granted the second permission. It would be very odd, I think, to distrust Aten in the one case yet stubbornly take him at his word in the second.

Again, if even one other person in the entire world could reproduce Aten's alleged experience...

The story has always been:

Meta promised that they would not read a user's messages without an additional permission the user must enable inside of Muse, even after they granted Muse full disk access.

A journalist reported that Muse read his messages despite the fact that he did not grant permission for it to do so inside Muse. He never claimed he did not grant full disk access.

Apple announced that the full disk access permission was being abused.

> He never claimed he did not grant full disk access.

False. In fact he has claimed this multiple times:

"Full disk access off. Muse synced 187k lines form my messages chat db." https://www.threads.com/@jasonaten/post/DdezsMJFhBr

"I still haven’t gotten an answer as to how it was reading my messages with Full Disk Access turned off, but I’d be happy to dig into it with anyone from Meta that wants to help." https://www.inc.com/jason-aten/meta-keeps-apologizing-for-mu...

This is why he's not a reliable narrator.

And another false claim he made, "Also, that full disk access doesn’t say anything about your message database", which anyone can easily refute by opening System Settings and reading the text.

That's the setting to let it read your messages if you don't want to give it full disk access. If you give it full disk access wouldn't that supersede it unless you don't store your messages on the disk?

> I’ll be charitable and say the user isn’t lying. Okay he has made a mistake in the initial granting of permissions. Then why didn’t he correct or retract the article?

There is no answer to that consistent with the premise you assumed out of charity :).

> Meta has a long history of not respecting user privacy controls.

Meta's respect is irrelevant, because macOS TCC prevents any and every app, including malware, from accessing your Messages database without Full Disk Access.

> he never granted Muse permissions to read his messages

That's what he said, but I would suggest that one person's memory is a lot more fallible than a longstanding operating system security feature.

Seriously, stop trying to grandstand this thread and being Meta’s lap cat. It’s gross.

How on earth, after literally decades of abusive behavior by meta, are you standing the straw man that maybe and based on your assumption the user is lying??

Please read and respect the HN guidelines: https://news.ycombinator.com/newsguidelines.html

I said that Aten is misremembering. That's not the same as lying. We all misremember things.

I don't care about or trust Meta. In my blog post about the Muse first run experience, I said, "For testing I used a fresh VM, not signed in to my Apple Account, because of course I don’t trust Meta with any of my data!" https://lapcatsoftware.com/articles/2026/10/2.html

What I do care about is truth and accuracy. My mistrust of Meta is not going to make me distort the truth. Muse cannot bypass macOS TCC, that's a simple truth.

I'm a macOS software developer. That's the reason for my interest in this story, the technical aspects of it.

Both of these could be possible – Aten telling the truth, Muse accessing private data without Full Disk Access. AI excels at problem-solving, it's conceivable that Muse simply found a path to the data. Just one example that came out recently: https://shirtpocket.com/blog/quick_security_update. It's so trivial that it becomes easily plausible. Every time a backup starts, a startup disk snapshot is mounted without access controls, Muse gets the mount notification and discovers it can access the data it was hoping for on the exposed volume. It doesn't even require knowledge of exploits, it's just a matter of looking around to see what it can find.

> AI excels at problem-solving, it's conceivable that Muse simply found a path to the data.

No. What you're missing here is that Muse for Mac is a native, compiled, code signed, notarized app, with specified entitlements. It can't simply rewrite its own executable code, so it can't do whatever it wants. You can even reverse engineer the app. Muse looks in ~/Library/Messages for the messages database; this is actually hard-coded in the executable file. Whatever ideas the remote LLM may come up with cannot automatically be translated into instructions that are executed by the Mac app. That's not how it works.

Aren't permissions on notifications less restricted then full disk access?

Which privacy control did they fail to respect, in this instance? Everything on the journalist's machine was working as-intended.

Reply on news.ycombinator.com