Open Bug 1422890 Opened 2 years ago Updated 7 months ago
Add additional Canvas Fingerprinting Tests
I believe there are four APIs we trigger the permission prompt for: - canvas.toDataURL - canvas.toBlob - canvas.mozGetAsFile - canvas.isPointInPath We should have a test case for each of them.
Whiteboard: [fingerprinting] → [fingerprinting][gfx-noted]
2 years ago
Priority: -- → P3
may be relevant ... getImageData, readPixels - see https://github.com/kkapsner/CanvasBlocker/issues/158#issuecomment-350355730
We do prompt for getImageData; we should make sure it has a test. readPixels seems like it's a WebGL thing. I wonder if Tor Browser hasn't addressed it, and if not, if it's because they make WebGL click to play (in all circumstances). That would mean it would be important for us to address: TB doesn't need us to do it by next ESR; but it is a hole in FF's RP pref. If so we should open a new bug about it specifically.
(In reply to Tom Ritter [:tjr] (OOTO until 1/4) from comment #0) > I believe there are four APIs we trigger the permission prompt for: > > - canvas.toDataURL > - canvas.toBlob > - canvas.mozGetAsFile > - canvas.isPointInPath > > We should have a test case for each of them. Two more are: - canvas.isPointInStroke (blocked RFP) - canvas.measureText (not blocked by RFP, but perhaps should be; see https://trac.torproject.org/projects/tor/ticket/13400) (In reply to Tom Ritter [:tjr] (OOTO until 1/4) from comment #2) > readPixels seems like it's a WebGL thing. I wonder if Tor Browser hasn't > addressed it, and if not, if it's because they make WebGL click to play (in > all circumstances). That would mean it would be important for us to > address: TB doesn't need us to do it by next ESR; but it is a hole in FF's > RP pref. If so we should open a new bug about it specifically. Yes, readPixels has not been addressed by Tor Browser. (Indeed I would prefer if we did address it in any case, even though WebGL is disabled via NoScript except where the user enables it per-site.) https://arthuredelstein.net/webgl/read-pixels-test.html
(In reply to Arthur Edelstein (Tor Browser dev) [:arthuredelstein] from comment #3) > (In reply to Tom Ritter [:tjr] (OOTO until 1/4) from comment #0) One more API I forgot that needs a test is: CanvasRenderingContext2D.getImageData()
see https://github.com/ghacksuserjs/ghacks-user.js/issues/429 While that issue with the extension CanvasBlocker is reolved (kaspner coded around it), it brings up an interesting point, that IsPointinPath (and IsPointinStroke) are not *protected* by RFP like toDataURL (and maybe the others) are. This was in FF60 I hope that makes sense. In other words, when RFP canvas is spoofed, it ideally would be immunized from further spoofing by extensions. I do not know how this fits in with Bug 1412961 (FF61+) and Bug 1453916 (FF62+). i.e if an extension requests the canvas, do nothing. If web content requests the canvas, RFP kicks in and locks out extensions modifying it. Excuse my lack of terminology re origins and principals
comment 0 (blocked by RFP) > canvas.toDataURL > canvas.toBlob > canvas.mozGetAsFile > canvas.isPointInPath comment1 > getImageData (blocked RFP as per comment 2) > readPixels (? WebGL thing? open a new ticket) comment3 > isPointInStroke (blocked RFP) > measureText (not blocked by RFP) not mentioned, Canvas API allows - getContext - fillTest That makes 10 items
Regarding isPointInPath being not protected: they are in the same way the others are. It was a coding difference in CanvasBlocker that caused the different behaviour.
Whiteboard: [fingerprinting][gfx-noted] → [fingerprinting][gfx-noted][fp-triaged]
You need to log in before you can comment on or make changes to this bug.