Hacker News

I don't understand what you mean. What separates this from other fingerprinting techniques your company monetizes?

No software wants to be fingerprinted. If it did, it would offer an API with a stable identifier. All fingerprinting is exploiting unintended behavior of the target software or hardware.

The real reason is that fingerprint.com's selling point is tracking over longer periods (months, their website claims), and this doesn't help them with that.

I’m going to go out on a limb and guess that you define “vulnerability” as something like “thing that will be fixed soon”. After all, Joe Random not liking a behavior doesn’t make it a vuln, there needs to be a litmus test. Am I close?

All fingerprinting is a vulnerability, unless the client opts-in.

Any method of “fingerprinting” and invading a browser’s privacy is inherently an exploit.

Good opsec usually means you don't do this anyway. Don't use your anonymous browser for anything related to your real persona. In fact, don't re-use the OS between anonymous and public personas. Or even better: Don't re-use the hardware (also goes for networking). There will always be bugs across all levels of software and hardware that could eventually be chained to expose you. But if there is nothing there that could be exposed, you're already much better off by default. Even if that is very hard to achieve in practice.

Usually you have TOR browser for TOR and a standard Firefox for the standard browsing so they already are two sessions.

Anyone that serious about opsec should have dedicated hardware for that anyway

Why not tails in a VM?

I wonder why "New Identity" wasn't implemented as a fork-and-exec with a newly created profile?

Privacy and security conscious Tor users don’t.

Open enough tabs and you'd be lucky to keep firefox running for more than a couple weeks.

> I guess state agencies already know all nodes or may know all nodes.

Assume the same.

>The idea is to amass as much information as possible

Reminded, from 2012: https://www.wired.com/2012/03/ff-nsadatacenter/

All Tor nodes are publicly known. Just knowing them doesn't help tracking at all because of onion routing, they would need access to all nodes.

https://metrics.torproject.org/rs.html

It used to be called Panoptoclik (sp?), a reference to Foucault's theory of the panopticon. Focault's extracurriculars are well documented and not everything is an "incident" -- it's a thread on fingerprinting. People who study that are aware what is now called "cover your tracks", and people who do post grads tend to be well rounded enough to have read a bit of philosophy, or at least, they did in my day.

So what happened here is basically... AI told you that something that made you suspicious because you have zero subject matter expertise is suspect?

I'm not really sure how to react to someone who has a robot affirm their anxieties other than to stand by my previous statements and give a polite pointer at some terms to look up on Wikipedia rather than feed into a clanker.

I'd lump Mozilla into the bucket since it's a nonprofit and open source, it's hard to come up with an objective list of what makes an org "good" so sometimes it's been useful to fall back on the fact that at least in the states, academics are bound by the IRB.

pets is a good conference.

i also like anonbib as a central repo for interesting work.

https://www.freehaven.net/anonbib/topic.html

Most of the things you've listed here don't actually seem all that reasonable to me.

User agents as a concept are rather poorly thought out across the board and not all that useful but persist because that's just how technical cruft is.

Fonts should be provided by the website; if not provided the choice should take the form of a spec sent by the website including line height, sarifs or not, monospace or not, etc. There's little to no excuse for the current font situation IMO beyond poor design decisions that became heavily entrenched.

Timezone and other obviously private metadata should never be shared without the user explicitly granting permission on a case by case basis. The status quo here is completely inexcusable as is the continued failure to fix the problem.

Size of the physical screen should never be exposed under any circumstances. The current size of the browser window is reasonable on its face but now that fingerprinting is understood to be an issue should always be heavily letterboxed unless the user consents to sharing the exact value.

Video formats should be provided by the website as a list of offerings and the browser should respond with a choice; the user could optionally intervene. There's no reason to expose the full capabilities to a remote service.

Querying the current time should be gated behind an explicit permission. There's almost never a need for it. However from a fingerprinting perspective you also have to worry about correlating the rate of clock skew across clients. That can be solved by gating access to high resolution time counters behind an explicit permission as (once again) the vast majority of services have no legitimate use for such functionality.

These are all relics from the innocent 90's Internet. We had our global village and everything was fine. A couple of bad actors spamming blue pills here and there and that was it.

Now we have actual criminal organizations and other real bad actors.

I'm sure we can come up with something better than advertise our whole local computing platform on every HTTP request.

I fantasize having a browser that I can use only for viewing content.

No applications. No mail. No need for cookies.

I can use a "regular" browser for more enhanced stuff. But for simple content consumption, we can just have a "dumb" browser that can't do much.

> A user agent that says the browser's version? Reasonable enough.

No user agent. I'm guessing it will need it for JavaScript or HTML features, and dynamically update if using an old browser, but let's just not supply a user agent and let it be the reader's burden to have a reasonably decent browser.

> Being able to ask for fonts, if the system has them? Difficult to have font support without that.

What's the fallback if the system doesn't have them?

> Getting the user's timezone, language and keyboard layout? Reasonable.

Keyboard layout is irrelevant for viewing content. For timezone and language: Yeah, I can see the use cases, but these are in a small minority. Let there be a popup when requested, and the user can specify the timezone/language as requested.

> The size of the screen, and the size of the browser window? Difficult to lay things out without that.

Let's let this new browser return only from a (small) discrete set of sizes. It will pick the size closest to the actual browser window size and send that.

> Of course a video or audio player needs to know which video formats your browser supports - how else to provide the right video?

Same answer as user agent. Either let the user pick from a selection of video formats, or just hard code a reasonable one and put the onus on the user to have a browser that supports it.

> Obviously javascript can get the time, and it's trivial to figure out the system's clock error by comparing that to the time on a server.

This hypothetical browser could just not send the time :-) For 99% of content consumption, this function is not needed.

What I'm describing should be part of "Private mode". Or browsers should have an "Ultra-private" mode that is the above. If it's too complex/risky maintaining it all in one codebase ... fine. Just have a separate browser.

Right now, if I built such a browser, I'm sure a lot of sites meant for content would break. But in my fantasy world, using "Ultra-private" would be the default, and people who make sites will target them first.

I think much of the complexity in making a web browser is all the "other" stuff. Being able to run apps, cookie/privacy management, etc.

The tor project seeks this bypass this by keeping such things standardized across users, even down to reported screen size. And there is nothing stopping the browser from fibbing as most settings dong matter all that much (ie UK v Canadian v American English).

All of these could have a set of standard non identifiable answers (eg. firefox reports the same 20 fonts, couple video formats, one among a few standard window sizes etc.) and for anything more extensive/precise, it would require the user's authorization and the user should have the option of feeding fake info (eg. fake timezone)

most people would expect something different from tor, surely.

Most stock android phones don't either. You usually get to control precise location, notifications, some background activity, SMS, Calls, Mic, Camera, SD Card, etc.

But most ROMs don't allow controls for WiFi, Cell data, Phone ID, Phone number, User ID, local storage, etc...

> turning it off increases your signature.

Tor endpoints are pretty easy to identify, there are plenty of handy databases for that, using it to begin with increases your uniqueness. If noscript was set to strictly disallow javascript by default, that decreases the degree to which it increases your signature relative to the baseline of using tor.

Then we have to account for the simple fact that many, many fingerprinting techniques rely on javascript, so taking them out of the picture reduces the unique identity that can be gleaned.

Are we absolutely, positively sure that the tradeoff is worth it? Without a strict repeatable measurement, I think I'm highly skeptical about whether or not a default of "allow" is a net boon to hiding your identity. I remember the rationale about the switch mostly being directed towards "most of the web is broken otherwise and that's bad."

> JS also dramatically improves security

How so?

> Disabling JavaScript actually greatly increases your fingerprint as not many users turn it off, so that instantly puts you in a much smaller bucket that you need to be unique in.

I've heard a handful of people say this but are there examples of what I would imagine would have to be server-side fingerprinting and the granularity? Since most fingerprinting I'm aware of is client-side, running via JS. While I expect server-side checks to be limited to things like which resources haven't be loaded by a particular user and anything else normally available via server logs either way, which could limit the pool but I wonder how effective in terms of tracking uniqueness across sites.

I have my problems with that argument. Yes, less identifying bits means a smaller bucket but for the trackers, it also means more uncertainty, doesnt it? So when just a few others without JS join your bucket eg. via a VPN, profiling should become harder.

> increases your fingerprint as not many users turn it off

We're talking about users of the Tor browser, and I'd be very surprised if this was the case (that a majority keep JS turned on)

Basically every Tor guide (heh) tells you to turn it off because it's a huge vector for all types of attacks. Most onion sites have captcha systems that work without JS too which would indicate that they expect a majority to have it disabled.

> You can use a browser extension like "Local Storage Editor" to see the contents of the Local Storage of a website.

Or just open dev tools

As I understood not ANY website can see it. But the same website can see it regardless if you reset your identity in Tor Browser.

So it persists between anonymous sessions. So you could connect User A that logged out and reset the identity to User B who believed was using a fresh anonymous session and logged in afterwards.

But that's the key thing about tails. You start it fresh every time from a clean usb stick or iso image.

It's more than a browser restart, it's a complete system wipe every time.

Tails is made on the premise that exactly this kind of trick will occur. Sometimes even persisting between browser restart. For that reason even the persistent storage is very limited. But that's optional and cautioned against for maximum anonymity.

What would be worrying with tails would be if there was some way for some hardware identifier to be exposed. Like a serial number or MAC address. But this kind of thing is exactly what it's made to protect against.

Not sure about Chromium-based browsers, but the author of this paper on the technique:

https://www.ndss-symposium.org/wp-content/uploads/ndss2021_1...

Says that Firefox has a bug that prevents favicons from being loaded from cache, which inadvertently protects against this technique. They filed a bug report on it in 2020 but nothing has happened with it yet: https://bugzilla.mozilla.org/show_bug.cgi?id=1618257

Your idea of "dumping the rendered window pixels out to a simple viewer" with Chromium is essentially Remote Browser Isolation (RBI). If you're looking for a packaged way to do this, BrowserBox does exactly this and has a tor-run function built-in, which:

connects Chrome to a Tor SOCKS proxy and wraps all other browsing-related network calls over torsocks. It prevents local fingerprinting leaks (like this IndexedDB ordering bug) because the browser isn't running locally at all. You can host the BrowserBox instance as an onion hidden service, use it to browse over Tor, or both.

If you want to try an ephemeral "VPC in a box" style setup where the environment is destroyed after you're done, you can easily spin it up using this new GitHub action: https://github.com/marketplace/actions/browserbox (but you need a license key, obtainable at https://browserbox.io)

This is my attempt to make it easy to spin up bbx on ephemeral infrastructure that's mostly free (GitHub Actions runners are perfect).

Links can force to pass all connections to a proxy, so a FW might be redundant. Forget almost mouse, Links can be render the page either to plain X11 or a terminal.

Links litteraly put your a graphical (X11) or terminal based checkbox to enable that to enforce everything through the proxy with the settings menu. Not too easy. If you are going to use Tor you shouldn't be just using Tor Browser by default neither if it enables some JS options. Firefox' base is too huge to configure so nothing ever leaks. There are too many components. A/V, WebGL, telemetry, WASM, WebRTC...

I believe you are correct, and that this poses a significant risk for people who don't properly understand the underlying concepts.

A Qubes OS user needs to start a new disposable Whonix workstation VM to sidestep this attack, NOT create a new identity in the same disposable VM's browser, which is exactly what this attack targets.

On Qubes, you do not create a new identity in the same VM. This would go against the Qubes approach to security/privacy. Using separate VMs for independent tasks is the whole point of using Qubes.

Qubes OS hardware support, while still far from perfect, is vastly better than it was ten years ago.

Joanna Rutkowska's understandable preference for older kernels had its advantages, but the current team is much more likely to ship somewhat newer kernels and I've been surprised by what hardware 4.3 has worked well on.

Beyond that, I'm currently running a kernel from late Feb/early Mar (6.19.5).

Driver support can still be an issue, and a Wi-Fi card that doesn't play nice with Linux in general is doing to be no different on Qubes OS.

We buy off the shelf laptops, not sure anyone ever checked that it can run Qubes specifically before trying to install it (I'm sure of at least one person: myself). Doesn't just about any x64 machine with hardware where drivers are available in standard kernels also work with Qubes? What have you bought that's not supported?

No problems on framework laptop that I've run into at least.

Most hardware (especially GPUs) is hard to virtualize in a secure manner, which is the entire point of Qubes. People who use it typically buy compatible hardware.

Tested hardware can be found here https://qubes-os.org/hcl. New hardware is being constantly added. If you plan to switch to Qubes, consider buying something from that list or, better, certified, or community-recommended hardware linked there.

Different VMs result in different identifiers.

Given the dangers of JS and WASM they could just fork Netsurf and enhance the CSS3 support. If you are a journalist, running Tor with JS and tons of modern web tech enable makes you a bright white spot in a sea of darkness.

>Why Qubes OS?

>Physical isolation is a given safeguard that the digital world lacks

…

>In our digital lives, the situation is quite different: All of our activities typically happen on a single device. This causes us to worry about whether it’s safe to click on a link or install an app, since being hacked imperils our entire digital existence.

>Qubes eliminates this concern by allowing us to divide a device into many compartments, much as we divide a physical building into many rooms. …

Sold

https://doc.qubes-os.org/en/latest/introduction/intro.html

You should note that improperly using Qubes OS, creating a New Identity inside of Tor Browser, even in a disposable Whonix workstation VM, would leave one vulnerable to this.

A user would have to manually start a new disposable VM for each identity.