111–120 of 242 posts
Earlier quoted context omitted.
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 check the new relay guide: https://trac.torproject.org/projects/tor/wiki/TorRelayGuide)
Earlier quoted context omitted.
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.
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?
Hi all. I am a Tor Project Developer and work at Mozilla on this project. We appreciate everyone's enthusiasm and feedback. 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. There's no guarantee this will happen, but I hope it will and we will keep working towards it. If anyone is interested in assisting…
I think Mozilla should look at using Servo instead of Gecko in this mode along with a new JavaScript interpreter written in Rust, at least optionally, since perfect security is essential when using a Tor browser without a dedicated VM.
Servo components are being uplifted into Gecko gradually. There's less benefit to rewriting the JIT in Rust because static type systems can only do so much when the whole goal of a program is to generate code dynamically.
For security, instead of a JIT, a simple JavaScript bytecode interpreter written in Rust to be used exclusively in the Tor mode would be ideal, for maximum security at the cost of worse performance.
Another option is a JIT that generates code that is easily proven to be safe (e.g. because it does a bounds check on all memory accesses and only does indirect jumps using a jump table, or because it's the only thing running in a process and jumps are still constrained with a read only jump table and read only code).
Earlier quoted context omitted.
The CA/B Forum rules only allow EV certificates for .onion, so even if Let's Encrypt wanted they couldn't give out .onion certificates without getting that changed first.
I'm trying to get that rule changed and working with several other organizations on this.
I think Mozilla should look at using Servo instead of Gecko in this mode along with a new JavaScript interpreter written in Rust, at least optionally, since perfect security is essential when using a Tor browser without a dedicated VM.
Servo components are being uplifted into Gecko gradually. There's less benefit to rewriting the JIT in Rust because static type systems can only do so much when the whole goal of a program is to generate code dynamically.
Earlier quoted context omitted.
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.
How does this affect exit nodes?
> Ultimate eventual goal: Make Tor Browser obsolete, so Tor Project can focus on research instead of maintaining a fork of Firefox.
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.
Project Fusion is a superset of that effort.
Earlier quoted context omitted.
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.
Earlier quoted context omitted.
> Without HTTPS, you are relying entirely on the transport for assurance of who you are talking to. That's not the case, even with a SecureDrop setup, a Gov can compromise your SecureDrop machine and listen directly.
Exactly, they have to pop my machine too. They can't just take control of the traffic in the middle, which absolutely can be done in Tor with enough gov controlled guard nodes, as the arms race of patching has proven. I can set up multiple canaries that they will have to pop and the fingerprint of one of those canaries is going to change or drop off the net.
I think you're misunderstanding something here, with onion services traffic is e2e encrypted and self-authenticated, as Matt explains:
> When you connect to an onion service, how do you know no one is MitM'ing you? Easy. It's impossible. The bad guy would have to be in your browser (more accurately: between the browser part of Tor Browser and the Tor process it runs in the background) or between the Tor process the onion service operator is running and the webserver it's pointing at. If you assume your Tor Browser hasn't been compromised, and you assume the onion service is being run intelligently, then a MitM attack is impossible. (And if the onion service isn't being run intelligently, can you really trust its operator to do HTTPS intelligently?) > > https://matt.traudt.xyz/posts/dont-https-your-o44SnkW2.html