Opened 4 years ago

Last modified 11 months ago

#16221 new enhancement

Investigate WebRTC with TCP-ICE and hidden services

Reported by: mikeperry Owned by: tbb-team
Priority: Medium Milestone:
Component: Applications/Tor Browser Version:
Severity: Normal Keywords:
Cc: leif@…, gk, arthuredelstein, intrigeri, ln5, dmr Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description (last modified by 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
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/

Child Tickets

Change History (21)

comment:1 Changed 4 years ago by mikeperry

Description: modified (diff)

comment:2 Changed 4 years ago by mikeperry

Description: modified (diff)

comment:3 Changed 4 years ago by mikeperry

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

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.

comment:4 Changed 4 years ago by gk

Cc: gk added

comment:5 in reply to:  description Changed 4 years ago by 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 bugs 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.

Version 0, edited 4 years ago by gk (next)

comment:6 in reply to:  3 Changed 4 years ago by cypherpunks

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.

comment:7 Changed 4 years ago by arthuredelstein

Cc: arthuredelstein added

comment:8 Changed 4 years ago by mikeperry

Keywords: ff45-esr added; ff38-esr removed

comment:9 Changed 4 years ago by zyan

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.

comment:10 Changed 3 years ago by gk

Keywords: ff45-esr removed
Severity: Normal

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

comment:11 Changed 3 years ago by bugzilla

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

comment:12 Changed 2 years ago by mcs

Summary: Investiate WebRTC with TCP-ICE and hidden servicesInvestigate WebRTC with TCP-ICE and hidden services

comment:13 Changed 2 years ago by gk

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.

comment:15 Changed 2 years ago by intrigeri

Cc: intrigeri added

comment:16 Changed 14 months ago by cypherpunks

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?

Last edited 13 months ago by cypherpunks (previous) (diff)

comment:17 in reply to:  16 Changed 14 months ago by gk

Replying to cypherpunks:

PLZ CAN HAZ NICE THINGS?

PLZ CAN HAZ NICE PATCHES?

comment:18 Changed 13 months ago by ln5

Cc: ln5 added

comment:19 Changed 13 months ago by dmr

Cc: dmr added

comment:20 Changed 13 months ago by gk

Here is where we are when we switch to ESR 60: https://blog.mozilla.org/webrtc/active-ice-tcp-punch-firewalls-directly/.

comment:21 Changed 11 months ago by HostFat

Well, Tor Browser v8.0 is arriving, another step forward.

I see that there are updates here:
https://blog.mozilla.org/webrtc/the-evolution-of-webrtc/

Will it change more with the v1.0 webrtc spec at the end of the year?

Note: See TracTickets for help on using tickets.