[tbb-dev] Canvas Breakage Ideas

[Alex Catarineu]

I'd also agree that uploading an image/file should not be taken as an implicit
permission for reading the canvas.

With respect to 1), I guess there are two parts:

1. Showing the canvas prompt if there was a file upload (recently?), even if
`privacy.resistFingerprinting.autoDeclineNoUserInputCanvasPrompts = false`.

2. UI changes so that it is suggested that the user reloads the page for the
changes to be effective.

For the first, I'm not sure if the use case is so prevalent that it justifies
having this edge case (show prompt if user has uploaded a file). But I think
it might be ok in practice, and I don't see any drawbacks (like cases where
users might be annoyed by this change).

For the second, I guess this belongs more to UX people. In my personal opinion,
I'm not sure the UI change is really justified, at least as described in
https://bugzilla.mozilla.org/show_bug.cgi?id=1633813. I don't think it's true
that a page reload is needed for the canvas permission changes to take effect
(in general). For example, in the WhatsApp case described in that bug it's
enough to reupload the file, without reloading the page. And reuploading the
file is needed in any case, even if you reload the page. I just don't know if
that's the suggestion that should be given to users in general after allowing
canvas permissions. Besides, would we show the reload suggestion after all
canvas accepts, or only those that were allowed thanks to the "file upload"
exemption?

---

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.

Tom wrote:
> So the question then is, it seems like given Tor's strict stance, the
> only way this could be implemented was if the data read from the
> canvas was an exact match on the uploaded data. Is that accurate?  If
> so, the next step would be to test these websites, because if they
> don't behave that way it's probably not worth implementing this at
> all.
Is it really needed to check that there is an exact match between the uploaded
image and read canvas data? Even assuming `drawImage` differs between devices,
*I think* it might be ok to allow canvas extraction if `drawImage` is performed
with an image uploaded from a user. I don't see how the data could be used as an
effective fingerprinting vector.

In any case, I think implementing this "fingerprinting-tainting" logic for
canvas, starting with the `drawImage` case, may be interesting to pursue.
This may also have privacy benefits for users in practice, since it can potentially
avoid having to give full canvas access for cases where it's not needed.
Of course, websites could always force canvas "fp-tainting", so that the only way
to unbreak them is to allow canvas extraction, but that's a different story I think.

Thanks,
Alex