begipok689 yeah pretty much, you can do some cyber-sleuthing to figure out some info on Speek!'s company's CEO (a former sales person, not a software person) but no one seems to have any idea who these people are, especially since there is a shared github account being used to push commits. Def not sketchy at all lol but I digress.
Ricochet-Refresh was most recently audited Spring of 2021, and much of the dev work since then has been focused on resolving main 'cyber-stalking' issue found there (some other issues such as crashes and shitty URL handling have been fixed and/or features entirely removed).
To summarize the problem: an onion service's online/offline status can be determined by anyone who knows its service id/onion address, so if you share your ricochet id publicly, anybody can just periodically try to open a TCP connection to it to determine your online/offline status. That sucks for hopefully obvious reasons.
See this issue for discussion: https://github.com/blueprint-freespeech/ricochet-refresh/issues/73
To fix this, we've developing something we call 'Gosling' which basically pulls out and generalizes the 'authentication' layer of Ricochet-Refresh and (mostly) fixes the above issue by enabling an 'offline' mode whereby you don't run your 'introduction' server. When in this mode other users would not be able to add you as a contact or see you as online, but your contacts would (as they have a separate 'endpoint' onion to connect to which is secret).
See https://github.com/blueprint-freespeech/gosling/blob/main/docs/protocol.md#cyber-stalking for more details 🙂
I say 'mostly' here because a malicious third party can still cyber-stalk you assuming:
- you are using 'shared' endpoint servers (so multiple trusted contacts connect to a single endpoint, see Gosling spec for details)
- they used to be a contact, but were removed (and their client auth revoked); the tor daemon (fortunately/unfortunately depending on you use case) informs you when it tries to connect to an onion service that is online but which requires client auth if you do not have the key
This scenario can be mitigated altogether if you use a unique onion service per contact, but I am somewhat hesitant to make that default behaviour to be kind to the tor network (one endpoint onion service per contact implies worst case n2 onion services, ie every ricochet user having an onion for every other ricochet user assuming everyone is 'friends').
