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
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.