- tbb-dev - lists.torproject.org

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

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

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