Investigate WebRTC with TCP-ICE and hidden services

Mozilla added support for WebRTC over TCP, and WebRTC proxy support in Firefox 34 and 38: https://bugzilla.mozilla.org/show_bug.cgi?id=891551 https://bugzilla.mozilla.org/show_bug.cgi?id=949703

This might mean we can actually enable WebRTC now, if we turn off all of the IP address discovery and non-TCP ICE mechanisms: https://github.com/diafygi/webrtc-ips

We could also potentially list a hidden service address as a WebRTC ICE endpoint, though we would need to be careful about this since it means that potentially every Tor Browser user who visits a WebRTC-enabled page would suddenly spin up a hidden service. I wonder if we can have Tor create the keys for a hidden service without actually starting it up unless it is actually negotiated by WebRTC. OTOH, it may not be helpful to have an address that isn't accessible yet. I suppose it depends on how the ICE handshake works and how addresses are tried/negotiated.

This suggestion actually came from wiretapped (leif). WebRTC is no longer just for making calls. Tons of crazy decentralized apps are being built on top of it. Ex: https://instant.io/

added component::applications/tor browser owner::tbb-team priority::medium severity::normal status::new type::enhancement labels

Trac:
Description: Mozilla added support for WebRTC over TCP, and WebRTC proxy support in Firefox 34 and 38: https://bugzilla.mozilla.org/show_bug.cgi?id=891551 https://bugzilla.mozilla.org/show_bug.cgi?id=949703

This might mean we can actually enable WebRTC now, if we turn off all of the IP address discovery and non-TCP ICE mechanisms: https://github.com/diafygi/webrtc-ips

We could also potentially list a hidden service address as a WebRTC ICE endpoint, though we would need to be careful about this since it means that potentially every Tor Browser user who visits a WebRTC-enabled page would suddenly spin up a hidden service. I wonder if we can have Tor create the keys for a hidden service without actually starting it up unless it is actually negotiated by WebRTC.

to

Mozilla added support for WebRTC over TCP, and WebRTC proxy support in Firefox 34 and 38: https://bugzilla.mozilla.org/show_bug.cgi?id=891551 https://bugzilla.mozilla.org/show_bug.cgi?id=949703

This might mean we can actually enable WebRTC now, if we turn off all of the IP address discovery and non-TCP ICE mechanisms: https://github.com/diafygi/webrtc-ips

We could also potentially list a hidden service address as a WebRTC ICE endpoint, though we would need to be careful about this since it means that potentially every Tor Browser user who visits a WebRTC-enabled page would suddenly spin up a hidden service. I wonder if we can have Tor create the keys for a hidden service without actually starting it up unless it is actually negotiated by WebRTC.

This suggestion actually came from wiretapped. WebRTC is no longer just for making calls. Tons of crazy decentralized apps are being built on top of it. Ex: https://instant.io/

Trac:
Description: Mozilla added support for WebRTC over TCP, and WebRTC proxy support in Firefox 34 and 38: https://bugzilla.mozilla.org/show_bug.cgi?id=891551 https://bugzilla.mozilla.org/show_bug.cgi?id=949703

This might mean we can actually enable WebRTC now, if we turn off all of the IP address discovery and non-TCP ICE mechanisms: https://github.com/diafygi/webrtc-ips

We could also potentially list a hidden service address as a WebRTC ICE endpoint, though we would need to be careful about this since it means that potentially every Tor Browser user who visits a WebRTC-enabled page would suddenly spin up a hidden service. I wonder if we can have Tor create the keys for a hidden service without actually starting it up unless it is actually negotiated by WebRTC.

This suggestion actually came from wiretapped. WebRTC is no longer just for making calls. Tons of crazy decentralized apps are being built on top of it. Ex: https://instant.io/

to

Mozilla added support for WebRTC over TCP, and WebRTC proxy support in Firefox 34 and 38: https://bugzilla.mozilla.org/show_bug.cgi?id=891551 https://bugzilla.mozilla.org/show_bug.cgi?id=949703

This might mean we can actually enable WebRTC now, if we turn off all of the IP address discovery and non-TCP ICE mechanisms: https://github.com/diafygi/webrtc-ips

We could also potentially list a hidden service address as a WebRTC ICE endpoint, though we would need to be careful about this since it means that potentially every Tor Browser user who visits a WebRTC-enabled page would suddenly spin up a hidden service. I wonder if we can have Tor create the keys for a hidden service without actually starting it up unless it is actually negotiated by WebRTC. OTOH, it may not be helpful to have an address that isn't accessible yet. I suppose it depends on how the ICE handshake works and how addresses are tried/negotiated.

This suggestion actually came from wiretapped (leif). WebRTC is no longer just for making calls. Tons of crazy decentralized apps are being built on top of it. Ex: https://instant.io/

Skimming some docs makes it seem like it may be possible to advertise a non-running HS address before agreeing to use it (http://www.html5rocks.com/en/tutorials/webrtc/infrastructure/ is very good).

However, it also sounds like signaling/call setup is going to be very custom and webapp dependent. It is likely that many WebRTC apps will simply barf if they see an onion address instead of an IPv4 address passed through their signaling systems . But it sounds like well-designed apps should theoretically be able to handle non-live onion address negotiation properly, in a way that will also allow us to bring up the hidden service only when it has actually been negotiated by both parties.

Trac:
Summary: Enable WebRTC with TCP-ICE (and hidden services?) to Investiate WebRTC with TCP-ICE and hidden services

Trac:
Cc: leif@synthesize.us to leif@synthesize.us, gk

Replying to mikeperry:

Mozilla added support for WebRTC over TCP, and WebRTC proxy support in Firefox 34 and 38: https://bugzilla.mozilla.org/show_bug.cgi?id=891551

Well, parts of that bug got fixed, yes, but the important one, part 5, which is adding support for TCP candidates has not even landed on mozilla-central yet it seems. Thus, this won't be in scope for ESR 38 then given the code complexities, I think.

Replying to mikeperry:

Skimming some docs makes it seem like it may be possible to advertise a non-running HS address before agreeing to use it

Is this just to prevent hidden services from being silently created when the user doesn't want them?

I don't think it's necessary or desirable to do something with an ephemeral onion address before publishing its descriptor to the HSDirs. Instead, I think when a website tries to initiate WebRTC in Tor Browser it should initially fail (as it does now) but prompt the user (with the standard permissions prompt, like it does for canvas reads) asking something like "Do you want to allow incoming connections to your browser while you're viewing this site?". If the user says yes, an ephemeral onion should be created and the page should reload.

Trac:
Cc: leif@synthesize.us, gk to leif@synthesize.us, gk, arthuredelstein

Trac:
Keywords: ff38-esr deleted, ff45-esr added

If there's anything you need from the WebRTC spec in order to do this, let me know. We (the W3C technical architecture group) is in the process of doing a webrtc review.

While this is worthwhile this is not related to ESR45 in particular.

Trac:
Reviewer: N/A to N/A
Keywords: ff45-esr deleted, N/A added
Sponsor: N/A to N/A
Severity: N/A to Normal

Seems Mozilla has discovered what Proxy Obedience means: https://hg.mozilla.org/mozilla-central/rev/f17f59899b31.

Trac:
Summary: Investiate WebRTC with TCP-ICE and hidden services to Investigate WebRTC with TCP-ICE and hidden services

https://bugzilla.mozilla.org/show_bug.cgi?id=1176382 seems relevant. In particular https://bugzilla.mozilla.org/show_bug.cgi?id=1179345 needs to land first at least for this to work with e10s.

But see: https://blog.mozilla.org/webrtc/active-ice-tcp-punch-firewalls-directly/

Trac:
Cc: leif@synthesize.us, gk, arthuredelstein to leif@synthesize.us, gk, arthuredelstein, intrigeri

There is a lot of awesome p2p stuff happening with WebRTC nowadays, and Tor Browser is left out of all of this. Is anyone working on building ephemeral hidden service WebRTC integration?

https://github.com/Chocobozzz/PeerTube is one example awesome webrtc thing that actually does work with Tor Browser today, albeit not with webrtc, so, Tor users are all leeches (only able to get the video from the peertube instance's server, which typically has limited resources) Ideally TBB users could connect to eachother's onions, but, even lacking that, it would at least be nice of TBB users could make outbound connections to peers even if they can't receive inbound connections.

js-ipfs is also nice but also requires WebRTC.

PLZ CAN HAZ NICE THINGS?

Replying to cypherpunks:

PLZ CAN HAZ NICE THINGS?

PLZ CAN HAZ NICE PATCHES?

Trac:
Cc: leif@synthesize.us, gk, arthuredelstein, intrigeri to leif@synthesize.us, gk, arthuredelstein, intrigeri, ln5

Trac:
Cc: leif@synthesize.us, gk, arthuredelstein, intrigeri, ln5 to leif@synthesize.us, gk, arthuredelstein, intrigeri, ln5, dmr