Everyone talks about how evil browser fingerprinting is, and it is, but I don’t get why people are only blaming the companies doing it and not putting equal blame on browsers for letting it happen.

Go to Am I Unique and look at the kind of data browsers let JavaScript access unconditionally with no user prompting. Here’s a selection of ridiculous ones that pretty much no website needs:

  • Your operating system (Isn’t the whole damn point of the internet that it’s platform independent?)
  • Your CPU architecture (JS runs on the most virtual of virtual environments why the hell does it need to know what processor you have?)
  • Your JS interpreter’s version and build ID
  • List of plugins you have installed
  • List of extensions you have installed
  • Your accelerometer and gyroscope (so any website can figure out what you’re doing by analyzing how you move your phone, i.e. running vs walking vs driving vs standing still)
  • Your magnetic field sensor AKA the phone’s compass (so websites can figure out which direction you’re facing)
  • Your proximity sensor
  • Your keyboard layout
  • How your mouse moves every moment it’s in the webpage window, including how far you scroll, what bit of text you hovered on or selected, both left and right clicks, etc.
  • Everything you type on your keyboard when the window is active. You don’t need to be typing into a text box or anything, you can set a general event listener for keystrokes like you can for the mouse.

If you’re wondering how sensors are used to fingerprint you, I think it has to do with manufacturing imperfections that skew their readings in unique ways for each device, but websites could just as easily straight up record those sensors without you knowing. It’s not a lot of data all things considered so you likely wouldn’t notice.

Also, canvas and webGL rendering differences are each more than enough to 100% identify your browser instance. Not a bit of effort put into making their results more consistent I guess.

All of these are accessible to any website by default. Actually, there’s not even a way to turn most of these off. WHY?! All of these are niche features that only a tiny fraction of websites need. Browser companies know that fingerprinting is a problem and have done nothing about it. Not even Firefox.

Why is the web, where you’re by far the most likely to execute malicious code, not built on zero trust policies? Let me allow the functionality I need on a per site basis.

Fuck everything about modern websites.

  • Zagorath@aussie.zoneEnglish
    32·
    2 days ago
    • Your operating system
    • Your CPU architecture

    Agree. No reason they should have this.

    • Your JS interpreter’s version and build ID

    I can see a reasonable argument for this being allowed. Feature detection should make this unnecessary, but it doesn’t seem to be fully supported yet.

    • Plugins & Extensions

    This is clearly a break of the browser sandbox and should require explicit permission at the very least (if not be blocked outright…I’m curious what the legitimate uses for these would be).

    • Accelerometer and gyroscope & magnetic field sensor

    Should probably be tied to location permission, for the sake of a simple UX.

    • Proximity sensor

    Definitely potential legitimate reasons for this, but it shouldn’t be by default.

    • Keyboard layout

    As someone who uses a non-QWERTY (and non-QWERTY-based) layout, this is one I have quite a stake in. The bottom line is that even without directly being able to obtain this, a site can very easily indirectly obtain it anyway, thanks to the difference between event.code and event.key. And that difference is important, because there are some cases where it’s better to use one or the other. A browser-based game, for example, probably wants to use event.code so the user can move around based on where WASD would be on a QWERTY keyboard, even though as a Dvorak user, for me that would be <AOE. But keyboard shortcuts like J and K for “next”/“previous” item should usually use event.key.

    There could/should be a browser setting somewhere, or an extension, that can hide this from sites. But it is far too useful, relative to its fingerprinting value, to restrict for ordinary users.

    how sensors are used to fingerprint you, I think it has to do with manufacturing imperfections that skew their readings in unique ways

    It’s also simple presence detection. “You have a proximity sensor” is a result not every browser will have, so it helps narrow down a specific browser.

    • Technoguyfication@sh.itjust.works
      71·
      2 days ago

      Operating system and CPU architecture are useful for sites to serve the correct binaries when a user is downloading an application. I know you could just give them all the options, but the average idiot has no idea what the difference between ARM and x86 is, or whether they have a 64 bit system. Hell, I wouldn’t even trust some users to accurately tell me what operating system they’re using.

      • lambalicious@lemmy.sdf.orgEnglish
        1·
        3 hours ago

        Operating system and CPU architecture are useful for sites to serve the correct binaries when a user is downloading an application.

        Barely. You could trim down the data to incredibly low granularity (“OS: Windows”, “CPU: Intel Desktop”) and you’d still get the exact same binary as 99% of the people 99% of the time, anyway.

      • Novaling@lemmy.zipEnglish
        3·
        6 hours ago

        This was the only one I could think of a good reason to track. I immediately thought of all the grandparents and tech illiterate people who’d probably implode if they had to pick .exe vs .deb vs .dmg/.app (I actually had to look up what MacOS uses…) vs etc. And don’t even try to have them guess intel vs amd.

        Automatically guessing the operating system saves us tech people from having to figure out they downloaded a file for a completely different OS.

      • Zagorath@aussie.zoneEnglish
        21·
        17 hours ago

        Oh yes, that’s a very good point, actually. That actually seems such a fundamental use case that you could almost justify it being available without a permission.

        • lambalicious@lemmy.sdf.orgEnglish
          12·
          3 hours ago

          No. It should be made available with a permission, because not every site out there is going to offer you to download binaries. 1% of the web “”“requiring”“” this does not justify 99% of the web being able to violate that privacy.

            • lambalicious@lemmy.sdf.orgEnglish
              1·
              36 minutes ago

              Good catch. Still, doesn’t make it true either: it’s not such a “fundamental use case” that it would even require the capability. The browser already reports the usable information in the user agent (you rarely even in that 1% need more specificity than “Windows” on “Desktop Intel”).

    • Jesus_666@lemmy.world
      31·
      2 days ago

      Plugins and extensions could make sense if the site and plugin are designed to talk to each other. But that could be made safer by each extension being able to decide whether to announce itself (and the user being able to override that).

      • Zagorath@aussie.zoneEnglish
        4·
        2 days ago

        Maybe, but I’d like to see a concrete example of how they are “designed to talk to each other” that couldn’t be achieved by the extension just reading the DOM.