>You can also run Tor relays and help us improve the health of the network by working with Tor's new Relay Advocate

Since I've seen this come up before in many previous discussions of Tor I think it's worth emphasizing/clarifying up front: Tor relays are not the same as Tor exit nodes. Relays do not talk to the public internet, they serve only the full encrypted internal Tor virtual network. So they won't ever send out traffic from an IP under your control to some website or general Internet system (and in turn tie that IP in any way to spam/abuse/whatever, at least not for that reason). It's not necessarily hidden that it is acting as a relay, but the relay itself will have no knowledge of the traffic it's carrying.

Plenty of people have reasonable concerns about the risks/inconveniences that might come with acting as an exit node, but on both a legal and practical level there are many more jurisdictions where merely relaying encrypted traffic between other relays isn't a problem. And it's still quite helpful, both for network speed and because purely internal Tor Hidden Services do not need any exit nodes at all.

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 decision and choose ALL.

Running a relay on your own address isn't sensible because of this. Nevermind an exit node.

As someone who has run a relay on my home network for years now this has never come up. At least not that I've been able to discern.

I think it might be a problem if I also ran a mail server from home, but almost nobody does that anymore.

I do, and I've run a Tor relay at home as well (also exit for a while).

Yes, this is a common complaint from relay operators. Running relays at home, or on work networks, is risky.

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

I had nothing but pain when trying to run an exit node. Every site behind cloudflair would captcha me on what seemed like every page. Cox shut off my internet every other week due to "computers on my network being infected with viruses", and I'd have to call their support and tell them I cant be infected I only run linux at home.

I could do some shenanigans on my modem and end up with a new dynamic IP from cox, but generally within hours that new IP would be on whatever list people use to track exit node IPs and the pain would start all over again.

Tor publishes a list of all exit nodes, anyone could have flagged your new IP as an exit immediately after your client reconnected to the network.

And plenty of people insist that Tor relays are totally safe to run. They are not. I NEVER ran an exit node from my home IP, only relays, and my IP was still blacklisted from various sites due to this behavior.

I still contribute to Tor via VPS rentals and such, but relays are not no-risk alternatives to exit nodes. Period.

This is also, sadly, why the individual V4 /24 netblock of cheap VPS providers have terrible IP space reputations in most aggregated abuse systems.

Do you have any idea why it's unsafe? In theory, public site should even be able to see your IP. How would they blacklist you?

Edit: nvm, found the answer by pricechild below.

Seconding the other posters who mentioned that tor relays and Tor exit nodes are two very different things.

"Why you need balls of steel to run a Tor exit node":

https://lists.torproject.org/pipermail/tor-talk/2009-Septemb...

Given the low level of technical knowledge with a great deal of US law enforcement, increasing militarization, no knock warrants, etc... Please think twice before running an exit node from your house. Do it in Colo somewhere with a small, plucky ISP owned by a first and fourth amendment absolutist.

Thanks for your effort! If I can ask, how much overlap exists between your team and the team overseeing the implementation of security protocols within Firefox e.g. HSTS, CSP, etc.? It'd be neat to see Firefox drive innovation here alongside the effort to weave Tor into the browser; although I wouldn't necessarily treat Tor integration the same as I might the implementation of other security specifications, I can see how the teams working on such might overlap, hence my question.

The Fusion project is done by a subset of that team (+me, I happen to sit with Sandboxing due to other responsibilities).

By passing this on to Mozilla and discontinuing Tor Browser, you're going to inherit the innumerable issues in their code base. Wouldn't it be easier to hard-fork and create a simple browser with minimal overhead? It doesn't have to be loaded with features. Just minimalist and private.

Some anti-features that come to my attention off the top of my head:

* Biometric login (as of FF60)

* Dumb PR Stunts like Mr. Robot

* Telemetry

* Balrog (Analytics and browser fingerprinting on AmazonS3)

* Social API

* VR sensors

* DRM

* Google Chrome (large contract Mozilla has with them as they backport this into IPC)

* CloudFlare DNS (Department of Homeland Security partner and Tor arch-enemy)

etc...

Tor Browser will exist as long as Tor feels it needs to. If the features or anti-features in FF cause them to believe Firefox does not fit their need, then we're/they're not going to discontinue it.

> By passing this on to Mozilla and discontinuing Tor Browser, you're going to inherit the innumerable issues in their code base.

What issues exactly? Tor Browser = Firefox ESR + some patches + some other stuff and tweaks. Before the release of the next ESR TB devs rebase and submit these patches to mainline Firefox, that's why you have prefs like privacy.resistFingerprinting and privacy.firstparty.isolate in mainline Firefox, see: https://wiki.mozilla.org/Security/Tor_Uplift

> Google Chrome (large contract Mozilla has with them as they backport this into IPC)

What's this?

>Biometric login (as of FF60)

Are you talking about Web Authentication? What is wrong with it?

> Our ultimate goal is a long way away because of the amount of work to do and the necessity to match the safety of Tor Browser in Firefox when providing a Tor mode.

If that doesn't pan out, do you expect the ongoing work on this project to reduce the size of the patches that the Tor Browser project needs to carry on top of the Firefox trunk?

Yes. This Mozilla wiki page has more information about (what Mozilla calls) the "Tor Uplift":

> The intention of Tor Uplift project is to land all Tor Browser patches so that Tor can directly use Firefox main trunk instead of a fork.

https://wiki.mozilla.org/Security/Tor_Uplift

> first party isolate is generally more stable and usually only has breakage on particular login forms

Are you referring to third-party login services and comment systems (such as disqus and similar)?

> Are you referring to third-party login services and comment systems (such as disqus and similar)?

See the full list of bugs of breakage when privacy.firstparty.isolate is enabled: https://wiki.mozilla.org/Security/FirstPartyIsolation#First_...

Most of those involve third-party logins. And most of the others mix domains unnecessarily, through lazy design.