Posted by giuliomagnifico 2 days ago
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.
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.
Your link doesn't work though. I just get "file not found".
I agree on randomization, but there are other places where it doesn’t stick out like that. I’ll look up specifics if I find the time, but I think reading canvas data without permission is one place it’s utilized, including by Tor.
>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.
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...
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.
EDIT: just saw I need to download playonlinux or wine. Forget about it.
Let me rephrase it: you believe it, I don't believe.
For window size only 1 in 380326.0 browsers has this value.
I'm downloading safari right now.
EDIT: just saw I need to download playonlinux or wine. Forget about it.
Sorry, who concluded that this is fingerprintin resistant? Does the website tell you that, or was this your conclusion? Because my reading is with a number that small, you're almost uniquely identifiable. Is it possible you're misunderstanding what the report is showing?
Would you be assed to continue this conversation elsewhere? I'd like to get to the bottom of this?
Those two values are the only ones returned by the browser which are useful for fingerprinting beyond "stock safari". Window size being the biggest part of that, but window size tends to change fairly regularly.
"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."
How?
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.
The extra safety in the code base is nice, but this seems like a bigger deal.
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.
Does Rust have better portability than C?
> 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.
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...
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%).
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.
Wine took a roughly same amount of time to be versioned as well, but no one calls Wine a failure.
Second, you're simply ignoring that parent poster mentioned Ladybird, a non-rust project which is advancing much more speedily than servo. And I think they have a valid point -- and while the jury is still out, it's possible that in other rust-centric efforts which have experienced foot-dragging (eg WASI), the root cause may be rust itself.
Parent poster expressed their point somewhat sarcastically, but if I (C++/python dev, I admit!) were a betting transfem, my money would be on them being right.
That said, I think the Tor project got this decision right. This is as close to an ideal use-case for rust as you can get. Also, the project is mature, which will mitigate rewrite risk. The domain is one where rust can truly shine -- and it's a critical one to get right.
Your life might improve if you stop believing that Rust devs belong to a cult of your own imagination.
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++.
A TS compiler from scratch built in Rust would be fine.
> cultists
The cult is in your imagination.
> 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.
Rust can do complex graph processing, as well as efficient easy memory management, but it's going to do it in a different structure than a GCed lang would. Hence my statement that 1 to 1 translation was the primary factor.
> CTRL+F "rust" on the Go issue and see how many results you get.
Yes and so what? There's 35 for .NET or 74 for C#, yet you don't see people claiming the C# cult was harassing the TS team.
So it's expected to be frequently mentioned there.
Because esbuild is Go. tac was TypeScript and will be Go. Bun is Zig.
Come to think of it. I don't use a single Rust tool for the web. node is c++. deno breaks too much.
So, do you have a source for your claim?
All built with Rust
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.
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.
Debian forky has Rust in the kernel on by default.
EDIT: And now that I've scrolled down, I see you've left this comment many times as random replies. I'm sure those will get flagged, but for spam reasons, not due to some grand conspiracy.
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 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.
I believe that depends on the sophistication of algorithms. High-level algorithms (especially if they involve concurrency or parallelism) are much easier to write in Rust (or in C++) than in C, which gives them a pretty good chance to be at least as fast as any reasonably safe C implementation.
For low-level algorithms, of course, it's really hard to beat polished C 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.
I don't think that this is going to be a problem. The Tor Project developers I've interacted with sounded quite serious about security. Forbidding non-blessed cargo packages is pretty trivial.
> In addition, you could more easily inadvertently introduce security problems.
What do you mean?
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.
1. Programmer skill and talent are not enough to achieve similar security properties with memory-unsafe languages as with memory-safe languages.
2. Therefore, "memory-safe languages are technically superior, period, for applications processing untrusted data where security is an important goal", is not an un-nuanced argument nor a Rust fanboy argument, but self-evident.
That still leaves a lot of room for other languages (Rust is not my favorite language), but it pushes back against the developer equivalent of doctors and pilots resisting the adoption of checklists for decades because "I wouldn't make those kinds of mistakes so stop messing with my work".
1. Programmer skill and talent are not enough to achieve similar security properties with memory-unsafe languages as with memory-safe languages.
2. Therefore, "memory-safe languages are technically superior, period, for applications processing untrusted data where security is an important goal"
but the problem entirely boils down to what comes next:
3a. Therefore everything should use rust.
3b. Therefore everything processing untrusted data where security is an important goal should use rust. (Some folks like to stretch what could possibly process untrusted data to turn this into 3a, but there is a difference.)
3c. Therefore most programs really should be written with a garbage-collector, or if they really need to be low-level or high performance they should use an appropriate stack to avoid gc while remaining safe (whether that's Rust, Ada+SPARK, formally-verified assembly, or whatever).
I think you make an important oversight with these claims, which is that you can enforce logical safety over a memory unsafe language and have a much higher degree of safety than memory safety. Formally verified C doesn't change the language, you can in principle take C code run through compcert and compile it elsewhere. It's still a memory unsafe language, but we can express a much higher degree of safety than simple memory safety.
Another aspect to consider is that all garbage collected languages are memory safe. A language like Python actually has a far greater degree of memory safety than a language like Rust because it offers no ability to break memory safety (without calling into foreign code), while Rust lets you do it within unsafe blocks using raw pointers. That being said, anybody who would suggest using Python over Rust in a security-focused context is completely out of their mind.
In serious places where security is critical and margin for error is low, formal verification has existed for decades and is the standard. Any operation - specifically in the context where security is critical - which is not formally verifying its software is a mickey mouse operation, because they're fundamentally compromising on security to an unacceptable degree. I think it would be nice to have a formal verification toolchain and language extension for Rust to allow for full logical safety, but last I checked this area was still a work in progress for the language.
I know anytime Rust is brought up, someone brings up logical safety, and patterns are annoying. Rust obviously has a lot of tricks up its sleeve to automatically detect issues that a language like C++ cannot. Naive Rust is preferable over naive usage of a memory unsafe language. The problem is that in a serious security critical context, "naive" is completely unacceptable. If security is a core goal, there can be no replacement for fully blown logical safety enforcing strict behavioral and structural guarantees in every single facet of the codebase. I know the line, that logical safety is excruciatingly labor intensive and so the tradeoff with using Rust is that it affords some of the safety of formally spec'd and proven code. The problem is that the amount it affords you is completely marginal. The safety gap between C and Rust is much smaller than the safety gap between Rust and formally proven correct SPARK. It's just the reality. I'm loathe to see a future where marketing hype sees a degeneration of tools because it was presented as a serious alternative.
In almost (?) all garbage collected languages you can get data races in a multi threaded context. You will not get those memory errors in Rust.
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#
> Diagnosing a Double-Free Concurrency Bug in Rust's Unbounded Channels
https://materialize.com/blog/rust-concurrency-bug-unbounded-...
So unless they provide some Tor specific nuance, it's more or less applicable to wide range of applications.
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.
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.
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.
What makes you say that?
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.
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.
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.
Admittedly I stopped after going through a bunch of useless stuff related to CVE-2017-8823 (which was initially reported as remotely exploitable with no proof at all).
I went through the tor repository (not vidalia though) and read a bunch of conversations about some of the memory related bugs but none of those were exploitable either (exploitable as in remote execution, not a DoS) and most of the (not so many) bugs were actually logical bugs.
I really don't care what they decide to do with their project and honestly anything that can potentially improve the security of such a system is fine by me but I really think they're doing themselves and the language a disservice by communicating the way they do.
Also, as a side note, even with a C codebase there is SO MUCH you could (and should) do to minimize the impact of a vulnerability that the fact that some choose to present just rewriting code in a different language is not even funny.
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!)
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.
No one is claiming the new version is faster, only that it is safer.
Of course, technically, this problem is related to the quantity of high quality nodes :)
5 proxies does it even slower but would make attacks much more difficult.
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
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.)
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.
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)
Tails ships Tor browser with ublock but the Tor browser team doesn't want to for simple reason: fingerprinting. I use ublock too but I feel like majority still don't and disabling javascript alltogether is still the most secure way.
I don't understand this given reason. If they package in uBlock origin across their desktop and android browser. Then everybody will have uBlock origin so the same fingerprint. If the reasons are different subscriptions lists that users might enable/disable, sure that's fingerprintable, just make a disclaimer about that if users want to modify the default lists.
https://voodootomato.medium.com/managed-attribution-the-key-...
https://www.authentic8.com/blog/non-attribution-misattributi...
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.
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).
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/
3 relays is the goldilocks number for speed vs privacy. Using less is not a tradeoff the usual user of Tor should make.
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.
Tor is slow because traffic is routed through multiple layers. The design priority is anonymity, not speed.
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...
Also, using this kind of software without understanding how its works even just a little doesn't protect much of your privacy.
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?
But I wouldn't recommend it of course.
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.
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.
I have been a fan of gccrs the entire time.
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?
Do you like pattern matching in Rust? It is one of the features that Rust does decently well at.
I think perhaps cryptocurrency is worse than selling urine for its chemical properties, but the principle applies, money is just money
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/
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/
> 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
