Hacker News new | comments | show | ask | jobs | submit login

> Ultimate eventual goal: Make Tor Browser obsolete, so Tor Project can focus on research instead of maintaining a fork of Firefox.



Ultimatest super-goal: make anonymity the default stance and socially accepted norm. Do with anonymous browsing what WhatsApp did with E2E encryption. Force big data suckers to invent new business models for exploiting our data without breaching our privacy.


I can't read this article because I'm at work, but unless they managed to solve the problem of Tor being very, very, very slow, this will never happen. End users will definitely notice a difference and likely won't care about their privacy. They'll just see Firefox being way slower than Chrome and switch.


This would be a privacy option for Firefox, not the default. But yes, Tor introduces latency and reduces bandwidth. For traffic to the open Internet, traffic uses circuits through three relays: entry guard, middle and exit. So there are four hops between users and websites, instead of one. The Earth's circumference is about 40 thousand km. So the longest path is arguably ~20 thousand km. And rtt for that would be about 300-500 msec, according to my measurements.[0] It's only ~130 msec at lightspeed, but there are some copper links, plus switching time and caching.

So with four hops, rtt would at most be 1200-2000 msec, if every hop were the maximum length. In practice, rtt for Tor is at most half that, and often even less. But latency is actually good if your goal is anonymity. Because it reduces the accuracy of traffic analysis.

With traditional onion sites, there are two three-relay circuits, one for the user and one for the site, plus a rendezvous relay. So rtt is much greater. However, sites can opt for one-relay circuits, sacrificing anonymity, so overall rtt isn't that bad.

Bandwidth is also reduced with Tor. Increased latency is part of that. But also, many relays have low-bandwidth uplinks, especially ones that people run at home. The Tor client does pick faster relays, but there's a tradeoff, in that doing so reduces anonymity. Increased investment in high-bandwidth relays would help a lot.

Also, with more relays, it would be workable to implement multipath circuits. Especially for onion sites, where precious exit relays aren't needed. Using MPTCP, I managed ~50 Mbps throughput for bbcp transfers between onion sites (with gigabit uplinks).[1] I was getting ~36 subflows per tcp connection.

0) https://www.ivpn.net/privacy-guides/how-to-verify-physical-l...

1) https://ipfs.io/ipfs/QmUDV2KHrAgs84oUc7z9zQmZ3whx1NB6YDPv8ZR...


So basically satellite Internet speeds. That is pretty good.


Tor is not that slow these days. Sometimes you get a bad circuit but you can reroute and expect speeds comparable to mobile phone networks.


Is it even worth talking about speed without at least considering client network conditions? A lot of people have poor internet connections, many places world-over are basically mobile-internet only already, shared internet spaces with variable QoS (campuses), etc etc. Most people aren't using engineer-priced laptops/workstations or backed by enterprise-grade routing equipment, after all.


If I understand Tor correctly, last mile connectivity is not a bottleneck.


You are correct. Tor's speed has nothing to do with your local rig or network. Unless you're on an abacus.


Yes it is. I can't speak for everyone, but in Brazil, it's virtually impossible to use Tor even for HTML-only websites. And I can say most people have a slower bandwidth than I.


So long as Tor depends on volunteers to maintain exit nodes, and with that the risk of being arrested for all sorts of criminal activity by non-tech-savvy law enforcement, this is how it'll be.


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.


That wouldn't be as big an issue if all the nodes were very well connected, like positioned near big peering points, but they're not.


The "distributed all over the world" part would still be just as much of an issue; the speed of light puts a substantial lower bound on the total latency.


True, but pinging from one hub to another is way faster than someone's cable modem in Mumbai to someone's in Australia to someone's in Peru and back again. Those last miles add up in a huge way.


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.


What do you mean by this: "with that the risk of being arrested for all sorts of criminal activity by non-tech-savvy law enforcement"

You can be arrested for things just by using Tor if they mix you up with someone else or something?


You can be arrested for running an exit node, because other Tor users' traffic will appear to be coming from you.

For example: https://www.deepdotweb.com/2017/05/01/russian-tor-exit-node-... https://www.zdnet.com/article/dan-egerstads-tor-exit-nodes-g... https://www.pcworld.com/article/2452320/tor-exit-node-operat...


All of them from people running their exit from home, which has always been warned against.


Where is the recommended place to run one?



Also get on the tor-relays@lists.torproject.org mail list.

But the sad truth is that there aren't that many hosting providers that allow Tor relays. Especially exit relays, because of abuse complaints.

Also, as you might expect, Tor relays can use lots of bandwidth. It's more common to get flat-rate bandwidth for 100 Mbps uplinks, and metered bandwidth for 1 Gbps uplinks. Digital Ocean, for example, just switched to metered bandwidth, and that has killed some relays.

However, all this could arguably change, if Tor became mainstream, as part of Firefox.


Just use some cheap VPN service in front of your Tor/Firefox browser (which most people should do in any case) and you're good to go.


That has no relation to the cases above which were of people running Tor exit nodes from their home. If one wants to hide their Tor usage then that's something else and there are pluggable transports that are already built-in the Tor Browser to obfuscate Tor traffic to look like something else--no need for a VPN.


How does this affect exit nodes?


If you're worried that law enforcement will knock on your door because somebody used your exit node for illegal internet activity, a VPN service (that does not log traffic) will give you additional protection by exposing their IP address, not yours.


A lot of VPN services forbid running exit nodes in their ToS as it tends to trash IP reputation...


Looks like a cheap escape from jail card.

Run an exit node and then do something illegal. Then blame it on someone else.


Did you miss the part where exit node operators are getting arrested?


They sometimes are. Not always. And they walk out free, except for that Jewish guy who lived in Austria (I can’t remember his name but he was the only one to get in real trouble for running an exit node).


Why take that trouble when they can do it directly using Tor without running any exit at home? Also for instance Bogatov had an alibi when that happened.


Most forums ban all Tor exits.


The forum I run only bans IP addresses caught posting link-spam. Which, admittedly, asymptotically approached 100% of Tor exit nodes before I instituted more rapid ban-expiration. I added faster ban-expiration after hearing from some of my privacy-conscious users that Tor had become unusable for my forum.


> Most forums ban all Tor exits.

So running an exit at home to coverup for posting on a forum that bans all Tor exits, that makes no sense.


HN doesn't :)


If you use tor and only visit onion sites, the sites don't know who visited them.

If you use tor and visit the regular web sites (like, say, HN), the last computer that does the actual request to the website is an exit node, as far as that site is concerned, the exit node made the http request. If you run an exit node, your computer is going to be doing tons of requests to all kinds of websites, this may include sites that deal in illegal stuff like drugs, child prostitution, human trafficking, terrorism, etc.

edit: Forgot to say, you must explicit be running an exit node. Not every tor node is an exit node.



I think Tor will get faster, now new protocols like TLS/1.3, HTTP/2 and QUIC are being developed.

Currently Tor looks like HTTPS done with TLS/1.2 on TCP (like regular HTTPS). As these newer protocols get more and more delpoyed Tor can start using them too which will help make Tor faster.


Those standards have nothing to do with Tor's speed.


Not immediately, but I feel that as those protocols become more ubiquitous, _maybe_ the base Tor transport protocol (for nodes which aren't bridges) might be able to benefit from some of the same upgrades by using them?

I don't know how much (if at all) it might help—but other, similar overlay networks have previously noticed that (intuitively) inefficiency in the transport protocol is likely to be (broadly speaking) multiplied by the number of hops; so any improvements in that might be useful in improving the user experience by using the same available resources more efficiently.

What that might mean for Tor's perceived speed is a somewhat murky issue, as that's a function of the complex interaction of latency and bandwidth and crypto and routing overhead of all the involved nodes in a tunnel put together; which of course is also shared with other tunnels; not to mention it will _also_ be particularly affected by exit node outproxy bandwidth; _and_ any possible packet loss and delay caused by both incidental _and_ deliberate adverse network conditions…


There are in fact some vague ideas floating around about using QUIC as a transport protocol for Tor. However, there is so much work to do and so few people that have the necessary skills (solid cryptography -- not at a "build the next AES" level, but "implement AES with no side channels" is already incredibly difficult -- plus low-level networking, C, and so on...) that in my view it is a minimum of 2-3 years from being mainstream available (look at how long HSv3 took).


Tor circuits tend to be rather high latency, so anything that reduces the number of round trips needed for page loads is likely to have a significant impact on Tor's effective speed.


Well HTTP/2 is disabled in the Tor Browser (for now), and it has a positive impact on speed, so they do matter: https://bugs.torproject.org/14952


> what WhatsApp did with E2E encryption

Convince everyone that using a closed source, proprietary app is good security?


WhatsApp is not perfect and certainly its code not being available for inspection is one of its flaws. However, it did bring security to the masses. I mean I am pretty sure the security it offers is enough for 95% of people. I would not use it for sending documents stolen from NSA, but for the rest of cases - it gets you covered. Security very often need to be balanced with convenience - with WhatsApp you get immense boost of protection without sacrificing much convenience. One could argue, that you could get better security with Signal - true, but first you'd need to convince all your family and friends to install it.


You also get encryption while your traffic looks just the same as everybody else’s. You don’t stand out like when you’re using Tor.


> You also get encryption while your traffic looks just the same as everybody else’s. You don’t stand out like when you’re using Tor.

Detecting WhatsApp usage is trivial. With Tor you can use pluggable transports to obfuscate your traffic.


But everyone and their cousin is a WhatsApp user, so using Whatsapp isn't suspicious.


So the solution is to grow Tor usage, or use bridges with pluggable transports.


No, using Whatsapp is a more efficient solution.


They need to solve the issue of speed, altough maybe for sensitive queries(assuming that's enough, a very big assumption,), people may be willing to use a slow "super private browsing mode". another option is to make people pay for faster speeds ?

And if i recall correctly, a "global passive attacker" listening to internet traffic around can de-anonimize TOR using ML. Seems like something that would be possible and profitable for a Google and internet infra companies.


Google isn't a GPA. Also having a low-latency anonymity system that isn't affected by a GPA is an open problem. The important thing here is that using Tor is better than not.


>another option is to make people pay for faster speeds

This is what Telegram is trying to acheive with their TON and Gram.


Likely actual result: Firefox will become increasingly irrelevant.

If Tor is going to be a built-in feature of Firefox, most employers are going to flag it as malware. This is a ridiculously dumb thing on so many levels -- promote privacy by directing your network traffic to "volunteer" proxy services?


Most businesses deploy Firefox ESR, so I wouldn't be surprised if they omit the Tor capabilities in that version.


You already don't know what proxies your traffic is going through. Using Tor might increase the odds of a bad actor a bit but end-to-end security is something the web is getting better at right now.


The risk now is that some bad actor is replacing TLS certificates, which is an uncommon and tamper-evident event. Tor is handing your traffic to an unknown 3rd party.

Plus, users do not understand what Tor is or how to use it.

Fighting political battles with software is dumb — the end result is going to be a permanent loss of freedom, as governments force the use of platforms with trusted app stores.


The risk now is BGP hijacking. Or really just normal operation of BGP. You data could go anywhere on the planet on its way to the destination and you're not going to know ahead of time what path any particular packet will take.

If you're using TLS, it doesn't matter so much if the exit node is malicious because they still won't be able to read it.


How about my compromised browser exfiltrating information to an onion address?

Obviously I’m being downvoted into oblivion, but I truly feel this is a solution looking for a problem.


It's been my understanding that Firefox has been soft splitting its consumer and business versions of the product for a while. This would presumably just be another step down that road.


Why would they do that? employers could still spy on you before the data gets on the tor network...


Good, now if only we could have bitorrent baked in...

EDIT: I mean baked in in the browser like tor, not baked in tor. Although interesting, it's really not my priority.


Firefox recently whitelisted a bunch of p2p protocols so that they can be used by browser extensions. One of them is the Dat protocol [0], which is similar to BitTorrent but has better support for mutable data and random access [1]. It's far from being "baked in", but it's a step in the right direction.

[0]: https://docs.datproject.org/

[1]: https://docs.datproject.org/faq#dat-vs


We always could do that with extensions since JS is turing complete and has access to the network. Webtorrent is a thing after all.

The issue is not technical. It's just a chicken and egg problem. Most won't use bittorent unless it's stupidely easy to do. Remember that the average user don't know what an URL is and doesn't open new tabs willingly. Since they are the majority, they drive cost and benefits, so we must include them.


> We always could do that with extensions

You couldn't, until Firefox 59. Before that, protocol handlers were not allowed to handle links to Dat/IPFS resources [0].

And while I agree with your comment regarding the chicken and egg problem, there are still some technical issues. As the shadowbanned sibling comment says, extensions don't have access to UDP/TCP sockets, meaning that you will need to run a gateway on your machine. See e.g. what dat-fox [1] does.

[0]: https://developer.mozilla.org/en-US/Add-ons/WebExtensions/ma...

[1]: https://github.com/sammacbeth/dat-fox


> You couldn't, until Firefox 59. Before that, protocol handlers were not allowed to handle links to Dat/IPFS resources [0].

You could, kind of, before Firefox 57 (or at least, at some point). Implementing nsIProtocolHandler/nsIChannel/etc. correctly was difficult (and probably not from JavaScript), and distribution problems meant nobody did it.


No, not nobody. OverbiteFF was implemented in nearly exactly that fashion, and 100% JavaScript.

https://addons.mozilla.org/en-US/firefox/addon/overbiteff/

But, not possible anymore (without tricks).


True, I remember looking into that and it was all a bit of a mess.


> and has access to the network

It does not have access to TCP or UDP sockets.


Opera had built-in Bittorrent (this feature is now removed, probably after Opera became rebranded version of Chromium).


Well, removed insofar as it was never reimplemented when the browser UI was rewritten from scratch, but yes.


Nope, I wouldn't want to have to keep the browser open all the time just because I'm downloading a torrent.


Chrome extensions [1], and Firefox WebExtensions [2], can have background scripts that can continue running even when the browser window is closed. So in theory, with a p2p filesharing extension, you may not have to keep any browser window open or even minimized.

[1] https://developer.chrome.com/extensions/background_pages

[2] https://developer.mozilla.org/en-US/Add-ons/WebExtensions/An...


So when you download something that is not a torrent, you close your browser ?


Hey Sametmax, big fan of your site.

Apart from the existing ecosystem of content, are their any reasons you want BitTorrent over ipfs?

Everyone on tor AND ipfs... Now that would be something.


Thanks :)

I think IFPS needs a little more field testing before being set in stone. Indeed, if you bake in something in the browsers, then those implementation will be the boundary of what is practical to do. So any innovation will then be constraint by the browsers release and good will.

IFPS is a young tech, it needs time to evolve yet.

Tor and bittorrent are now quite mature.


This works today: https://webtorrent.io/

It used WebRTC which is also encrypted. So gets you some privacy.


I know. Check my other comments.

It's nice, but not nearly good enough.


>"IFPS is a young tech, it needs time to evolve yet."

Could you share your concerns about IPFS in its current state or what you see as its limitations? Thanks.


Honest question: is bittorrent even still a thing?


Last month I download 2 linux ISO with it for work. This month all the seasons of the pretender for fun.

Facebook used to deploy their code using bittorent. I doubt it has changed.

A lot of blizzard video games update using bittorent as well. If you play Starcraft 2, you use bittorent.

Streaming services like stremio are basically bittorent. After netflix, it's my main source of video content.

If you want to download the internet archive, that's the saner option. Same if you are a pentester, as a lot of heavy leak or hash db are so huge only bittorent makes it practical. Too expensive to host for one small actor. It's also more resistant to take down notice.

We talked a lot about RSS lately, and how to revive it, while in comments people said it actually never died. Bittorrent is a lot like that. Great tech, great standard, it works flawlessly and fill its use case perfectly.

The only reason it's not more adopted is because it's not in the browser by default. Otherwise the hosting benefit and the dl speed is such that it would be an instant hit.


Blizzard games no longer use BitTorrent but a proprietary http-based protocol called ngdp. BitTorrent was causing a lot of issues with firewalls so users were disabling it, so they had added http mirrors to them... And then CDNs became a thing, the rest is history.

I'll be happy to give more details on ngdp if you are curious.


Please.


Here, I pulled my docs for ya:

https://gist.github.com/jleclanche/91f2f5c0f2042a81db1c61464...

They basically created their own git protocol + virtual filesystem, optimized for asset patches inside large compressed binary files. I wish they'd open source it.


That was interesting to poke through.

Related discussion: https://news.ycombinator.com/item?id=13140257


It definitely still is. And with the concept of private trackers, it's not really a simple thing to turn off. Companies like IP Echelon tend to automatically bully US/cloud users, but in general they're IMHO far from killing the network. The only problem is that there's fewer and fewer torrent search engines...


tameme.fr is my new fav.


If my movie library is of any indication, yes it’s definitely still a thing.

(And before you say anything, I do pay for Netflix and have video included in my Amazon Prime membership - none of which had those movies)


It is. For both legitimate and nefarious uses. Bigger software/game devs still use bittorrent to distribute patches and updates—World of Warcraft is an example.


If you are asking about torrents and pirate community, then yes - it is alive and well.

However it is usually through VPN, not Tor.


Torrenting through Tor overloads relays, increasing latency and throttling bandwidth for other users. Also, it's unworkably slow. Just use nested VPN chains.


Of course it is. It didn't go away because you don't use it.


Hopefully other browsers are encouraged to do something similar also, else Mozilla will effectively control the destiny of Tor


Brave is already working on Tor private tabs though it won't have the same fingerprinting/first-party isolation guarantees as with a Tor Browser, https://github.com/brave/browser-laptop/labels/feature/tor Should be shipping soon https://twitter.com/BrendanEich/status/984231250104733696


Ultimate goal of the Tor project, that is. Lots of people in this comment thread seem to have not clicked the link and are presuming that this is a Firefox roadmap. The Mozilla analogue of this page only mentions bringing Tor features into Firefox, without stating a goal of obviating the Tor Browser entirely.


Well, Mozilla engineers wouldn't be the ones in charge of, or benefiting from, shutting down the Tor Browser fork, would they? So why would they need to include that kind of (incredibly distant, virtually pie in the sky) goal on their wiki page?


Is it a fork? I thought it was a heavily customized version of Firefox ESR with specific settings and defaults using the channels OEM configs. Looking at the binaries, it's definitely not the standard build anymore.


OEM configs have never been enough to implement everything they need in Tor Browser. They eventually started their uplift effort [1], to upstream all the patches and features they've added to it, so that they can possibly just use OEM configs.

Project Fusion is a superset of that effort.

[1] https://wiki.mozilla.org/Security/Tor_Uplift


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] https://hg.mozilla.org/build/partner-repacks/file

[2] https://www.mozilla.org/en-US/about/partnerships/distributio...

[3] https://brashear.me/blog/2017/12/07/how-to-deploy-firefox-wi...


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.


It's a fork based on Firefox ESR, see for the details: https://www.torproject.org/projects/torbrowser/design/




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: