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...
It’s probably precisely because his browser is not customized that it’s not easily fingerprintable, because stock Safari has privacy protections and users generally don’t change anything.
I got a very similar result on unmodified iOS Safari, randomized among 380k users and conveying 15.5 bits of information. I only have the Dark Reader extension.
It's not "install" that matter here. If two people have the same "install" but their browser windows have different sizes, they'll be distinguishable. Or any perperty that can be queried via JS.
Let me rephrase it: you believe it, I don't believe.
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."
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!
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.
Given how heavily most C programs lean on type erasure vs. monomorphization and how often they reimplement basic data structures, it's kind of a miracle they hold up against Rust/C++.
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.
It seems they worry about it, which I can understand. But now with Rust I worry about about new logic bugs, supply chain issues, and lack of proper security updates.
Or, you could look at other projects who have been using Rust for many years, and consider these factors there too. The folks who have have generally concluded the opposite.
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.
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.
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).
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#
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.
From the looks of it, Rust is usable un a tiny embedded system but it is not "great". I think that out of the recent, trendy languages, Zig is the best suited for this task, but in practice C is still king.
The big thing is memory allocation, sometimes, on tiny systems, you can't malloc() at all, you also have to be careful about your stack, which is often no more than a few kB. Rust, like modern C++ tend to abstract away these things, which is perfectly fine on Linux and a good thing when you have a lot of dynamic structures, but one a tiny system, you usually want full control. Rust can do that, I think, like C++, it is just not what it does best. C works well because it does nothing unless you explicitly ask for it, and Zig took that philosophy and ran away with it, making memory allocation even more explicit.
It probably depends how tiny you mean. If the reason you can't allocate memory is because the only 1024 bytes of static RAM is all stack, then, yeah, Rust won't be very comfortable on that hardware. On the other hand C isn't exactly a barrel of laughs either. In my mind if I can sensibly chart what each byte of RAM is used for on a whiteboard then we should write machine code by hand and skip "high level" languages entirely.
Rust has no malloc in the language whatsoever. In embedded, you don't even include the libraries for dynamic allocation in the first place, unless you want to. And it's very normal not to.
For an example, if a function in no_std overflows, it can result in undefined behavior, no unsafe required. And stack overflows are easy in Rust, like they are easy in most other systems languages.
Steve Klabnik has lied about that in the past, as he is wont to do.
I don't know where I've lied about this, supposedly. Unless you say that, because of this implementation exception (which is based on target, not std vs no_std by the way) as meaning that "there's no UB in safe Rust" to be a lie.
I would still stand by that statement generally. Implementation issues on specific platforms are generally not considered to be what's being discussed when talking about things like this. It's similar to how cvs-rs doesn't make this a lie; a bug isn't in scope to what we're talking about 99% of the time.
In context, I'd have no reason to deny that this is something you'd want to watch out for.
> For an example, if a function in no_std overflows, it can result in undefined behavior, no unsafe required. And stack overflows are easy in Rust, like they are easy in most other systems languages.
This is true, no_std has no Rust runtime so it doesn't provide stack protection. I am aware of efforts to address this for embedded, but they're not available at the moment.
> Steve Klabnik has lied about that in the past, as he is wont to do.
1) I don't know what Steve has to do with anything I asked so it is bizarre to bring up and 2) I find this is to be a ridiculous statement.
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.
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.
This is a bit of an exaggeration. Many types of bugs can also happen with Rust, and with you use unsafe or have some dependency that uses it, then also memory safety bugs. At the same time, it is possible to reduce the probability and impact of such bugs in C code in a reasonable way even without formal verification.
Does every discussion of Rust and C need this recurring subthread conversation? It is approaching Groundhog Day levels of repetition. Yes, `unsafe` code can have memory safety bugs. Yes, `unsafe` doesn't mean "unsafe". Yes, a sufficiently advanced C-developer can have a sufficiently advanced C-codebase with reduced probability of bugs that might be even better than an insufficiently advanced Rust-developer. Yes, regular safe-Rust isn't the same formal verification. Yes, Rust doesn't catch every bug.
On the other hand, most developers have no need of writing `unsafe` Rust. The same tools used for static and dynamic analysis of C codebases are available to Rust (ASAN and friends) and it is a good idea to use them when writing `unsafe` (plus miri).
The reason I'm replying is that "the impact of Rust on memory safety" is always a conversation that gets outsized amounts of ink that it drains focus away from other things. I would argue that sum types and exhaustive pattern matching are way more important to minimize logic bugs, even if they aren't enough. You can still have a directory traversal bug letting a remote service write outside of the directory your local service meant to allow. You can still have TOCTOU bugs. You can still have DoS attacks if your codebase doesn't handle all cases carefully. Race conditions can still happen. Specific libraries might be able to protect from some of these, and library reuse increases the likelihood of of these being handled sanely (but doesn't ensure it). Rust doesn't protect against every potential logic error. It never claimed to, and arguing against it is arguing against a strawman. What safe-Rust does claim is no memory safety bugs, no data races, and to provide language and tooling features to model your business logic and deal with complexity.
I might make such comments as long as other continue to make statements about Rust vs Cs. which I think are exaggerated. As long as people make such statements, it is obviously not a strawman.
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!)
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.
13 years to get to v0.0.1 is a success? Look at how much progress Ladybird has made in a fraction of that time. Remember that these people are constantly starting rewrites of C and C++ projects (when they're not demanding others do it) in Rust "for safety" (and "oops it's MIT now"), even of ancient Unix utilities with minimal attack surfaces like the "date" command, yet when it comes to a browser rendering engine, which entails computationally-intensive, aggressively-optimized rendering of untrusted input--a massive attack surface, and the very thing for which Rust was supposedly designed--they somehow can't get the right combination of enough Rust zealots (and Adderall) to get past the finish line.
Success isn't a binary thing. It's true that Servo has long struggled to make progress, and that can be seen as a failure. It's recent progress can also be seen as a success.
Your life might improve if you stop believing that Rust devs belong to a cult of your own imagination.
Measuring success of a project against a bar that the project didn't set is like complaining that an F1 car is hard to park: that's not what it was meant to do.
Servo was meant to be a test-bed for new architectures that might or might not be usable by Firefox. It was never meant to become Firefox' new web renderer, and it wasn't until more recently and long after the Mozilla-pocalypse that a new team took over the project with a goal of productionalizing the project as a whole. Stylo, for example, was integrated into Firefox 57 and allowed for parallel CSS style calculation, an effort that was tried unsuccessfully multiple times in C++.
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.
TS decision to choose Go was primarily, because they could take the existing code and do a near 1-1 translation. You can frame that as an architectural concern, but it's really only one that applies when your attempting to migrate an existing program to a new language. The Go rewrite has some negative outcomes as well, most concerning is the performance of the WASM builds is worse than the old JS/TS version.
A TS compiler from scratch built in Rust would be fine.
> You can frame that as an architectural concern...
"Go also offers excellent control of memory layout and allocation (both on an object and field level) without requiring that the entire codebase continually concern itself with memory management."
"The TypeScript compiler's move to Go was influenced by specific technical requirements, such as the need for structural compatibility with the existing JavaScript-based codebase, ease of memory management, and the ability to handle complex graph processing efficiently. "
If memory management and ability to handle complex graph processing efficiently isn't related to architecture to you I don't know what to tell you.
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.
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 :)
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
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.
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.
The modern TLS 1.3 handshake is exactly the same as your connection setup. If we ignore the fact that (Because Middleboxes) you have to pretend you're talking TLS 1.2 it goes like this:
Client: "Hi, some.web.site.example please, I want to talk HTTP and I assume you know how AES works and I've randomly picked these numbers to agree the AES key"
Server: "Hi, I do know AES and I've picked these other numbers so now we're good."
Included in the very same packet as that response from the server is the (now AES encrypted) first things the TLS server wants to say e.g. to prove who it is, and agree that it knows HTTP as well.
0RT is a (very dangerous, do not use unless you understand exactly what you're doing) extension for some niche applications where we can safely skip even this roundtrip, also included in TLS 1.3
What do you mean by "exactly the same as your connection setup."? Are you talking about TCP?
This TLS handshake can only happen after the TCP handshake, right? So 1 rtt for TCP, + 1 rtt for TLS. 2 rtt total. (2.5 rtt for the server to start receiving actual data. 3 rtt for the client to receive the actual response.)
Today, Tor doesn't move QUIC so you'd have to do TCP, but that's not actually a design requirement of Tor, a future Tor could actually deliver QUIC instead. QUIC is encrypted with TLS 1.3 so your first packet as the client is that Hello packet, there's no TCP layer.
QUIC really wants to do discovery to figure out a better way to move the data and of course Tor doesn't want discovery that's the whole point, so these features are in tension, but that's not hard to resolve in Tor's favour from what I can see.
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)
> 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.
Knowing not so much about Tor but some about math: the number of nodes you need to compromise in order to de-anonymize a Tor user is exponential in the number of hops. Google says there are roughly 7000 Tor nodes, including 2000 guards (entry) and 1000 exit nodes. If you have a single hop, there's roughly a 1/1000 chance that you will connect to a single malicious node that can de-anonymize you, going up linearly with the number of nodes an attacker controls. If you have 3 hops, you have a 1 in 1000 * 7000 * 2000 = roughly 14 billion chance. 2 hops would give you 1 in 2 million, 4 hops would give you 1 in 1000 * 7000 * 7000 * 2000 = 98 trillion. In practical terms 1:14B is about the same as 1:98T (i.e. both are effectively zero), but 1:2M is a lot higher.
There are currently ~9000 relays if you look at https://metrics.torproject.org/networksize.html. The current problem is the fact that majority of relays are in Germany and if you rotate your circuits enough, you'll also notice the same path. German govt has been very hostile towards Tor for a long time, they were also behind KAX17. We need more relays obviously but also in different regions.
4 = ... actually, you have more attack surface and you are more susceptible to fingerprinting because everybody else is using 3, so you're timings etc help identify you
So the default is 3 and nobody ought change it! Use 3 like everybody else.
The exception is .onion sites. TOR actually deliberately defaults to 6 hops when accessing .oninon sites - 3 to protect you and 3 to project the site.
They should be fine since I made up the setting name, and even though I am not familiar with Tor client's configuration, I don't believe this is possible without altering its source code.
Also, using this kind of software without understanding how its works even just a little doesn't protect much of your privacy.
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.
It's very difficult for me to contemplate how anybody could run a VPN, however reputable, that isn't compromised by one intelligence agency at least. Their incentive structures and their costs to participate in this space just make it a no-brainer.
If you're starting a brand new VPN company with ironclad ideals about privacy - are you going to be able to compete with state-run enterprises that can subsidize their own competing "businesses", on top of whatever coercive authority they possess to intervene in local small businesses?
> 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.
This would be a fantastic argument against rust for the m68k or some other embedded architecture. But we live in a world with an actual rust compiler for basically all architectures tor serves. & obviously the c standard can't save c from itself.
Yet you are wrong, for a standard matters about other matters, and there are many other differences. For instance, building a large project in a language with only one major compiler, can introduce risk. That rustc is open source decreases the risk from that, but getting something like gccrs up and running would be really helpful.
That parts of the Rust community has in the past been actively hostile against gccrs, is then mind-boggling. But Steve Klabnik will lie about that, as he has lied many times in the past and is his wont.
> I know, please don't be discouraged. It's just an (unfortunately) prominent, loud subsection. It's not just gaslighting, it's basically concern trolling. The negative top OP plays concerned, but has been trolling GCC-RS posts for many months now. Especially on this subreddit, it's a small number of people that know how to play to a reddit audience and get people riled up. I also know that it's spread to sites like HN.
Ahh here you are speaking nonsense again. We ain't talking formal logic, we're speaking human to human
> For instance, building a large project in a language with only one major compiler, can introduce risk.
Ok let's introduce an alternative to gcc then
> But Steve Klabnik will lie about that
You seem fine to both tarnish the reputation of, erm, c defenders with your own actions and to slander the reputation of Klabnik (or "lie" as I'm sure you'd term it), who both speaks more coherently and with his own name. Why do this in the name of open source if you have nothing to contribute, knowing that you're setting your own project back?
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.
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
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.
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.
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.)
> I can't even get Rust to work here on my slightly older Mac system.
Could you elaborate on that? macOS Sierra (released on 2016) on Intel macs is supported[1][2], which should allow for Macs from late 2009 onward to work. The Intel Mac build is no longer Tier 1 because the project no longer has access to CI machines for them, and 32-bit cross building is hampered by Xcode 14 not shipping the corresponding SDK[3].
> 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.
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.
I thought the default for both Rust and Go were to statically compile everything except the dynamic link to libc? And that you could optionally statically include musl with a bit of extra work.
I've never had to do anything unusual with building, but I thought the "almost-ststically-compiled" thing was somewhere Go and Rust were almost identical.
You and your parent are talking about slightly different things. You are both correct in different ways.
Your parent is saying that, while what you say is true for Rust and Go code themselves, in practice, it is less true for Rust, because Rust code tends to call into C code more than Go code does, and Rust doesn't always statically link to that C code by default.
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.
I'm willing to be Rust suck a ton more to hire devs. Since, as we both agree, Go is easy to learn. Any C#, PHP or Java dev can get going with Go in not time.
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 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 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.
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.
It was a project I worked on as an intern at Electric Boat. I can only speak to specifics I was explicitly given the okay to share though (i.e. this is all on my LinkedIn).
The project was a virtual training simulation for a submarine cockpit, first in Blender Game Engine. With support for BGE being deprecated, I was tasked to find an alternative engine and to port the work. (I'm very proud my research pointed to Godot- this was during the Godot 2 era).
There was a lot of interest in the project, but my internship was coming to an end and they decided to port it to Amazon Lumberyard for fear of Godot's longevity and support. They didn't want to be left "waiting for Godot". The final task I took on was to document the project, to make that transition easier for whoever came next.
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.
To be fair, you haven't explained why it's an issue to see projects being rewritten in Rust, other than it is a bit annoying to you?
For me, I had a very good experience rewriting a project in Rust (from Python). It was just an improvement in every regard (the project was easier to build and distribute, it was a good opportunity to rearchitect it, and the code ended up 20k times faster.) So, I have the opposite feeling when I see titles like these.
I also feel the opposite about the tooling. For me, cmake, npm, pip, maven, etc. all live in this realm where any invocation could become a time purgatory. The big thing that makes me like Rust is that I've never had that experience with cargo. (In fact, pip was the primary motivation to move away from Python to Rust. Everything else was just nice.)
I'm not saying this to convince you to feel otherwise, I just wanted to offer how I felt about the same topics. I grew up with C and Java, but Rust clicked after I read SICP and followed along in Racket. I could probably fill a page of small grievances about Rust's syntax if I had to.
> whereas I am sure a C/C++ large project of a similar size wouldn't run out of memory
This is a common issue on large C++ projects for users with limited resources. You typically have to tinker with build settings and use a different linker etc.. to get the project building without OOMing.
> A lot of the tooling reminds me of NPM
My feeling is that you'd have the same criticism about a lot of other modern ecosystems because they allow you to pull dependencies easily. With things like vcpkg, that's also possible in C++ but even without it: nothing stops the same behavior of importing "random" code from the internet.
> 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 guess you and me live different lives because I have spent far more time messing with ancient C/C++/CMake/Automake/Autoconf/configure/just have this particular .so file in this particular spot/copy some guys entire machine because this project only builds there/learn and entirely different language just to write build files (CMake sucks and 5 other alternatives are just lipstick on a pig) etc. etc.
I am of the opinion that half of Rusts success is based on that fact that C/C++'s tooling is annoying and ancient. People want to write code not mess with build envs.
Sure. That doesn't matter. Of course you can keep writing your C/C++ or using CMake, nobody is going to stop that. But other people's project are not going to stop adopt new tech stack because how you feel about it.
RE: memory, any self-respecting CI/CD system will allow you to compile any Rust project without out-of-memory halts.
RE: NPM, you have a right to a preference of course. I certainly don't miss the times 20 years ago when pulling in a library into a C++ project was a two-week project in itself. make and CMake work perfect right up until they don't and the last 2% cost you 98% of the time. Strategically speaking, using make/CMake is simply unjustified risk. But this is of course always written off as "skill issue!" which I gave up arguing against because the arguers apparently have never hit the dark corners. I have. I am better with Just and Cargo. And Elixir's mix / hex.
What you like as a language (or syntax) and what you roll your eyes at are obviously not technological or merit-based arguments. "Weird" I can't quite place as an argument either.
Use what you like. We all do the same. The original article lists good arguments in favor of Rust. Seems like a good case of "use the right tool for the job" to me.
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.
I agree this is problematic, sure, and is not unique to Rust or JS. Feel free to propose and work on something better, I'd be your enthusiastic supporter.
It's simply a way to be able to move at a reasonable speed is how I see it.
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.
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".
It seems to reward totally unique randomized fingerprints also, which is maybe not great.
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...
No, on this device literally the only customization I have is the RECAP browser extension. And even RECAP only runs on whitelisted websites.
It’s probably precisely because his browser is not customized that it’s not easily fingerprintable, because stock Safari has privacy protections and users generally don’t change anything.
I got a very similar result on unmodified iOS Safari, randomized among 380k users and conveying 15.5 bits of information. I only have the Dark Reader extension.
I'm downloading safari right now.
EDIT: just saw I need to download playonlinux or wine. Forget about it.
Could you clarify if that's with or without JS?
I have not disabled JS or made any other configuration changes on this device. Entirely stock Safari and entirely stock MacOS.
That's not really believable. I'm starting to think this website isn't very reliable.
No, it's believable. All this website is communicating to us that most MacOS Safari installs look the same.
It's not "install" that matter here. If two people have the same "install" but their browser windows have different sizes, they'll be distinguishable. Or any perperty that can be queried via JS.
Let me rephrase it: you believe it, I don't believe.
Browser window size and timezone are basically the only identifying details the page gets besides the fact that I use Safari on MacOS
For window size only 1 in 380326.0 browsers has this value.
For example, what does the section "time zone" and "time zone offset" read for you? You have JS on, so what did JS return on that point?
I'm downloading safari right now.
EDIT: just saw I need to download playonlinux or wine. Forget about it.
It gets my correct timezone.
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?
Hovering can trigger network request
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.
You're correct, incognito mode never has been for privacy protection from websites, ISPs, etc.
it's commonly used for checking how sites look when not logged in, without logging out, or logging in as another user temporarily.
While this was possible in the past, I believe it got patched and is impossible today.
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
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.
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.
Given how heavily most C programs lean on type erasure vs. monomorphization and how often they reimplement basic data structures, it's kind of a miracle they hold up against Rust/C++.
Why? Monomorphization often leads to great results in microbenchmarks due to super-specialized code but also to bloat.
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.
It seems they worry about it, which I can understand. But now with Rust I worry about about new logic bugs, supply chain issues, and lack of proper security updates.
Well, given that this has been going on for years, you can already start to empirically evaluate that question.
> (So far, it's a not-very-complete client. But watch this space!)
Yes, it's a beginning not the end.
Or, you could look at other projects who have been using Rust for many years, and consider these factors there too. The folks who have have generally concluded the opposite.
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.
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.
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).
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-...
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.
From the looks of it, Rust is usable un a tiny embedded system but it is not "great". I think that out of the recent, trendy languages, Zig is the best suited for this task, but in practice C is still king.
The big thing is memory allocation, sometimes, on tiny systems, you can't malloc() at all, you also have to be careful about your stack, which is often no more than a few kB. Rust, like modern C++ tend to abstract away these things, which is perfectly fine on Linux and a good thing when you have a lot of dynamic structures, but one a tiny system, you usually want full control. Rust can do that, I think, like C++, it is just not what it does best. C works well because it does nothing unless you explicitly ask for it, and Zig took that philosophy and ran away with it, making memory allocation even more explicit.
It probably depends how tiny you mean. If the reason you can't allocate memory is because the only 1024 bytes of static RAM is all stack, then, yeah, Rust won't be very comfortable on that hardware. On the other hand C isn't exactly a barrel of laughs either. In my mind if I can sensibly chart what each byte of RAM is used for on a whiteboard then we should write machine code by hand and skip "high level" languages entirely.
Rust has no malloc in the language whatsoever. In embedded, you don't even include the libraries for dynamic allocation in the first place, unless you want to. And it's very normal not to.
But with no_std, Rust is not memory safe, even when not using unsafe. It does have pattern matching and modules, however.
> But with no_std, Rust is not memory safe, even when not using unsafe.
What makes you say that?
For an example, if a function in no_std overflows, it can result in undefined behavior, no unsafe required. And stack overflows are easy in Rust, like they are easy in most other systems languages.
Steve Klabnik has lied about that in the past, as he is wont to do.
I don't know where I've lied about this, supposedly. Unless you say that, because of this implementation exception (which is based on target, not std vs no_std by the way) as meaning that "there's no UB in safe Rust" to be a lie.
I would still stand by that statement generally. Implementation issues on specific platforms are generally not considered to be what's being discussed when talking about things like this. It's similar to how cvs-rs doesn't make this a lie; a bug isn't in scope to what we're talking about 99% of the time.
In context, I'd have no reason to deny that this is something you'd want to watch out for.
> For an example, if a function in no_std overflows, it can result in undefined behavior, no unsafe required. And stack overflows are easy in Rust, like they are easy in most other systems languages.
This is true, no_std has no Rust runtime so it doesn't provide stack protection. I am aware of efforts to address this for embedded, but they're not available at the moment.
> Steve Klabnik has lied about that in the past, as he is wont to do.
1) I don't know what Steve has to do with anything I asked so it is bizarre to bring up and 2) I find this is to be a ridiculous statement.
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.
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.
This is a bit of an exaggeration. Many types of bugs can also happen with Rust, and with you use unsafe or have some dependency that uses it, then also memory safety bugs. At the same time, it is possible to reduce the probability and impact of such bugs in C code in a reasonable way even without formal verification.
Does every discussion of Rust and C need this recurring subthread conversation? It is approaching Groundhog Day levels of repetition. Yes, `unsafe` code can have memory safety bugs. Yes, `unsafe` doesn't mean "unsafe". Yes, a sufficiently advanced C-developer can have a sufficiently advanced C-codebase with reduced probability of bugs that might be even better than an insufficiently advanced Rust-developer. Yes, regular safe-Rust isn't the same formal verification. Yes, Rust doesn't catch every bug.
On the other hand, most developers have no need of writing `unsafe` Rust. The same tools used for static and dynamic analysis of C codebases are available to Rust (ASAN and friends) and it is a good idea to use them when writing `unsafe` (plus miri).
The reason I'm replying is that "the impact of Rust on memory safety" is always a conversation that gets outsized amounts of ink that it drains focus away from other things. I would argue that sum types and exhaustive pattern matching are way more important to minimize logic bugs, even if they aren't enough. You can still have a directory traversal bug letting a remote service write outside of the directory your local service meant to allow. You can still have TOCTOU bugs. You can still have DoS attacks if your codebase doesn't handle all cases carefully. Race conditions can still happen. Specific libraries might be able to protect from some of these, and library reuse increases the likelihood of of these being handled sanely (but doesn't ensure it). Rust doesn't protect against every potential logic error. It never claimed to, and arguing against it is arguing against a strawman. What safe-Rust does claim is no memory safety bugs, no data races, and to provide language and tooling features to model your business logic and deal with complexity.
I might make such comments as long as other continue to make statements about Rust vs Cs. which I think are exaggerated. As long as people make such statements, it is obviously not a strawman.
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!)
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.
> Did it fail
13 years to get to v0.0.1 is a success? Look at how much progress Ladybird has made in a fraction of that time. Remember that these people are constantly starting rewrites of C and C++ projects (when they're not demanding others do it) in Rust "for safety" (and "oops it's MIT now"), even of ancient Unix utilities with minimal attack surfaces like the "date" command, yet when it comes to a browser rendering engine, which entails computationally-intensive, aggressively-optimized rendering of untrusted input--a massive attack surface, and the very thing for which Rust was supposedly designed--they somehow can't get the right combination of enough Rust zealots (and Adderall) to get past the finish line.
Success isn't a binary thing. It's true that Servo has long struggled to make progress, and that can be seen as a failure. It's recent progress can also be seen as a success.
Your life might improve if you stop believing that Rust devs belong to a cult of your own imagination.
Measuring success of a project against a bar that the project didn't set is like complaining that an F1 car is hard to park: that's not what it was meant to do.
Servo was meant to be a test-bed for new architectures that might or might not be usable by Firefox. It was never meant to become Firefox' new web renderer, and it wasn't until more recently and long after the Mozilla-pocalypse that a new team took over the project with a goal of productionalizing the project as a whole. Stylo, for example, was integrated into Firefox 57 and allowed for parallel CSS style calculation, an effort that was tried unsuccessfully multiple times in C++.
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
TS decision to choose Go was primarily, because they could take the existing code and do a near 1-1 translation. You can frame that as an architectural concern, but it's really only one that applies when your attempting to migrate an existing program to a new language. The Go rewrite has some negative outcomes as well, most concerning is the performance of the WASM builds is worse than the old JS/TS version.
A TS compiler from scratch built in Rust would be fine.
> cultists
The cult is in your imagination.
Not your parent commenter but:
> You can frame that as an architectural concern...
"Go also offers excellent control of memory layout and allocation (both on an object and field level) without requiring that the entire codebase continually concern itself with memory management."
"The TypeScript compiler's move to Go was influenced by specific technical requirements, such as the need for structural compatibility with the existing JavaScript-based codebase, ease of memory management, and the ability to handle complex graph processing efficiently. "
If memory management and ability to handle complex graph processing efficiently isn't related to architecture to you I don't know what to tell you.
[0] https://github.com/microsoft/typescript-go/discussions/411
> The cult is in your imagination.
CTRL+F "rust" on the Go issue and see how many results you get. 31 for me and that's before expanding spam.
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
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.
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 :)
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
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.
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.
Plus TLS handshakes.
5 proxies does it even slower but would make attacks much more difficult.
The modern TLS 1.3 handshake is exactly the same as your connection setup. If we ignore the fact that (Because Middleboxes) you have to pretend you're talking TLS 1.2 it goes like this:
Client: "Hi, some.web.site.example please, I want to talk HTTP and I assume you know how AES works and I've randomly picked these numbers to agree the AES key"
Server: "Hi, I do know AES and I've picked these other numbers so now we're good."
Included in the very same packet as that response from the server is the (now AES encrypted) first things the TLS server wants to say e.g. to prove who it is, and agree that it knows HTTP as well.
0RT is a (very dangerous, do not use unless you understand exactly what you're doing) extension for some niche applications where we can safely skip even this roundtrip, also included in TLS 1.3
What do you mean by "exactly the same as your connection setup."? Are you talking about TCP?
This TLS handshake can only happen after the TCP handshake, right? So 1 rtt for TCP, + 1 rtt for TLS. 2 rtt total. (2.5 rtt for the server to start receiving actual data. 3 rtt for the client to receive the actual response.)
Today, Tor doesn't move QUIC so you'd have to do TCP, but that's not actually a design requirement of Tor, a future Tor could actually deliver QUIC instead. QUIC is encrypted with TLS 1.3 so your first packet as the client is that Hello packet, there's no TCP layer.
QUIC really wants to do discovery to figure out a better way to move the data and of course Tor doesn't want discovery that's the whole point, so these features are in tension, but that's not hard to resolve in Tor's favour from what I can see.
Nature just hasn't switched to Rust (and Arch) yet. Maybe it'll also get rid of those pesky black holes.
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)
> 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/
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.
How is 3 so much better than 2, but 4 not so much better than 3?
Knowing not so much about Tor but some about math: the number of nodes you need to compromise in order to de-anonymize a Tor user is exponential in the number of hops. Google says there are roughly 7000 Tor nodes, including 2000 guards (entry) and 1000 exit nodes. If you have a single hop, there's roughly a 1/1000 chance that you will connect to a single malicious node that can de-anonymize you, going up linearly with the number of nodes an attacker controls. If you have 3 hops, you have a 1 in 1000 * 7000 * 2000 = roughly 14 billion chance. 2 hops would give you 1 in 2 million, 4 hops would give you 1 in 1000 * 7000 * 7000 * 2000 = 98 trillion. In practical terms 1:14B is about the same as 1:98T (i.e. both are effectively zero), but 1:2M is a lot higher.
There are currently ~9000 relays if you look at https://metrics.torproject.org/networksize.html. The current problem is the fact that majority of relays are in Germany and if you rotate your circuits enough, you'll also notice the same path. German govt has been very hostile towards Tor for a long time, they were also behind KAX17. We need more relays obviously but also in different regions.
1 = no privacy from relay
2 = risk of collusion between relays
3 = goldilocks default
4 = ... actually, you have more attack surface and you are more susceptible to fingerprinting because everybody else is using 3, so you're timings etc help identify you
So the default is 3 and nobody ought change it! Use 3 like everybody else.
The exception is .onion sites. TOR actually deliberately defaults to 6 hops when accessing .oninon sites - 3 to protect you and 3 to project the site.
There's no exit nodes for onions because there's nothing to exit to. Nothing beats anonymity of onions and it's design is well created.
That reminds me of the holy Handgranate of the Monty pythons
The right number for you to use is the default. But the right default is not necessarily 3.
because then there is at least one node that knows neither the source nor the destination of a request
The law of diminishing returns
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.
If this is sarcastic you should probably add /s or someone might actually follow your "advice".
They should be fine since I made up the setting name, and even though I am not familiar with Tor client's configuration, I don't believe this is possible without altering its source code.
Also, using this kind of software without understanding how its works even just a little doesn't protect much of your privacy.
Yeah I was confused! Pretty sure this is not configurable.
Or people should not be idiots and think for themselves just a smidge, and not use /s.
Your config improvement made it into Google AI https://i.imgur.com/v5DsXy9.png
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...
The setting doesn’t exist.
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.
It's very difficult for me to contemplate how anybody could run a VPN, however reputable, that isn't compromised by one intelligence agency at least. Their incentive structures and their costs to participate in this space just make it a no-brainer.
If you're starting a brand new VPN company with ironclad ideals about privacy - are you going to be able to compete with state-run enterprises that can subsidize their own competing "businesses", on top of whatever coercive authority they possess to intervene in local small businesses?
It would shifts part of the data route info from your provider toward that particular relay.
But I wouldn't recommend it of course.
Of course it would hence you should stick with mullvad, a reputable VPN. Tor is not made for single relay paths, you're just wasting it's potential.
> 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.
This would be a fantastic argument against rust for the m68k or some other embedded architecture. But we live in a world with an actual rust compiler for basically all architectures tor serves. & obviously the c standard can't save c from itself.
Yet you are wrong, for a standard matters about other matters, and there are many other differences. For instance, building a large project in a language with only one major compiler, can introduce risk. That rustc is open source decreases the risk from that, but getting something like gccrs up and running would be really helpful.
That parts of the Rust community has in the past been actively hostile against gccrs, is then mind-boggling. But Steve Klabnik will lie about that, as he has lied many times in the past and is his wont.
https://reddit.com/r/rust/comments/12y85ww/gcc_13_and_the_st...
> I know, please don't be discouraged. It's just an (unfortunately) prominent, loud subsection. It's not just gaslighting, it's basically concern trolling. The negative top OP plays concerned, but has been trolling GCC-RS posts for many months now. Especially on this subreddit, it's a small number of people that know how to play to a reddit audience and get people riled up. I also know that it's spread to sites like HN.
> Yet you are wrong
Ahh here you are speaking nonsense again. We ain't talking formal logic, we're speaking human to human
> For instance, building a large project in a language with only one major compiler, can introduce risk.
Ok let's introduce an alternative to gcc then
> But Steve Klabnik will lie about that
You seem fine to both tarnish the reputation of, erm, c defenders with your own actions and to slander the reputation of Klabnik (or "lie" as I'm sure you'd term it), who both speaks more coherently and with his own name. Why do this in the name of open source if you have nothing to contribute, knowing that you're setting your own project back?
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.
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.
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
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
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.
>better portability across operating systems
Does Rust have better portability than C?
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.)
> I can't even get Rust to work here on my slightly older Mac system.
Could you elaborate on that? macOS Sierra (released on 2016) on Intel macs is supported[1][2], which should allow for Macs from late 2009 onward to work. The Intel Mac build is no longer Tier 1 because the project no longer has access to CI machines for them, and 32-bit cross building is hampered by Xcode 14 not shipping the corresponding SDK[3].
1: https://github.com/rust-lang/compiler-team/issues/556
2: https://doc.rust-lang.org/nightly/rustc/platform-support/app...
3: https://github.com/rust-lang/rust/pull/118083
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.
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.
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.
Rust - "I am inevitable"
Unless you use aluminum or stainless steel...
"And I... am the Oxidized Man."
[snaps fingers]
Rust never sleeps.
N. Young
young and rustless ?
Rust in peace
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.
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.
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...
>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!
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.
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.
I thought the default for both Rust and Go were to statically compile everything except the dynamic link to libc? And that you could optionally statically include musl with a bit of extra work.
I've never had to do anything unusual with building, but I thought the "almost-ststically-compiled" thing was somewhere Go and Rust were almost identical.
You and your parent are talking about slightly different things. You are both correct in different ways.
Your parent is saying that, while what you say is true for Rust and Go code themselves, in practice, it is less true for Rust, because Rust code tends to call into C code more than Go code does, and Rust doesn't always statically link to that C code by default.
Oh that makes more sense! That's a bit of a blindspot to me for the pretty bog-standards ways I'd been using Rust and Go.
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.
AFAIK if the project has a rust-toolchain.toml[0] file, cargo will download the correct compiler for the project.
[0] https://rust-lang.github.io/rustup/overrides.html#the-toolch...
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
> They both suck getting new devs for
I'm willing to be Rust suck a ton more to hire devs. Since, as we both agree, Go is easy to learn. Any C#, PHP or Java dev can get going with Go in not time.
Go been around for quite a while now. It isn't going anywhere.
Rust has been around for over 10 years now. In the last five years the language hasn't changed much and has gotten better and better
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 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/
I don't see any transparency with the funds. So it's hard to grasp how much is it.
But it's never going to surpass Go which is owned by a 4 trillion dollar conglomerate.
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.
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.
It was a project I worked on as an intern at Electric Boat. I can only speak to specifics I was explicitly given the okay to share though (i.e. this is all on my LinkedIn).
The project was a virtual training simulation for a submarine cockpit, first in Blender Game Engine. With support for BGE being deprecated, I was tasked to find an alternative engine and to port the work. (I'm very proud my research pointed to Godot- this was during the Godot 2 era).
There was a lot of interest in the project, but my internship was coming to an end and they decided to port it to Amazon Lumberyard for fear of Godot's longevity and support. They didn't want to be left "waiting for Godot". The final task I took on was to document the project, to make that transition easier for whoever came next.
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.
To be fair, you haven't explained why it's an issue to see projects being rewritten in Rust, other than it is a bit annoying to you?
For me, I had a very good experience rewriting a project in Rust (from Python). It was just an improvement in every regard (the project was easier to build and distribute, it was a good opportunity to rearchitect it, and the code ended up 20k times faster.) So, I have the opposite feeling when I see titles like these.
I also feel the opposite about the tooling. For me, cmake, npm, pip, maven, etc. all live in this realm where any invocation could become a time purgatory. The big thing that makes me like Rust is that I've never had that experience with cargo. (In fact, pip was the primary motivation to move away from Python to Rust. Everything else was just nice.)
I'm not saying this to convince you to feel otherwise, I just wanted to offer how I felt about the same topics. I grew up with C and Java, but Rust clicked after I read SICP and followed along in Racket. I could probably fill a page of small grievances about Rust's syntax if I had to.
> whereas I am sure a C/C++ large project of a similar size wouldn't run out of memory
This is a common issue on large C++ projects for users with limited resources. You typically have to tinker with build settings and use a different linker etc.. to get the project building without OOMing.
> A lot of the tooling reminds me of NPM
My feeling is that you'd have the same criticism about a lot of other modern ecosystems because they allow you to pull dependencies easily. With things like vcpkg, that's also possible in C++ but even without it: nothing stops the same behavior of importing "random" code from the internet.
> 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 guess you and me live different lives because I have spent far more time messing with ancient C/C++/CMake/Automake/Autoconf/configure/just have this particular .so file in this particular spot/copy some guys entire machine because this project only builds there/learn and entirely different language just to write build files (CMake sucks and 5 other alternatives are just lipstick on a pig) etc. etc.
I am of the opinion that half of Rusts success is based on that fact that C/C++'s tooling is annoying and ancient. People want to write code not mess with build envs.
Sure. That doesn't matter. Of course you can keep writing your C/C++ or using CMake, nobody is going to stop that. But other people's project are not going to stop adopt new tech stack because how you feel about it.
RE: memory, any self-respecting CI/CD system will allow you to compile any Rust project without out-of-memory halts.
RE: NPM, you have a right to a preference of course. I certainly don't miss the times 20 years ago when pulling in a library into a C++ project was a two-week project in itself. make and CMake work perfect right up until they don't and the last 2% cost you 98% of the time. Strategically speaking, using make/CMake is simply unjustified risk. But this is of course always written off as "skill issue!" which I gave up arguing against because the arguers apparently have never hit the dark corners. I have. I am better with Just and Cargo. And Elixir's mix / hex.
What you like as a language (or syntax) and what you roll your eyes at are obviously not technological or merit-based arguments. "Weird" I can't quite place as an argument either.
Use what you like. We all do the same. The original article lists good arguments in favor of Rust. Seems like a good case of "use the right tool for the job" to me.
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.
On the flip side C/C++ devs like to let ancient libs hang around because updating them can be such a pain in the ass.
You can choose to write Rust with fewer external crates or vendor them like you would with c++ that is a dev choice.
Having more choices is better.
I agree this is problematic, sure, and is not unique to Rust or JS. Feel free to propose and work on something better, I'd be your enthusiastic supporter.
It's simply a way to be able to move at a reasonable speed is how I see it.
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 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.
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.