[tbb-dev] Canvas Breakage Ideas
sysrqb at torproject.org
Tue May 19 04:02:49 UTC 2020
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?
More information about the tbb-dev