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