Easier sharing of private rooms

[NasalDaemon]

Should be able to send a private room URL which includes the password, such that one doesn't need to type in the room password. This is already an established pattern with zoom calls.

This can be contained purely in the local javascript layer by putting the password in the part of the URL after the hash #, since anything after hash is not sent to the server in the HTTP request.

If there's a concern about the URL being too readable, potentially a hash of the password is in the URL, rather than the password itself, and manually entered passwords are internally hashed to the same value before being passed to Trystero api call.

[NasalDaemon]

Should be an easy way to share the private room with password in URL if so chosen, but probably shouldn't be default.

[jeremyckahn]

Hi @NasalDaemon, thanks for making this feature request! I agree that it should be easier to share private room passwords. We'll need to avoid embedding the password as plaintext in the URL, as it would then be visible to any system that transmits the room URL (such as Slack/Discord/SMS).

If there's a concern about the URL being too readable, potentially a hash of the password is in the URL, rather than the password itself, and manually entered passwords are internally hashed to the same value before being passed to Trystero api call.

It's not clear to me how this would this be more secure than a public room with random UUID room name, or more convenient than the way private rooms currently work. It seems like the room name would effectively just be getting hashed twice, wouldn't it?

[NasalDaemon]

It's not clear to me how this would this be more secure than a public room with random UUID room name, or more convenient than the way private rooms currently work. It seems like the room name would effectively just be getting hashed twice, wouldn't it?

Without the password, the SDPs are not encrypted on the tracker. https://github.com/dmotz/trystero#encryption. Since the secret doesn't leave the browser, being after the #, it gives protection against MITM attacks.

In addition, the private room offers extra privacy features like lack of backfilling for new peers that doesn't rely on the security of the secret.

If you are using a secure method to send the password to somebody, then it would be convenient if they can open the room in one go via an URL that contains both the room name and some representation of the password. To be honest, hashing the password in the URL to make it less readible is probably overkill, but offers protection from side channel attacks (e.g. somebody quickly looking over your shoulder and reading the password).

Perhaps the UX for sharing the URL with the password should mention that the URL with password (hashed or not) should only be transmitted over a secure medium, just like the plaintext password would be. It is purely a convenience feature to avoid typing in or copying passwords.

[jeremyckahn]

Without the password, the SDPs are not encrypted on the tracker.

That's accounted for in public rooms: https://github.com/jeremyckahn/chitchatter/blob/5d3d019cd6a528e7c89d45cde0ed92440d599a12/src/components/Room/useRoom.ts#L46

Since there is no password, the room name is used as the password to hash the SDP string with. So, users should already be protected in that regard.

Perhaps the UX for sharing the URL with the password should mention that the URL with password (hashed or not) should only be transmitted over a secure medium, just like the plaintext password would be. It is purely a convenience feature to avoid typing in or copying passwords.

I think this might be glossed over by less technical users, which is the primary target audience for Chitchatter. I'd rather err on the side of inconveniencing users if that means nudging them towards safer usage habits. Passwords and room names should be shared via separate channels (such as sharing the room link through Discord and the password through SMS).

I'm open to more convenient ways of sharing passwords for private rooms, but I don't think it's prudent to encourage users to use the same channel for sharing the room name and password or have the password available in plaintext (within Chitchatter, anyways). Do you have thoughts on other ways this might be achieved?

[NasalDaemon]

Without the password, the SDPs are not encrypted on the tracker.

That's accounted for in public rooms:

https://github.com/jeremyckahn/chitchatter/blob/5d3d019cd6a528e7c89d45cde0ed92440d599a12/src/components/Room/useRoom.ts#L46

Since there is no password, the room name is used as the password to hash the SDP string with. So, users should already be protected in that regard.

Sorry, but that offers no security, it's not much better than no password. That can be considered broken for an adversary who wants to find your IP. In other words, public rooms are still public in terms of SDPs.

If we're worried about novice users, there are ways of making it difficult for them to do silly things. For example, if they find the button to get the URL with the secret, instead of copying an URL straight to the clipboard, a windows pops up with a red message saying "this URL contains a secret, it must be shared by secure means or the room will be compromised", they tick a box to say they understand, and then they can use the URL.

If one is to trust a secure medium for password transfer, then one should be able trust it for transferring the room name too. If one is worried about the competence of a peer to keep a secret, then one should already consider the room compromised as soon as that peer knows the password by any means. The secret in the URL could be prepended with some obvious hint like secret= or even secretDoNotShare=.

This is a convenience feature for people to join the room, so they don't have to faff around with separate passwords etc. If we want to make it difficult for an existing peer to compromise the room, then there are still ways of doing it without imposing inconvenience on everyone else. At some point you have to trust the peers in the room not to compromise it, else it's not really a private room at all.

I think it will be an increase security for the average user over public rooms, while still having the convenience similar to public rooms. For people really worried about privacy, it's up to them whether to share the url that contains the secret or not, but in the end they should have some level of trust in the peers they invite, and the medium through which they do so. The decision still lies with them, and there's still a tick box or other hurdle to jump over to make it foolproof.

[jeremyckahn]

Sorry, but that offers no security, it's not much better than no password. That can be considered broken for an adversary who wants to find your IP. In other words, public rooms are still public in terms of SDPs.

This is not quite true, as Trystero hashes the offer name:

https://github.com/jeremyckahn/trystero/blob/c0ccbe938283f6c8f8650df059ec87d2249c0943/src/torrent.js#L49-L50 https://github.com/jeremyckahn/trystero/blob/c0ccbe938283f6c8f8650df059ec87d2249c0943/src/torrent.js#L215-L219

So even by default, Chitchatter room names and SDPs are hidden from the WebTorrent tracker.

If we're worried about novice users, there are ways of making it difficult for them to do silly things. For example, if they find the button to get the URL with the secret, instead of copying an URL straight to the clipboard, a windows pops up with a red message saying "this URL contains a secret, it must be shared by secure means or the room will be compromised", they tick a box to say they understand, and then they can use the URL.

This seems like a reasonable UX to prevent mishandling of room passwords. It trades a bit of security for convenience, so it would need to be opt-in functionality. You've made a good case for this feature, so I'm willing to keep an open mind towards accepting a PR to explore this idea. 🙂

[NasalDaemon]

Sorry, but that offers no security, it's not much better than no password. That can be considered broken for an adversary who wants to find your IP. In other words, public rooms are still public in terms of SDPs.

This is not quite true, as Trystero hashes the offer name:

https://github.com/jeremyckahn/trystero/blob/c0ccbe938283f6c8f8650df059ec87d2249c0943/src/torrent.js#L49-L50 https://github.com/jeremyckahn/trystero/blob/c0ccbe938283f6c8f8650df059ec87d2249c0943/src/torrent.js#L215-L219

So even by default, Chitchatter room names and SDPs are hidden from the WebTorrent tracker.

Again, this does somewhat obscure things from the tracker if it knows nothing about chitchatter, but it's not really cryptographically secure if they do know about chitchatter and the room name, since they can derive the offer and the "password" from it just by looking at the source code. Security by obscurity is not really security you can rely on if we really get serious about this.

I'm not saying hashing the room name for the offer and password are bad ideas, but they don't guarantee privacy from anybody who actually wants to know who the peers are.

Obviously, if the public room name is random with plenty of entropy, you're in a good place, apart from the fact that the room name is sent as part of the http request to the host. Also, you'd be losing the ability to share the room in more than one way. You can't share a random room name verbally. Being able to share a nice room name and password, while also being able to share a simple link including the secret (which is never sent in the http request) is the golden spot.

For example, the combined room and pass link removes the possibility of mistakenly typing the wrong password or room name and ending up in the wrong room and potentially speaking to the wrong people.

If we're worried about novice users, there are ways of making it difficult for them to do silly things. For example, if they find the button to get the URL with the secret, instead of copying an URL straight to the clipboard, a windows pops up with a red message saying "this URL contains a secret, it must be shared by secure means or the room will be compromised", they tick a box to say they understand, and then they can use the URL.

This seems like a reasonable UX to prevent mishandling of room passwords. It trades a bit of security for convenience, so it would need to be opt-in functionality. You've made a good case for this feature, so I'm willing to keep an open mind towards accepting a PR to explore this idea. 🙂

I'm glad you to hear that you think that the feature is appealing. 😊

Unfortunately I am a complete novice when it comes to client side web dev, no where near your level, so there's a learning curve that I would need to overcome before I could submit a PR for this feature. As you well know, being able to read code in another language is much simpler than writing it yourself. If you truly think this feature is valuable, I am sure your deft hands will be able to whip something up 10x faster than mine.

So it is really up to you how you want to prioritise this feature. If you were to leave it to me to create a PR, it's probably something like putting it near the bottom of the pile. I have no idea how long it would take me, maybe it would take a day, maybe several weekends that I happen to have free to code (not many this side of Christmas).

[jeremyckahn]

Thanks for the explanation @NasalDaemon. This feature isn't a high priority to me personally, so I'm not likely to build it myself in the near future. I'd support anyone who wants to build this functionality, and I'm happy to shepherd along any PRs. In any case, my availability will be pretty limited through the end of this month. Let me know if you get around to working on a PR for this (or if anyone else reading this would like to).