Open pes10k opened 3 years ago
The colour seems to be related to the underlying image, being the opposite colour
Guys, your "farbling" thing is a complete nonsense.
It is a task of a web browser to rasterize vector graphics into a Canvas correctly, according to standards. All browsers should rasterize vector graphics identically. So if one rasterizes it differently, than the other, there is a bug in one of them, and this bug should be fixed.
If your way of rasterizing vector graphics allows fingerprinting, you should fix it and make sure, that it is rasterized the same way always, on all devices, in all countries, during all weather conditions. Adding random noise is not a solution.
I guess if Math.sin() in Brave allowed fingerprinting, you would also add random numbers to the result of Math.sin().
It is a task of a web browser to rasterize vector graphics into a Canvas correctly, according to standards
I think there is a misunderstanding here. Farbling / randomization is not applied on rasterization. As long as you're just painting pixels in a canvas, Brave doesn't change a bit. Brave only applies randomization defenses when script tries to read pixels back out of the canvas. While I appreciate this can be frustrating for the rare apps that need to read pixels out of canvas (painting apps, mainly), the unfortunate truth is that this feature is used for fingerprinting purposes far more often than it is for user-serving purposes.
As mentioned above, its possible there is a bug in Brave's farbling implementation, and we're randomizing more than we intend. Its in our queue to investigate. But we're pretty happy with the privacy / functionality trade off we're making here modulo bugs.
All browsers should rasterize vector graphics identically. So if one rasterizes it differently, than the other, there is a bug in one of them, and this bug should be fixed.
If only! That would be a great thing, but how pixels get painted in a canvas is a mix of a wide range of inputs (graphical hardware, OS, system settings and user color preferences, etc). You might find https://hovav.net/ucsd/dist/canvas.pdf interesting (and the wide range of papers that cite it) if you'd like more background information. But the unfortunate truth is that making-all-instances-of-a-browser do the same thing is not possible, given the perf and HW accel decisions browsers have made, among other reasons.
I guess if Math.sin() in Brave allowed fingerprinting, you would also add random numbers to the result of Math.sin().
You might be interested in knowing that in some browsers Math.sin() actually is a fingerprinting vector, bc it leaks the floating point implementation the browser was built with (and whether floating point operations were done in HW vs SF). You might find discussion here of background interest: https://github.com/WebAudio/web-audio-api/issues/2061.
Reading pixels from a canvas is just as important feature, as painting into a canvas. If two browsers are real browsers (they work according to standards), they should return idetnical pixels from a canvas, without allowing any fingerprinting.
With an attitude like this, why doesn't Brave render all webpages at a resolution of 600 x 600 pixels? Different screen resolutions can also be used for fingerprinting.
This link https://hovav.net/ucsd/dist/canvas.pdf is a pseudo-science from ten years ago. If there are still differences between browsers aften ten years, it should be considered to be a bug and fixed by each browser.
Why is photopea blocked? I like brave for preventing fingerprinting, but painting web apps are then rendering images with random pixels. There should be an easy per website option to disable it.
There is an easy per website way to disable it. Either drop shields or change the fingerprinting setting in shields to “allow” and you’ll disable this protection for just this site
On May 7, 2022, at 18:41, Lukáš Kovář @.***> wrote:
Why is photopea blocked? I like brave for preventing fingerprinting, but painting web apps are then rendering images with random pixels. There should be an easy per website option to disable it.
— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.
So to reiterate, from Brave's perspective what Photopea should do here is:
1) Introduce "farbling" detection. 2) Upon successfully detected "farbling" in user's browser, prompt them to disable tracking prevention for the site to prevent unwanted visual noise. 3) Apologize the user for such nuisance, Brave developers for couple of slightly snarky comments and (optional) start working on fixing every single rendering engine to have pixel identical outputs on all systems, to prevent fingerprinting for once for all.
Is that correct?
wrt 1) IIUC something like detecting mismatch of two consecutive readings of two canvases constructed in the same way, or detecting deviations in readings of pixel columns of rendered "||||||" or horizontal of "–––––" in single canvas should suffice, I guess (?).
Is there any way to detect and warn users that things won't work because of their non-standard browser?
Sure, sites could check from navigator.brave
, and if it exists, say something Brave specific to the user and / or suggest they disable fingerprinting protections for the site
Why is photopea blocked? @brave
Why is photopea blocked? @brave
Probably for this:
your "farbling" thing is a complete nonsense. With an attitude like this, why doesn't Brave render all webpages at a resolution of 600 x 600 pixels? This link is a pseudo-science from ten years ago.
and referenced comments:
You can keep using Brave, if you like pain. Or you can switch to a normal browser, like MS Edge, Firefox, Safari, Chrome or Opera.
which is an even worse advice than switching off shields and get going.
Issue originally reported to Brave here: https://github.com/brave/adblock-lists/issues/638 And to the site here: https://github.com/photopea/photopea/issues/3704
Its surprising that there is so much visual noise