June 2020 - tbb-dev - lists.torproject.org

Re: [tbb-dev] Canvas Breakage Ideas
by Alex Catarineu 21 Sep '20

21 Sep '20

On 5/19/20 6:02 AM, Matthew Finkel wrote: > 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. Yes, by fingerprinting-safe I meant the subsequent canvas extraction after a `drawImage`. And by checking the image source I meant that we might consider a `drawImage` fp-safe if we know the input is an image uploaded by the user, even if `drawImage` was not "fingerprinting-safe" in general (with the idea that canvas extraction might not result in useful fingerprinting in that case). > Are any of the conversions passed onto the > GPU? Do we know if format conversation is deterministic? True, I did not consider that the extraction (e.g. `toDataURL('image/jpeg')`) might add some entropy by itself. Good questions, we would need to investigate if this approach is going to be pursued. And I agree with tom, it would be good first to investigate what these sites are doing exactly with the canvas to evaluate what would be the best approach.

5 10

Re: [tbb-dev] Tor Browser: Re-enable 'javascript.enabled' on safest security level?
by analord＠secmail.pro 22 Jun '20

22 Jun '20

Hi Georg, can you tell me more about this supposed bug? I tried to find it but couldn't. Would be interested in investigating it myself. Greetings, Richard

2 1

Tor Browser: Re-enable 'javascript.enabled' on safest security level?
by analord＠secmail.pro 01 Jun '20

01 Jun '20

Hey, as far as I know, javascript.enabled was disabled by default on the safest security level due to an issue with NoScript not blocking scripts when it should have in certain cases. As far as I know, this issue has been fixed on the latest NoScript version. To me it would make sense to revert the change disabling javascript.enabled by default and use a tight NoScript permissions list by default on the safest security level, so users such as myself can decide to whitelist sites that require JavaScript through the NoScript panel, instead of having to open about:config and changing it manually. Thoughts? P.S: Excuse the posts to the other mailing lists, apparently I can't read and couldn't find the right mailing list. But eh, more exposure I guess..

2 1