Hacker News Reader

Comment by kelnos | Hacker News Reader

It really bothers me that all this information is available through JS (no, please don't suggest I disable it). Why does a website need to know the list of installed fonts? Why can they enumerate the list of "videoinput" and "audioinput" devices before they've asked for video/microphone permission? Why is information about how I've set various permissions (prompt vs. allow vs. deny) available? Exposing the visibility of menu/tool/personal/status bar is just weird (though for me all of them say "Visible", which isn't the case, so I guess Firefox is lying).

View on HN

Regarding the list of fonts, they don't get that info (they could with Flash, but not JS). What they do is have a list of font names in the JS source, and they set a text element to each one, comparing the resulting size of the element to a baseline (the size when the element is set to the font "sans-serif" or "serif"). If it's different, the font is installed.

Regarding the list of devices, it should be noted those IDs are site-specific, so they can't really be used for cross-site tracking, and clearing cookies also resets them (at least in Firefox). But there are discussions pointing to a consensus around disabling the enumeration before permission is granted. As in other cases, the browsers will probably have to lie to avoid breaking sites.

Firefox has an undocumented about:config preference "font.system.whitelist" to specify a list of which fonts are exposed to web content (such as the default set shipped with your OS). The preference is used by the Tor browser.

https://bugzilla.mozilla.org/show_bug.cgi?id=1121643

Opera Presto had this enabled by default.

> comparing the resulting size of the element to a baseline

This is the real hole, imo. 99% of web pages should not need that kind of information. I’m close to thinking 100% shouldn’t, although I understand its need in particularly advanced applications. Maybe there should be a sandbox specifically for these very advanced JavaScript apps - nothing else should be allowed to get font metrics.

Is it? It seems to me getting the size of an element is a pretty basic operation that a lot of scripts use.

Maybe scripts for advanced apps, but most apps and all content shouldn’t have the slightest interest in positioning elements down to the pixel.

35% of all websites run Wordpress. A lot of those sites run pre-made templates which often heavily use jQuery scripts to show pop-ups, sliders, tooltips, what have you... Accessing the width/height of an element is pretty standard in those scripts. That's not at all limited only to advanced apps.

I'm just saying that simply blocking or limiting that part of the DOM API is probably not a practical solution.

This is equivalent to saying that nothing dynamic can depend on the position or size of elements. Which means you can't use <picture> or srcset to load different images in different cases, because that can be exploited to leak what size other elements are. You can't use media queries to affect anything that can send requests. There can't be any way to lazy-load images that are way down the page.

From an anti-fingerprinting perspective you do much better to restrict what system fonts are available than to remove all of these valuable and common reactive features.

> This is equivalent to saying that nothing dynamic can depend on the position or size of elements.

Unless that dependency is specified in a style sheet language, yes. I think that’s exactly how it should be: the web of 'apps' is fine to break this if it wants, the web of 'content' shouldn’t be concerned with extremely detailed matters of presentation.

> From an anti-fingerprinting perspective you do much better to restrict what system fonts are available

Agreed; I’m not saying there isn’t lower hanging fruit, I’m just commenting on the one that interested me.

The problem is, even if you restrict this to being specified in CSS it can still be used for fingerprinting

I have JS turned off and still have plenty of other factors that make me unique so it's not just JS. My question is why is the rest of the information available / given, especially the user agent? The other headers mostly make sense. I can see the argument to turn 'do not track' off. But user agent? I've been making websites and apps for almost a quarter century and have never even read of a good use for that outside the tracking industry, let alone seen a good use of it.

How much of the internet still functions with JavaScript turned off?

The best parts imho.

didn’t Chrome recently announce that they’re going to freeze the user-agent string?

Yes, but also expose the information through:

+ A new set of optional HTTP headers

+ A new JS API

User-agents can be used for web-servers to differentiate between bots/crawlers and actual human beings. But there could be a generic user-agent instead of the ones we have now.

Note: This only matters for bots that serve to aid your website. Like search engine crawlers being given instructions what pages to ignore.

Most crawlers/bots, particularly the ones you want to be able to identify, spoof their user agent, making this mostly moot.

I've written code several times that relies on user agent parsing to know whether it needs to work around a bug:

* Chrome on iOS started sending "webp" on it's Accept header when it didn't support inline webp yet.

* Firefox would take CSPs applied to same-origin IFrames and additionally apply them to the parent document.

* Edge wouldn't accept data URLs for IFrames that were more than 4096 characters.

In all of these cases the bug was eventually fixed, but we needed to work around the bug in the meantime. UA parsing to say "if it's Edge < v76" or whatever was the best way to do this.

Why the hell do you need data URLs for iframes?

If you want to render untrusted content, cross-origin IFrames are a great way to do it. A data: url gives you an cross origin context without a network round trip and with fewer issues than using the sandbox attribute.

I've used the user agent at work before. We were building something similar to Googles app store for a telecom, and we used it to know which file to serve to the user when they clicked download. Since we supported all kinds of phones (including old ones that used Java files for games), we couldn't just serve an apk file.

Ouch... Firefox Focus includes:

chargingTime : Infinity level : 0.77

Yes that is indeed my phone's current battery level. And no matter if incognito Brave, Firefox Focus or Chrome browsers, I am unique to the site.

Even Firefox Focus which is meant to be good for privacy by throwing the entire session each time is leaky as eg with the audio context.

Surely the battery level isn't particularly useful for fingerprinting, since it's going to change fairly quickly?

But why the fuck should a website know how much charge my phone has?

It's quite clever, that a site that uses lots of processing, or has autoplay, can limit what it does: " your battery is low, do you want to continue ".

The problem is that shitheads exploit every possibility to reduce the utility of society in favour of their own profit.

This is why we can't have nice things; as the aphorism goes.

Well that is the problem with it, every shitty features like that someone can come up with something "quite clever" to do with it, in reality, all these things are being used 99% of the time for tracking.

Maybe programmers and designers should start thinking the other way around: what could be pretty clever that could be used for a feature but that CANNOT be misused for tracking

We are living in the best of all possible worlds. Without shitheads we would be vulnerable and wouldn't even know it.

> It's quite clever, that a site that uses lots of processing, or has autoplay, can limit what it does: " your battery is low, do you want to continue ".

That sounds like a client concern, not a server concern.

I mean, as a consumer of web content I do not want my power saving profile to be accessible or actively influenced by a third party.

To stop computationally intensive or security related or otherwise sensitive operations when charge level is low? Save the state / synchronize more often when charge level is low to prevent data loss?

Running untrusted code doing these things is not something I'm ok with.

Many places will increase prices with low battery as a despiration tactic. Its shady af and should be illegal imho.

https://news.ycombinator.com/item?id=12208880

I read the article you linked to, but the method it describes would surely only work for a few minutes, or until the battery level goes down?

Having said that, I do get that battery level has some potential as part of a very short-lived fingerprint, and I really don't see the need to expose this information to remote sites.

I can't speak to the rest, but the list of installed fonts is presumably so that websites can decide whether to download a font or to pick from the options already available.

In CSS you list the fonts you want, and the browser will decide if it downloads them or not. There is simply no reason JS shouldn't do the same.

It's easy to specify a font in CSS and then watch to see if the browser downloads it or not. JS isn't revealing anything which you can't already trivially get.

For a start, you have to specify it. If I have some weird font installed, you don't get to know it for free.

Anyway, if the site had to ask for the fonts, it would be viable for the browsers to impose some sane limitations on their API.

If you can load a font on the client, the loading can fail. If the load can fail you can catch the error. If you can catch the error you can store a list of fonts without being able to actually do an enumerate request. And it wouldn't be much of a browser if it couldn't POST data to an html endpoint.

As soon as you introduce a programming environment you introduce the ability to do all sorts of things that aren't builtin.

It's generally not the browser saying, here's the list of my settings, you asked for, but rather a program being executed that pokes around at all the things it can interact with to squeeze out info.

But I agree, that javascript should not have access to audio device models numbers with or without permission, nor should it have any kind of access to the browsers chrome.

Reply on news.ycombinator.com