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:
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.
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.
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.
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.
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.
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 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)
If flatpak/appimage are the only way to get a piece of software, I won't even waste my time evaluating it.
"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.
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 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.
I have nothing against Signal implementing screenshot hiding. But it's not exactly fixing a gaping security hole.
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.
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.
This is incorrect. Any process running as your user can trivially get the key.
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).
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.