Hacker News Reader

> For example, WebGL reports the video card that you use. Who needs that? Well, maybe there is a tiny percentage of sites that use this information to detect bugs but main use of this feature is a reliable unforgeable signal for fingerprinting a device. Most of sites do not need WebGL at all.

WEBGL_debug_renderer_info is an optional extension to webgl specifically so it can be denied to the page at the browser's discretion. And Firefox's privacy.resistFingerprinting (the subject of this article) disables it: https://developer.mozilla.org/en-US/docs/Web/API/WEBGL_debug...

If it is enabled in standard configuration of major browsers, it is not optional anymore. Sites become dependent on it.

And disabling it now becomes a tracking bit. Profit!

>It seems that browser vendors hurry to push forward as many features as possible without much thinking about user's privacy.

Vendors in plural makes it sound like the market isn't a monopoly of Google at this point. Google naturally loves to be able to fingerprint people based on as many metrics as possible, for their ads.

Last I checked, Google still adheres to w3c standards on these things. And they haven't captured the w3c process itself... We need to be holding the w3c accountable for considering privacy as they refine new rfcs for apis.

> Last I checked, Google still adheres to w3c standards on these things.

It adheres to web standards that it primarily writes and pushes through.

> We need to be holding the w3c accountable for considering privacy as they refine new rfcs for apis.

You know, when w3c does that HN is ablaze with "Safari is the new IE" and "Firefox is irrelevant". See all of hardware APIs (Bluetooth, Serial, HID etc.) that are rejected by both Safari and Firefox primarily on privacy issues.

How did that saying go?

It Is Difficult to Get a Man to Understand Something When His Salary Depends Upon His Not Understanding It

Follow the money, people in tech get their paychecks from companies that do not respect privacy. And I don't mean that as an accusation: in capitalism it is your duty to do whatever you can get away with.

Who do you think proposose the standards?

"We need to be holding the w3c accountable for considering privacy as they refine new rfcs for apis."

How do we do that?

It's actually the WHATWG you need to watch[0], not the W3C. The latter has had basically no power for some time now and only endorses what the WHATWG propose[1].

[0] https://github.com/whatwg/sg

[1] https://www.w3.org/2019/04/WHATWG-W3C-MOU.html

You know Google literally writes the specifications that are subsequently used by advertisers to fingerprint users, right?

For example, the AudioContext API allows websites with zero audio to query sensitive personalized information about your audio equipment, with no permission. It was written by a Google employee, and implemented first in Chrome, then abused throughout DoubleClick's (owned by Google) display advertising network.

That's what I mean by "holding them accountable." So Safari and Firefox should implement that API behind a privacy-check flag (same as we get for location services, etc.). If Google complains it's not to spec, tell Google to fix the spec.

Don't rubber stamp specs that aren't privacy-conscious; Apple, Mozilla, and Microsoft are WHATWG standards members too.

Indeed, the WebGL extension that leaks videocard and driver name [1] is written by Google's employee.

[1] https://www.khronos.org/registry/webgl/extensions/WEBGL_debu...

I think you do need driver or video card name if you need to make it work (or have a usable performance) in every vendor.

Video cards behaves wildly different between vendors. Some shader runs smoothly in one vendor while lag like hell in another. And some don't even run correctly under certain vendor. Without knowing the vendor, it is not possible to patch them up to get a usable program.

They share the same API doesn't mean they behave identical.

Sure but most websites don't need this, and if they do they can ask nicely.

There is no way you can expect a non-technical user to understand the full implications of a prompt like that.

Then this feaure should be disabled so that nobody relies on it.

Something like: "This web site is requesting access to 3D acceleration. This is required for fancy 3D graphics, but can also give the web site more information about your computer than it would otherwise, which may be used to track you, so only say yes if you are expecting fancy 3D graphics and you trust this web site" seems usable?

1) Almost noone is going to read all that. It also assumes the common person knows what 3D acceleration is (yes gamer types and graphics professionals know what it is but the average grandparent probably won't).

2) WebGL is being used for a lot more than just 3D objects now -- it's used for everything from 2D games, graphing libraries and even webgl-accelerated machine learning in the browser (like tensorflow.js).

Most of the major applications that actually rely on WebGL do need this. Largely so they can avoid graphics glitches for the small fraction of users with buggy graphics drivers

…these are few and far between in comparison to the sheer amount of the web that now gets to freely query that information.

They should be asking nicely, not getting it for free.

Totally agree. I bet in the wild 99% of pages that use this are ad trackers and 1% are valid WebGL applications.

Yes... And people keep bashing at the Safari team for holding the web development back. I mean, it's clear that the Safari team also has their own agenda, regarding competition with the App Store. But the stuff that Google is pushing is just more ways for them to track you in the end.

The things safari lack isn't even relevant to privacy.

They are more about buggy layout (not the shiny grid layout or style worker, it doesn't even works correctly with css2 a lot of time), incorrectly implemented API (not the 'not implemented due to privacy' one, they are those implemented but reporting wrong result).

Firefox also rejects a lot of proposal due to security reasons. But for every one it supported, it works correctly. Instead of work in funny way and require devs to guess the browser and insert ransom workaround just to make it not using the improper result safari gives and breaking the page.

Fun fact: Safari doesn't even handle the full ISO8601 correctly until very recent version. A timestamp without timezone will be parsed into incorrect timezone. A timestamp without colon in the middle of timezone don't even be parsed(which is unfortunately go's default output format).

Regarding timezones, this seems to be a fault of ISO standard. Why do they allow several representations of the same thing?

> Google naturally loves to be able to fingerprint people based on as many metrics as possible, for their ads.

I guess that's why they have a explicit policy of prohibiting browser fingerprinting in all their ad business.

https://digiday.com/media/googles-opaque-practices-to-restri...

It is actually. They want their system to do it, but not the people who buy ads from them, so their advertisers become reliant on google's user segmentation.

At this point, what's really needed is an additional layer of abstraction. The site needs to run in a virtual computer within the browser, identical to all others, and every interaction where any information from the user is needed for the site needs to go through a filter that will sufficiently randomize and sanitize identifying inputs to make it much much harder to fingerprint. That will probably break some content like games and whatnot, but the reality is, as much as everyone loves their web-apps, it really is a tiny fraction of web-browsing.

The sandbox provided by Javascript (or WASM) engine is already like a virtual machine. The problem is that browser vendors leak important information into this sandbox.

Also what I don't like that enabling this feature disables page zoom. This is inconvenient because you have to choose between using zoom and fingerprint protection.

Actually I think that when zoom is less than 100% (i.e. the page is made smaller) it is possible to report to the page original window size rather than scaled up size. Many sites today use gigantic font sizes and they are difficult to read without zoom or high-DPI display.

Page zoom is mandatory for me as it seems that most web devs love to use tiny text. Here is a blatant example: http://www.aaronsw.com/weblog/

Are you fricking kidding me with that? Sure 30 year old me could have read that as is, but why would I want to?

12px is not tiny. A bit small for body text considering the narrow font, but not unreadable. If you consider that text tiny then you should configure your browser (or OS) to enable DPI scaling (effectively zoom by default) instead of demanding all websites have giant text.

> Also what I don't like that enabling this feature disables page zoom. This is inconvenient because you have to choose between using zoom and fingerprint protection.

I don't think it does disable page zoom; I have privacy.resistFingerprinting set to true and can still zoom just fine. (It does disable per-site zoom settings, but you can still zoom any site to whatever size you want each time you visit—which is certainly inconvenient, but, well, the state of the web is such that you can choose convenience or privacy; Firefox giving you that choice does not mean that the necessity of choosing is their fault.)

The extension Zoom Page WE can re-enable this if you want.

> WebGL reports the video card that you use. Who needs that?

Basically anybody trying to do a high performance game in webgl. Even today, the quirks of individual cards are enough that a game relying on sufficient feature capabilities is going to need a quirks list of cards to substitute implementations on. There's nothing to be done about it if a card just lies about its capabilities in the gestalt API or has an honest to God bug that you have to work around in the shader.

But, if an API like that isn't behind a permission allow dialogue and is instead on by default, that's a major privacy mistake.

I am not sure that it would work because it is unlikely that you can test your application with all existing videocards (and yet to be released cards). And even if you do that the performance might depend on other factors (OS, CPU model, RAM type and size, driver version).

Instead game developers should provide an option to select graphic settings: more textures, less textures, more shaders, less shaders and so on, and display a FPS counter so that the user is able to decide what is better for them. Or automatically switch to lower settings if fps falls below cetrain threshold.

It's not just about performance. There are bugs in certain GPUs and drivers that can crash the browser or even produce fundamentally wrong results. It's not just "scale graphics quality", in some cases specific work-arounds with completely different semantics are needed.

Like which ones?

One particular one I've struggled with only appears on macOS with Intel Iris Xe GPUs in which the texture sampling in my default, high-performance, seamless skybox renderer bugs out and only makes one face of the cube render correctly. I have to fall back to physical geometry to fix it, which is not as efficient, causes ugly seams at the edges of the cube, and also overcomplicates handling transparent images and image alignment if I'm not very, very careful.

And my app isn't even all that complex. There are so many bugs to handle, but luckily Three.js handles the vast majority of them for me. You can't count on even very basic apps to be completely compatible across all devices.

I encountered problems on an Intel card config once where a simple multiplication of three values in the shader resulted in 0 being emitted due to a bug in the shader compiler itself. Workaround was to wrap the whole equation in a multiplication by 1.00000000001, which (we assume, closed source architecture that's very difficult to crack the black box on) forced the compiler to stop trying to use an optimization that was dropping our values on the floor.

This bug presense can be tested without knowing the GPU model.

It's tested far faster with a card list.

But you're right, in practice a lot of engines do both... They render a known image at boot-up and check it for consistency. But once you know you have a problem, you don't know how to solve it, so you might as well query the card anyway.

> This bug presense can be tested without knowing the GPU model

Testing for bugs is fingerprinting - you are back at square zero.

And the bug should be fixed in the driver, yes. Still no reason to provide the fingerprinting info for free for all cards and vendors.

> And the bug should be fixed in the driver, yes.

But that's the problem. The developer has no power to make that happen. Between vendors failing to support their chips once they released to the public and users failing to upgrade their machines... Some of the Intel bugs are over a decade old.

This is one of those network effect problems not unlike the question of whether a website is broken if it doesn't work under Firefox. If a game doesn't work on a user's computer, the game is broken, not the computer.

This whole conversation has raised an interesting point, because bugs like that will never be fixed in the driver. And similarly, different versions of web browsers have different quirks and bugs in their implementations. I suspect you could build quite a fingerprinting profile by tickling those bugs and quirks... Not just in the webgl implementation, but in the DOM implementation, etc.

You might not be able to test every possible card, but game engines that target browsers might have that capacity.

Like sibling comments say, this behavior is really common, trying to tell people to stop doing it just isn't going to happen.

If you really want to get your blood boiling, Vulkan since day 1 has had an application info struct which gets passed down to drivers, so drivers can work around application bugs and optimize for their specific loads! https://www.khronos.org/registry/vulkan/specs/1.3-extensions...

Yet another reason why making the web into an app platform was a mistake.