I'm all for anti-fingerprinting, but i'm also for interactive graphics on the web, and getImageData() is essentially your way of accessing a pixel buffer... I would be better if it was more conditional.
e.g instead gate the call that ultimately attempts to send any derivatives of that data over the network - although I understand that may entail significant complexity in the JS engine. Alternatively, gate getImageData() only if fingerprintable context methods have previously been called, i.e those with antialiasing, compositing, blending differences etc or any other rendering method with potential differences emerging from the underlying algorithm. That way someone just trying to use the pixel buffer as an output doesn't get punished by needlessly causing modals to be thrown in front of the user.
> interactive graphics on the web, and getImageData() is essentially your way of accessing a pixel buffer
I'm sure it's a great feature when you need it, but most websites have no legitimate need for it. Having this sort of feature off/blocked by default and whitelisted on a case-by-case basis makes a lot of sense to me. Are you trying to use a webapp image editor? Makes sense to whitelist it. Are you trying to read a local newspaper article online? Keep that shit off by default.
In fact, that's how I treat even first-party javascript, because most websites are made worse by turning javascript on. It seems to follow a 90-9-1 rule; 90% of websites need no javascript, 9% need first-party javascript whitelisted, and 1% require some 3rd-party javascript.
The problem here is that the main audience impacted by these "permissions prompts" has zero idea whether what the site is requesting makes any sense.
You - as a developer - probably know that an image editing site might need this permission and other sites don't. The average user has zero (ZERO) clue.
They don't know, they don't really care. Instead they arbitrarily accept or deny based on how scary the popup text is, or how annoying it becomes, or how much they depend on the site.
Which is pretty terrible from all perspectives
- Users get prompts that require decisions that they don't have the knowledge or context for.
- Valid sites & businesses lose traffic because some users are scared away by scary sounding prompts that they don't understand.
- Malicious sites still get a broad swath of data on users who don't give a rats ass about the prompts and have been conditions to just always hit yes.
I think this style of implementation is basically always indicative of a failure.
I think that is basically why vista's UAC prompt is so hated. They jump on so many place may or may not relevant to user's safety. And users don't really have clue the request is valid or not. Ends up just accept everything or "ok google, how to disable the damn UAC propmt"
Whether or not you need it is tangential imo. People should be able to experience cool interactive visuals on websites without sacrificing their privacy
I wonder whether introducing slight per-pixel-per-draw noise into the values could be used here, to mask this sort of detail? Or would you be able to average it out somehow
In general noise is never the answer to fingerprinting. It makes gathering "accurate" data a little harder; it doesn't stop statistical analysis from revealing the truth.
This totally works as an approach! Brave does it for canvas data and a bunch of other web APIs as well. The "farbling" noise is deterministic per profile/origin combo to prevent being able to average it out across multiple page loads, but otherwise random.
If you own hundreds of domains, you're welcome to try, but there's no good reason to. Fingerprinting scripts rely on a canvas being identical between sessions to identify that the same user is even there in the first place. If you can already single out one user's activity across a hundred domains, you don't need to fingerprint them any further.
how do you ensure the noise doesn't change between calls? if I want to fingerprint how the letter "a" is rendered, how do you ensure that I can't try drawing "a1", "a2", "a3", etc. which are "different" draw calls, but still allow me to build a composite image of what "a" looks like?
I think you're right on both... adding noise would reduce the accuracy of the fingerprint, but boarder biases would continue to be detectable. For instance i'm aware of some quite significant biases between firefox and chrome in antialiasing fillRect() for subipixel values as the dimensions drop bellow 1x1 pixel that only a distracting amount of noise would be able to conceal for one sample. I know that's already detectable via the useragent string, but I suspect those who are focused on collecting those biases will find strong ones for other data points.
I've also encountered problems with getImageData(). I just want to be able to blit a sprite sheet for god's sake. It would be tolerable if there were a couple pre-defined functions that could handle blitting, compositing and other operations, and return an HTMLImageElement with the same permissions as the source.
The problem I forsee with getImageData() and gl.readPixels() is that despite all this security, it's possible that it leaks some data through the openGL implementation, like with a spectre/meltdown type attack. Like imagine there is some cached data on the GPU that lingers between draw calls, I don't know.
What do you mean "by default"? Unless you have resistfingerprint enabled (not the default), webgl/canvas should behave as expected. If you're the type of developer that takes offense to this (ie. the user agent acting in a manner that the user would like it to act), I think that's going too far for you as a developer, and would only lead to the dominance of your competitor ;)
The problem starts when the user has not been educated about the potential drawbacks of enabling such a feature. The privacy.resistFingerprinting option is the leading cause for angry Firefox users and unwarranted negative reviews on my part, despite being an obscure feature that can only be enabled from config.
Things will break in unexpected ways, while web developers are the ones expected to spend their time offering support for a browser that has been rendered broken.
They need to be very careful about how these features are presented, and evaluate how they affect the entire web ecosystem.
>They need to be very careful about how these features are presented, and evaluate how they affect the entire web ecosystem.
It's hidden behind an about:config option (rather than being in the settings page), and the linked article literally says "It is likely that it may degrade your Web experience so we recommend it only for those willing to test experimental features". What more do you want?
Inform users when they silently pass garbage through web APIs such as HTMLCanvasElement.toDataURL(), when it happens. And the UX of that should also be very carefully considered.
Otherwise you might end up with some critical document scans on a government website being uploaded as striped nonsense images without your knowledge, and the "may degrade your Web experience" that you glanced over a year before when you enabled the option may not cut it when your Visa application is delayed or rejected.
> Otherwise you might end up with some critical document scans on a government website being uploaded as striped nonsense images without your knowledge, and the "may degrade your Web experience" that you glanced over a year before when you enabled the option may not cut it when your Visa application is delayed or rejected.
I use a different (from my regular privacy optimized) unmodified browser for such websites and use cases.
While this is clearly not a perfect solution, I also subscribe to the adage[0], that “perfect is the enemy of the good”[1]
>Inform users when they silently pass garbage through web APIs such as HTMLCanvasElement.toDataURL()
>[...] when your Visa application is delayed or rejected.
Isn't that what the prompt (pictured in the article[1]) is for? It doesn't always show up, but AFAIK it only does that when the page tries to grab canvas data before the user has interacted with the page. For a page where you're uploading documents, that seems unlikely.
It can auto decline the canvas request and return fake image data from the API by default when privacy.resistFingerprinting is enabled. privacy.resistFingerprinting.autoDeclineNoUserInputCanvasPrompts must be set to false to always show the popup, and even then they shouldn't serve fake data when the user declines the request, but throw an error for the API call.
>It can auto decline the canvas request and return fake image data from the API by default when privacy.resistFingerprinting is enabled. privacy.resistFingerprinting.autoDeclineNoUserInputCanvasPrompts must be set to false to always show the popup
Right, it can auto-decline it in certain circumstances. As the name suggests, it auto-declines it when there there isn't any user input. That seems fairly reasonable to me, and is unlikely to cause issues with you uploading documents for a visa application (you need to interact with the site to upload the document in the first place). That said, I was playing around with it using various codepen demos and discovered that even if you interacted with the page, if the page was in an iframe it would always not show the popup. That might cause issues in certain circumstances and I do hope it will get fixed.
>and even then they shouldn't serve fake data when the user declines the request, but throw an error for the API call.
Whether that's the best approach is debatable. For the use case of uploading a document, I agree that would be the best behavior, but for other cases (ie. it's trying to display something), an exception would likely crash the app. In many cases (eg. google maps), the garbage data doesn't interfere with my use of the app, and crashing the app would be far more disruptive.
A better UX should be "I'm sending this image instead of this one, because of fingerprinting. Are you OK with that? Yes, No send the original image this time."
This would prevent problems but I don't think it can cope with the number of requests in the normal flow of web browsing.
> A better UX should be "I'm sending this image instead of this one, because of fingerprinting. Are you OK with that? Yes, No send the original image this time."
I'm presuming you want the browser to somehow detect whether the garbage image data ends up in a POST request? I don't see how you can implement that in a reliable way, considering there are dozens of ways to go from canvas data to a POST request.
Give the settings page a "blog" (like the extensions page) describing each setting that has been changed manually in a way users can understand it so that they might learn the drawbacks and can restore it.
People follow instructions from a web page that tell them how to change the about:config values. Then they forget what they've changed.
I just noticed there is a "Show only modified preferences" which is wonderful. It shows me uhh.. a few hundred things I haven't changed myself.
I really can't remember what I've changed.
(5 minutes later)
I remembered, last time I've looked the about:config right click context menu was replaced with the rather useless default webpage menu. Kinda funny as I was looking to disable dom.event.contextmenu.enabled
Putting "enabled" and "disabled" behind the preferences feels kinda silly. It would make more sense if the gui replaced true/false with disabled/enabled.
I'm all for anti-fingerprinting, but i'm also for interactive graphics on the web, and getImageData() is essentially your way of accessing a pixel buffer... I would be better if it was more conditional.
e.g instead gate the call that ultimately attempts to send any derivatives of that data over the network - although I understand that may entail significant complexity in the JS engine. Alternatively, gate getImageData() only if fingerprintable context methods have previously been called, i.e those with antialiasing, compositing, blending differences etc or any other rendering method with potential differences emerging from the underlying algorithm. That way someone just trying to use the pixel buffer as an output doesn't get punished by needlessly causing modals to be thrown in front of the user.