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.
This tool is deeply flawed. Fingerprinting protection is sometimes done by binning, which this tool rewards, and is sometimes done by randomizing, which this tool harshly punishes. The net result is it generally guides you away from the strongest protection.
The flip side of this, having the complementary flaw of testing only persistence, not uniqueness, is (warning, real tracking link) fingerprinting.com/demo. You can try resetting your ID and seeing if it changes here. Since tracking requires (a degree of) uniqueness AND (a degree of) persistence, the danger signal is only failing both the EFF test and this test.
Failing both is a requirement to derive meaning, not being lax: measuring only uniqueness would fail a random number generator, and measuring only persistence would fail the number 4.
You make an interesting point on binning vs randomization. I'm not an expert but to me your point is consistent with Tor having the "best protection" according to the website, because I know that Tor's strategy is binning. However, this is what actually makes sense for many variables though. For example, font sizes come in integers. If you're trying to be clever by "randomizing" and claiming to use decimal-sized, you might be the only person in the world to do so and immediately fingerprinted. So I think that randomization might indeed be a bad idea in many cases.
Your link doesn't work though. I just get "file not found".
Regular OS X safari: Our tests indicate that you have strong protection against Web tracking.
>Your browser fingerprint has been randomized among the 378,837 tested in the past 45 days. Although sophisticated adversaries may still be able to track you to some extent, randomization provides a very strong protection against tracking companies trying to fingerprint your browser.
>Currently, we estimate that your browser has a fingerprint that conveys at least 18.53 bits of identifying information.
Anyway, this test doesn't really communicate the results very well. Yes, Tor browser stands out. No, it's not easy to differentiate between different Tor browser users via this kind of fingerprinting.
Huh, I use a "stock" (I think?) MacOS Safari and got "Your browser has a nearly-unique fingerprint" and "Partial protection" for ads and invisible trackers.
Did you change a setting or add an ad blocker or something?
edit: I feel like someone with a username "monerozcash" must have some customization to your browsing experience, that maybe you don't even remember doing...
Tor Browser tries to widen the fingerprint buckets you can get put into by eg rounding off canvas sizes. The widest bucket and unavoidable is “Tor (browser) user”.
Visiting this site with a freshly installed, stock Tor browser (therefore with JS enabled, no settings changed from defaults) on Debian stable gives me:
"Our tests indicate that you have strong protection against Web tracking."
"Within our dataset of several hundred thousand visitors tested in the past 45 days, only one in 301.9 browsers have the same fingerprint as yours.
Currently, we estimate that your browser has a fingerprint that conveys 8.24 bits of identifying information."
Interestingly, increasing the Tor Browser Security level from Safe to Safer actually increased the bits of identifying information and reduced the anonymity:
"Within our dataset of several hundred thousand visitors tested in the past 45 days, only one in 832.32 browsers have the same fingerprint as yours.
Currently, we estimate that your browser has a fingerprint that conveys 9.7 bits of identifying information."
And at the Safest Security level (i.e. with JS diabled) the identifying bits and anonymization appear to be at their best:
"Within our dataset of several hundred thousand visitors tested in the past 45 days, only one in 261.41 browsers have the same fingerprint as yours.
Currently, we estimate that your browser has a fingerprint that conveys 8.03 bits of identifying information."
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.
Arti is also designed to be embedded as a library in other apps, so messaging clients (for example) will be able to leverage the network without needing a correctly configured Tor daemon on the host.
The extra safety in the code base is nice, but this seems like a bigger deal.
> Portability has been far easier than C, though sometimes we're forced to deal with differences between operating systems. (For example, when we've had to get into the fine details of filesystem permissions, we've found that most everything we do takes different handling on Windows.)
Remember, we’re not talking about the language. We’re talking about the stdlib and the surrounding ecosystem. The Rust stdlib and third party libraries generally handle windows well, so the Tor developers don’t need to special case windows.
Doubtful. I can't even get Rust to work here on my slightly older Mac system. So with TOR switching away from a well supported language like C it's simple another project lost to me (unlikely you can stick with an older version for long in this case as they regularly break backwards compatibility in their network.)
Thanks! This is a much better link than the OP, and better preempts the usual round of "why not my other pet language X instead"? questions. Clearly this choice and strategy has been in the works for a long time and the team has carefully thought out all options.
I mean, they are, so presumably you mean more quickly ? There's a HN article about this after Mozilla fired loads of Rust hackers, and a larger fraction of the Firefox codebase is in Rust than was then, which was in turn more than in 2021 when I first was interested.
It's possible that if Rust had remained "secret sauce" for Mozilla it would have hurt its usage elsewhere, impossible at this distance in time to be sure. There is, for example, far less Rust in Chromium (less than 4%) than in Firefox (more than 12%).
The language surely has many cons, like any language out there. And maybe it wasn't a good fit for Mozilla products. But Mozilla the organisation doesn't really looks that great in term of governance. Given Rust is now even integrated officially in Linux kernel, I have strong doubt that the technical caveats are the main factor of misalignment with Mozilla priorities.
Mozilla was the primary steward of Rust for most of the time that the Servo project was active. So if you want to lay Servo’s failure at the feet of the Rust language, it’s pretty hard to cast Mozilla as the blameless victims of… whatever it is that Rust users as a whole did to make Servo fail.
Sensible take, thank you. When HN get these "our project: from x to y language" frontpage stories I am always thinking that it would be far more exciting with "our project: 38.2% smaller code base by optimizing our dependency use", "our project: performance optimized by 16.4% by basic profiler use" or similar!
Is the trade off here having more secure code in exchange for added complexity/difficulty? This is a real question, has the Tor code itself been exploited by bad actors before? All the incedences I've seen in the news were some other software running over tor that would be exploited to phone home or give up user data.
Isn't this just the same value judgment mistake? You're just presupposing that things like "smaller code base" are better in virtue of themselves the same way that "rewritten in Rust" might be as well.
The parent poster's point is seemingly to reject "this is simply the better thing" (ie: "small code is better") and instead to focus on "for what we are doing it is the better thing". Why would "basic" profiler use be better than "niche" or "advanced" profiler use if for that context basic would actually have been inferior (for whatever value of basic we choose to go with)?
It seems to me that the reality we're often confronted with is that "better" is contextual, and I would say that "basic" or "smaller" are contextual too.
I think the chance that your Rust application is going to be more performant or efficient than C, is whether you are focused on writing performant and efficient code. Out-of-the-box, I’m guessing people will use too many cargo packages, each that are over-engineered or written by less-experienced developers, so it will be less efficient and less performant.
In addition, you could more easily inadvertently introduce security problems.
Is Rust the right choice for Tor? Sure. Is Tor the right choice for security? If they moved to Rust, they increased security risks to make it easier to manage and find help from younger less-experienced developers, so no.
Why do you even bring this up, the blog post does not contain this message, they rewrote it to eliminate a class of bugs. They don’t bash C, so refrain yourself from mentioning what hypothetically could have been written…
Because Hacker News gamifies engagement, and they know that this kind of message tends to attract a lot of upvotes. The whole conversation tree is a carpet of land-mines, laid out in the hopes that someone steps on one so they can pounce.
This sort of gamification of discourse is poison if you actually care about good faith or reasonable discussions. HN is not a good place for either.
We could move past all the unproductive, polarized online arguments if everyone accepted that:
1. Programmer skill and talent are not enough to achieve similar security properties with memory-unsafe languages as with memory-safe languages.
2. Therefore, "memory-safe languages are technically superior, period, for applications processing untrusted data where security is an important goal", is not an un-nuanced argument nor a Rust fanboy argument, but self-evident.
That still leaves a lot of room for other languages (Rust is not my favorite language), but it pushes back against the developer equivalent of doctors and pilots resisting the adoption of checklists for decades because "I wouldn't make those kinds of mistakes so stop messing with my work".
1. Programmer skill and talent are not enough to achieve similar security properties with memory-unsafe languages as with memory-safe languages.
2. Therefore, "memory-safe languages are technically superior, period, for applications processing untrusted data where security is an important goal"
but the problem entirely boils down to what comes next:
3a. Therefore everything should use rust.
3b. Therefore everything processing untrusted data where security is an important goal should use rust. (Some folks like to stretch what could possibly process untrusted data to turn this into 3a, but there is a difference.)
3c. Therefore most programs really should be written with a garbage-collector, or if they really need to be low-level or high performance they should use an appropriate stack to avoid gc while remaining safe (whether that's Rust, Ada+SPARK, formally-verified assembly, or whatever).
I want to preface this with "This isn't a gotcha".
I think you make an important oversight with these claims, which is that you can enforce logical safety over a memory unsafe language and have a much higher degree of safety than memory safety. Formally verified C doesn't change the language, you can in principle take C code run through compcert and compile it elsewhere. It's still a memory unsafe language, but we can express a much higher degree of safety than simple memory safety.
Another aspect to consider is that all garbage collected languages are memory safe. A language like Python actually has a far greater degree of memory safety than a language like Rust because it offers no ability to break memory safety (without calling into foreign code), while Rust lets you do it within unsafe blocks using raw pointers. That being said, anybody who would suggest using Python over Rust in a security-focused context is completely out of their mind.
In serious places where security is critical and margin for error is low, formal verification has existed for decades and is the standard. Any operation - specifically in the context where security is critical - which is not formally verifying its software is a mickey mouse operation, because they're fundamentally compromising on security to an unacceptable degree. I think it would be nice to have a formal verification toolchain and language extension for Rust to allow for full logical safety, but last I checked this area was still a work in progress for the language.
I know anytime Rust is brought up, someone brings up logical safety, and patterns are annoying. Rust obviously has a lot of tricks up its sleeve to automatically detect issues that a language like C++ cannot. Naive Rust is preferable over naive usage of a memory unsafe language. The problem is that in a serious security critical context, "naive" is completely unacceptable. If security is a core goal, there can be no replacement for fully blown logical safety enforcing strict behavioral and structural guarantees in every single facet of the codebase. I know the line, that logical safety is excruciatingly labor intensive and so the tradeoff with using Rust is that it affords some of the safety of formally spec'd and proven code. The problem is that the amount it affords you is completely marginal. The safety gap between C and Rust is much smaller than the safety gap between Rust and formally proven correct SPARK. It's just the reality. I'm loathe to see a future where marketing hype sees a degeneration of tools because it was presented as a serious alternative.
C++ in particular has a thriving industry of people who'll come teach your team to write "proper" C++.
You've probably heard that "It is difficult to get a man to understand something, when his salary depends on his not understanding it" and so of course we shouldn't expect such people to say "Don't write this in C++" when they can instead get paid to teach "How to write this in C++" for 2-3 days and feel like they made the world a better place on top.
It so happens Rust is my favourite language, or at least, my favourite general purpose language, but it's also true that I am currently mostly paid to write C# and I see absolutely no reason why I'd say "No, this should be Rust" for most work I do in C#
What are the project specific nuance you are talking about? Anything in this and linked post could be applied to any performant application which values memory safety.
So unless they provide some Tor specific nuance, it's more or less applicable to wide range of applications.
In this case Rust makes sense. However for the majority of UI projects it doesn't make sense. For UI you want to iterate quickly because requirements change often, and you want garbage collection to be able to move fast. At the same time, performance does not matter (low level stuff like bit blitting can be done by lower level libraries perhaps written in Rust or even at the hardware level). A language designed for systems programming makes zero sense there. Unfortunately, we see a lot of "This UI project now in Rust!" on HN, and people get annoyed by that, and I think rightfully so. People don't want to maintain code that was written in the wrong language, and that __will__ happen if other people pick a language for the wrong reasons.
> (So far, it's a not-very-complete client. But watch this space!)
Is that comment outdated? The blog post gave me a different impression. If Arti is not ready yet, shouldn't that have been made clear in the blog post and in the various posts here? Not directing it at you, amelius.
I hate the "rewrite it in Rust" mentality, however, I think that in this particular case, Rust is the right tool for the job.
The Rust specialty is memory safety and performance in an relatively unconstrained environment (usually a PC), with multithreading. Unsurprisingly, because that's how it started, that's what a web browser is.
But Tor is also this. Security is extremely important as Tor will be under attack by the most resourceful hackers (state actors, ...), and the typical platform for Tor is a linux multicore PC, not some tiny embedded system or some weird platform, and because it may involve a lot of data and it is latency-sensitive, performance matters.
I don't know enough of these projects but I think it could also take another approach and use Zig in the same way Tigerbeetle uses it. But Zig may lack maturity, and it would be a big change. I think it is relevant because Tigerbeetle is all about determinism: do the same thing twice and the memory image should be exactly the same. I think it has value when it comes to security but also fingerprinting resistance, plus, it could open the way for dedicated Tor machines, maybe running some RTOS for even more determinism.
I think companies hired too many Rust engineers, and now those engineers are writing technical blogs and making product decisions. We're seeing a lot of those everyday on HN first page
I had that thought too; the author claims tor suffers from user free bugs but like, really? A 20 year old code base with a massive supportive following suffers from basic memory issues that can often be caught with linters or dynamic analysis? Surely there are development issues I'm not aware of but I wasn't really sold by the article
That can easily happen in C programs. Some edge case doesn't really happen, unless you specifically craft inputs for that, or even sequences of inputs, and simply no one was aware for those 20 years, or no one tried to exploit that specific part of the code. With C you are never safe, unless you somehow proved the code to be free of such bugs.
If a codebase is being maintained and extended, it's not all code with 20 years of testing.
Every change you make could be violating a some assumption made elsewhere, maybe even 20 years ago, and subtly break code at distance. C's type system doesn't carry much information, and is hostile to static analysis, which makes changes in large codebases difficult, laborious, and risky.
Rust is a linter and static analyzer cranked up to maximum. The whole language has been designed around having necessary information for static analysis easily available and reliable. Rust is built around disallowing or containing coding patterns that create dead-ends for static analysis. C never had this focus, so even trivial checks devolve into whole-program analysis and quickly hit undecidability (e.g. in Rust whenever you have &mut reference, you know for sure that it's valid, non-null, initialized, and that no other code anywhere can mutate it at the same time, and no other thread will even look at it. In C when you have a pointer to an object, eh, good luck!)
There’s a fundamental trade-off between performance and privacy for onion routing. Much of the slowness you’re experiencing is likely network latency, and no software optimization will improve that.
It’s important to remember that safety is the whole purpose of the thing. If Tor is slow, it’s annoying. If Tor is compromised, people get imprisoned or killed.
completely agree but it could be added that a new language can sometimes help explore new ideas faster, in which case maybe the routing layer and protocol can see new optimizations
This is not correct. Tor is generally not bottlenecked by the quantity of available nodes, the usual bottleneck is the quality of nodes picked by your client rather than the quantity of nodes available.
Of course, technically, this problem is related to the quantity of high quality nodes :)
With 3 proxies traffic circles around the planet 2 times, which takes light 1/4 second to travel. Response does it again, so 1/2 second in total. Light is slow.
You meant Tor network, right? Sadly, making very fast anonymous overlay networks is extremely difficult. You either make it fast or don't sacrifice anonymity. I personally noticed that Tor network has significantly improved and is way faster since a few years. It's also not recommended to exit and if you religiously stay over onions, you increase your anonymity.
And significantly faster to access onion websites than go through exit nodes, which are probably saturated most of the time.
Reddit over their onion website is very snappy, and compared to accessing reddit over VPN it shows fewer issues with loading images/videos and less likely to be blocked off.
It would be nice if more websites were available as onion addresses (and I2P as well).
edit: also if the Tor browser (desktop and mobile) would ship with ublock origin bundled, that would further improve the experience (Brave browser Tor window compared to the Tor browser is a night and day difference)
Hey, if you want a fast anonymity netowrk, there are commercial providers. Companies doing research on thier competition use these to hide thier true idents from targets. They are not cheap (not free but cheaper than AWS imho) but have much greater functionality than tor.
>Hey, if you want a fast anonymity netowrk, there are commercial providers.
For most people seeking anonymity via Tor network (whistleblowers, journalists, activists, etc.), paying a company who can then subsequently be compelled to hand over your information is a bad choice.
And in most other scenarios, Authentic8 is probably still a bad choice. If you require a FedRAMP-authorized service, then sure, look at Authentic8.
> My biggest gripe with the Tor project is that it is so slow.
It’s not supposed to be a primary browsing outlet nor a replacement for a VPN. It’s for specific use cases that need high protection. The tradeoff between speed and privacy for someone whistleblowing to a journalist, as an example, is completely reasonable.
Having too much bandwidth available to each participant would incentivize too much abuse. In my past experience, a Tor associated IP was already highly correlated with abuse (users trying to evade bans, create alternate accounts to break rules, and then of course the actual attacks on security).
>It’s not supposed to be a primary browsing outlet nor a replacement for a VPN.
Tor wants people to use the network for primary browsing because it helps mask the people that need the protection. The more people using the network, the better for everyone's anonymity.
You should preface this with some important information about what that does.
There are some trade-offs!
Changing that setting to 1 gives you weaker anonymity guarantees. Using multiple guards spreads your traffic across different IP addresses, making it harder for an adversary who controls a subset of the network to correlate your activity.
Reducing to a single guard concentrates all traffic through one point, increasing the chance that a hostile relay could observe a larger fraction of your streams...
What's the point of having one relay? You're better off using a reputable VPN like mullvad or ivpn. Tor is the best you're gonna get for low latency anonymous overlay network. It's been studied and refined over the years.
> Well it's certainly not worse than c, and it's hard to argue it's as bad, so...
Except in regards to having a proper standard (the standard from Ferrocene has significant issues), and to the size of the language and how easy it is to implement a compiler for.
I agree it probably won't make it faster. But there is absolutely no comparison when it comes to safety/stability. I've written a ton of C code, and it's just not even close. Rust really outshines C and C++ in this regard, and by a very large margin too.
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.
For anyone wondering how else they can help without attracting scrutiny, consider running a bridge. I have done this at home for years and haven't noticed any ill effects like discrimination of my public IPs: https://community.torproject.org/relay/setup/bridge/
Or, if you're OK with a little discrimination (say you're colo hosted, not residential), but still want to avoid exit-relay-level attention, running guard/middle relays is helpful: https://community.torproject.org/relay/types-of-relays/
You can host torrents to Linux isos to help. You’ll need to block some Chinese ASNs though. They use fake downloaders to detect peers. Like 99% of the traffic my node generated was that. Nodes from one ASN that do partial downloads over and over
Else hosting open map data tile server though I gather this can generate a lot of traffic
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.
Portable to what? Rust works fine on all of today's popular platforms.
I see people complaining about Rust's lack of portability, and it is always some obsolete platform that has been dead for 20 years. Let's be serious, nobody is gonna run Tor on an old SGI workstation or Itanium server.
It is still possible to build for targets such as Itanium. There is nothing stopping you from writing your own targets too in LLVM and its not obscenely difficult
That's a good point, really there's no reason to waste time on anything but popular platforms. Obviously, of course, this means dropping support for everything except Windows (x64 and maybe ARM) and macOS (ARM). (\s)
In all seriousness, I guess you can make this argument if you only care about Windows/macOS, but the moment you run anything else I have to ask why, say, Linux deserves support but not other less-common platforms.
Don't Rust and Go build to mostly-statically-compiled binaries? (With the exception of a link to libc.) (This isn't a rhetorical question, this is something I don't know a lot about
I'd imagine the biggest cultural reason is that many Rust developers were C developers who had a reason to find something better, but still scoff at garbage collection, large runtimes, etc. They probably have a lot more Rust expertise in their circle.
Another technical reason is that they were trying to replace their C code with Rust in bits and pieces before they went with a full rewrite. I don't know about Go, but this is something ergonomically doable in Rust.
I like loose type systems for some quick scripting, but I started to adopt Rust for many of my personal projects because I find it's so much easier to get back into a project after a year when there are good type system guard rails.
Rust can create statically-compiled binaries on Linux by using musl instead of glibc, but it’s not the default like it is in Go and is as a result not quite as effortless. There are a lot of crates with native dependencies that require slight environment tweaks to work on a musl build. Go on the other hand goes to great lengths to not need to link to any C code at all, to the point of shipping its own default TLS library and cryptographic primitives.
In terms of compilation of programs Go is far, far easier than Rust. For Rust to compile a random Rust program on the internet one almost always has to have the absolutely latest out of repo compiler toolchain from curl rustup.whatever | sh. The normal 4 year release cycle is incompatible with rust development. For commercial use cases this doesn't matter. But for open source like the tor project it does.
That said, since they use Firefox this bridge has already been burned.
This is legit question, especially for Tor binaries.
Advantage of Rust (or original C implementation) is for users that do not have runtime and want to import Tor libraries (like arti-client) in their code. Go could work but those unmanaged languages are better here. So in the end Rust (or C, C++ etc.) can serve more user-cases.
Rust is going to feel more familiar to Tor contributors than Go. Based on the list of platinum members (which includes Google and Tor btw) there's some serious money going into the Rust Foundation, assuming it's managed properly I can't see funding as an issue.
i have no dog in the fight, but based on tor release schedule it seems to me that the team is very very talented and rust complexity is not a challenge for them
Complete rewrites have been done before. They're not impossible tasks. C to C++ (like with fish), C++ to Rust (fish again, Tor, etc), Java to C# (something I've seen), C# to C++ (evernote), Blender Game Engine to Godot (many small cases), Godot to Lumberyard (something I've seen), Unity to Godot (many small cases), etc. And there are all the myriad rewrites within the same language, or across major breaking changes (like Python 2 to Python 3).
I think "you should never do a full rewrite" is something of a reactionary response to the juvenile idea new devs and interns get every now and then. But sometimes, a rewrite really is a good idea.
But in this case, per the announcement ( https://blog.torproject.org/announcing-arti/ ), the reasons are pretty convincing. The major reasons are, unsurprisingly, all around memory safety.
> Godot to Lumberyard
Do you remember what project(s) this was? I'd be super curious on the motivations of the developers. I guess I could see it when it first went open source and Godot wasn't all it was today.
The issue is that every other week there is a rewrite of something in Rust. I just do an eyeroll whenever I see that yet another thing is being rewritten in Rust.
I've tried compiling large projects in Rust in a VM (8GB) and I've run out of memory whereas I am sure a C/C++ large project of a similar size wouldn't run out of memory. A lot of this tooling I had to compile myself because it wasn't available for my Linux distro (Debian 12 at the time).
A lot of the tooling reminds me of NPM, and after spending a huge amount of my time fighting with NPM, I actually prefer the way C/C++/CMake handles stuff.
I also don't like the language. I do personal stuff in C++ and I found Rust really irritating when learning the language (the return rules are weird) and just gave up with it.
Comelete rewrite are not always bad, they are _just_ very costly. You just need to do cost benefit analsys and compare it with the cost and benefit of other actions.
Well, an underrated aspect of the Rust rewrites, is that it's easy to publish and share official libraries from the projects that the community can use, something that is too hard in C land.
If anything, from a security standpoint, this is one of the bigger issues with a rewrite in Rust. Besides the "MIT EVERYTHING" mindset, Rust people are also similar to JS devs in having projects with huge supply chain attack surfaces, from their eagerness to rely on so many crates.
Nobody ever said rewrites are always a bad idea. You just made that up. It has been done successfully many times, with many more happening (e.g. TypeScript compiler rewrite).
What matters is how the project is planned and implemented.
Typically, complete rewrites that halt all feature development and fail to achieve feature parity is a recipe for disaster. On the other hand, balancing the work for feature/regular maintenance and rewrite and gradually achieving feature parity before rolling things out has worked well.
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.
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/
This tool is deeply flawed. Fingerprinting protection is sometimes done by binning, which this tool rewards, and is sometimes done by randomizing, which this tool harshly punishes. The net result is it generally guides you away from the strongest protection.
The flip side of this, having the complementary flaw of testing only persistence, not uniqueness, is (warning, real tracking link) fingerprinting.com/demo. You can try resetting your ID and seeing if it changes here. Since tracking requires (a degree of) uniqueness AND (a degree of) persistence, the danger signal is only failing both the EFF test and this test.
Failing both is a requirement to derive meaning, not being lax: measuring only uniqueness would fail a random number generator, and measuring only persistence would fail the number 4.
You make an interesting point on binning vs randomization. I'm not an expert but to me your point is consistent with Tor having the "best protection" according to the website, because I know that Tor's strategy is binning. However, this is what actually makes sense for many variables though. For example, font sizes come in integers. If you're trying to be clever by "randomizing" and claiming to use decimal-sized, you might be the only person in the world to do so and immediately fingerprinted. So I think that randomization might indeed be a bad idea in many cases.
Your link doesn't work though. I just get "file not found".
2 replies →
It seems to reward totally unique randomized fingerprints also, which is maybe not great.
2 replies →
Regular OS X safari: Our tests indicate that you have strong protection against Web tracking.
>Your browser fingerprint has been randomized among the 378,837 tested in the past 45 days. Although sophisticated adversaries may still be able to track you to some extent, randomization provides a very strong protection against tracking companies trying to fingerprint your browser.
>Currently, we estimate that your browser has a fingerprint that conveys at least 18.53 bits of identifying information.
Anyway, this test doesn't really communicate the results very well. Yes, Tor browser stands out. No, it's not easy to differentiate between different Tor browser users via this kind of fingerprinting.
Huh, I use a "stock" (I think?) MacOS Safari and got "Your browser has a nearly-unique fingerprint" and "Partial protection" for ads and invisible trackers.
Did you change a setting or add an ad blocker or something?
edit: I feel like someone with a username "monerozcash" must have some customization to your browsing experience, that maybe you don't even remember doing...
4 replies →
Could you clarify if that's with or without JS?
9 replies →
Tor Browser tries to widen the fingerprint buckets you can get put into by eg rounding off canvas sizes. The widest bucket and unavoidable is “Tor (browser) user”.
Visiting this site with a freshly installed, stock Tor browser (therefore with JS enabled, no settings changed from defaults) on Debian stable gives me:
"Our tests indicate that you have strong protection against Web tracking."
"Within our dataset of several hundred thousand visitors tested in the past 45 days, only one in 301.9 browsers have the same fingerprint as yours.
Currently, we estimate that your browser has a fingerprint that conveys 8.24 bits of identifying information."
Interestingly, increasing the Tor Browser Security level from Safe to Safer actually increased the bits of identifying information and reduced the anonymity:
"Within our dataset of several hundred thousand visitors tested in the past 45 days, only one in 832.32 browsers have the same fingerprint as yours.
Currently, we estimate that your browser has a fingerprint that conveys 9.7 bits of identifying information."
And at the Safest Security level (i.e. with JS diabled) the identifying bits and anonymization appear to be at their best:
"Within our dataset of several hundred thousand visitors tested in the past 45 days, only one in 261.41 browsers have the same fingerprint as yours.
Currently, we estimate that your browser has a fingerprint that conveys 8.03 bits of identifying information."
I'm also on Debian 13 stable, that's definitely not what I get with JS. Weird.
Tor without JS is still subject to some degree of fingerprinting through CSS (media queries, caching) and tracking methods through mouse (without JS).
> and tracking methods through mouse (without JS).
How?
1 reply →
You can even track people by favicon which bypasses incognito mode. Another part is hiding font urls in css with more tracking...
Was incognito mode ever meant to prevent tracking? I thought it was for porn, I mean buying surprise presents on a shared computer.
2 replies →
While this was possible in the past, I believe it got patched and is impossible today.
Interesting, Chrome failed but Firefox and Brave "have strong protection against Web tracking."
In iOS embedded WebView: “strong protection against Web tracking”, and a fingerprint of ~20 bits.
A basic Brave install: "strong protection against Web tracking" / 18.58 bits
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.
Arti is also designed to be embedded as a library in other apps, so messaging clients (for example) will be able to leverage the network without needing a correctly configured Tor daemon on the host.
The extra safety in the code base is nice, but this seems like a bigger deal.
Yes, this is a complete exaggeration of a headline and should be flagged for that alone.
This has been a long running project, and the Tor team clearly took their time to make it, as opposed to being a spur-of-the-moment change.
You're reading way to much into the title. "[...] is switching to [...]" does not have any implication of being a "spur-of-the-moment" thing
>better portability across operating systems
Does Rust have better portability than C?
As the link I posted says
> Portability has been far easier than C, though sometimes we're forced to deal with differences between operating systems. (For example, when we've had to get into the fine details of filesystem permissions, we've found that most everything we do takes different handling on Windows.)
Remember, we’re not talking about the language. We’re talking about the stdlib and the surrounding ecosystem. The Rust stdlib and third party libraries generally handle windows well, so the Tor developers don’t need to special case windows.
It might have better abstractions over the current popular operating systems (Windows, Mac, Linux). Obviously not more portable in general.
Depends on what C code you are talking about.
Doubtful. I can't even get Rust to work here on my slightly older Mac system. So with TOR switching away from a well supported language like C it's simple another project lost to me (unlikely you can stick with an older version for long in this case as they regularly break backwards compatibility in their network.)
1 reply →
Thanks! This is a much better link than the OP, and better preempts the usual round of "why not my other pet language X instead"? questions. Clearly this choice and strategy has been in the works for a long time and the team has carefully thought out all options.
I still wish Mozilla had kept oxidizing Firefox. It would have been a net positive for Rust itself.
At least the Chrome team is still oxidizing.
I mean, they are, so presumably you mean more quickly ? There's a HN article about this after Mozilla fired loads of Rust hackers, and a larger fraction of the Firefox codebase is in Rust than was then, which was in turn more than in 2021 when I first was interested.
It's possible that if Rust had remained "secret sauce" for Mozilla it would have hurt its usage elsewhere, impossible at this distance in time to be sure. There is, for example, far less Rust in Chromium (less than 4%) than in Firefox (more than 12%).
Clearly, the fact that Servo failed must be indicative of shortcomings in Mozilla itself, and not Rust the language, its ecosystem, or its users.
The language surely has many cons, like any language out there. And maybe it wasn't a good fit for Mozilla products. But Mozilla the organisation doesn't really looks that great in term of governance. Given Rust is now even integrated officially in Linux kernel, I have strong doubt that the technical caveats are the main factor of misalignment with Mozilla priorities.
Did it fail? The servo project seems alive and well, just not under Mozilla. They decided CEO pay packages were more important.
6 replies →
Mozilla was the primary steward of Rust for most of the time that the Servo project was active. So if you want to lay Servo’s failure at the feet of the Rust language, it’s pretty hard to cast Mozilla as the blameless victims of… whatever it is that Rust users as a whole did to make Servo fail.
There are architectural concerns. Even when Rust proponents and cultists try to harass unrelated projects into submission, as they are wont to do.
https://github.com/microsoft/typescript-go/discussions/411
7 replies →
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.
Sensible take, thank you. When HN get these "our project: from x to y language" frontpage stories I am always thinking that it would be far more exciting with "our project: 38.2% smaller code base by optimizing our dependency use", "our project: performance optimized by 16.4% by basic profiler use" or similar!
Sometimes language is a limiting factor and so you need to change languages before getting better. However this is rare.
Is the trade off here having more secure code in exchange for added complexity/difficulty? This is a real question, has the Tor code itself been exploited by bad actors before? All the incedences I've seen in the news were some other software running over tor that would be exploited to phone home or give up user data.
12 replies →
Isn't this just the same value judgment mistake? You're just presupposing that things like "smaller code base" are better in virtue of themselves the same way that "rewritten in Rust" might be as well.
The parent poster's point is seemingly to reject "this is simply the better thing" (ie: "small code is better") and instead to focus on "for what we are doing it is the better thing". Why would "basic" profiler use be better than "niche" or "advanced" profiler use if for that context basic would actually have been inferior (for whatever value of basic we choose to go with)?
It seems to me that the reality we're often confronted with is that "better" is contextual, and I would say that "basic" or "smaller" are contextual too.
I think the chance that your Rust application is going to be more performant or efficient than C, is whether you are focused on writing performant and efficient code. Out-of-the-box, I’m guessing people will use too many cargo packages, each that are over-engineered or written by less-experienced developers, so it will be less efficient and less performant.
In addition, you could more easily inadvertently introduce security problems.
Is Rust the right choice for Tor? Sure. Is Tor the right choice for security? If they moved to Rust, they increased security risks to make it easier to manage and find help from younger less-experienced developers, so no.
3 replies →
Why do you even bring this up, the blog post does not contain this message, they rewrote it to eliminate a class of bugs. They don’t bash C, so refrain yourself from mentioning what hypothetically could have been written…
Because Hacker News gamifies engagement, and they know that this kind of message tends to attract a lot of upvotes. The whole conversation tree is a carpet of land-mines, laid out in the hopes that someone steps on one so they can pounce.
This sort of gamification of discourse is poison if you actually care about good faith or reasonable discussions. HN is not a good place for either.
He wrote it because he has eyes and has seen how the typical conversations about switching to Rust often go.
We could move past all the unproductive, polarized online arguments if everyone accepted that:
1. Programmer skill and talent are not enough to achieve similar security properties with memory-unsafe languages as with memory-safe languages.
2. Therefore, "memory-safe languages are technically superior, period, for applications processing untrusted data where security is an important goal", is not an un-nuanced argument nor a Rust fanboy argument, but self-evident.
That still leaves a lot of room for other languages (Rust is not my favorite language), but it pushes back against the developer equivalent of doctors and pilots resisting the adoption of checklists for decades because "I wouldn't make those kinds of mistakes so stop messing with my work".
Almost? I'd fully support
1. Programmer skill and talent are not enough to achieve similar security properties with memory-unsafe languages as with memory-safe languages.
2. Therefore, "memory-safe languages are technically superior, period, for applications processing untrusted data where security is an important goal"
but the problem entirely boils down to what comes next:
3a. Therefore everything should use rust.
3b. Therefore everything processing untrusted data where security is an important goal should use rust. (Some folks like to stretch what could possibly process untrusted data to turn this into 3a, but there is a difference.)
3c. Therefore most programs really should be written with a garbage-collector, or if they really need to be low-level or high performance they should use an appropriate stack to avoid gc while remaining safe (whether that's Rust, Ada+SPARK, formally-verified assembly, or whatever).
I want to preface this with "This isn't a gotcha".
I think you make an important oversight with these claims, which is that you can enforce logical safety over a memory unsafe language and have a much higher degree of safety than memory safety. Formally verified C doesn't change the language, you can in principle take C code run through compcert and compile it elsewhere. It's still a memory unsafe language, but we can express a much higher degree of safety than simple memory safety.
Another aspect to consider is that all garbage collected languages are memory safe. A language like Python actually has a far greater degree of memory safety than a language like Rust because it offers no ability to break memory safety (without calling into foreign code), while Rust lets you do it within unsafe blocks using raw pointers. That being said, anybody who would suggest using Python over Rust in a security-focused context is completely out of their mind.
In serious places where security is critical and margin for error is low, formal verification has existed for decades and is the standard. Any operation - specifically in the context where security is critical - which is not formally verifying its software is a mickey mouse operation, because they're fundamentally compromising on security to an unacceptable degree. I think it would be nice to have a formal verification toolchain and language extension for Rust to allow for full logical safety, but last I checked this area was still a work in progress for the language.
I know anytime Rust is brought up, someone brings up logical safety, and patterns are annoying. Rust obviously has a lot of tricks up its sleeve to automatically detect issues that a language like C++ cannot. Naive Rust is preferable over naive usage of a memory unsafe language. The problem is that in a serious security critical context, "naive" is completely unacceptable. If security is a core goal, there can be no replacement for fully blown logical safety enforcing strict behavioral and structural guarantees in every single facet of the codebase. I know the line, that logical safety is excruciatingly labor intensive and so the tradeoff with using Rust is that it affords some of the safety of formally spec'd and proven code. The problem is that the amount it affords you is completely marginal. The safety gap between C and Rust is much smaller than the safety gap between Rust and formally proven correct SPARK. It's just the reality. I'm loathe to see a future where marketing hype sees a degeneration of tools because it was presented as a serious alternative.
2 replies →
Even C programmers with decades of experience are having hard time writing safe programs in C. If that's not enough, I don't know what is.
C++ in particular has a thriving industry of people who'll come teach your team to write "proper" C++.
You've probably heard that "It is difficult to get a man to understand something, when his salary depends on his not understanding it" and so of course we shouldn't expect such people to say "Don't write this in C++" when they can instead get paid to teach "How to write this in C++" for 2-3 days and feel like they made the world a better place on top.
It so happens Rust is my favourite language, or at least, my favourite general purpose language, but it's also true that I am currently mostly paid to write C# and I see absolutely no reason why I'd say "No, this should be Rust" for most work I do in C#
Thing is, Rust is not a memory safe programming language. It's not even close to being one.
> Diagnosing a Double-Free Concurrency Bug in Rust's Unbounded Channels
https://materialize.com/blog/rust-concurrency-bug-unbounded-...
1 reply →
What are the project specific nuance you are talking about? Anything in this and linked post could be applied to any performant application which values memory safety.
So unless they provide some Tor specific nuance, it's more or less applicable to wide range of applications.
In this case Rust makes sense. However for the majority of UI projects it doesn't make sense. For UI you want to iterate quickly because requirements change often, and you want garbage collection to be able to move fast. At the same time, performance does not matter (low level stuff like bit blitting can be done by lower level libraries perhaps written in Rust or even at the hardware level). A language designed for systems programming makes zero sense there. Unfortunately, we see a lot of "This UI project now in Rust!" on HN, and people get annoyed by that, and I think rightfully so. People don't want to maintain code that was written in the wrong language, and that __will__ happen if other people pick a language for the wrong reasons.
I am confused by this comment on the project page.
https://gitlab.torproject.org/tpo/core/arti
> (So far, it's a not-very-complete client. But watch this space!)
Is that comment outdated? The blog post gave me a different impression. If Arti is not ready yet, shouldn't that have been made clear in the blog post and in the various posts here? Not directing it at you, amelius.
I hate the "rewrite it in Rust" mentality, however, I think that in this particular case, Rust is the right tool for the job.
The Rust specialty is memory safety and performance in an relatively unconstrained environment (usually a PC), with multithreading. Unsurprisingly, because that's how it started, that's what a web browser is.
But Tor is also this. Security is extremely important as Tor will be under attack by the most resourceful hackers (state actors, ...), and the typical platform for Tor is a linux multicore PC, not some tiny embedded system or some weird platform, and because it may involve a lot of data and it is latency-sensitive, performance matters.
I don't know enough of these projects but I think it could also take another approach and use Zig in the same way Tigerbeetle uses it. But Zig may lack maturity, and it would be a big change. I think it is relevant because Tigerbeetle is all about determinism: do the same thing twice and the memory image should be exactly the same. I think it has value when it comes to security but also fingerprinting resistance, plus, it could open the way for dedicated Tor machines, maybe running some RTOS for even more determinism.
FWIW, rust is great on a tiny embedded system.
9 replies →
I think companies hired too many Rust engineers, and now those engineers are writing technical blogs and making product decisions. We're seeing a lot of those everyday on HN first page
I had that thought too; the author claims tor suffers from user free bugs but like, really? A 20 year old code base with a massive supportive following suffers from basic memory issues that can often be caught with linters or dynamic analysis? Surely there are development issues I'm not aware of but I wasn't really sold by the article
That can easily happen in C programs. Some edge case doesn't really happen, unless you specifically craft inputs for that, or even sequences of inputs, and simply no one was aware for those 20 years, or no one tried to exploit that specific part of the code. With C you are never safe, unless you somehow proved the code to be free of such bugs.
5 replies →
If a codebase is being maintained and extended, it's not all code with 20 years of testing.
Every change you make could be violating a some assumption made elsewhere, maybe even 20 years ago, and subtly break code at distance. C's type system doesn't carry much information, and is hostile to static analysis, which makes changes in large codebases difficult, laborious, and risky.
Rust is a linter and static analyzer cranked up to maximum. The whole language has been designed around having necessary information for static analysis easily available and reliable. Rust is built around disallowing or containing coding patterns that create dead-ends for static analysis. C never had this focus, so even trivial checks devolve into whole-program analysis and quickly hit undecidability (e.g. in Rust whenever you have &mut reference, you know for sure that it's valid, non-null, initialized, and that no other code anywhere can mutate it at the same time, and no other thread will even look at it. In C when you have a pointer to an object, eh, good luck!)
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.
There’s a fundamental trade-off between performance and privacy for onion routing. Much of the slowness you’re experiencing is likely network latency, and no software optimization will improve that.
I believe that the slowness is a matter of the amount nodes in the tor network, not something that can be fixed solely by code changes.
No one is claiming the new version is faster, only that it is safer.
It’s important to remember that safety is the whole purpose of the thing. If Tor is slow, it’s annoying. If Tor is compromised, people get imprisoned or killed.
completely agree but it could be added that a new language can sometimes help explore new ideas faster, in which case maybe the routing layer and protocol can see new optimizations
This is not correct. Tor is generally not bottlenecked by the quantity of available nodes, the usual bottleneck is the quality of nodes picked by your client rather than the quantity of nodes available.
Of course, technically, this problem is related to the quantity of high quality nodes :)
1 reply →
With 3 proxies traffic circles around the planet 2 times, which takes light 1/4 second to travel. Response does it again, so 1/2 second in total. Light is slow.
Nature just hasn't switched to Rust (and Arch) yet. Maybe it'll also get rid of those pesky black holes.
Plus TLS handshakes.
5 proxies does it even slower but would make attacks much more difficult.
3 replies →
I think this shows a misunderstanding of the purpose of TOR. It’s for privacy, not optimal latency for your video stream.
You meant Tor network, right? Sadly, making very fast anonymous overlay networks is extremely difficult. You either make it fast or don't sacrifice anonymity. I personally noticed that Tor network has significantly improved and is way faster since a few years. It's also not recommended to exit and if you religiously stay over onions, you increase your anonymity.
And significantly faster to access onion websites than go through exit nodes, which are probably saturated most of the time.
Reddit over their onion website is very snappy, and compared to accessing reddit over VPN it shows fewer issues with loading images/videos and less likely to be blocked off.
It would be nice if more websites were available as onion addresses (and I2P as well).
edit: also if the Tor browser (desktop and mobile) would ship with ublock origin bundled, that would further improve the experience (Brave browser Tor window compared to the Tor browser is a night and day difference)
3 replies →
Hey, if you want a fast anonymity netowrk, there are commercial providers. Companies doing research on thier competition use these to hide thier true idents from targets. They are not cheap (not free but cheaper than AWS imho) but have much greater functionality than tor.
https://voodootomato.medium.com/managed-attribution-the-key-...
https://www.authentic8.com/blog/non-attribution-misattributi...
>Hey, if you want a fast anonymity netowrk, there are commercial providers.
For most people seeking anonymity via Tor network (whistleblowers, journalists, activists, etc.), paying a company who can then subsequently be compelled to hand over your information is a bad choice.
And in most other scenarios, Authentic8 is probably still a bad choice. If you require a FedRAMP-authorized service, then sure, look at Authentic8.
> My biggest gripe with the Tor project is that it is so slow.
It’s not supposed to be a primary browsing outlet nor a replacement for a VPN. It’s for specific use cases that need high protection. The tradeoff between speed and privacy for someone whistleblowing to a journalist, as an example, is completely reasonable.
Having too much bandwidth available to each participant would incentivize too much abuse. In my past experience, a Tor associated IP was already highly correlated with abuse (users trying to evade bans, create alternate accounts to break rules, and then of course the actual attacks on security).
>It’s not supposed to be a primary browsing outlet nor a replacement for a VPN.
Tor wants people to use the network for primary browsing because it helps mask the people that need the protection. The more people using the network, the better for everyone's anonymity.
They even have a whole "Outreach" section at https://community.torproject.org/outreach/
1 reply →
I had that problem too, very slow on network requests, just change the setting "num_relays_proxied" from 3 to 1 to make it blazingly fast.
Then the single relay knows both who you are (your IP) and where you are going. This offers no anonymity against the relay itself.
3 relays is the goldilocks number for speed vs privacy. Using less is not a tradeoff the usual user of Tor should make.
9 replies →
This is a joke, for those who didn’t notice.
Tor is slow because traffic is routed through multiple layers. The design priority is anonymity, not speed.
You should preface this with some important information about what that does.
There are some trade-offs!
Changing that setting to 1 gives you weaker anonymity guarantees. Using multiple guards spreads your traffic across different IP addresses, making it harder for an adversary who controls a subset of the network to correlate your activity.
Reducing to a single guard concentrates all traffic through one point, increasing the chance that a hostile relay could observe a larger fraction of your streams...
1 reply →
Your config improvement made it into Google AI https://i.imgur.com/v5DsXy9.png
If this is sarcastic you should probably add /s or someone might actually follow your "advice".
4 replies →
What's the point of having one relay? You're better off using a reputable VPN like mullvad or ivpn. Tor is the best you're gonna get for low latency anonymous overlay network. It's been studied and refined over the years.
3 replies →
> And I am also not entirely convinced that Rust is really better than C.
Well it's certainly not worse than c, and it's hard to argue it's as bad, so...
> I don't think merely moving to Rust makes Tor faster either.
It would be crazy to think switching languages would make a network protocol faster without some evidence of this.
> Well it's certainly not worse than c, and it's hard to argue it's as bad, so...
Except in regards to having a proper standard (the standard from Ferrocene has significant issues), and to the size of the language and how easy it is to implement a compiler for.
There are a lot of differences and trade-offs.
4 replies →
I agree it probably won't make it faster. But there is absolutely no comparison when it comes to safety/stability. I've written a ton of C code, and it's just not even close. Rust really outshines C and C++ in this regard, and by a very large margin too.
How much C++ have you written? Not C, but C++.
Do you like pattern matching in Rust? It is one of the features that Rust does decently well at.
This was mostly funded by Zcash Community Grants. Good things can come from crypto R&D.
Pecunia non olet
I think perhaps cryptocurrency is worse than selling urine for its chemical properties, but the principle applies, money is just money
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.
Tor provides a great blog about running an exit node: https://blog.torproject.org/tips-running-exit-node/
I remember reading that it’s better to register as an organization if you want to run an exit node.
If you want to help the network, you can run relays. That’s much safer. https://community.torproject.org/relay/
For anyone wondering how else they can help without attracting scrutiny, consider running a bridge. I have done this at home for years and haven't noticed any ill effects like discrimination of my public IPs: https://community.torproject.org/relay/setup/bridge/
Or, if you're OK with a little discrimination (say you're colo hosted, not residential), but still want to avoid exit-relay-level attention, running guard/middle relays is helpful: https://community.torproject.org/relay/types-of-relays/
Not to my knowledge.
> now I have gigabit
You can host torrents to Linux isos to help. You’ll need to block some Chinese ASNs though. They use fake downloaders to detect peers. Like 99% of the traffic my node generated was that. Nodes from one ASN that do partial downloads over and over
Else hosting open map data tile server though I gather this can generate a lot of traffic
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.
i'm starting to wonder what if those rust rewrites might be covert attempt to introduce back doors in plain sight?
Isn't Tor a concept, a protocol? It's like saying you're going to rewrite http in rust...
Onion routing is the protocol. Tor is the network and the name of the reference implementation.
It's a product. You can download and implement it's many components.
No.
They should just start compiling Tor with Fil-C — free memory safety, no new bugs from full code rewrite
This move started before Fil-C existed.
Rust - "I am inevitable"
"And I... am the Oxidized Man."
[snaps fingers]
Unless you use aluminum or stainless steel...
Rust never sleeps.
N. Young
young and rustless ?
1 reply →
[flagged]
It did look like that ever since an NSA critical Tor developer got canceled using the same methods as against Assange.
I suppose soon we'll get nsa-leftpad from cargo as a dependency among 347 other packages.
What was the parent comment?
[dead]
Why not Go? It's more portable.
Portable to what? Rust works fine on all of today's popular platforms.
I see people complaining about Rust's lack of portability, and it is always some obsolete platform that has been dead for 20 years. Let's be serious, nobody is gonna run Tor on an old SGI workstation or Itanium server.
>Let's be serious, nobody is gonna run Tor on an old SGI workstation or Itanium server.
dont temp me with a good time and awesome weekend project!
It is still possible to build for targets such as Itanium. There is nothing stopping you from writing your own targets too in LLVM and its not obscenely difficult
https://github.com/llvm/llvm-project/tree/main/llvm/lib/Targ...
Not under OpenBSD i686.
Also, the more heterogeneous it's a CPU architecture support, the least exploitable a service will be.
3 replies →
That's a good point, really there's no reason to waste time on anything but popular platforms. Obviously, of course, this means dropping support for everything except Windows (x64 and maybe ARM) and macOS (ARM). (\s)
In all seriousness, I guess you can make this argument if you only care about Windows/macOS, but the moment you run anything else I have to ask why, say, Linux deserves support but not other less-common platforms.
5 replies →
Don't Rust and Go build to mostly-statically-compiled binaries? (With the exception of a link to libc.) (This isn't a rhetorical question, this is something I don't know a lot about
I'd imagine the biggest cultural reason is that many Rust developers were C developers who had a reason to find something better, but still scoff at garbage collection, large runtimes, etc. They probably have a lot more Rust expertise in their circle.
Another technical reason is that they were trying to replace their C code with Rust in bits and pieces before they went with a full rewrite. I don't know about Go, but this is something ergonomically doable in Rust.
Plus, Rust has a more expressive type system.
I like loose type systems for some quick scripting, but I started to adopt Rust for many of my personal projects because I find it's so much easier to get back into a project after a year when there are good type system guard rails.
Rust can create statically-compiled binaries on Linux by using musl instead of glibc, but it’s not the default like it is in Go and is as a result not quite as effortless. There are a lot of crates with native dependencies that require slight environment tweaks to work on a musl build. Go on the other hand goes to great lengths to not need to link to any C code at all, to the point of shipping its own default TLS library and cryptographic primitives.
4 replies →
Probably because:
- better data race handling;
- no garbage collection, more predictable performance;
- stricter type system that can enforce constraints better;
- closer to metal and better FFI support.
Which seems to matter more for Tor project than support for some barely used platform.
What do you mean? Rust supports far more platforms.
Also Rust has a lot more inherent safety features than go.
(I think Go is great and its my primary language)
In terms of compilation of programs Go is far, far easier than Rust. For Rust to compile a random Rust program on the internet one almost always has to have the absolutely latest out of repo compiler toolchain from curl rustup.whatever | sh. The normal 4 year release cycle is incompatible with rust development. For commercial use cases this doesn't matter. But for open source like the tor project it does.
That said, since they use Firefox this bridge has already been burned.
1 reply →
No Rust under OpenBSD i686. Rust on PowerMacs? Alpha?
This is legit question, especially for Tor binaries.
Advantage of Rust (or original C implementation) is for users that do not have runtime and want to import Tor libraries (like arti-client) in their code. Go could work but those unmanaged languages are better here. So in the end Rust (or C, C++ etc.) can serve more user-cases.
and easier to learn.
and better funded.
and easier to find devs.
They both suck getting new devs for
Also, just because it's part of Google doesn't make go better funded. Theyd probably be fine killing go.
Definitely easier to learn though :P
4 replies →
Rust is going to feel more familiar to Tor contributors than Go. Based on the list of platinum members (which includes Google and Tor btw) there's some serious money going into the Rust Foundation, assuming it's managed properly I can't see funding as an issue.
https://rustfoundation.org/members/
2 replies →
i have no dog in the fight, but based on tor release schedule it seems to me that the team is very very talented and rust complexity is not a challenge for them
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]
Complete rewrites have been done before. They're not impossible tasks. C to C++ (like with fish), C++ to Rust (fish again, Tor, etc), Java to C# (something I've seen), C# to C++ (evernote), Blender Game Engine to Godot (many small cases), Godot to Lumberyard (something I've seen), Unity to Godot (many small cases), etc. And there are all the myriad rewrites within the same language, or across major breaking changes (like Python 2 to Python 3).
I think "you should never do a full rewrite" is something of a reactionary response to the juvenile idea new devs and interns get every now and then. But sometimes, a rewrite really is a good idea.
But in this case, per the announcement ( https://blog.torproject.org/announcing-arti/ ), the reasons are pretty convincing. The major reasons are, unsurprisingly, all around memory safety.
> Godot to Lumberyard Do you remember what project(s) this was? I'd be super curious on the motivations of the developers. I guess I could see it when it first went open source and Godot wasn't all it was today.
1 reply →
The issue is that every other week there is a rewrite of something in Rust. I just do an eyeroll whenever I see that yet another thing is being rewritten in Rust.
I've tried compiling large projects in Rust in a VM (8GB) and I've run out of memory whereas I am sure a C/C++ large project of a similar size wouldn't run out of memory. A lot of this tooling I had to compile myself because it wasn't available for my Linux distro (Debian 12 at the time).
A lot of the tooling reminds me of NPM, and after spending a huge amount of my time fighting with NPM, I actually prefer the way C/C++/CMake handles stuff.
I also don't like the language. I do personal stuff in C++ and I found Rust really irritating when learning the language (the return rules are weird) and just gave up with it.
14 replies →
Comelete rewrite are not always bad, they are _just_ very costly. You just need to do cost benefit analsys and compare it with the cost and benefit of other actions.
Fish did a complete rewrite in Rust, but they did it in the right way.
1. Rewrite each C file in Rust as a 1:1 mapping.
2. Rewrite the Rust to make it idiomatic.
3. Start making structural changes.
Well, an underrated aspect of the Rust rewrites, is that it's easy to publish and share official libraries from the projects that the community can use, something that is too hard in C land.
If anything, from a security standpoint, this is one of the bigger issues with a rewrite in Rust. Besides the "MIT EVERYTHING" mindset, Rust people are also similar to JS devs in having projects with huge supply chain attack surfaces, from their eagerness to rely on so many crates.
2 replies →
I worked at a startup where the original code base was outsourced to cheap developers and was riddled with security vulnerabilities.
A complete rewrite made sense.
Opinions with “always” in them are always a bad idea.
Nobody ever said rewrites are always a bad idea. You just made that up. It has been done successfully many times, with many more happening (e.g. TypeScript compiler rewrite).
What matters is how the project is planned and implemented.
Typically, complete rewrites that halt all feature development and fail to achieve feature parity is a recipe for disaster. On the other hand, balancing the work for feature/regular maintenance and rewrite and gradually achieving feature parity before rolling things out has worked well.
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.
It is intended. Like any other US gov funded projects.
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.