8 ms·

Some of these are probably fingerprinting but the Twitch one isn't (I worked on the video system at Twitch for a number of years). "player-core-variant-....js"

Some of these are probably fingerprinting but the Twitch one isn't (I worked on the video system at Twitch for a number of years). "player-core-variant-....js" is the Javascript video player and it uses WebGL as a way to guess what video format the browser can handle. A lot of the times mobile android devices will say "I can play video X, Y, Z" but when sent a bitstream of Y it fails to decode it. WebGL allows you to get a good indication of the supported hardware features which you can use to guess what the actual underlying hardware decoder is. This is sadly the state of a lot of "lower end" mobile SoCs. They will pretend to do anything but in reality it just... doesn't.

nerdponx 5y ago
That said, surely this "functional" information can also be valuable fingerprinting data, no? What's stopping an enterprising data science team from pulling it into their data lake, using to build ad models for logged-out users, maybe submitting it to 3rd-party machine learning vendors, etc. and generally making it undeletable?
kjrose 5y ago
This is interesting. I can see how it could have legitimate uses to get around bad inplementations with stating what capabilities are possible. However that being said it's like fingerprinting to sort out what their system really has. Still an abuse of the system.
- nerdponx 5y ago
  As per my sibling (cousin?) comment, pretty much any legitimate capability-determining data can be used for fingerprinting. This can only be solved with legislation, IMO. There is no way for an industry to self-regulate something like this, the candy bowl too big and the candy too sweet.
  - throwawgler87 5y ago
    To make fingerprinting illegal, you mean? Or were you thinking of some other way to solve the problem with regulation?
    - nerdponx 5y ago
      More like (the spirit of) GDPR, where data collection itself becomes a legal and financial liability to point where it's not worth it to collect and retain it for a typical entity.
  - difosfor 5y ago
    Yeah, I think the world would be better off without ads altogether. Just allow people to search for what they need or want by themselves, that's enough.
    - nine_k 5y ago
      ...and pay out of pocket for the use of a search engine? Why, well, I'd do that; e.g. neeva.com is accepting sign-ups. Also, ads without personal targeting, much like dead-trees newspaper / magazine ads, could still work and prop up certain web publishers.
      - tjpnz 5y ago
        >...and pay out of pocket for the use of a search engine? That's the only way service providers will see a cent from me going forward. Ads present not only a privacy risk but they're increasingly becoming a security risk too. I will not allow them on any of the devices I own or that connect to my home WiFi.
        nine_k 5y ago
        I think that static ads served from the first-party CDN are security-wise no worse that the content itself. Blocking scripts and requests by third-party ad networks makes complete sense from security perspective, though. Affiliate links going directly to relevant item pages in a store are fine by me, too. They have to be relevant for anyone to click on them, they don't play video or make sound, etc. They do give some tracking opportunity, but without third-party cookies and third-party requests, it's hard to achieve anything resembling the privacy-invading precise tracking which current ad networks routinely do. In any case, I much more prefer the absence of AWS and an honest donation button.
- slashink 5y ago
  That's a fair take. In a sense it's is a "fingerprinting" method although I personally think fingerprinting embodies using this data to track devices between contexts. If you're interested why this data was exposed in the first place, the MDN docs has good info https://developer.mozilla.org/en-US/docs/Web/API/WEBGL_debug_renderer_info https://developer.mozilla.org/en-US/docs/Web/API/WEBGL_debug... . "Generally, the graphics driver information should only be used in edge cases to optimize your WebGL content or to debug GPU problems." Sadly that's the reality of some of these tools. The intent was good and in many cases they are a necessity to create a web experience that works on every device. On the flip side this allows people to use this data to fingerprint.
kjeetgill 5y ago
... but that is sorta fingerprinting, right? Atleast, inferring a user's device capabilities via WebGL is hardly using WebGL. I think it's a beautiful, legitimate use — but I can't fault the author for labeling fingerprinting.
- jeffgreco 5y ago
  Is fingerprinting not trying to uniquely identify a user?
  - calhoun137 5y ago
    Since there is no way to 100% fingerprint a device, therefore there is no way to uniquely identify anyone with 100% confidence using pure fingerprinting techniques. My view is that fingerprinting is a set of tools which can be used for "good or evil" if that makes sense. If you are gathering meta-data to determine the capabilities of the device, then this is part of the wider framework of data points which can, in principle, be used for fingerprinting a user. This data can be imported into a completely different system by a sophisticated adversary, so it needs to be treated as a security vector, imho
    - salawat 5y ago
      >Since there is no way to 100% fingerprint a device, therefore there is no way to uniquely identify anyone with 100% confidence using pure fingerprinting techniques. Pedantic point, so forgive me, but 100% uniquely identifying a device does not imply 100% uniquely identifying the user of the device. We call them User-Agents for a reason. Anyone could be using it. It's critical people not fall into the habit of conflating users and user-agents. Two completely different things, and increasingly, law enforcement has gotten more and more gung-ho about surreptitiously forgetting the difference. Ad networks and device/User-Agent based surveillance only makes it worse. There are several initiatives to implement UUID's for devices. There is the Android Advertising ID, systemD's machine-id file, Intel burns in a unique identifier into every CPU. IPv6 (without address randomization) would also work as a poor man's UUID. It's frighteningly easy, and you'll be surprised how unintentionally one can be implementing something seemingly innocent and end up furthering the purposes of those seeking to surveil.
tmpz22 5y ago
So absolutely no data on the device obtained via webGL is used for marketing or other BI workloads? None of it is shared with 3rd parties (especially advertisers)? Its entirely used for the user experience and then discarded when no longer relevant? FWIW while I'm playing hardball here I really appreciate your answer and expertise.
- Ensorceled 5y ago
  > FWIW while I'm playing hardball here I really appreciate your answer and expertise. You’re actually just outright accusing them of lying.
  - djrogers 5y ago
    Do you see those question marks? Those denote questions. Questions are not accusations.
    - wizzwizz4 5y ago
      Tell that to Socrates.
    - itsananderson 5y ago
      Have you stopped beating your wife? Edit: this is the typical example of a loaded question, not an actual accusation against the parent comment https://en.m.wikipedia.org/wiki/Loaded_question https://en.m.wikipedia.org/wiki/Loaded_question
    - jameshart 5y ago
      Really? never? So when did you stop beating your wife?
      - II2II 5y ago
        I understand the point you are trying to make, with the question incorporating an accusation (i.e. that the person beat their wife in the past). That is different from asking pointed questions about potential actions (e.g. "have you ever beat your wife?").
Arnavion 5y ago
I'm curious if something like [1] would work for those SoCs, eg ask if it supports "video/mp4-liar-liar-pants-on-fire-from-twitchtv" [1]: https://devblogs.microsoft.com/oldnewthing/?p=40663 https://devblogs.microsoft.com/oldnewthing/?p=40663
- slashink 5y ago
  Good question! So the problem here is a bit different. It's not that devices will say "I can play Format X" and then not play it. It's that devices say "I can play Format X at Resolution A, B, C". When you give the device resolution A and B it succeeds but at resolution C it fails to decode it. In H.264 this would be the "Level" https://en.wikipedia.org/wiki/Advanced_Video_Coding#Levels https://en.wikipedia.org/wiki/Advanced_Video_Coding#Levels . A device may say that it can decode Level 4.2 but in reality it can only do 4.1. That means it can play back 1080p30 but not 1080p60. The only way to know is to actually try and observe the failure (which often btw is a silent failure fro m the browsers point of view, meaning you need to rely on user reports).
  - greggman3 5y ago
    Wouldn't it be just as easy to test videos in formats A, B, and C and see if the play? You could check that video.currentTime advances. If it lies about that you could draw to a canvas and check the values. That seems more robust than checking WebGL.
    - slashink 5y ago
      Also a good question. The issue here is the architectural difference between the hardware decoder and the GPU. What happens under the hood with MSE ( https://developer.mozilla.org/en-US/docs/Web/API/Media_Source_Extensions_API https://developer.mozilla.org/en-US/docs/Web/API/Media_Sourc...) is that you are responsible for handing off a buffer to the hardware decoder as a bitstream. Underneath, the GPU sets up a texture and sends the bitstream to the hardware decoder that's responsible for painting the decoded video into that texture. What often ends up happening is that the GPU driver says "yes the hardware decoder can do this", it accepts the bitstream, sets up the texture for you which is bound against your canvas in HTML. Starts playing the video, moves the timeline playhead but the actual buffer is just an empty black texture. From the software's point of view, the pipeline is doing what it's supposed, due to the hardware decoder being a black box from the Javascript perspective it's impossible to know if it "actually" worked. Good decoders will throw errors or refuse to advance the PTS, bad decoders won't. Knowing this, your second suggestion was to read back the canvas and detect video. That would work but the problem here is "what constitutes working video". We can detect if the video is just a black box but what if the video plays back but at 1 frame per second, or plays back with the wrong colors. It's impossible to know without knowing the exact source content, a luxury that a UGC platform like Twitch does not have. For this reason just doing heuristics with WebGL is often the "best" path to detecting bad actors when it comes to decoders.
rasz 5y ago
incidentally part of my anti fingerprinting script looks like this let UNMASKED_RENDERER_WEBGL = ["ANGLE (AMD Radeon HD 7900 Series Direct3D11 vs_5_0 ps_5_0)", "ANGLE (Intel(R) HD Graphics 4000 Direct3D11 vs_5_0 ps_5_0)", "ANGLE (Intel(R) HD Graphics 4600 Direct3D11 vs_5_0 ps_5_0)", "ANGLE (Intel(R) HD Graphics 520 Direct3D11 vs_5_0 ps_5_0)", "ANGLE (Intel(R) HD Graphics 530 Direct3D11 vs_5_0 ps_5_0)", "ANGLE (Intel(R) HD Graphics Family Direct3D11 vs_5_0 ps_5_0)", "ANGLE (NVIDIA GeForce GTX 960 Direct3D11 vs_5_0 ps_5_0)", "ANGLE (NVIDIA GeForce GTX 1070 Direct3D11 vs_5_0 ps_5_0)", "ANGLE (NVIDIA GeForce GTX 760 Direct3D11 vs_5_0 ps_5_0)"] those were the most popular desktop GPUs according to Steam a year or two ago.
- x775 5y ago
  Would you be willing to share this script?
  - stevehawk 5y ago
    nice try NSA
  - gruez 5y ago
    Don't bother. It's hard to do it correctly. If you look through the snippets (or the MDN docs[1]), the value is retrieved using the getParameter() function. You might be tempted to override the function by doing something like gl.getParameter = () => "test" but that's easily detectable. If you run gl.getParameter.toString() You get back "() => "test"" whereas the original function you get back "function getParameter() { [native code] }" In general, don't try to fix fingerprinting via content scripts[2]. It's very much detectable. Your best bet is a browser that handles it natively. [1] https://developer.mozilla.org/en-US/docs/Web/API/WEBGL_debug_renderer_info https://developer.mozilla.org/en-US/docs/Web/API/WEBGL_debug... [2] https://palant.info/2020/12/10/how-anti-fingerprinting-extensions-tend-to-make-fingerprinting-easier/ https://palant.info/2020/12/10/how-anti-fingerprinting-exten...
jefftk 5y ago
Agreed: fingerprinting is using ways one browser or device consistently differs from others to derive a stable identifier. Several others on this list are also not used for fingerprinting, and are instead detecting robots/spam/abuse. Unfortunately, there isn't any technical way for the public to verify that, because client-side all it looks like is collecting a bunch of high-entropy signals. All the major browsers have said they intend to remove identifying bits to where fingerprinting is not possible, which will also make these other uses stop working.
- AlotOfReading 5y ago
  That was always a short-term hack anyway. The limiting case is that spammers simply pay humans somewhere to continue whatever "abuse" was formerly automated, as currently happens with captchas.
  - thu2111 5y ago
    Almost all spam is not profitable enough to pay humans to do every step manually, so if you make it that expensive, it's the same thing as winning.
javajosh 5y ago
JavaScript legitimately needs to know about it's runtime environment. The problem with fingerprinting is not the act of examining the environment itself, but rather sending the results of that examination to the server as a form of identification. I would rather confront the second problem more directly with a "per tab Little Snitch" type solution that eliminates communication that is not in the user's interest, rather than eliminate fingerprinting, for precisely the reasons you give, slashink.
- smolder 5y ago
  Unfortunately web apps can defeat that by bundling unwanted telemetry type stuff in with other API calls, directly or by batching. So, it would need to be a complex tool to deal with that or suffer limited applicability. Perhaps if it stayed under the radar it could be effective in many cases without instigating countermeasures by site owners.
  - javajosh 5y ago
    Let's not make perfect the enemy of good. Counter-measures like user-interactive, request specific firewalls (like Little Snitch) can always be defeated by a motivated malfactor willing to commmit resources. That does not mean it isn't worth doing. Consider that virtually all physical locks are trivial to pick by someone who knows how (see youtube.com/lockpickinglawyer), and yet we still use locks. Pickable locks improve security because they increase the cost to the attacker enough that it deters most attacks.
    - hnlmorg 5y ago
      The point is there isn't any extra cost nor difficulty in circumventing the checks you describe. You just run a library.
      - javajosh 5y ago
        I write webapps for a living. If a browser plugin wanted to selectively allow XHR/fetch calls based on payload, there is very little I could do about it. The implementation might be to have your plugin content script wrap the DOM XHR/fetch in a proxy. The proxy runs a predicate on the payload, and if true, lets it go through. The predicate would be something like "No PII", which would also imply that the traffic be unencrypted. An app could remove the proxy. But it seems to me that most people wouldn't bother. It's also possible that there are other mechanisms, for example a special Plugin IO API that cannot be changed by content scripts.
deleted 5y ago
[deleted]

nerdponx 5y ago

That said, surely this "functional" information can also be valuable fingerprinting data, no? What's stopping an enterprising data science team from pulling it into their data lake, using to build ad models for logged-out users, maybe submitting it to 3rd-party machine learning vendors, etc. and generally making it undeletable?

kjrose 5y ago

This is interesting. I can see how it could have legitimate uses to get around bad inplementations with stating what capabilities are possible. However that being said it's like fingerprinting to sort out what their system really has. Still an abuse of the system.

nerdponx 5y ago
As per my sibling (cousin?) comment, pretty much any legitimate capability-determining data can be used for fingerprinting. This can only be solved with legislation, IMO. There is no way for an industry to self-regulate something like this, the candy bowl too big and the candy too sweet.
- throwawgler87 5y ago
  To make fingerprinting illegal, you mean? Or were you thinking of some other way to solve the problem with regulation?
  - nerdponx 5y ago
    More like (the spirit of) GDPR, where data collection itself becomes a legal and financial liability to point where it's not worth it to collect and retain it for a typical entity.
- difosfor 5y ago
  Yeah, I think the world would be better off without ads altogether. Just allow people to search for what they need or want by themselves, that's enough.
  - nine_k 5y ago
    ...and pay out of pocket for the use of a search engine? Why, well, I'd do that; e.g. neeva.com is accepting sign-ups. Also, ads without personal targeting, much like dead-trees newspaper / magazine ads, could still work and prop up certain web publishers.
    - tjpnz 5y ago
      >...and pay out of pocket for the use of a search engine? That's the only way service providers will see a cent from me going forward. Ads present not only a privacy risk but they're increasingly becoming a security risk too. I will not allow them on any of the devices I own or that connect to my home WiFi.
      - nine_k 5y ago
        I think that static ads served from the first-party CDN are security-wise no worse that the content itself. Blocking scripts and requests by third-party ad networks makes complete sense from security perspective, though. Affiliate links going directly to relevant item pages in a store are fine by me, too. They have to be relevant for anyone to click on them, they don't play video or make sound, etc. They do give some tracking opportunity, but without third-party cookies and third-party requests, it's hard to achieve anything resembling the privacy-invading precise tracking which current ad networks routinely do. In any case, I much more prefer the absence of AWS and an honest donation button.
slashink 5y ago
That's a fair take. In a sense it's is a "fingerprinting" method although I personally think fingerprinting embodies using this data to track devices between contexts. If you're interested why this data was exposed in the first place, the MDN docs has good info https://developer.mozilla.org/en-US/docs/Web/API/WEBGL_debug_renderer_info https://developer.mozilla.org/en-US/docs/Web/API/WEBGL_debug... . "Generally, the graphics driver information should only be used in edge cases to optimize your WebGL content or to debug GPU problems." Sadly that's the reality of some of these tools. The intent was good and in many cases they are a necessity to create a web experience that works on every device. On the flip side this allows people to use this data to fingerprint.

kjeetgill 5y ago

... but that is sorta fingerprinting, right? Atleast, inferring a user's device capabilities via WebGL is hardly using WebGL. I think it's a beautiful, legitimate use — but I can't fault the author for labeling fingerprinting.

jeffgreco 5y ago
Is fingerprinting not trying to uniquely identify a user?
- calhoun137 5y ago
  Since there is no way to 100% fingerprint a device, therefore there is no way to uniquely identify anyone with 100% confidence using pure fingerprinting techniques. My view is that fingerprinting is a set of tools which can be used for "good or evil" if that makes sense. If you are gathering meta-data to determine the capabilities of the device, then this is part of the wider framework of data points which can, in principle, be used for fingerprinting a user. This data can be imported into a completely different system by a sophisticated adversary, so it needs to be treated as a security vector, imho
  - salawat 5y ago
    >Since there is no way to 100% fingerprint a device, therefore there is no way to uniquely identify anyone with 100% confidence using pure fingerprinting techniques. Pedantic point, so forgive me, but 100% uniquely identifying a device does not imply 100% uniquely identifying the user of the device. We call them User-Agents for a reason. Anyone could be using it. It's critical people not fall into the habit of conflating users and user-agents. Two completely different things, and increasingly, law enforcement has gotten more and more gung-ho about surreptitiously forgetting the difference. Ad networks and device/User-Agent based surveillance only makes it worse. There are several initiatives to implement UUID's for devices. There is the Android Advertising ID, systemD's machine-id file, Intel burns in a unique identifier into every CPU. IPv6 (without address randomization) would also work as a poor man's UUID. It's frighteningly easy, and you'll be surprised how unintentionally one can be implementing something seemingly innocent and end up furthering the purposes of those seeking to surveil.

tmpz22 5y ago

So absolutely no data on the device obtained via webGL is used for marketing or other BI workloads? None of it is shared with 3rd parties (especially advertisers)? Its entirely used for the user experience and then discarded when no longer relevant? FWIW while I'm playing hardball here I really appreciate your answer and expertise.

Ensorceled 5y ago
> FWIW while I'm playing hardball here I really appreciate your answer and expertise. You’re actually just outright accusing them of lying.
- djrogers 5y ago
  Do you see those question marks? Those denote questions. Questions are not accusations.
  - wizzwizz4 5y ago
    Tell that to Socrates.
  - itsananderson 5y ago
    Have you stopped beating your wife? Edit: this is the typical example of a loaded question, not an actual accusation against the parent comment https://en.m.wikipedia.org/wiki/Loaded_question https://en.m.wikipedia.org/wiki/Loaded_question
  - jameshart 5y ago
    Really? never? So when did you stop beating your wife?
    - II2II 5y ago
      I understand the point you are trying to make, with the question incorporating an accusation (i.e. that the person beat their wife in the past). That is different from asking pointed questions about potential actions (e.g. "have you ever beat your wife?").

Arnavion 5y ago

I'm curious if something like [1] would work for those SoCs, eg ask if it supports "video/mp4-liar-liar-pants-on-fire-from-twitchtv" [1]: https://devblogs.microsoft.com/oldnewthing/?p=40663 https://devblogs.microsoft.com/oldnewthing/?p=40663

slashink 5y ago
Good question! So the problem here is a bit different. It's not that devices will say "I can play Format X" and then not play it. It's that devices say "I can play Format X at Resolution A, B, C". When you give the device resolution A and B it succeeds but at resolution C it fails to decode it. In H.264 this would be the "Level" https://en.wikipedia.org/wiki/Advanced_Video_Coding#Levels https://en.wikipedia.org/wiki/Advanced_Video_Coding#Levels . A device may say that it can decode Level 4.2 but in reality it can only do 4.1. That means it can play back 1080p30 but not 1080p60. The only way to know is to actually try and observe the failure (which often btw is a silent failure fro m the browsers point of view, meaning you need to rely on user reports).
- greggman3 5y ago
  Wouldn't it be just as easy to test videos in formats A, B, and C and see if the play? You could check that video.currentTime advances. If it lies about that you could draw to a canvas and check the values. That seems more robust than checking WebGL.
  - slashink 5y ago
    Also a good question. The issue here is the architectural difference between the hardware decoder and the GPU. What happens under the hood with MSE ( https://developer.mozilla.org/en-US/docs/Web/API/Media_Source_Extensions_API https://developer.mozilla.org/en-US/docs/Web/API/Media_Sourc...) is that you are responsible for handing off a buffer to the hardware decoder as a bitstream. Underneath, the GPU sets up a texture and sends the bitstream to the hardware decoder that's responsible for painting the decoded video into that texture. What often ends up happening is that the GPU driver says "yes the hardware decoder can do this", it accepts the bitstream, sets up the texture for you which is bound against your canvas in HTML. Starts playing the video, moves the timeline playhead but the actual buffer is just an empty black texture. From the software's point of view, the pipeline is doing what it's supposed, due to the hardware decoder being a black box from the Javascript perspective it's impossible to know if it "actually" worked. Good decoders will throw errors or refuse to advance the PTS, bad decoders won't. Knowing this, your second suggestion was to read back the canvas and detect video. That would work but the problem here is "what constitutes working video". We can detect if the video is just a black box but what if the video plays back but at 1 frame per second, or plays back with the wrong colors. It's impossible to know without knowing the exact source content, a luxury that a UGC platform like Twitch does not have. For this reason just doing heuristics with WebGL is often the "best" path to detecting bad actors when it comes to decoders.

rasz 5y ago

incidentally part of my anti fingerprinting script looks like this let UNMASKED_RENDERER_WEBGL = ["ANGLE (AMD Radeon HD 7900 Series Direct3D11 vs_5_0 ps_5_0)", "ANGLE (Intel(R) HD Graphics 4000 Direct3D11 vs_5_0 ps_5_0)", "ANGLE (Intel(R) HD Graphics 4600 Direct3D11 vs_5_0 ps_5_0)", "ANGLE (Intel(R) HD Graphics 520 Direct3D11 vs_5_0 ps_5_0)", "ANGLE (Intel(R) HD Graphics 530 Direct3D11 vs_5_0 ps_5_0)", "ANGLE (Intel(R) HD Graphics Family Direct3D11 vs_5_0 ps_5_0)", "ANGLE (NVIDIA GeForce GTX 960 Direct3D11 vs_5_0 ps_5_0)", "ANGLE (NVIDIA GeForce GTX 1070 Direct3D11 vs_5_0 ps_5_0)", "ANGLE (NVIDIA GeForce GTX 760 Direct3D11 vs_5_0 ps_5_0)"] those were the most popular desktop GPUs according to Steam a year or two ago.

x775 5y ago
Would you be willing to share this script?
- stevehawk 5y ago
  nice try NSA
- gruez 5y ago
  Don't bother. It's hard to do it correctly. If you look through the snippets (or the MDN docs[1]), the value is retrieved using the getParameter() function. You might be tempted to override the function by doing something like gl.getParameter = () => "test" but that's easily detectable. If you run gl.getParameter.toString() You get back "() => "test"" whereas the original function you get back "function getParameter() { [native code] }" In general, don't try to fix fingerprinting via content scripts[2]. It's very much detectable. Your best bet is a browser that handles it natively. [1] https://developer.mozilla.org/en-US/docs/Web/API/WEBGL_debug_renderer_info https://developer.mozilla.org/en-US/docs/Web/API/WEBGL_debug... [2] https://palant.info/2020/12/10/how-anti-fingerprinting-extensions-tend-to-make-fingerprinting-easier/ https://palant.info/2020/12/10/how-anti-fingerprinting-exten...

jefftk 5y ago

Agreed: fingerprinting is using ways one browser or device consistently differs from others to derive a stable identifier. Several others on this list are also not used for fingerprinting, and are instead detecting robots/spam/abuse. Unfortunately, there isn't any technical way for the public to verify that, because client-side all it looks like is collecting a bunch of high-entropy signals. All the major browsers have said they intend to remove identifying bits to where fingerprinting is not possible, which will also make these other uses stop working.

AlotOfReading 5y ago
That was always a short-term hack anyway. The limiting case is that spammers simply pay humans somewhere to continue whatever "abuse" was formerly automated, as currently happens with captchas.
- thu2111 5y ago
  Almost all spam is not profitable enough to pay humans to do every step manually, so if you make it that expensive, it's the same thing as winning.

javajosh 5y ago

JavaScript legitimately needs to know about it's runtime environment. The problem with fingerprinting is not the act of examining the environment itself, but rather sending the results of that examination to the server as a form of identification. I would rather confront the second problem more directly with a "per tab Little Snitch" type solution that eliminates communication that is not in the user's interest, rather than eliminate fingerprinting, for precisely the reasons you give, slashink.

smolder 5y ago
Unfortunately web apps can defeat that by bundling unwanted telemetry type stuff in with other API calls, directly or by batching. So, it would need to be a complex tool to deal with that or suffer limited applicability. Perhaps if it stayed under the radar it could be effective in many cases without instigating countermeasures by site owners.
- javajosh 5y ago
  Let's not make perfect the enemy of good. Counter-measures like user-interactive, request specific firewalls (like Little Snitch) can always be defeated by a motivated malfactor willing to commmit resources. That does not mean it isn't worth doing. Consider that virtually all physical locks are trivial to pick by someone who knows how (see youtube.com/lockpickinglawyer), and yet we still use locks. Pickable locks improve security because they increase the cost to the attacker enough that it deters most attacks.
  - hnlmorg 5y ago
    The point is there isn't any extra cost nor difficulty in circumventing the checks you describe. You just run a library.
    - javajosh 5y ago
      I write webapps for a living. If a browser plugin wanted to selectively allow XHR/fetch calls based on payload, there is very little I could do about it. The implementation might be to have your plugin content script wrap the DOM XHR/fetch in a proxy. The proxy runs a predicate on the payload, and if true, lets it go through. The predicate would be something like "No PII", which would also imply that the traffic be unencrypted. An app could remove the proxy. But it seems to me that most people wouldn't bother. It's also possible that there are other mechanisms, for example a special Plugin IO API that cannot be changed by content scripts.

deleted 5y ago

[deleted]