6 ms·

It is interesting, that while technologies like canvas, WebGL or WebRTC were intented for other purposes, their main usage became fingerprinting. For example, W

It is interesting, that while technologies like canvas, WebGL or WebRTC were intented for other purposes, their main usage became fingerprinting. For example, WebGL provides valuable information about GPU model and its drivers. This shows how browser developers race to provide new features ignoring privacy impact. I don't understand why features that allow fingerprinting (reading back canvas pixels or GPU buffers) are not hidden behind a permission.

fxtentacle 4y ago
It's because the developer of the browser needs fingerprinting for their ads. I don't think Chrome accidentally exposed data that Google wanted.
- supriyo-biswas 4y ago
  The fly in the ointment with this theory is why Apple (or even Mozilla) would expose the same kind of information. Apple has only recently started experimenting with ads, and their ads are limited to the apps that they control. The more benign explanation would be to allow developers to work around device-specific or browser-specific bugs. (I'm aware Apple changes the GPU Model to "Apple GPU", however they do expose a ton of other properties that make it possible to fingerprint a device.)
  - threatofrain 4y ago
    Continuing the push the browser to be a general app platform is the only way it can survive against native experience, which is already eating into the enthusiasm for the web. It seems like the trend for consumer companies is to maybe launch first on the web for velocity but eventually migrate to native experiences. I wonder to what degree we can enable hardware performance without leaking user data.
  - camyule 4y ago
    Firefox do have a mechanism to limit the amount of data being leaked for fingerprinting, but it’s disabled by default: https://support.mozilla.org/en-US/kb/firefox-protection-against-fingerprinting https://support.mozilla.org/en-US/kb/firefox-protection-agai...
    - philliphaydon 4y ago
      Wow I just realised I’ve had this enabled for… since I first remember the feature announced, and the internet hasn’t broken.
      - cmeacham98 4y ago
        They're not that big of a deal, but my two biggest annoyances with RFP: 1. prefers-color-scheme is completely broken, even in the dev tools. Mozilla refuses to fix this in any way, it is allegedly "by design" that you have to disable all RFP protection if you're a web dev and need to test the dark color scheme of your website. 2. Similarly, RFP always vends your timezone as UTC with no way to change.
        arein3 4y ago
        They could add switches for individual features to mask on a hidden/advanced menu
        nightpool 4y ago
        that's a great way to get even more fingerprinting potential, each additional switch is another bit of identification on top of the actual fingerprint itself.
        cmeacham98 4y ago
        Mozilla refuses to add _any_ toggle to disable RFP's control over features it touches, including even an about:config entry. See example bugzilla: https://bugzilla.mozilla.org/show_bug.cgi?id=1535189 https://bugzilla.mozilla.org/show_bug.cgi?id=1535189 My "fix" for this involves using a janky old version of an addon that attempts to muck with the CSS/JS to reproduce the effect.
        asalahli 4y ago
        Does adding your website to privacy.resistFingerprinting.exemptedDomains not work?
  - jakear 4y ago
    Apple devices are in fact fairly difficult to fingerprint. In my experiments [1] all instances of the same hardware model (on iOS, iPadOS, and macOS) give the same fingerprint, so the best a tracker can get is "uses iPhone 14". Better than nothing, but not terribly unique. [1] fingrprintr.pages.dev
    - deleted 4y ago
      [deleted]
    - deleted 4y ago
      [deleted]
  - RobotToaster 4y ago
    Isn't Mozilla's main source of income from Google?
- danielheath 4y ago
  I thought the developer of the browser is the only ad provider that _doesn't_ need it (since they have other, better ways to get that intel which their competitors do not).
  - asdfghjkjhg 4y ago
    they (google) did try. that's the profile icon you see on your google-chrome UI. but only fools use that feature.
    - somekyle2 4y ago
      what makes someone who uses that feature a "fool"? Some users don't particularly mind being tracked.
      - Cockbrand 4y ago
        Also, it's very convenient in a work context if your employer uses G Suite/Workspace. I don't have anything to hide work-wise, and I do everything else in incognito windows.
- IshKebab 4y ago
  Please don't spread obviously untrue conspiracy theories. The main reason is that it's really hard to avoid fingerprinting (while providing rich features like WebGL and WebRTC anyway). A secondary reason is that web browsers started off from a position of leaking fingerprint data all over the place so there's not much incentive to care about it for new features. You might be interested in this effort to reduce fingerprinting: https://developer.chrome.com/en/docs/privacy-sandbox/privacy-budget/ https://developer.chrome.com/en/docs/privacy-sandbox/privacy... (The real conspiracy is that Google added logins to Chrome specifically so that they don't have to rely on fingerprinting. They have a huge incentive to stop fingerprinting because it leaves them as the only entity that can track users.)
PetahNZ 4y ago
Come on, it's not their main usage... An intentional side effect maybe, but their main usage is clear.
- 0xy 4y ago
  If something is used 99% of the time for tracking and 1% of the time for genuine useful reasons, it's safe to say it's a tracking mechanism. Intent is irrelevant, the APIs are fundamentally insecure. Google directly benefits from this financially.
jsnell 4y ago
It is absurd to claim that the main use of WebRTC is fingerprinting. Especially during the pandemic the world pretty much ran on WebRTC. Real-time media is clearly a pretty core functionality for the web to be a serious application platform, it wasn't just some kind of a trojan horse for tracking. Now, it is true that a lot of older web APIs do expose too much fingerprinting surface. But the design sensibilities having changed a lot over time, it's just not the case that you can make statements about what browser developers do now based on what designs from a decade or two ago look like. These days privacy is a top issue when it comes to any new browser APIs. But let's take your question at face value: why aren't thesespecific things behind a permission dialog? Because the permissions would be totally unactionable to a normal user. "This page wants to send you notifications" or "this page wants to use the microphone" is understandable. "This page wants to read pixels from a canvas" isn't. If you go the permission route, the options are to either a) teach users that they need to click through nonsensical permission dialogs, with all the obvious downsides; b) make the notifications so scare or the permissions so inaccessible that the features might as well not exist. And the latter would be bad! Because the legit use cases for e.g. reading from a canvas do exist; they're just pretty rare. The Privacy Sandbox approach to this is to track and limit how much entropy a site is extracting via these kinds of side channels. So if you legit need to read canvas pixels, you'll have to give up on other features that could leak fingerprinting data. (I personally don't really believe in that approach will work, but it is at least principled. What I'd like to see instead is limiting the use of these APIs to situations where the site has a stable identifier for the user anyway. But that requires getting away from implementing auth with cookies as opaque blobs of data with unknown semantics, and moving to some kind of proper session support where the browsers understands the semantics of signed-in session, and it's made clear to users when they're signing in somewhere and where they're signed in right now. And then you can make a lot better tradeoffs with limiting the fingerprinting surface in the non-signed in cases.)
- 0xy 4y ago
  Of course it's main use is fingerprinting. Do you think WebRTC is instantiated for genuine reasons the majority of the time? That's real absurdity. WebRTC is instantiated most often by ad networks and anti-fraud services. Same thing with Chrome's fundamentally insecure AudioContext tracking scheme (yes, it's a tracking scheme), which is used by trackers 99% of the time. It provides audio latency information which is highly unique (why?). Given Chrome's stated mission of secure APIs and their actions of implementing leaky APIs with zeal, I have reason enough to question their motives. After all, AudioContext is abused heavily on Google's ad networks. Google knows this.
ivoras 4y ago
Of course it's not that simple. In most parts of the world, if a person is in a public space, anyone can take a photo of that person, including shop owners. This photo could be considered as a type of "fingerprint" for that person. The only important difference is that in some countries, you are not allowed make money off of such photos. The Internet is a lot like a big public space, and possibly worse - while you are using certain services (web pages or apps), it might be argued that you are actually "on premises" for that service provider. The best we can do now is more and more education about what can go wrong with such data collection.
- ajsnigrutin 4y ago
  Yes, but taking photos is expensive, fingerprinting online is cheap. Also, there's a difference between taking a photo of the eiffel tower and taking a photo of a bunch of other tourists there (legal), or intentionally targeting and photographing an individual and creating a database of those photos (illegal in most countries).
ghayes 4y ago
Take a look at Firefox’s Fingerprinting Prevention feature. This includes a permission for canvas, as well as: - Your timezone is reported to be UTC - Not all fonts installed on your computer are available to webpages - The browser window prefers to be set to a specific size - Your browser reports a specific, common version number and operating system - Your keyboard layout and language is disguised - Your webcam and microphone capabilities are disguised - The Media Statistics Web API reports misleading information - Any Site-Specific Zoom settings are not applied - The WebSpeech, Gamepad, Sensors, and Performance Web APIs are disabled https://support.mozilla.org/en-US/kb/firefox-protection-against-fingerprinting https://support.mozilla.org/en-US/kb/firefox-protection-agai...
madeofpalk 4y ago
> This shows how browser developers race to provide new features ignoring privacy impact. I think it showed how many years ago browser vendors were naive with understanding how this tech could be misused. These days I think browser vendors are very much aware of it and will frequently block features or proposals that they feel compromise on privacy and/or could be used as a tracking vector, especially Firefox and Safari. Sort this list https://mozilla.github.io/standards-positions/ https://mozilla.github.io/standards-positions/ by Mozilla Position to see the reason they reject/refuse to implement standards and proposals.
neop1x 4y ago
For those who are unaware of how big of a problem fingerprinting is, there is an EFF website [1]. EU cookie policy is nothing compared to this. There are libraries like fingerprintjs [2] which can generate a pretty stable visitor ID. If you change or alter some browser APIs in order to make your browser less unique, some payment processors webs may stop working. And webs proxied through CloudFlare will constantly display "Checking if the site connection is secure" page, sometimes in an infinite loop where even solving their captchas won't help. [1] https://coveryourtracks.eff.org/ https://coveryourtracks.eff.org/ [2] https://fingerprint.com/ https://fingerprint.com/

fxtentacle 4y ago

It's because the developer of the browser needs fingerprinting for their ads. I don't think Chrome accidentally exposed data that Google wanted.

supriyo-biswas 4y ago
The fly in the ointment with this theory is why Apple (or even Mozilla) would expose the same kind of information. Apple has only recently started experimenting with ads, and their ads are limited to the apps that they control. The more benign explanation would be to allow developers to work around device-specific or browser-specific bugs. (I'm aware Apple changes the GPU Model to "Apple GPU", however they do expose a ton of other properties that make it possible to fingerprint a device.)
- threatofrain 4y ago
  Continuing the push the browser to be a general app platform is the only way it can survive against native experience, which is already eating into the enthusiasm for the web. It seems like the trend for consumer companies is to maybe launch first on the web for velocity but eventually migrate to native experiences. I wonder to what degree we can enable hardware performance without leaking user data.
- camyule 4y ago
  Firefox do have a mechanism to limit the amount of data being leaked for fingerprinting, but it’s disabled by default: https://support.mozilla.org/en-US/kb/firefox-protection-against-fingerprinting https://support.mozilla.org/en-US/kb/firefox-protection-agai...
  - philliphaydon 4y ago
    Wow I just realised I’ve had this enabled for… since I first remember the feature announced, and the internet hasn’t broken.
    - cmeacham98 4y ago
      They're not that big of a deal, but my two biggest annoyances with RFP: 1. prefers-color-scheme is completely broken, even in the dev tools. Mozilla refuses to fix this in any way, it is allegedly "by design" that you have to disable all RFP protection if you're a web dev and need to test the dark color scheme of your website. 2. Similarly, RFP always vends your timezone as UTC with no way to change.
      - arein3 4y ago
        They could add switches for individual features to mask on a hidden/advanced menu
        nightpool 4y ago
        that's a great way to get even more fingerprinting potential, each additional switch is another bit of identification on top of the actual fingerprint itself.
        cmeacham98 4y ago
        Mozilla refuses to add _any_ toggle to disable RFP's control over features it touches, including even an about:config entry. See example bugzilla: https://bugzilla.mozilla.org/show_bug.cgi?id=1535189 https://bugzilla.mozilla.org/show_bug.cgi?id=1535189 My "fix" for this involves using a janky old version of an addon that attempts to muck with the CSS/JS to reproduce the effect.
      - asalahli 4y ago
        Does adding your website to privacy.resistFingerprinting.exemptedDomains not work?
- jakear 4y ago
  Apple devices are in fact fairly difficult to fingerprint. In my experiments [1] all instances of the same hardware model (on iOS, iPadOS, and macOS) give the same fingerprint, so the best a tracker can get is "uses iPhone 14". Better than nothing, but not terribly unique. [1] fingrprintr.pages.dev
  - deleted 4y ago
    [deleted]
  - deleted 4y ago
    [deleted]
- RobotToaster 4y ago
  Isn't Mozilla's main source of income from Google?
danielheath 4y ago
I thought the developer of the browser is the only ad provider that _doesn't_ need it (since they have other, better ways to get that intel which their competitors do not).
- asdfghjkjhg 4y ago
  they (google) did try. that's the profile icon you see on your google-chrome UI. but only fools use that feature.
  - somekyle2 4y ago
    what makes someone who uses that feature a "fool"? Some users don't particularly mind being tracked.
    - Cockbrand 4y ago
      Also, it's very convenient in a work context if your employer uses G Suite/Workspace. I don't have anything to hide work-wise, and I do everything else in incognito windows.
IshKebab 4y ago
Please don't spread obviously untrue conspiracy theories. The main reason is that it's really hard to avoid fingerprinting (while providing rich features like WebGL and WebRTC anyway). A secondary reason is that web browsers started off from a position of leaking fingerprint data all over the place so there's not much incentive to care about it for new features. You might be interested in this effort to reduce fingerprinting: https://developer.chrome.com/en/docs/privacy-sandbox/privacy-budget/ https://developer.chrome.com/en/docs/privacy-sandbox/privacy... (The real conspiracy is that Google added logins to Chrome specifically so that they don't have to rely on fingerprinting. They have a huge incentive to stop fingerprinting because it leaves them as the only entity that can track users.)

PetahNZ 4y ago

Come on, it's not their main usage... An intentional side effect maybe, but their main usage is clear.

0xy 4y ago
If something is used 99% of the time for tracking and 1% of the time for genuine useful reasons, it's safe to say it's a tracking mechanism. Intent is irrelevant, the APIs are fundamentally insecure. Google directly benefits from this financially.

jsnell 4y ago

It is absurd to claim that the main use of WebRTC is fingerprinting. Especially during the pandemic the world pretty much ran on WebRTC. Real-time media is clearly a pretty core functionality for the web to be a serious application platform, it wasn't just some kind of a trojan horse for tracking. Now, it is true that a lot of older web APIs do expose too much fingerprinting surface. But the design sensibilities having changed a lot over time, it's just not the case that you can make statements about what browser developers do now based on what designs from a decade or two ago look like. These days privacy is a top issue when it comes to any new browser APIs. But let's take your question at face value: why aren't thesespecific things behind a permission dialog? Because the permissions would be totally unactionable to a normal user. "This page wants to send you notifications" or "this page wants to use the microphone" is understandable. "This page wants to read pixels from a canvas" isn't. If you go the permission route, the options are to either a) teach users that they need to click through nonsensical permission dialogs, with all the obvious downsides; b) make the notifications so scare or the permissions so inaccessible that the features might as well not exist. And the latter would be bad! Because the legit use cases for e.g. reading from a canvas do exist; they're just pretty rare. The Privacy Sandbox approach to this is to track and limit how much entropy a site is extracting via these kinds of side channels. So if you legit need to read canvas pixels, you'll have to give up on other features that could leak fingerprinting data. (I personally don't really believe in that approach will work, but it is at least principled. What I'd like to see instead is limiting the use of these APIs to situations where the site has a stable identifier for the user anyway. But that requires getting away from implementing auth with cookies as opaque blobs of data with unknown semantics, and moving to some kind of proper session support where the browsers understands the semantics of signed-in session, and it's made clear to users when they're signing in somewhere and where they're signed in right now. And then you can make a lot better tradeoffs with limiting the fingerprinting surface in the non-signed in cases.)

0xy 4y ago
Of course it's main use is fingerprinting. Do you think WebRTC is instantiated for genuine reasons the majority of the time? That's real absurdity. WebRTC is instantiated most often by ad networks and anti-fraud services. Same thing with Chrome's fundamentally insecure AudioContext tracking scheme (yes, it's a tracking scheme), which is used by trackers 99% of the time. It provides audio latency information which is highly unique (why?). Given Chrome's stated mission of secure APIs and their actions of implementing leaky APIs with zeal, I have reason enough to question their motives. After all, AudioContext is abused heavily on Google's ad networks. Google knows this.

ivoras 4y ago

Of course it's not that simple. In most parts of the world, if a person is in a public space, anyone can take a photo of that person, including shop owners. This photo could be considered as a type of "fingerprint" for that person. The only important difference is that in some countries, you are not allowed make money off of such photos. The Internet is a lot like a big public space, and possibly worse - while you are using certain services (web pages or apps), it might be argued that you are actually "on premises" for that service provider. The best we can do now is more and more education about what can go wrong with such data collection.

ajsnigrutin 4y ago
Yes, but taking photos is expensive, fingerprinting online is cheap. Also, there's a difference between taking a photo of the eiffel tower and taking a photo of a bunch of other tourists there (legal), or intentionally targeting and photographing an individual and creating a database of those photos (illegal in most countries).

ghayes 4y ago

Take a look at Firefox’s Fingerprinting Prevention feature. This includes a permission for canvas, as well as: - Your timezone is reported to be UTC - Not all fonts installed on your computer are available to webpages - The browser window prefers to be set to a specific size - Your browser reports a specific, common version number and operating system - Your keyboard layout and language is disguised - Your webcam and microphone capabilities are disguised - The Media Statistics Web API reports misleading information - Any Site-Specific Zoom settings are not applied - The WebSpeech, Gamepad, Sensors, and Performance Web APIs are disabled https://support.mozilla.org/en-US/kb/firefox-protection-against-fingerprinting https://support.mozilla.org/en-US/kb/firefox-protection-agai...

madeofpalk 4y ago

> This shows how browser developers race to provide new features ignoring privacy impact. I think it showed how many years ago browser vendors were naive with understanding how this tech could be misused. These days I think browser vendors are very much aware of it and will frequently block features or proposals that they feel compromise on privacy and/or could be used as a tracking vector, especially Firefox and Safari. Sort this list https://mozilla.github.io/standards-positions/ https://mozilla.github.io/standards-positions/ by Mozilla Position to see the reason they reject/refuse to implement standards and proposals.

neop1x 4y ago

For those who are unaware of how big of a problem fingerprinting is, there is an EFF website [1]. EU cookie policy is nothing compared to this. There are libraries like fingerprintjs [2] which can generate a pretty stable visitor ID. If you change or alter some browser APIs in order to make your browser less unique, some payment processors webs may stop working. And webs proxied through CloudFlare will constantly display "Checking if the site connection is secure" page, sometimes in an infinite loop where even solving their captchas won't help. [1] https://coveryourtracks.eff.org/ https://coveryourtracks.eff.org/ [2] https://fingerprint.com/ https://fingerprint.com/