by ekjhgkejhgk
9 subcomments
- OT on Tor:
Recently this link was on HN[1]. It ranks your browser on regular tracking and fingerprinting separately. "Tor without JS" was the only option I found to be completely fingerprint resistant. Even Tor "with JS on strict settings" ranked it as only "partly fingerprint resistant". (Interestingly firefox without JS never returns)
Scary stuff.
I'd like to hear other people's experiences/experiments here.
[1] https://coveryourtracks.eff.org/
by testdelacc1
4 subcomments
- This isn’t a recent decision, which the title implies. This rewrite started in 2020, and they released Arti 1.0 in 2022. Check out the release post (https://blog.torproject.org/arti_100_released/) where they explain their rationale for the rewrite. They were unhappy with the state of the C codebase and couldn’t see a way to slowly refactor it. Their experience with Rust was positive for all the commonly cited reasons - if it compiles it works, good ecosystem leading to development velocity, better portability across operating systems, and attracting more contributors. They did say they weren’t happy at the time with binary sizes.
The change log in the arti repo (https://gitlab.torproject.org/tpo/core/arti/-/blob/main/CHAN...) shows a lot of recent development too- versions 1.6, 1.7 and 1.8 were released in the last 3 months and they talk about setting the foundations for larger features to come. All in all it seems like the decision worked out for the team.
by giancarlostoro
3 subcomments
- I still wish Mozilla had kept oxidizing Firefox. It would have been a net positive for Rust itself.
by epolanski
8 subcomments
- If Rust helps with their pains and they like Rust this seems very sensible.
That's exactly why we have different languages and tools, because they adapt differently to different projects, teams and problems.
But as soon as you get into the silly "tool X is better period" arguments, then all the nuance of choosing the right tool for the job is lost.
by shevy-java
10 subcomments
- Hmmmm.
My biggest gripe with the Tor project is that it is so slow.
I don't think merely moving to Rust makes Tor faster either.
And I am also not entirely convinced that Rust is really better than C.
by buildbuildbuild
1 subcomments
- This was mostly funded by Zcash Community Grants. Good things can come from crypto R&D.
by linsomniac
3 subcomments
- Is there any way to run a Tor exit node without expecting to get a knock on the door from the FBI/DHS? Like advertising as an exit node but only to a whitelist of sites? For ~20 years I ran a dozen cabinet at a colo but never felt I could donate bandwidth to Tor because of that (did a big mirror server instead), and now I have gigabit (could be 10gig) at home, but still just don't want to deal with the issues.
by runtimepanic
0 subcomment
- Rust adoption in privacy tooling always feels like watching an old fortress quietly replace its wooden beams with steel ones. Tor’s codebase has carried decades of security assumptions, C-era tradeoffs and performance scars, so a gradual Rustification seems like the most sensible way to buy safety without breaking the ecosystem.
The real win isn’t “rewrite everything” but reducing the surface area where memory-unsafety bugs can even exist. If the team can shift the high-risk subsystems (parsing, crypto glue, protocol edges) into Rust while keeping well-tested C where it’s stable, Tor ends up with a sturdier core without a multi-year rewrite freeze.
The interesting question is how far they’ll push it:
Will future pluggable transports be Rust-first?
Will relay operators eventually run a hybrid runtime?
Or does this turn into a long coexistence phase like Firefox?
Either way, a safer Tor is a good Tor.
by voidUpdate
3 subcomments
- Isn't Tor a concept, a protocol? It's like saying you're going to rewrite http in rust...
- i'm starting to wonder what if those rust rewrites might be covert attempt to introduce back doors in plain sight?
- Rust - "I am inevitable"
- They should just start compiling Tor with Fil-C — free memory safety, no new bugs from full code rewrite
by bbcismyfriend
1 subcomments
- [flagged]
- Why not Go? It's more portable.
- Rust is one of the natural choices for this kind of migration.
There are others like Go.
I think they made the choice based on ecosystem, performance and prior experience with C.
- Complete rewrites are always a bad idea ... [mutters of agreement] ... except in Rust! [cheering]
by hnthrow82926
1 subcomments
- I'm sure replacing the battle-tested C implementation with a Rust implementation that's extremely vulnerable to supply-chain attacks and has seen little real-world usage is not going to backfire at all.
- I think we will see more Rust adoption as code generation gets better.
Machines will generate all the code, test that it works according to spec, you only need a vague notion of what is succint (do you just implement some existing trait?), what is typical (do you use index based data structures? do you simply use a Box, do you need Rc? Where should you use Optional?, do you want to use RefCell to make it mutable and so on), what is concise (just macro expand?), what is the correct type to use so you can warn the machine to re-adjust itself.
Personally I don't use Rust, I don't want to learn everything about Rust. It is the new enterprise Java boilerplate BS of our time.
So instead of running people through that ordeal, let them write the specs and machines should write the verbose boilerplate so the code is so called "safe" and concise without giving up too much.
Hacker News