tbb-dev August 2020

tbb-dev@lists.torproject.org

9 participants
7 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

Release schedule for the Tor Browser alphas?
by anonym 27 Aug '20

27 Aug '20

Hi, I'm in the process of scheduling a release candidate for Tails 4.11 and I'd like it to include the latest possible Tor Browser 10 alpha, so I'm interested in what your plans are for the coming weeks (especially around September 7-11, which likely is when we have to release this release candidate). Do you have any dates set yet? Guesses? Is there a (public) schedule I can look at somewhere so I don't have to ask you in the future? :) Otherwise, do you think we'll miss out on anything important to test if we ship the current 10.0a5 in the release candidate? Cheers!

2 2

Deriving identity public key from
by Konstantin Y. Rybakov 23 Aug '20

23 Aug '20

Dear developers, How can I derive an identity public key given onion secret key in form of: |ED25519-V3:UJL1wgWVeMz9f7oM+Xrbq0i8tJ2/aeBi3K0cl8VCrlicSts8Gg98agO5DUXHjsfQb+yooLgN0CB0Y0A9U0rMUQ==| ? I assume that a secret key is 64 bytes long, and identity public key is last 32 bytes of decoded private key. So, my algorithm is as follows: |base64Decode(privatekey) //without ED25519-V3: part ||slice resulting buffer in half ||base32Encode(second half of the buffer)| As a result I expect to see first 52 characters of corresponding onion address, but I see totally unrelated random string instead. I've already tested the part that converts a public key into onion address as per tor/src/test/hs_build_addres.py, that part is working. The problem is that I derive wrong identity public key from the secret key. ||Thank you! ||

1 0

Nightly builds based on Firefox 78 ESR and beyond
by Georg Koppen 19 Aug '20

19 Aug '20

Hello! Some of you might have seen that our Tor Browser nightly builds for desktop switched to Firefox 78 ESR recently. We've been waiting with a more or less official announcement until we got our nightly setup into a more stable shape, but believe now is a good time to call for wider testing. If you already were on the nightly channel before reading this mail you have likely already got an update to Tor Browser using ESR 78[1], but alas only one, due to a bug we overlooked[2]. So, the easiest way to solve that particular problem is to save your bookmarks and start over again with a fresh nightly build.[3] Any nightly build after August 2, 2020 should be good. For those of you not already being on the nightly channel and willing to test the latest Tor Browser work, just grab the latest nightly[3] and enjoy the auto-updater to keep you up-to-date[1], which makes this bleeding-edge series so more useful. Please report bugs as you find them, ideally in our bug tracker[4], but we are happy to receive them via other channels, too. We currently plan to release a first Tor Browser 10 alpha based on Firefox 78 ESR in about two weeks from now, making sure the toolchains[5] are in the shape we want them to be for the stable release and the audit for potential proxy bypass bugs is done[6] (and issues encountered are addressed). Those two items are the hard blockers for that first alpha but it goes without saying that we try to squeeze as many bug fixes as we can into that alpha as well. :) As I indicated at the beginning of this mail the above plan and status update is only for our desktop Tor Browser. For mobile we are still busy to get the switch to Fenix going and announcements for (wider) testing of Tor Browser on that platform will be sent out separately. Thanks, Georg [1] With the caveat that we currently only provide auto-updates for en-US, de, es-ES, fr, and ru locales. [2] https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/4… [3] http://f4amtbsowhix7rrf.onion/tor-browser-builds/ [4] https://gitlab.torproject.org/users/sign_in [5] See: https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/3… and child bugs for issues we are aware of right now [6] https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/40017

3 4

langpacks tarball vs alpha/nightly builds
by anonym 19 Aug '20

19 Aug '20

Hi, list! [I'd prefer to do this over Gitlab MR, but my request for an account hasn't been accepted yet. So email it is.] Back when intrigeri added the generation of a tarball containing all langpacks it was decided to not do so for nightly and alpha builds, and to revisit if we decided we wanted it for those builds too: https://trac.torproject.org/projects/tor/ticket/32676#comment:6 Now I'd like to revisit that decision! Let's first note that Firefox' translation system is pretty fragile (e.g. missing string => scary exception pop-up + broken functionality) which we have been bitten by a few times (i.e. we released something broken for some non-en_US locales). So testing is essential! Not having these langpacks tarball has the following negative consequences for Tails: * Nightly builds: when a new Tor Browser major release is in the works, we prefer to start the integration work for Tails as early as possible, preferably starting no later than when the first build based on a new ESR is out (the changes in upstream Firefox is often a cause for problems on our side). This sometimes mean we need to use your nightly builds, like was the case for this 10.x cycle. Not having the langpacks mean that we only get to test the en_US locale, and thus our automated tests for the other locales will fail in our CI. I don't really have a problem with that failure spam, but it would be very sweet to know whether the basic functionality we automatically test for non-en_US locales work already at this stage. * Alpha builds: The same problem as for nightly builds apply, but with an addition: before we release the Tails that will contain the major release of Tor Browser, we release a Tails release candidate with the last Tor Browser alpha (which is the best we can reasonably do at that stage). But if that alpha does not have langpacks, then the Tails testers can only test en_US, so we have no clue about the other locales. Actually, the first time we'll have all the langpacks will be when we release the final stable Tails with the final stable new major release of Tor Browser, which is too late. So, can we please enable the generation of the langpack tarball for alpha and nightly builds? It seems it will only bloat each build ~15MB, which looks insignificant. Any other considerations? If you agree with my proposal, I believe the attached patch implements it. Cheers!

2 3

request from a reporter
by isabela 06 Aug '20

06 Aug '20

Hello TBB dev list :) we got an email from a reporter asking how TB protects the user against a series of tracking mechanisms. I was hoping I could 'crowdsource' the answer and use your help with it, here is the email: https://pad.riseup.net/p/t2_CyOhC_G3FiCvRXugx Thank you in advance! cheers, isabela -- Isabela Bagueros Executive Director The Tor Project https://www.torproject.org http://expyuzz4wqqyqhjn.onion/

2 2

Adding defenses against keystroke and mouse stylometry into TBB
by joel04g_t535e＠secmail.pro 03 Aug '20

03 Aug '20

Does Tor browser have any defenses against mouse and keystroke stylometry, if not could some be implemented? It can be as simple as adding an add-on that you can turn on or off. I think this would add extra protection against invasive websites who attempt to identify users. Users could also disable this if the website isn't working or requires a captcha which thinks they are a bot. -Joel

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

tbb-dev August 2020