'portable' bins

[elandorr]

We had a long-standing issue on this, I believe. But I can't find it. I considered I might've mistaken it for one of the other forks, but I remember reading @m-simonelli. GH's search didn't help.

The original ricochet was nice, because it offered a single self-contained archive that never left its own folder. It was perfectly clean, ignoring potential OS level caveats like windows storing some paths for unknown reasons for an unknown time.

This is of critical importance. Especially for something like rico, which I like to describe as the nuclear option of messaging. You don't typically use something naked like rico without a good reason. I personally love the simplicity, but most modern users wouldn't touch it, if it weren't for an extreme need for privacy.

A typical use case of the original rico was including a pre-made config in a zip, or at the very least a note with an id. Users don't expect data to end up all over.

Another nice option was having multiple identities, all contained in the individual folder. Easy, and hard to get wrong. Yes, you can create a batch file on windows and a bash script on linux, but an average user will not know about CLI flags. And an experienced user can make mistakes. A folder per identity is primitive and reliable. Remember the guy who shall not be named that now rots in solitary confinement for 9000 years? Yes, he made a simple, silly mistake. It happens. He didn't make any grave mistake or logical error, just an ordinary slip-up. Data being where it's not expected can bite.

The standard linux behaviour is already questionable. Sure, an experienced linux user knows about everything under the sun spamming to a dozen ill-defined ~/.config, ~/.local, ..., but that's not helpful for something of life-threatening magnitude.

I propose doing what the original richochet did. A simple zip file/binary for windows/linux on the website that is completely self-contained. Then we can go back to telling end-users to just 'go to x and download'.

Remember, an ordinary user believes deleting a desktop icon on windows uninstalls the program. The self-contained directory paradigm is intuitively graspable and leaves little room for mistakes.

The Tor browser bundle gets it right too, by the way. On linux, it also includes desktop files you can run directly, which will launch it without being attached to the terminal. And if you use a graphical file manager I believe they will also launch. = intuitively understandable for regular users, safe.

[pospeselr]

With 3.0.17 we now have portable binaries for all platforms apart from macOS (well sorta who knows w/ macOS).

You can run the ricochet-refresh executable with an argument indicating the profile directory eg:

$ ricochet-refresh /path/to/profile

We do need to implement a help page though.

[pospeselr]

So broadly speaking we're fighting an impossible to win battle here with regards to minimizing dist leaks. Or at the very least, all we can do at best is forever be playing catch-up with platform vendors.

Over in tor-browser lnd (hi I'm richard, Tor Project applications team lead and Tor Browser developer for some years) we're pretty much telling users to use Tails if Disk Leaks are a major part of their threat model.

This is because as an application running within an operating system and desktop environment, we fundamentally can't stop the leaks; we have no control over what explorer.exe writes into HKLM, what gets written to Linux syslogs, what gets written to whatever exists on macOS. Cleaning up such traces is theoretically possible of course but necessarily requires elevated privileges which opens op the possibility for all sorts of interesting security vulnerabilities (no thanks).

If your safety depends on a forensics expert not finding any trace of Ricochet-Refresh on your system, then go use an ephemeral operating system that is purpose designed and built with this threat-model in mind. Of course, we need to add support for https://gitlab.torproject.org/legacy/trac/-/wikis/doc/Tor_friendly_applications_best_practices to work on Tails.

[pospeselr]

motly fixed in 3.0.17 remaining work arguably in https://github.com/blueprint-freespeech/ricochet-refresh/issues/119

[elandorr]

Thank you for your reply.

With 3.0.17 we now have portable binaries for all platforms apart from macOS (well sorta who knows w/ macOS).

You can run the ricochet-refresh executable with an argument indicating the profile directory eg:

$ ricochet-refresh /path/to/profile

I thought that was already possible with -p or so.

That's still the opposite of what we had before you took over ricochet, though. Configs next to the binary used to be default, which is how it was often handed to people in need, even preconfigured. We can make shell scripts, but it's another step and misclicks are bound to happen. (Unsure if that even works on latest stock windows, at least ps needs to be manually whitelisted before you can click it. Good luck telling a "regular" user to open a shell or create a shortcut for adding the arg [that breaks the second the directory is moved].)

Agree, tails is always a good idea. That's also easier with a binary that is "portable" by default. E.g. having multiple identities without bothering with args was very easy. Just a small dir on a USB key. It could test for a running TOR instance and offer to use that.

I already mentioned OS traces years ago in the original thread, but that is not such a big deal when "portable". Ricochet is a simple program that doesn't need much other than TOR + config files/key. If you name the dir/file innocuously, the path traces windows leaves are harmless. Traces like these also (usually) disappear after a while. (Don't know how the latest windows handles it, haven't touched that in a while.) No idea why it would end up in linux syslogs.

There's also a big difference between being obvious and a real "forensic" investigation. Unless the target is obviously a "techy" who is suspected of "advanced" skills or at least accused of actively deleting, few investigators will bother dissecting esoteric system traces. Especially not for "low value targets" like all the mass arrests these days. One of the EU tyrannies uses a fancy automated tool now, but it still generates so much useless data, it costs money and time to look through.

It's not just about leaving traces of having used ricochet anyway. Your key and contact data should be in the same directory for usability. You don't want to mess around with such a critical tool, particularly not as a "regular" user who may not even find the files. One of the best use-cases for the original ricochet was setting it up for "regular people" who can handle a binary in a directory without too much risk of creating chat logs or losing track of the files. That's also why I'm not particularly fond of the new log export feature. Yes, someone can always copy paste it or even type it, but the less convenient, the less likely a "regular" user will start creating dumps. Config files with contacts/keys, chat logs, those are my main concerns.

Have a good one