Onion link, capability formatting

[n8fr8]

• v3 client auth cookie?
• obfs4 bridge included?

[tladesignz]

Let's discuss this!

@micahflee, @grote, please chime in!

Having a link URL and an extra private key piece is quite annoying.

I was thinking about the following formats:

http://:[email protected]/

and

http://example.onion/?key=privatekey

Both seem no good:

• E.g. Tor Browser definitely wants to use the key in the first form for HTTP basic/digest auth only, and even issues a warning, when the OnionShare server doesn't ask for HTTP auth.
• The latter might end up in server logs and where not.

For at least Android and iOS, we could of course work with custom schemes:

onionshare://:[email protected]/

But that's not universal and would mean, we would need to show one more thing in the UI and - even worse - explain it.

We could also register the apps to listen to specific domains, so we could do something like this:

https://onionshare.org/link?onion=example&key=privatekey

But that also only works on Android and iOS and makes the users leak stuff to our server and everything in between in all cases, where the app is not installed, resp. they're not on mobile.

Do we have any other options? I already asked in Tor Project and waiting for answer, but besides: do you know of any other documented thinking about this problem?

@n8fr8, why do you want to add bridge info into these links? What exactly are you thinking about there?

[grote]

Having a link URL and an extra private key piece is quite annoying.

I am personally not yet convinced that the gain of having an extra private key bit outweighs the UX issues.

• Do users share private key and onion address on different channels?
• Do we have any reason to think that (short lived) v3 onion addresses can be enumerated and discovered?
• Is having an extra private key more than security theater?

I think we agreed that MVP will just be the onion address without private key.

why do you want to add bridge info into these links?

Wouldn't the ability to force the receiver to use a custom bridge give the sender the ability to de-anonymize the receiver?

[n8fr8]

I think we agreed that MVP will just be the onion address without private key.

Yes agreed.

Do users share private key and onion address on different channels?

Yes potentially... you can share the key via qrcode scanning over a video call, while sharing multiple links for downloads over a wechat chat or even SMS if needed. You might have one person get a private key, and then share it in person at a group meeting. Then later all of those people can use it with future onion links they are sent.

Do we have any reason to think that (short lived) v3 onion addresses can be enumerated and discovered?

Always a good question, likely beyond our pay grade, but something we can/should keep an eye on @micahflee

Is having an extra private key more than security theater?

defense in depth!

Wouldn't the ability to force the receiver to use a custom bridge give the sender the ability to de-anonymize the receiver?

It was an idea to make the process of someone in China being able to connect to Tor quickly easier... but you are right, @grote it could be used maliciously. Again, we can leave it out for now, and think about it more with the Tor anti-censorship/rdsys team.

[tladesignz]

This is also discussed here:

https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/40642

The proposed solution there is to use a fragment instead of the query.

That's probably a good idea, as a fragment typically never leaves the browser, so accidental leaks are way less probable.