4 ms·

> I think unless we lock down new APIs that aide in fingerprinting to only be accessible to WebAssembly and let people block or enable WASM theres not too much

> I think unless we lock down new APIs that aide in fingerprinting to only be accessible to WebAssembly and let people block or enable WASM theres not too much else we can do. IMO, it should be enough if incognito mode presents an identical fingerprint on everyone's browser.

grishka 4y ago
It's not that easy to "present a fingerprint" without compromising the user experience. Sure, you could remove all those PWA and pretend-OS APIs and hardly anyone would notice, but what about things like viewport size and font rendering? You can't exactly hide them from a website.
- nordsieck 4y ago
  > It's not that easy to "present a fingerprint" without compromising the user experience. And that's exactly what I'm talking about. > what about things like viewport size and font rendering? Not much can be done about viewport size, but a browser could easily ship with 2 fonts (one serif and one sans serif) and only allow access to those.
  - derefr 4y ago
    “Font rendering” is a different thing than “what fonts you have.” Font rendering is about how fonts are drawn to the screen. The trick is to draw some words to a <canvas> and then pixel-peep the result. Different OSes and browsers use different font renderers and font hinting logic; fonts will even render differently on a different-DPI screen.
    - grishka 4y ago
      Not just the <canvas>. The font rendering of the underlying platform also influences the width of strings. So if you create a <span> with some text, its width will differ several pixels depending on the host OS.
    - GoblinSlayer 4y ago
      Don't they already use freetype to parse webfonts?
      - derefr 4y ago
        Is that a standard — that all browsers are forced to use the Freetype library, or to be bug-for-bug compatible with its glyph+hint parsing semantics? I've never heard of anything like that. But also, even if they did, AFAIK browsers still mostly lean on OS text-drawing APIs for font rendering. Text in Chrome on Windows looks different than text in Chrome on macOS, etc. The same pile of beziers, and the same pile of hints, converts into a different set of hinted pixels (and sub-pixels!) when fed to each OS text-drawing API. Especially when those APIs are configured by user settings around subpixel hinting / "font smoothing", and when those APIs are aware of the device being rendered to and so render subpixels differently for high-DPI vs low-DPI screens, RGB vs BGR displays, etc.
    - account42 4y ago
      Different browsersare always distinguishable but a single browser could choose to always use the same font rendering code and settings, at least for private browsing.
- IX-103 4y ago
  For viewport, you can limit the size presented to the page to a few sizes with different aspect ratios. Browsers can simply rescale the page to the actual window size for display on the screen. That also works for font rendering. If users decide they want pixel-perfect display, they can either resize the window to one of the allowed sizes or disable this feature for a specific page.
  - account42 4y ago
    You are describing the "compromising the user experience" alternative.
- matheusmoreira 4y ago
  > what about things like viewport size and font rendering? You can't exactly hide them from a website. Of course you can. Viewport? Just return fake viewport data containing the most statistically common display properties. Website renders incorrectly? They only have themselves to blame, shouldn't have abused that data for hostile purposes. Data is a privilege, we can and should take it away. Fonts? Just force everything to use Noto Sans or Noto Mono. Everything will render correctly. Maybe the designer's vision won't be fully realized but that's not a problem.
- GoblinSlayer 4y ago
  User and javascript can simply see different things, like adnauseam does. User experience is already shit.

grishka 4y ago

It's not that easy to "present a fingerprint" without compromising the user experience. Sure, you could remove all those PWA and pretend-OS APIs and hardly anyone would notice, but what about things like viewport size and font rendering? You can't exactly hide them from a website.

nordsieck 4y ago
> It's not that easy to "present a fingerprint" without compromising the user experience. And that's exactly what I'm talking about. > what about things like viewport size and font rendering? Not much can be done about viewport size, but a browser could easily ship with 2 fonts (one serif and one sans serif) and only allow access to those.
- derefr 4y ago
  “Font rendering” is a different thing than “what fonts you have.” Font rendering is about how fonts are drawn to the screen. The trick is to draw some words to a <canvas> and then pixel-peep the result. Different OSes and browsers use different font renderers and font hinting logic; fonts will even render differently on a different-DPI screen.
  - grishka 4y ago
    Not just the <canvas>. The font rendering of the underlying platform also influences the width of strings. So if you create a <span> with some text, its width will differ several pixels depending on the host OS.
  - GoblinSlayer 4y ago
    Don't they already use freetype to parse webfonts?
    - derefr 4y ago
      Is that a standard — that all browsers are forced to use the Freetype library, or to be bug-for-bug compatible with its glyph+hint parsing semantics? I've never heard of anything like that. But also, even if they did, AFAIK browsers still mostly lean on OS text-drawing APIs for font rendering. Text in Chrome on Windows looks different than text in Chrome on macOS, etc. The same pile of beziers, and the same pile of hints, converts into a different set of hinted pixels (and sub-pixels!) when fed to each OS text-drawing API. Especially when those APIs are configured by user settings around subpixel hinting / "font smoothing", and when those APIs are aware of the device being rendered to and so render subpixels differently for high-DPI vs low-DPI screens, RGB vs BGR displays, etc.
  - account42 4y ago
    Different browsersare always distinguishable but a single browser could choose to always use the same font rendering code and settings, at least for private browsing.
IX-103 4y ago
For viewport, you can limit the size presented to the page to a few sizes with different aspect ratios. Browsers can simply rescale the page to the actual window size for display on the screen. That also works for font rendering. If users decide they want pixel-perfect display, they can either resize the window to one of the allowed sizes or disable this feature for a specific page.
- account42 4y ago
  You are describing the "compromising the user experience" alternative.
matheusmoreira 4y ago
> what about things like viewport size and font rendering? You can't exactly hide them from a website. Of course you can. Viewport? Just return fake viewport data containing the most statistically common display properties. Website renders incorrectly? They only have themselves to blame, shouldn't have abused that data for hostile purposes. Data is a privilege, we can and should take it away. Fonts? Just force everything to use Noto Sans or Noto Mono. Everything will render correctly. Maybe the designer's vision won't be fully realized but that's not a problem.
GoblinSlayer 4y ago
User and javascript can simply see different things, like adnauseam does. User experience is already shit.