Hacker News new | ask | show | jobs
by mysteryDate 1574 days ago
A legitimate point! Unfortunately from our end it's also impossible to tell what canvases are being used for. Somewhat reassuringly, the vast majority canvases that are being created are much larger than would be necessary for fingerprinting, so we have some reason to believe that most uses are legitimate. There's also the fact that the vast majority of canvases never perform `getImageData`, which is an essential part of every fingerprinting technique I've ever seen.

At this point it's possible to fingerprint with CSS alone, no javascript: https://css-tricks.com/css-based-fingerprinting/

So to say that canvas is an element "for fingerprinting" I think is an outdated notion that's the result of some bad PR the element got like 10 years ago.

So, yes, fingerprinting is an issue and we all wish it would go away. Unfortunately there is a ton of work to do. A lot of very smart people are working on this and I wish them the best of luck.

2 comments

>At this point it's possible to fingerprint with CSS alone, no javascript: https://css-tricks.com/css-based-fing

Fingerprinting isn't a boolean state. The more fingerprinting vectors you have the more reliably you can identify users. Therefore having CSS fingerprinting (or any other fingerprinting vector) doesn't really make canvas fingerprinting less bad.

True. Any data the user leaks is data the user leaks and we should work to prevent this. However I don't think people realize just how easy it is to reliably fingerprint users who are blocking javascript and canvas and other web features.
>how easy it is to reliably fingerprint users who are blocking javascript and canvas and other web features.

The key difference is that most of the fingerprinting attributes listed in the article, most are very innocuous and/or easy to change (ie. unreliable for fingerprinting). That includes:

1. pointer type

2. prefers-color-scheme

3. window size

4. @supports

The only other one (local fonts) is interesting, but is still easily changeable and conceivably be mitigated by removing all non-default fonts. This is in contrast to canvas/webgl fingerprinting which fingerprints both the software and hardware parts of your rendering stack, and is nearly impossible to change.

Oh I realize. I also realize literally nobody is going to bite the hand that feeds and that this industry is never going to regulate itself.
In the future, everyone is using a 640x480 window into a browser that's completely software stack in a VM that runs at a regulated frequency with a specifically allocated amount of RAM and hard drive space, doesn't accept cookies, and clears cache after every page load.
> Unfortunately from our end it's also impossible to tell what canvases are being used for.

you mean trivial, right? calling getImageData toBlob toDataURL means fingerprinting.

I guess it didn't occur to you that retrieving and setting image data with getImageData()/putImageData() actually turn out to be indispensable features when generating complex multi-layer canvases. Your trivial heuristic would flag a lot of false positives.