Yeah. I wanted a test page that could draw attention to things of interest (which specific API is blocked, whether there is obvious randomization going on, etc). FWIW, I edited my earlier message and posted version 1.6. I liked your dark theme too. I expected to see what you reported and I did. I noticed that the AMO page says: "CAUTION! Only version 0.3.0 works with e10s". I also noticed something else. The "Show notifications" option doesn't appear to work when loading my test page from file: or http://test.example/test.html where test.example is hosts file mapped to 127.0.0.1 and a localhost server. The readout is faked but no notification bar. Same result for my normal profile and a fresh portable app version. I do see the notification bar if I use the browser leaks test. Did you see a notification when using my test page (and CanvasBlocker block mode set to fake readout API)? EDIT: For testing purposes I added a ctx.getImageData() call to my code and afterwards CanvasBlocker started to show notifications. So I think notifications may not be triggered by all the calls that can extract canvas data. Exercising all of those wasn't my intention and I'm not sure how best to do it so I'm leaving getImageData() out for now. Also, while looking into that issue I took a look at data URLs. First example is "allow everything", second one is "fake readout API": Looks like the fake readout adds a little noise. At least when canvas.toDataURL() is used to extract data.
Oh thats just Stylish with the Global Midnight style. I hate being blinded by white backgrounds, so I have that for night browsing. I prefer darker themes anyways... No notification, but I get a notification using the browser leaks test same as you. Pretty small quirk overall though, especially since most people seem to want the canvas hash to change with each request (which I just dont understand).
@Anonfame1: I edited my post moments before you just replied. Did you catch the edit? Edit: Asking because the last thing was actually above the edit and not in your quote: I noticed that the (CanvasBlocker) AMO page says: "CAUTION! Only version 0.3.0 works with e10s".
I missed it on my last response, but saw you replied via notifications. Running the latest version of your code with both fake readout api and allow everything (a separate load of the test file for each setting), I dont see any additional noise on my end (on fake readout api). Since i'm running 1920x1080 resolution on a 15" display, I figured I should screenshot and zoom to see if I could see a difference- none that I can tell at all. I havent looked through your code (and im not too hot with html anyways) but did your last version (1.6) have canvas.toDataURL() still? I can clearly see in your screenshot the noise... Im still not getting notifications either but you said youre leaving that bit out so thats to be expected.
Are you looking at Canvas1 or are you copying its Data (data:image/png;base64, ...) and viewing that? I think you need to look at the latter because that is what is read out (and tampered with). Can you paste it into your address bar?
Unless I'm missing what you're saying, they look identical. What I did: first, I right click saved each image and viewed them blown up with gimp (I realized in the middle of this thats not what you were saying). I then took the data block from the page and pasted it into the address bar (for both the fake readout api and allow everything test loads)- the images loaded look identical. I did not restart the browser for both, but given multiprocess I shouldnt need to right? All the other settings change as soon as I change in the addon preferences... Ive got 20/20 vision and a color corrected screen, so either I'm an idiot or theres something different between our setup. What OS are you on (not that it should make a difference)? What version of FF?
OK, just posted 1.7. If the canvas data smells legit (starts with "data:image/png;base64,") then the word Data is turned into a link. Which when clicked will open the data: url in a new window. To make viewing easier. I just ran it on a Windows 7 FF 49.0.2 machine and get the same results. When the test page is allowed to read the canvas, it looks as it should... sharp. When set to fake readout API (happened to be non-persistent at the time) I get the noisy version. I can't say for sure you'll *notice* a difference but there *is* a difference if the fingerprints are different. That is the data that gets fingerprinted (hashed). So if the fingerprints don't match then the images don't match.
@Anonfame1: I forgot to quote you on my previous I see. Not why I'm replying again though. First of all, I'm not happy with myself for having encouraged you... particularly so tersely... to go copying and pasting that into your address bar. Many people have done that type of thing thinking it was safe advice, only to find out it wasn't. Under these particular circumstances I think it was safe and I did it myself. I hope and expect you made your own call before doing so. However, there could be scenarios where that isn't safe and it also sets a bad example. So I apologize for that, and want to encourage you to not let MY enthusiasm for tinkering/exploring lead you down the wrong path. Moving on, I dug a bit deeper and found myself heading down a road similar to what you described. FWIW, here is what I see. It is a 2-frame animated GIF alternating between the "allow everything" dataUrl and the "fake readout" dataUrl. I think you will have to click on it to see it in animated form. The registration is a bit off, but I never tried to do this before.
I looked at CanvasBlocker 3.1 source. It appears that the Random Number Generator: Persistent|Non-persistent setting affects not only persistence but also the randomization algorithm itself. It looks like the algorithm used for Persistent mode can only alter the least significant bit of a byte in the cavas image data. The canvas image data consisting of four bytes (r, g, b, and a) for each pixel times number of pixels. Whereas the algorithm used for Non-persistent mode produces greater magnitude changes to the bytes. IOW, in Persistent mode the changes are hard to see. In Non-persistent mode the changes can be quite easy to see. Both magnitude changes should be sufficient to alter fingerprinting that simply hashes all of the canvas image data. However, a fingerprinting routine could effectively ignore the least significant bit in each byte of image data when calculating a fingerprint. I'm thinking that the information conveyed by that least significant bit might not be necessary to capture the differences between canvas manipulations on different systems. IOW, I'm thinking that the alterations made in persistent mode may not be sufficient to protect against some types of canvas fingerprinting and tracking.
Its cool. I have Firefox sandboxed with Firejail, and further locked down with AppArmor. Beyond that, I also swapped out the profile with another after running the code. With all that failing, I have backups and a working Qubes install if **** really hit the fan. Given your time here, post count, and the fact you arent banned, I also made a bit of a social judgement call. Ive seen you post around, so I doubted you had done anything yourself. And it doesnt really matter, because my damn LUKS partition went foul a day later and I had to end up reformatting and rsyncing over my backup anyway- my fault :| Muffed up a command when creating more space for Qubes as it was nearly out of disk space That sucks. Well, I keep hoping Canvas Defender will fix their extension but that is seeming increasingly unlikely. I think Ill leave it in persistent anyways- I use Torbrowser for any random browsing anyways. My plain jane FF setup is only for a small list of sites I frequent now
@Anonfame1: Bummer about the partition, but welcome back! CanvasBlocker 0.3.2 was released November 3, 2016. I haven't looked at it yet, but I'm glad to see the project is alive.
CanvasBlocker 0.3.3 released. changes: - switching of the mode, white- and black-listing only affects new loaded pages new features: - auto close of the notifications (preference) - button to show the release notes fixes: - "about:"-tabs could not be dragged - performance issues
CanvasBlocker 0.3.4 Released. changes: - different fake modes show independent notifications fixes: - bug in readPixels (prevented google street view to work) - performance issues - German translations
CanvasBlocker 0.3.5 Released, but not much in the Release Notes. https://addons.mozilla.org/en-US/firefox/addon/canvasblocker/ Edit: Version 0.3.5 new features: - improved performance when canvas bigger than maxSize. fixes: - German translations - Fennec stopped working in version 50
I use canvas defender on Fx https://multiloginapp.com/how-canvas-fingerprint-blockers-make-you-easily-trackable/
Mentioned earlier in this thread. I was using it but ditched it for CanvasBlocker, also mentioned earlier (and why).
Ah, thread to big for me to go through, I find threads like these usually jammed with the same members arguing over methodology's and adding little of interest to me
To add my choice yes, not to ask if its useful or if it fulfills its use, as I have already said I don't read through these huge threads to see if I'm adding a software\addon that has already been added due to the immense amount of dribble
After starting Chrome with "--disable-reading-from-canvas" "Canvas toDataURL" is blocked but while visiting websites i don't see any number under icons (uMatrix or uBlock for example) I switched back to Canvas Defender.
CanvasBlocker 0.3.6 Released. changes: - only last bit of image values are changes also in non persistent mode - removed default entry in white list fixes: - faking webGL - added readPixels for webGL2 - removed error message when notification can not be closed - about:blank pages are treated with respect to the opening page - removed memory leak - persistent rnd same for all tabs/windows with e10s enabled
