Jeremy, thanks for Chitchatter and for bringing this up here. The first feedback I can give you is about the threat model and the associated OPSEC measures mentioned in the README.
Anyone with knowledge of the room UUID can listen to the conversation, even though the presence of the eavesdropper may (or may not) show up in the connected peers' counter. It is of essence to share such UUIDs over a secure channel, or the communication security will be compromised trivially.
It is mentioned in the README the relevance of government level threat actors and email, SMS, Discord, among the possible mediums over which the UUIDs can be shared. Of course this leaves Chitchatter open to be attacked by governments and network operators, who do have access to the phone network(s), email servers, and other platforms involved. It would be best to prefer other out-of-bound channels, or come up with one-time UUIDs generators able to resynchronise and shared among the peers.
That's a great point. I'll tweak the README a little later to suggest using https://burnernote.com/ (as others here have suggested) to more securely share room links. Thanks for the suggestion!
> Anyone with knowledge of the room UUID can listen to the conversation, even though the presence of the eavesdropper may (or may not) show up in the connected peers' counter.
Though much of Chitchatter's security model is based on security by obscurity, I don't know that peers would be able to connect without room participants being notified. Is there a scenario you have in mind where a peer would be able to connect and intercept messages without the peer counter incrementing?
An attacker may try to exploit bugs in the code base, or subtle language features (e.g., weird behaviours, overflows), in order to hide one or more connected endpoints. Further, in order to build assurance about the counter integrity, we would need to employ formal verification and code authentication techniques, so as to ensure that 1/ the software will behave only as intended, and 2/ nobody has tampered with the code base. In absence of such assurance guarantees – which are difficult to provide when the client can be instantiated essentially on any compatible device, the security of the protocol (ie., WebRTC + UUID out-of-band communication) reduces to software security of the code base.
> Further, in order to build assurance about the counter integrity, we would need to employ formal verification and code authentication techniques
Can you point me to resources that might help be understand what that might look like? I'm assuming it requires a third party to audit the project in-depth. I would further assume that such a service costs quite a bit of money. Chitchatter is not a revenue-generating project, so that would have to be to be figured out.
FWIW, I don't consider myself a security expert. I'm learning security best practices by developing Chitchatter. More than anything, I'm hoping to form a community of interested subject matter experts around this project to help build towards the vision of simple and secure communication! :)
Formal verification is basically mathematically proving the code does what you intend it to do - no third party auditors necessary. I'm not super familiar with it, but I've heard quite a bit about it in recent years.
The README is a bit optimistic about it the security model. Like the parent said the room UUID is a very critical asset and should be handled as a critical secret. Sadly, users may not know that.
In addition, the README says one can audit the full code and the assets used. For example, it suggests to audit the gh-pages branch for the static assets. But when hosting with github, that branch could change at any time and deliver non-audited content. Powerful attackers like government could do it easily, and less powerful ones too.
> For example, it suggests to audit the gh-pages branch for the static assets. But when hosting with github, that branch could change at any time and deliver non-audited content. Powerful attackers like government could do it easily, and less powerful ones too.
That's a great point. There's nothing stopping folks from producing their own builds and self-hosting Chitchatter though, so that seems like a reasonably easy problem to solve.
I started building this out last year to explore web crypto and webrtc but got sidetracked.
Have you looked into webcrypto? Create a new ecdh keypair for each session for each party, keep the private inextricable in memory, trade public keys over webrtc. This (I think) ensures no-one can evesdrop.
Peer auth could occur normally with ecdsa signatures done OUTSIDE of the browser or whatever.
Do you know if that might be mitigated by using Chitchatter via a Tor browser? I’m still building my understanding of the low-level mechanics of WebRTC.
There are multiple reasons why TOR is not a good fit for WebRTC tunneling. However, TOR is already capable of establishing p2p connections via hidden services.
I had a relevant thought just the other day: why do our chat apps (sms, wechat, etc) need the ability to message someone without first meeting face to face? Maybe just use a QR code you scan from their phone and that’s it. If anyone gets your phone number they can send you unwanted spam because it’s “push”
Butnernote.com could be a good way to share the room URL over generally insecure channels. After MVP, maybe an ephemeral room link could be created using the code from burnernote to save a step.
When you don't have a secure E2EE coms channel with someone, these services enable creation of a one time link that you can send over SMS/email. If the intended recipient is unable to open the link, you know your coms have been intercepted.
But who said they don't backtrack every note with sender IP index? I would do that, imagine the temptation to store all the secrets making a centralised secret notes service
Burnernote code is FOSS if you want to investigate how it works. As for IP addresses, you are probably aware of TOR and VPN's if you want that additional layer of obscurity.
There are numerous problems with that. First – why on earth i need to believe that the source hosted on Github is actually used to build burnernote.com bundle? The bundle is highly minified and obfuscated and the only way to check that is to build the same bundle on your machine and checksum. Did anyone ever did that? Another big issue is since it open-source – it relies on 1000 open-source dependencies, any one of them can be compromised, and the changes to them happening quicker than you can audit them all
Thanks for the post, nice to see new apps. In my experience with webRTC, a lot of the time the p2p connection does not get fully achieved, and the connection falls back to the server. Are you saying that the chat room will not run unless it is true p2p? If not, it would be good if the app shows the type of connection that is being used (p2p or via server).
Thanks for the feedback! Chitchatter uses https://www.metered.ca/tools/openrelay/ for relaying communication when P2P connections can't be established. So, chatting should "just work" for users right now. I don't know if the current connection type (P2P or relayed) can be determined by JavaScript. If not, it seems that allowing the user to disable relaying servers might be the safest option (at the expense of the app not actually working).
I was curious about this too. In my experience the real obstacle behind true p2p is everyone is behind a router or firewall these days with shared ip. Most also prevent hole punching through port randomization.
Yes, not many people measured NAT boxes at scale. "UDP NAT and Firewall Puncturing in the Wild" [1] this scientific article from our lab might be helpful.
We also have UDP puncturing also working in a 3G or wifi setting with Android-to-Android mode, see "Kotlin-IPv8" link in here: https://github.com/Tribler/trustchain-superapp
would be good to make the discovery be a module that can be replaced or used as a redundant plugin. That way the user can use DHT, WebTorrent, CloudFlare or whatever.
The library they are using does this. I wrote my own separate library that uses Cloudflare because it uses a bespoke protocol that takes advantage of some WebRTC hacks (SDP munging, DTLS certificate reuse, peer reflexive candidates, etc) to minimize I/O to R2 and hence reduce costs on Cloudflare.
This looks kind of interesting, can't dig too much into right now on my phone, but is the idea just for signalling while the "rooms/channels" are empty?
I'm not sure what the point might be in that case.
Or is it a cloudflare service based websocket service?
I'll check it out when I have a chance at Which point I'll probably have some more dumb questions!
It's a HTTP polling based Cloudflare worker that can be used to establish WebRTC connections. A signaling service of some kind is always necessary to use WebRTC. The OP uses WebTorrent trackers which can work but have some limitations and ultimately have their own risk profiles.
The Cloudflare worker approach offers some unique tradeoffs that make it compelling relative to other options:
- Outage risk is reduced down to Cloudflare workers platform. (vs volunteer-run services like WebTorrent trackers)
- The costs are zero for a moderate level of traffic. (I intentionally designed the protocol for this project to take advantage of the cheapest available approach on Cloudflare, which is free in the best case.)
I'm using https://github.com/dmotz/trystero for all the networking, and I don't think it supports p2pcf. If that existed a connection strategy for Trystero, I'd be open to experimenting with it!
Any application using WebRTC is forced to use some kind of centralized signaling service. The OP uses WebTorrent trackers. At least, until there's a well established analog to the BitTorrent DHT, but that doesn't seem likely anytime soon.
Thanks for taking a look! This is my first time hearing of Tox, so it’s hard to for me give a great answer at the moment. Based on a quick look at Tox, it seems that a key differentiator is that Chitchatter conversations are ephemeral. Also the Chitchatter client is web-based, so you can just share a room link without anyone having to install anything to participate.
The Tox website doesn't say anything about the architecture, neither does Wikipedia. Apparently it's a library implemented in C and everyone's expected to use that. The Wikipedia reference links are dead, the only 3rd party implementation says "On hold until Tox gets proper docs."
"Only rely on github" is amazing. And I have anticipated something crazier, maybe too crazy to be true. A server-less IM/forum mobile app which can hold persistant multi-party chatting.
I know, server-less can mean a lot of information loss. I'm simply wondering if people can still find each other after going offline and online with a different IP, and even somehow retrieve information during offline time.
As a tradeoff, the users understand and don't care if some messages are dropped (as chatters can figure it out using human brains) or security threats (MITM, eavesdropping, etc.).
Since I'm new to network and P2P, this can be nonsense. And if this is possible, can anyone provide some links concerning the problem?
first comment on HN :)
Cool project. I'm curious why you don't use Tor to provide peer-to-peer connectivity? It gives you NAT hole-punching and encryption for free. It seems the obvious choice.
Thanks for checking out the project! Chitchatter uses https://github.com/dmotz/trystero for peer connectivity, which doesn't support Tor. I don't know how Tor would be supported in a typical web browser. Have you seen Tor being used directly in that way?
The short of it is, sending secure messages without anonymity is pretty well solved, and while DHTs/webtorrent will buy you some obscurity, it can't solve any anonymity problems at scale.
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?
"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.
> "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.
Not sure how this was supposed to work but I had two different browsers (safari and Ddg) open on my phone connected to the same room.
When I sent a message from the second browser, it didn’t get delivered to anyone, and the first room showed a message saying “someone has left the room”.
Looks like your message identity is driven off ip or something unique to the device rather than browser.
Possible though I did try opening two DDG sessions connected to the same room. The room stayed open when I switched between the two DDG browser windows.
its interesting people are talking to each other and the conversation everyones taking part in the people cool and chill i dunno how to explain it, it the anonimity make people candid because i like it?
Or rather, a medium of communication can be considered secure exactly to the extent that it is useful for selling drugs i.e. the less useful for selling drugs, the less secure.
Anyone with knowledge of the room UUID can listen to the conversation, even though the presence of the eavesdropper may (or may not) show up in the connected peers' counter. It is of essence to share such UUIDs over a secure channel, or the communication security will be compromised trivially.
It is mentioned in the README the relevance of government level threat actors and email, SMS, Discord, among the possible mediums over which the UUIDs can be shared. Of course this leaves Chitchatter open to be attacked by governments and network operators, who do have access to the phone network(s), email servers, and other platforms involved. It would be best to prefer other out-of-bound channels, or come up with one-time UUIDs generators able to resynchronise and shared among the peers.