Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Mozilla Project Fusion: Tor Integration into Firefox

trac.torproject.org

Post reply on HN
Print view View original

201–210 of 242 posts

Re: Mozilla Project Fusion: Tor Integration into Firefox

#201

Post by actuator »

Hello71 wrote: post #191
darpa_escapee wrote: post #157

Earlier quoted context omitted.

Cloudflare.

Source? Cloudflare did post a moderately hostile response to Tor a few years back, but their technical implementation is sound and does not present multiple CAPTCHAs to users who have cookies enabled (the CAPTCHA might be broken with JS off, but that's a Google problem).

Even I have seen CF captchas on multiple sites when using Tor. Though might be because of my usage pattern where I use Tor for a selective list of sites giving CF less chance to maintain my identity.

Re: Mozilla Project Fusion: Tor Integration into Firefox

#202

Post by Vinnl »

bunkydoo wrote: post #185

I believe Tor browser is already just a version of Firefox if I'm not mistaken. What would be the advantage of integrating with Firefox as opposed to say, a VPN integrated into the browser via a plugin. Just seems a little redundant and Tor is beginning to seem dated also with new solutions popping up and making the pitfalls of Tor more apparent.

I think an important part is to lessen the maintenance burden for the Tor project: if the code is in Firefox proper, Firefox developers will encounter it when working on other features and make sure they work together, whereas currently the Tor project needs to rebase their modifications onto "regular" Firefox.

Re: Mozilla Project Fusion: Tor Integration into Firefox

#203

Post by mirimir »

pathseeker wrote: post #165
openasocket wrote: post #63

Earlier quoted context omitted.

Tor is slow because every packet has to be routed through several random servers distributed all over the world with multiple layers of crypto at every pass. Even with plenty of top-of-the-line inner and exit nodes you will still see substantially more latency than just sending packets directly.

No, IPSec tunnels to remote headquarters have indistinguishable latency impacts for normal users browsing (<150ms). The bad latency is because of congestion, not crypto and multiple hops.

Mirimir typically uses a three-VPN nested chain. Just now, rtt to google.com was ~260 msec. That's four hops. Just not with servers on the far side of the planet.

Re: Mozilla Project Fusion: Tor Integration into Firefox

#204

Post by gsnedders »

crunchatized wrote: post #151
hollerith wrote: post #138

Earlier quoted context omitted.

Could someone please explain what "OEM configs" means here?

Looking it up, I think the more accurate term is actually "partner repacks." [1] They're versions of Firefox shipped with different default settings and/or an extension included by default at install time, IIUC. Though reading this rather opaque page [2] it doesn't seem to explicitly preclude patches to the compiled code, though it seems like they would forbid that. The key config file is distribution.ini. [3] [1] ht…

I haven't looked into it in a while, but last I knew you had to have MoFo sign-off on a bunch of stuff, including code changes (i.e., you're only allowed to use the Firefox branding if you get MoFo sign-off on those changes; you can always redistribute it without the trademarks).

Re: Mozilla Project Fusion: Tor Integration into Firefox

#205

Post by gsnedders »

floatboth wrote: post #152
kodablah wrote: post #29

Cool, now let me start an ephemeral v3 onion service from JS and have it reachable via WebRTC by a peer who has their own. It's the perfect tech marriage, removes signalling servers and NAT busters, but may be a bit taxing on directory servers and too slow to use for media streams (but I'll take data channels only).

Hah, kinda reminds me of Opera Unite. (That one wasn't from JS, it offered some fixed applications like file hosting, notes, etc., but it was hosting stuff from the browser)

Unite allowed server-side JavaScript (though I forget how many privileged APIs there were), but I don't think you could support custom protocols.

Re: Mozilla Project Fusion: Tor Integration into Firefox

#206

Post by gsnedders »

bzbarsky wrote: post #190
neokantian wrote: post #150

"Removing fingerprintability" amounts to the browser just NOT sending all the http request headers that it sends by default. How hard can it be to "comment out" these lines?

I just checked and there are over 100 checks for "should I have different behavior here if I am resisting fingerprinting?" just in the C++ code in Firefox today. There are some more in the JS code but they're harder to search for. Some simple examples: * Various navigator APIs (oscpu, platform, etc) need to be disabled. * Gamepad API needs to be disabled. * Have to prevent reading canvas pixel data * Have to block in…

Need to do something about fonts and the CSSOM (Element.getBoundingClientRect() for example), too.

Just shipping a standard bundled set of fonts and only allowing use of that doesn't suffice because anti-aliasing width differences could give away the used font renderer.

Re: Mozilla Project Fusion: Tor Integration into Firefox

#207

Post by jerheinze »

fwdpropaganda wrote: post #193

> How many more "super private browsing mode" Firefox users will there be? Potentially hundreds of millions of daily users. Tor has hundreds of millions of daily users?

https://metrics.torproject.org/userstats-relay-country.html

Re: Mozilla Project Fusion: Tor Integration into Firefox

#208

Post by jerheinze »

tomrittervg wrote: post #181
MayeulC wrote: post #178

Great news ! With wider adoption of ipv6 and all the good things that come with it (don't mistake me, they are great!) also comes the risk that each computer will get a uniquely identifiable IP address that will be used for fingerprinting. I've never really used Tor in the past, but this got me thinking about it. An option could be to provide a webRTC-based node, but I am not sure how feasible that would be, after re…

> An option could be to provide a webRTC-based node, but I am not sure how feasible that would be, after reading some comments here. I'll point you at FlashProxy ( https://crypto.stanford.edu/flashproxy/ ) and Snowflake ( https://github.com/keroserene/snowflake ) the latter of which is in active development. =)

https://trac.torproject.org/projects/tor/wiki/doc/Snowflake

Re: Mozilla Project Fusion: Tor Integration into Firefox

#209

Post by JohnTHaller »

gsnedders wrote: post #204
crunchatized wrote: post #151

Earlier quoted context omitted.

Looking it up, I think the more accurate term is actually "partner repacks." [1] They're versions of Firefox shipped with different default settings and/or an extension included by default at install time, IIUC. Though reading this rather opaque page [2] it doesn't seem to explicitly preclude patches to the compiled code, though it seems like they would forbid that. The key config file is distribution.ini. [3] [1] ht…

I haven't looked into it in a while, but last I knew you had to have MoFo sign-off on a bunch of stuff, including code changes (i.e., you're only allowed to use the Firefox branding if you get MoFo sign-off on those changes; you can always redistribute it without the trademarks).

That's correct. At least it was the last time I chatted with the Mozilla folks about it and from a quick read of their current trademark policy.

Re: Mozilla Project Fusion: Tor Integration into Firefox

#210

Post by jerheinze »

zrm wrote: post #199
pricechild wrote: post #164

Earlier quoted context omitted.

That said, plenty of providers use the list of tor relays (which is also public) to block traffic. Sites such as https://www.dan.me.uk/dnsbl then help people do this. That site in particular may "warn": > This DNS blacklist contains ALL tor nodes (entry, transit and exit nodes) - think carefully before choosing to use this list for blocking purposes. but anyone who doesn't understand tor simply won't understand the d…

One way to help that avoids this is to operate a bridge node. Bridge nodes are used as entry points into the Tor network for people in regions where Tor is blocked, so efforts are made to keep the addresses of bridges confidential. Which makes it less likely that people who don't know what they're doing will wrongfully put it on a block list.

One can also run pre-bridges for the snowflake transport by just having some JS code run in a browser's tab (requires WebRTC to be enabled): https://trac.torproject.org/projects/tor/wiki/doc/Snowflake
Post reply on HN