4 ms·
This blog post was really helpful. Thank you blamestross! My understanding of your concern: So long as there is a static WebTorrent tracker initiating the peer
by jckahn 4y ago
This blog post was really helpful. Thank you blamestross! My understanding of your concern: So long as there is a static WebTorrent tracker initiating the peer connections, the system can't be fully trusted. I agree with this, and I plan to counter this threat vector by enabling users to specify their WebTorrent pairing server and STUN/TURN relay servers. That way, concerned users can choose to self-host the relevant servers and effectively treat Chitchatter as a front end to those. Do you think that would address the concern you brought up?
Additionally, a core feature of Chitchatter is that all communication is ephemeral and not persisted to disk, ever. Even if peers are identified, there would be no record of what communication took place. Do you think that should sufficiently protect users?
- blamestross 4y ago"Sufficient" is a product perspective I don't really have. Anonymity isn't even a product most users want to buy and the users that do, you may not want as customers. There are reasons I strongly recommend you do not download the bitmessage Blockchain for example. I'll agree those ideas are better. My concerns are really only around "how to you meet in the middle". If you are running your own relay, what benefits does your software now have over a more general self-hosted chat? Design with "ease of deployment and use" in mind. I actually think this is a good start on that. "Never stored" is moot. "We don't store it" is better. You can at best promise the client the user is currently using isn't logging. Nothing stops the relay or the other clients. Any relay that can know the password owns all data going over it, and any other relay knows at least who is saying how much and when. "I can't afford to spy on you and I don't even want the liability of being able to do so" is the real argument. WebRTC using 3rd party MITM servers provides that in theory. In practice WebRTC degrades into servers acting as proxies a decent chunk of the time. You are basically at the cutting edge of message ephemeralness and security you can get out of a browser app right now.
- jckahn 4y ago> "Sufficient" is a product perspective I don't really have. Anonymity isn't even a product most users want to buy and the users that do, you may not want as customers. FWIW, Chitchatter is intended to be a community-driven project that takes no funding and makes no money. I'd like for it to exist as a sort of public good. So, there are no "customers" for this project. I've updated the README to clarify that. :) > My concerns are really only around "how to you meet in the middle". If you are running your own relay, what benefits does your software now have over a more general self-hosted chat? That makes sense. Having pairing and relay servers directly associated with Chitchatter is counterproductive because it effectively centralizes the overall solution. However, I'm imagining a variety of public pairing and relay servers that users could individually choose. It's not a great UX, but it seems like that would provide an effective anonymity solution. > You can at best promise the client the user is currently using isn't logging. Nothing stops the relay or the other clients. Any relay that can know the password owns all data going over it, and any other relay knows at least who is saying how much and when. Excellent point. There's only so much Chitchatter can do to solve this. I think the best solution is to inform the user of security concerns like this and encourage safer settings (like using non-default servers once the option to do so is implemented). > You are basically at the cutting edge of message ephemeralness and security you can get out of a browser app right now. That's what it seems like. It'll be interesting to see if a purely client-side solution for P2P browser networking develops, but as far as I know that is currently an unsolved problem.