2 ms·

Canvases can vary very slighly between users' setups. The inconsistencies in rendering are used to fingerprint And to my knowledge you can't ask the browser ab

Canvases can vary very slighly between users' setups. The inconsistencies in rendering are used to fingerprint And to my knowledge you can't ask the browser about the cpu, only the number of cores. The regular fingerprinting you described would be just an user agent string that can be trivially spoofed

bhouston 2y ago
> Canvases can vary very slighly between users' setups. The inconsistencies in rendering are used to fingerprint I think it overlaps mostly with OS, CPU, Browser, GPU Type, GPU driver version. These can already be queried by UA string and WebGL/WebGPU. It is easier to query them explicitly for most users but I guess canvas fingerprinting is a fallback for when these APIs do not return some of the data. > And to my knowledge you can't ask the browser about the cpu, only the number of cores. Generally you can. Not all browsers give up all info, but most browsers give up most of the info. Here is a demo of what you get from ua parsing: https://uaparser.dev/#demo https://uaparser.dev/#demo
- IggleSniggle 2y ago
  Years ago you could get crazy specific fingerprints from canvas. It got far less precise when Chrome introduced jitter into timers and treated performance timers as security sensitive functions. The main difference between canvas and this other stuff is that canvas couldn't be spoofed whereas everything else could and can be spoofed, or was so general as to be useless as an identifier.
  - Jerrrry 2y ago
    The granularity of the performance timers were too specific, allowing the number of cores to be deduced by the amount of time it took to do certain math functions. Those certain math functions happen to be floating point operations that are ordered in a way to maximize the inaccuracy property off floating point types. These inaccuracies are very correlatable.
  - trod123 2y ago
    That's not true. The jitter had very little intended effect since accurate system timing can be derived from the instruction processing time of arbitrary javascript code in a mostly browser agnostic way, specifically iteration (i=i+1). It applied broadly to a large number of different types of instructions
    - IggleSniggle 2y ago
      But how do you measure the timing of those instructions without a precise timer? Yes it was the instructions that produce the reproducible timing, and that timing will be consistent on the system, but the measurement of those timings from the performance timers will not display that same consistency. Is there another way to measure from a within-session context?

bhouston 2y ago

> Canvases can vary very slighly between users' setups. The inconsistencies in rendering are used to fingerprint I think it overlaps mostly with OS, CPU, Browser, GPU Type, GPU driver version. These can already be queried by UA string and WebGL/WebGPU. It is easier to query them explicitly for most users but I guess canvas fingerprinting is a fallback for when these APIs do not return some of the data. > And to my knowledge you can't ask the browser about the cpu, only the number of cores. Generally you can. Not all browsers give up all info, but most browsers give up most of the info. Here is a demo of what you get from ua parsing: https://uaparser.dev/#demo https://uaparser.dev/#demo

IggleSniggle 2y ago
Years ago you could get crazy specific fingerprints from canvas. It got far less precise when Chrome introduced jitter into timers and treated performance timers as security sensitive functions. The main difference between canvas and this other stuff is that canvas couldn't be spoofed whereas everything else could and can be spoofed, or was so general as to be useless as an identifier.
- Jerrrry 2y ago
  The granularity of the performance timers were too specific, allowing the number of cores to be deduced by the amount of time it took to do certain math functions. Those certain math functions happen to be floating point operations that are ordered in a way to maximize the inaccuracy property off floating point types. These inaccuracies are very correlatable.
- trod123 2y ago
  That's not true. The jitter had very little intended effect since accurate system timing can be derived from the instruction processing time of arbitrary javascript code in a mostly browser agnostic way, specifically iteration (i=i+1). It applied broadly to a large number of different types of instructions
  - IggleSniggle 2y ago
    But how do you measure the timing of those instructions without a precise timer? Yes it was the instructions that produce the reproducible timing, and that timing will be consistent on the system, but the measurement of those timings from the performance timers will not display that same consistency. Is there another way to measure from a within-session context?