Look into using Firefox for the WebRTC implementation

Reduce fingerprintability and solve Windows reproducible builds problem by replacing the current Chome-based C++ WebRTC implementation with Firefox's built-in WebRTC implementation.

Update: After discussions with dcf, it looks like fingerprintability is not much of a concern and in any case would be no different with Firefox vs Chrome. Also, since meek is moving to uTLS instead of Firefox this isn't necessarily more convenient.

Leaving this ticket open just as another alternative for looking at different WebRTC implementations (related: #28942 (moved))

added anti-censorship-roadmap component::circumvention/snowflake priority::medium resolution::wontfix severity::normal sponsor::28-can status::closed type::task labels

Trac:
Cc: dcf, arlolra to dcf, arlolra, gk

Trac:
Cc: dcf, arlolra, gk to dcf, arlolra, gk, cohosh

Trac:
Priority: Very High to Medium

Firefox is likely not the answer here as the workflow and details are very close to Chrome. Fingerprintability is not at the moment a problem, nor would Firefox likely provide a solution better than the current Chrome library.

Trac:
Summary: Use Firefox for the WebRTC implementation to Look into using Firefox for the WebRTC implementation
Description: Reduce fingerprintability and solve Windows reproducible builds problem by replacing the current Chome-based C++ WebRTC implementation with Firefox's built-in WebRTC implementation

to

Reduce fingerprintability and solve Windows reproducible builds problem by replacing the current Chome-based C++ WebRTC implementation with Firefox's built-in WebRTC implementation.

Update: After discussions with dcf, it looks like fingerprintability is not much of a concern and in any case would be no different with Firefox vs Chrome. Also, since meek is moving to uTLS instead of Firefox this isn't necessarily more convenient.

Leaving this ticket open just as another alternative for looking at different WebRTC implementations (related: #28942 (moved))

I had thought the idea here was to drive an actual firefox to talk webrtc to the snowflakes. That way Tor users would be talking webrtc just like firefox, because it would be firefox. Rather than linking in a library and trying to call it in the same ways that Firefox calls it (and react to errors and network conditions etc in the same way that Firefox reacts).

And we picked Firefox because "we already have one" in tor browser (though tor browser currently disables webrtc at compile time, but hey, nobody said this would be easy).

So, kind of like how meek launches a browser and drives it to do the domain fronting connection.

Replying to arma:

I had thought the idea here was to drive an actual firefox to talk webrtc to the snowflakes. That way Tor users would be talking webrtc just like firefox, because it would be firefox. Rather than linking in a library and trying to call it in the same ways that Firefox calls it (and react to errors and network conditions etc in the same way that Firefox reacts).

And we picked Firefox because "we already have one" in tor browser (though tor browser currently disables webrtc at compile time, but hey, nobody said this would be easy).

So, kind of like how meek launches a browser and drives it to do the domain fronting connection.

This was the idea, I had a conversation with dcf over email about it. Some key points brought up were:

• Using a headless browser is difficult and meek just moved to using uTLS for this reason (#29077 (moved)).

• What you mentioned with the currently disabled WebRTC:

"Omitting WebRTC is a safety measure to avoid IP address leaks; instead of disabling WebRTC through a runtime configuration option, the Tor Browser devs have decided not even to compile it."

• WebRTC fingerprintability isn't currently as much of an issue as, for example, the Firefox TLS fingerprints. There are so many variations in WebRTC implementations at the moment that fingerprinting is a long way out

So overall, I would say it's still something to consider, but we should evaluate it along with other options such as #28942 (moved) and try to figure out (esp. since headless Firefox is going away for meek) whether or not it actually makes our live easier. My understanding is that the "makes our lives easier" bit is more important at the moment than "stop all conceivable future fingerprinting attemps" especially since possible attempts are not well-defined at the moment.

Adding the keyword to mark everything that didn't fit into the time for sponsor 19.

Trac:
Keywords: N/A deleted, ex-sponsor-19 added

Moving from Sponsor 19 to Sponsor 28.

Trac:
Sponsor: Sponsor19 to Sponsor28-must

Trac:
Keywords: ex-sponsor-19 deleted, anti-censorship-roadmap-august added

Trac:
Sponsor: Sponsor28-must to Sponsor28-can

Trac:
Keywords: anti-censorship-roadmap-august deleted, anti-censorship-roadmap added

Fair to say we went with #28942 (moved) instead.

Trac:
Resolution: N/A to wontfix
Status: new to closed

closed

moved to tpo/anti-censorship/pluggable-transports/snowflake#29205 (closed)