tbb-dev July 2020

tbb-dev@lists.torproject.org

5 participants
4 discussions

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

Updated Tor Browser Signing Key
by Matthew Finkel 22 Jul '20

22 Jul '20

Hello everyone, The Tor Browser (OpenPGP) Signing Key is expiring soon. We extended the expiration dates of the long-term key (+5 years) and the current subkey (+5 months). We usually rotate onto a new subkey at this time, but we'll do that later this year at a less critical and crazy time. I'm attaching the update key for everyone, so you don't need to fight with keyservers. Let me know if you have any questions. - Matt

1 0

reconsider shipping uBO or enabling ETP?
by gunes acar 17 Jul '20

17 Jul '20

Hi all, I was wondering if Tor Browser team is open to reconsider shipping an adblocker or turning on Firefox's Enhanced Tracking Protection (ETP) mode, and whether you need some research input that may inform that decision. I am aware of issue #17569 and I agree with most of the arguments laid out in the "No filters" part of the design doc. Especially that the list-based approaches would not improve TB's existing privacy protections with respect to curtailing online tracking. However, tracking protection/adlocking also have significant performance benefits [1, 2], which is the main reason why I'm bringing this up. Just to find out whether there could be potential performance benefits of shipping uBO with TB, I did a quick crawl of sites from the Trexa list [3] using TB with and without uBlock Origin (uBO) installed. Having uBO *reduced the median page load time by 27.6%* (from 7.6s to 5.5s) on top 1K sites. You can imagine there would be a similar reduction in the network footprint due to blocked requests. Another reason why it may be timely to reconsider this issue is that today all major browsers except Chrome ship a built-in adblocker or tracking protection mode (Safari, Firefox, Edge, Opera, Brave...). So, Tor Project may not really stand out for "damag[ing] the acceptance of Tor users by sites"[4] by blocking ads. I and some colleagues could be interested in dedicating some research time into studying the potential privacy and performance impact of adding adblockers or enabling ETP mode -- esp. if the JIT issue (#23719) makes uBO and other addons infeasible. Can you let us know if there's willingness to reconsider shipping an adblocker/ETP, and if so what research may help you with your decision? Best, Gunes [1] http://www.ieee-security.org/TC/SPW2015/W2SP/papers/W2SP_2015_submission_32… [2] https://dl.acm.org/doi/pdf/10.1145/3366423.3380292 [3] https://github.com/mozilla/trexa [4] https://2019.www.torproject.org/projects/torbrowser/design/#philosophy

5 6

HTTP2+self-signed certificates
by juanjo 11 Jul '20

11 Jul '20

Hello, We all know HTTP2 is faster than HTTP1, the downside for Onion sites is that it requires encrypted connections by default. Getting TLS certificate validation for onion sites is very hard and impossible for some people. I wanna ask how Tor Browser behaves if you enable HTTP2 with a self-signed certificate? Do you get a warning like on a normal website? If so, could TB change this behavior so onion sites can enable HTTP2 easier for faster webpages?

2 3

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

tbb-dev July 2020