Hacker News Reader

Comment by vel0city | Hacker News Reader

I'm happy to have this setting. It's a great setting and I appreciate Signal adding it.

However, if an attacker has the ability to directly query the Recall database, they almost certainly have access to read all your Signal messages on your device. The locations where Recall files live are even more protected and isolated than your %APPDATA%\Roaming\Signal directory is.

Everything running as you on your computer has full control of all your Signal messages and your identity assigned to the device. This is untrue of your Recall data, which from last I saw required a lot of finagling to get the permissions right for you to access it raw.

View on HN

It's kind of funny that this argument always comes up when talking about Windows security.

What if I told you that botched sandboxing by default is not the standard we should accept? And that Windows' lack of competence to isolate processes isn't even what the NT Kernel envisioned (see e.g. ReactOS)?

I'd never run Windows as a host system, given the track record of how Microsoft deals with RCEs and privilege escalation issues that have been unfixed for decades at this point.

It's the same security for the Signal as on MacOS and Linux. Your user has full control to it, generally all processes running as you can see it and mess with it.

* Arguing about what should be doesn't alter the facts of the current situation

* It's unfair to single out Windows here, when other platforms are not much better. Mechanisms for stronger sandboxing and storage firewalling do exist on all platforms, but in practice these are barely used on desktops, and this is true across all three major OS families. E.g. Flatpaks exist, but I believe they still represent the minority of actual application installs

And ironically Wayland also gets frequent, heavy criticism for doing the right thing here - treating screen or input capture as a privileged operation, rather than a default right of any random application you have running (though I agree they should have standardized an escape hatch earlier)

I do not want stronger sandboxing for my apps. I'll only allow it to run on my machine if I trust it anyway. I'm not worried about my apps being able to read my data. If a piece of software doesn't do what I want safely and securely, then I don't try to duct-tape it into a sandbox that's regularly broken out of anyway. I remove and use other software.

If flatpak/appimage are the only way to get a piece of software, I won't even waste my time evaluating it.

Do you also run everything as root?

No, I don't. Because it doesn't need to. But not running as root already provides all the protection I want. System files are not my data. My data lives in my home. I want my apps to have access to my stuff, not the whole system. But more importantly, I do want them to be able to talk to each other and effortlessly open files written by one another. "Isolating" them from each other is pointless if I then proceed to punch holes in everything just so it can work.

"This thing isn't working ... "Oh... it turns out it was missing a permission, should I give it that permission? What's it for? Fuck if I know..."

Or the other way round:

"This app seems like it's working properly, but can I restrict this particular permission for it? Fuck if I know. I'll just try and see if anything is broken"

Or I can just run the application normally and have everything always work.

You should dig into ~/.local and what happens there. I'd never store my keepassxc database file in my home folder if I were you.

Apps need sandboxing, because the linux/posix philosophy of separation through users and groups for each process doesn't really work in the modern day and how graphical software works.

Firejail's approach comes close to "sane" user sandboxes, but technically that's the job of the init daemon (pid 0), there's just no GUI for systemd sandboxes yet that's easily usable.

Podman is also really nice as a user-facing sandboxing daemon.

i know what happens in there. Shit that I install because I want to goes in there. And my keepassxc password is protected by a strong password and a hardware token. They are specifically designed so you can safely store them anywhere (ex cloud backup), so I don't see why you brought that specific example up

Well, I agree with the Wayland and copy/paste clusterfvck.

I was more referring towards Qubes. I think Qubes does a lot of things right, I just wish its user facing settings and tools were easier to use in a graphical manner.

Recall is encrypted with a key in the TPM. But getting access to that encrypted sqlite db is a yawn.

Getting the key is harder, but possible. You can breach into Microsoft's group with a particular set of GPOs - if you can run a particular set of server commands on the local network.

Signal data is encrypted at rest. The key is stored in the OS store - usually meaning the TPM.

However, the key isn't in Microsoft's main grouping. To date, no one has extracted the Signal key this way. Other exploits are required.

Signal being smaller than the whole of Microsoft, reduces the attack surface.

> no one has extracted the Signal key this way

This is incorrect. Any process running as your user can trivially get the key.

If Signal uses the Windows Data Protection API for saving/encrypting the key (and some data online suggests that it does), then it’s trivial to fetch it back with the same APIs if you’re running as the same user. (I use `keyring` on Windows to access the key(s) VMware Workstation uses to encrypt Windows 11 VM vTPMs)

It’s kept secure by a chain of keys that may be backed by the TPM, but the security boundary is the user, not the app identity. IIRC Store/UWP apps may get their own boundary for credentials (due to how .appx is implemented).

At least this gives forward secrecy, so if someone takes control of your computer they can only spy on signal messages AFTER that point, and can't access prior messages that Recall has captured.

This is only forward secrecy for messages that were deleted and would have been captured by Recall and are still within the snapshot history which has a maximum number of days.

All the messages you've previously synced to the device exist in that Signal AppData directory and can be trivially searched and read by any application running as your user account. And all attachments are also just sitting there.

For example:

https://vmois.dev/query-signal-desktop-messages-sqlite/

Given how popular the disappearing messages feature is, a lot of messages are going to be deleted where Recall is a second, less tested copy of things which the user believes are gone. Given the past history of AI tools it seems dangerously likely that someone would find that their Recall history was retained longer than necessary or could be retrieved through some creative misuse of Recall which doesn’t require system access.

> Given how popular the disappearing messages feature is,

I don't think it's really that popular or extensively used. Most people I know who use signal use it pretty rarely. I'll turn it on when I'm about to send something sensitive, but generally it's not enabled. I've been using Signal since 2015 and I've probably only sent or received a hundred or so disappearing messages. I've sent and received many, many thousands of messages. And I mean even in this HN thread tons of people are taking about how they wish the iOS app would have better backup and transfer functions. Something tells me they're not itching to transfer all those already deleted messages.

And sure, maybe Recall ends up saving things longer than it was set for. Maybe Signal does as well. And once again, accessing all your Signal database doesn't even require system privileges just your local user account.

Your browser can access all your Signal messages. Your chat app can access all your Signal messages. Your email client can access all your Signal messages. Your calculator app can access all your Signal messages. That videogame made by Tencent can access all your Signal messages. They don't even have to screengrab, they can just read them.

You should be able to access everything on your own computer - that is a good thing.

The real problem with Recall is that Microsoft will access the data to apply some algorithmic secret sauce. The product manager already probably has all kinds of ideas for the future: targeting ads, upselling licenses, or making MS more attractive to law enforcement.

Yes, there is a benefit for the user, like a nicer search or something, but that is relatively minor. ..because Microsoft is not your friend. This feature is born from a harvesting mindset.

Regarding disappearing messages: I have two chats on WhatsApp where disappearing messages are turned off, and maybe a handful on Signal.

It is actually less common to disable them on WhatsApp than on Signal, mainly because Signal forbids delete windows longer than four weeks. That is not long enough sometimes.

I have no idea how our usage here ends up being so dramatically different. I don't even tend to talk about the feature with most contacts.

> Microsoft will access the data

Incorrect. This runs locally. Microsoft is advertising the data just as much as you opening the file in notepad or browsing a folder in explorer.

And once again I just point to all the people complaining about a lack of backup and weak transfer ability. They're not looking to backup a nearly empty history.

> Incorrect. This runs locally.

It does not matter whether Recall runs locally. Microsoft controls the OS, the feature, and the update pipeline. If they decide tomorrow to start syncing Recall data to the cloud - for any reason - they can. The local processing angle is just an implementation detail, not a meaningful protection.

What matters is that - with this feature turned on - MS is structuring and indexing your private data at the system level. That is not a neutral act. Once the data is structured and accessible, uploading it is trivial. And given Microsoft's cloud-first direction, the trajectory seems clear to me.

I understand your point, but the theoretical similarity between unstructured local data and the Recall database is not useful in practice. It's like telling a farmer that it doesn't matter whether the grain is in the barn or still in the field because he can access it either way.

> Microsoft controls the OS, the feature, and the update pipeline

So then this is true whether or not Recall exists, because Microsoft could have gathered this data either way. They could decide tomorrow to have Explorer siphon off that data, they could have Edge siphon off that data, they could have Windows update siphon off that data. Microsoft could have silently been doing this the whole time.

If you don't trust Microsoft with Recall, you shouldn't trust Microsoft with any of it. And you probably should have moved off Windows a long time before.

> MS is structuring and indexing your private data at the system level

This has been going on for a long time. Once again, if you don't like the idea of Microsoft running software in a Microsoft operating system to read your files you really shouldn't be running Windows, and shouldn't have been running Windows for decades.

https://en.wikipedia.org/wiki/Windows_Search

https://en.wikipedia.org/wiki/Windows_thumbnail_cache

signal desktop keeps database keys in the os keystore via electron safestorage api

on linux that’ll be kwallet or something, on mac it’s the keyring. it’s as secure as your password manager

edit: okay, you’re right, on windows it’s useless lol https://www.electronjs.org/docs/latest/api/safe-storage

> [on Windows] content is protected from other users on the same machine, but not from other apps running in the same userspace.

It's not different on Linux, every App can access any key in kwallet. To make this not possible the os would need to generate some kind of unique app id that can access only what it stored. This would probably result in a lot of lost passwords for normal users.

Right, this feels like an entry to Raymond Chen's "it rather involved being on the other side of this airtight hatchway"!

I have nothing against Signal implementing screenshot hiding. But it's not exactly fixing a gaping security hole.

Reply on news.ycombinator.com