[tbb-dev] Canvas Breakage Ideas

[Sanketh Menda]

Alex: thanks for your thoughtful comments.

--[ Response to comments on (1)

> 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).

I think a lot of people use WhatsApp Web (at least on Firefox) and, in the short
term, this seems to be a nice way to unbreak it without turning off RFP or setting 
`privacy.resistFingerprinting.autoDeclineNoUserInputCanvasPrompts = false`.

> Besides, would we show the reload suggestion after all
> canvas accepts, or only those that were allowed thanks to the "file upload"
> exemption?

I was thinking after all canvas accepts. But, first, you're right, one does not
need to reload the page to be able to extract data from the canvas. Reloading is
nice because it is a silver bullet and handles all edge cases where a request
might already have been made.

--[ Response to comments on (2)

I really like the "fingerprinting-tainting" idea. Perhaps it would be worthwhile
to implement this behind a default-off pref and conduct a study (and, of course,
try to attack it.)

Tom: What do you think?

Best,
Sanketh

?On 2020-04-29, 7:08 AM, "tbb-dev on behalf of Alex Catarineu" <tbb-dev-bounces at lists.torproject.org on behalf of acat at torproject.org> wrote:

    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
    _______________________________________________
    tbb-dev mailing list
    tbb-dev at lists.torproject.org
    https://lists.torproject.org/cgi-bin/mailman/listinfo/tbb-dev