We currently expose the major version of Android and the CPU architecture on Linux in every HTTP request.
That is, these are exposed to passive fingerprinting that doesn't involve running JS. (On Android, the CPU architecture is exposed via JavaScript but not in the HTTP User-Agent string. Exposing it probably doesn't help users, but the exposure probably doesn't contribute JS-reachable entropy on top of WebGL-exposed values.) Previously, we've had problems from exposing the Android version. Back when Firefox still ran on Android versions lower than 4.4, we ended up reporting 4.4 for those to avoid discrimination by Web sites. I'm aware of one use case for the Android version that could be justified from the perspective of what users might want: Deciding if intent links work. This only requires checking < 6 vs. >= 6, and Fenix runs on 5 still. Assuming that we accept the level of breakage that a device currently running Android 9 or 10 experience relative to what Android 8 devices experience (9 and 10 have potential breakage from not having a dot and a minor version), what would break if we reported 5.0 for anything below 6 and the latest (currently 10) for anything 6 or above? As for the CPU architecture on Linux, on Mac and Windows we don't expose aarch64 separately. (On Windows, consistent with Edge, aarch64 looks like x86. On Mac, aarch64 looks like x86_64 which itself doesn't differ from what x86 looked like.) The software download situation for each desktop platform is different: On Windows, an x86 stub installer can decide whether to install x86, x86_64, or aarch64 app. On Mac, Universal Binaries make it irrelevant to know the CPU architecture at the app download time. On Linux, downloads outside the distro's package manager typically involve the user having to choose from various options anyway due to tarball vs. .deb vs. .rpm vs. Flatpak vs. Snap, etc. OTOH, unlike on Windows and Mac, x86 or x86_64 emulation isn't typically automatically ready to work on Linux. We don't ship official builds for aarch64 Linux (do we have plans to?), but we do have it as an option on try and the configuration is becoming increasingly relevant in distro-shipped form. However, if we wanted to avoid the fingerprintability here, it would be good to take action before Linux on aarch64 is popular enough for us to ship official builds. Does reporting "Linux aarch64" have significant concrete benefits to users? Would actual presently-existing app download pages break if, for privacy, we always reported "Linux x86_64" on Linux regardless of the actual CPU architecture (or reported it on anything but 32-bit x86)? Historically, distros and BSDs have wanted to draw attention to themselves instead of letting their users hide in the crowd for privacy, which is unfortunate considering that the user cohort is already smaller than the Windows and Mac cohorts. Does that dynamic apply to ISAs? I.e. should we expect distro maintainers to undo the change if we made mozilla-central say "Linux x86_64" regardless of the actual ISA on Linux? -- Henri Sivonen hsivo...@mozilla.com _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
