HN Explorer

89 comments

[ 4.8 ms ] story [ 170 ms ] thread
[deleted]
(comment deleted)
cjtrowbridge
I know this is an MVP but it seems unclear what meaningful structural improvements you're making over more feature-rich alternatives like Tox?
jckahn
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.
rendaw
What is Tox actually?

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

timbit42
Tox is distributed but your IP is visible. You can use Tox inside Whonix which forces Tox to go through Tor.

Briar is distributed but runs over Tor so your IP is hidden. You can't use Briar over Tor because it already uses Tor so it doesn't work in Whonix.

porcc
Excellent work. We need more of these build-it-once peer to peer serverless webpages.
saimiam
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.

djbusby
Could the browsers lose the connexion when not the app with focus on the phone? Like maybe it reset the websocket?
saimiam
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.
adg001
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.

kornhole
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.
[deleted]
(comment deleted)
jamesholden
Burnernote.com ? I think you meant?
edf13
How do the likes of Burnernote and yopass prove security/safety/offline?
kornhole
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.
gloosx
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
kornhole
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.
gloosx
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
feb
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.

dspillett
> should be handled as a critical secret. Sadly, users may not know that.

Or find it inconvenient at some point and think "it doesn't matter that much, does it?"...

As is often the case, the human is the weakest link in the security chain.

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

DreamFlasher
Initial key exchange via public private keys would be an amazing addition!
jwally
Agree.

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.

jckahn
This is an interesting idea. How do you envision this working, broadly speaking?
ajconway
On top of that, like every p2p service without onion routing, one's IP address is visible to every other room participant by design.
jckahn
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.
easrng
Pretty sure Tor browser has WebRTC turned off.
jckahn
I didn't realize that. That's a bummer. =/
ajconway
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.
jckahn
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?

adg001
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.
jckahn
That makes sense. Thank you for the explanation!

> 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! :)

piperswe
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.
jckahn
Interesting! This isn't something I know anything about. I will research it!
TheJoeMan
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”
gfodor
Author might be interested in a recent thing I released to use a cloudflare worker instead of webtorrent servers for signaling:

https://github.com/gfodor/p2pcf

earnesti
Sounds centralized
gfodor
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.
Sophira
Wouldn't that make it centralised, though, with Cloudflare being necessary for it to work?
nl
https://github.com/dmotz/trystero#how-it-works

You always need some kind of centralization for discovery with WebRTC.

deepstack
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.
gfodor
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.
bilekas
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!

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

deepstack
gfodor, just FYI your link on github is not working. I get "We had issues producing the response to your request." from github.
jckahn
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!
SquidJack
I can access anyone room just simply changing the MD5 hash url Random Password protection for room may be the best feature
[deleted]
(comment deleted)
anon115
can i use this to sell drugs?
geysersam
Yes, any medium of communication can be used to sell drugs. There's a theorem fo that.
pessimizer
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.
laserfly
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).
ackbar03
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.
jlokier
Tailscale comes up here a lot recently, and their article on how they do p2p over routers and firewalls (NAT traversal) is superb: https://tailscale.com/blog/how-nat-traversal-works/

Unfortunately it doesn't include statistics on how successful the strategies are in practice.

jckahn
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).
anon115
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?
can16358p
Perhaps irrelevant question but:

Why does it have the feeling of something being designed by Google?

onion2k
Because it's a new chat app.
can16358p
Too bad it will be discontinued soon then.
o_m
The components are made with MUI, which is a component library based on Material design, originally created by Google.
wgx
It uses Google’s Material Design UI kit, pretty much out of the box with no tweaks. Hence looking very “Googley”.
DeathArrow
If I would try something like that, I would use a spy camera and image recognition.
nl
Specific suggestions:

Make it clear you can use markdown

Have a max size of message (noting that MD can make short messages take a lot of space)

Allow rooms to have names

QR Code to link to room

jckahn
These are excellent suggestions. Thank you! I will add this to my list of improvements to make to the app. :)
deknos
i just wish, magic wormhole also would adopt open stun/turn relays like this :(
blamestross
Why write a really long hn post when you can write a blog post: https://www.miasma.space/anon-dhts/

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.

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

e12e
> If you would like to verify that the app hosted at https://chitchatter.im/ is the one that is hosted on GitHub, you can use dig:

And if you trust github/Microsoft to not play games on what is delivered to you (say, because someone backed by the patriot act asked them to).

pandemicsoul
Oh good, another service where people can plan genocide and exchange pedo content!
snewhacker
"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 :)
jstanley
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.

For an alternative (but sadly barely-used) chat protocol that does use Tor, see Ricochet: https://en.wikipedia.org/wiki/Ricochet_(software)

jckahn
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?
timbit42
Another option is I2P which, unlike Tor, supports UDP.