On Wed, Apr 29, 2020 at 01:07:40PM +0200, Alex Catarineu wrote:
With respect to 2), I think it's interesting, but I also don't know whether it's feasible in practice. Specifically, I was thinking of Gijs idea of trying to keep state about whether the canvas is safe to read or not, fingerprinting-wise. I assume that there is a (non-empty) subset of canvas write operations that are "fingerprinting-safe". Probably a bit naively, I'd like to think that `canvas.drawImage` is "fp-safe" (irrespective of the image source). But even if we have to check the image source, I think implementing this could potentially unbreak some of these common legit canvas use cases.
For example, in the WhatsApp case mentioned above, I'm quite sure it's just used for image format conversion, since the bug does not occur when uploading "jpeg" images. So, that would be something like `canvas.drawImage(pngImage, 0, 0);` plus `canvas.toDataURL('image/jpeg');`, which should be covered if we implement the `canvas.drawImage` exemption when the image was uploaded by the user. This "fingerprinting-tainting" canvas logic might start with just the `drawImage` case, but perhaps it would be possible to extend little by little, if we know that some canvas write operation is safe and can help fixing breakage for legit use cases.
I generally agree with your message, but I am curious about this idea. Are you saying that ctx.drawImage() is fingerprinting-safe, or are you saying that any "canvas extraction" from a canvas element initialized by ctx.drawImage is fingerprinting-safe? As far as I'm aware, drawImage() is not protected by the Canvas prompt (so that should never be a problem). If your comment was about "subsequent canvas extraction", then that is worth investigating. Are any of the conversions passed onto the GPU? Do we know if format conversation is deterministic?