search

blueprint-freespeech / ricochet-refresh

Anonymous peer-to-peer instant messaging
https://www.ricochetrefresh.net
Other
223 stars 27 forks source link

Ricochet-Refresh Version 4 Design Refresh #186

Open morganava opened 5 months ago

morganava commented 5 months ago

This is a issue to track the UX design for the next major Ricochet-Refresh series. Design updates are happening here:

Please use this issue to request design changes or chat about your UX-related requirements for the next major version!

UX Issues

Will check off issues when/if new designs would fix them:

Features With UX Requirements/Impact

webdingspowah commented 4 months ago

These feature-independent, purely UX related issues could likely be fixed before the next minor update: https://github.com/blueprint-freespeech/ricochet-refresh/issues/95 https://github.com/blueprint-freespeech/ricochet-refresh/issues/173

morganava commented 4 months ago

These feature-independent, purely UX related issues could likely be fixed before the next minor update: #95 #173

Happy to accept pulls to fix these issues, but I don't have the availability to investigate and fix these for the time being.

AyrA commented 3 months ago

With all these changes, I'm wondering if it would make sense to split the UI from the rest of the application. The two components would communicate through a HTTP api.

Amon other things, this would solve #73 because the backend can be run as a service on a device that is always online, eliminating the ability to probe a hidden service for availability, because it's always online this way. #133 also becomes easier because identity handling only has to be implemented in the backend, and for the frontend, the user can simply launch a second UI instance. If the API is simple enough it also makes it trivial for 3rd parties to implement their own UI.

morganava commented 3 months ago

@AyrA We've actually been developing Gosling to deal with #73 . Ideally I want to keep Ricochet-Refresh purely peer-to-peer, without the need of persistent connections or managing servers, etc. This does of course make things more difficult technically, but we we should expect users to have to run their own infra just to have anonymity.

But, you're on the right track re componentization. The high level plan for v4 is to create a breaking change to the protocol, base it on Gosling for the improved metadata protections, and develop a Rust crate with a C-FFI for the Ricochet-Refresh v4 protocol. This library would then be integrated into the official Ricochet-Refresh client, but potentially other front-ends could be built as well. I'd love a TUI interface for instance :D

AyrA commented 3 months ago

I don't think Gosling will fully solve #73. The root problem is that if you know a given hidden service name, you can look up its descriptor in the directory. This allows you to see if a service is online (or was very recently) in a fully passive manner. If you want to hide your online presence time you must keep the descriptor alive during your absence. And you can only do this by continuously publishing a new descriptor whenever the current one expires. This is why I was suggesting to split the application. If done properly it would not make it any more difficult for standard users because the application can be configured to run its own backend instance by default, but for expert users will allow them to run it separately and remotely. Basically like the Tor Browser which brings its own Tor client, but you can also download the client separately and run it as a service if you want to.

morganava commented 3 months ago

So just to start with there is no general solution to this problem (#73) that does not have trade-offs.

The current situation directly links your onion service online status with your IRL activity, so adversaries can secretly and passively build a profile of your online/offline status.

Your proposal fixes this problem with the trade-off of power users with a persistent connection can set up a forwarder/bouncer so you always seem online.

A resolution to https://gitlab.torproject.org/tpo/core/torspec/-/issues/150 would also be a potential solution with the tradeoff being initial contact discovery becomes harder (and you would need to give both your service id and some stealth client auth key) and if these credentials ever leaked you're back to the current status quo..

Gosling works around this problem by only requiring your 'public' identity be online for new friends to find you, and allowing trusted friends to connect to secret onion services. The trade-off here is a slightly more complicated UX/mental model and probably worse performance/scalability as your number of contacts grows.

Thinking on it though, I do think I like this idea of yours. I've been brainstorming about the implementation details of Ricochet-Refresh v4 along with UX updates. Coming from the browser space (Tor Browser dev here hi), I love the idea off sandboxing off the relevant processes the way browsers do, especially as we're planning on adding functionality for inline images and I really want to avoid the whole "lol bug in your image parser download this gif and get owned" problem. The entire Tor+chat protocol layer could be its own process. If we were to build this in by default then having this process be a remote one would be relatively straight forward (relatively doing a lot of work here).

The root of this difficulty is the of course the pure peer-to-peer requirement. Ricochet-Refresh aims to serve folks with the most extreme threat models (whistle blowers, activists, etc) first. I think it would be perfectly reasonable to have some other tool that drops this peer-to-peer requirement to allow for a central chat server to solve these problems (at the expense of metadata-resistance).