tbb-dev March 2019

tbb-dev@lists.torproject.org

4 participants
9 discussions

Nightly rebase experiment proposal
by Arthur D. Edelstein 03 Feb '20

03 Feb '20

Hi everyone, Here's a plan for experimenting with moving Tor Browser from ESRs to mozilla-central. Why try this? There are several reasons I can think of: * There is no mobile Firefox ESR. In order to keep mobile Tor Browser secure, we would either need to constantly monitor for security fixes and apply backports. It will be simpler to follow the Mozilla release cycle. * Tor Browser will receive all security patches and security features from Mozilla, not simply those deemed important enough to backport to the last ESR. * Closer collaboration between Mozilla and the Tor Browser team will be possible, because everyone will be focused on the same codebase. For example, non-urgent patches can land directly on mozilla-central, bypassing tor-browser.git altogether, and those patches will be deployed to Tor Browser faster than they would have been on an ESR-only schedule. Mozilla will provide expert review of patches. Also, some non-urgent patches by Tor Browser may be written by Mozilla engineers. * The Tor Browser development process will be smoother and more gradual. Instead of rebasing and patch-fixing sprints ahead of each ESR, we can automatically rebase patches every night, and fix any patch whenever its rebase fails. (The total rebase effort should be approximately the same as before.) * Patches that frequently break because they live on "hot code" can be identified and uplifted. * We'll need to continuously monitor the mozilla codebase for new features that could harm privacy. That's potentially difficult, but by focusing on Mozilla's current work, we can hopefully stop patches that affect privacy before they land. Here's how I envision the new rebase process: * An automated script rebases all tor browser patches every night against mozilla-central, mozilla-beta, mozilla-stable and mozilla-esr. An email alert will be sent if the rebase of any patch fails. (I have a prototype script that does the basic rebasing -- it found that ~40/140 patches from our ESR-52 branch could be auto-rebased onto mozilla-central without any intervention.) * Any failed patches will need to be manually fixed up promptly so that the automated rebase can resume. * Diagnostic Tor Browser bundles will be built against the latest rebase branches. We can also run regression tests. So how do we ramp up this experiment? 1. 2018-1-1 to 2017-2-22: Rebase tor-browser.git patches manually on top of Firefox 59-beta. (We have to do this anyway.) 2. 2017-2-22 to 2018-3-13: Activate a script that rebases Tor Browser patches nightly onto mozilla-(central, beta, stable, esr). 3. 2018-03-13 to 2018-05-07: Create nightly Tor Browser bundle builds based on nightly rebases. At this point, we can evaluate whether we would like to transition to releasing Tor Browser alphas based on the mozilla-beta branch. Switching Tor Browser stable to mozilla-stable can happen sometime after that. How does this sound? Interested to hear what you think. Thanks, Arthur

7 12

proposal for #28044 (Integrate Tor Launcher into tor-browser)
by Mark Smith 19 May '19

19 May '19

A draft proposal for #28044 (Integrate Tor Launcher into tor-browser) is attached. Your feedback is welcome and appreciated! -- Mark Smith Pearl Crescent http://pearlcrescent.com/

4 8

Upcoming weekly meeting time change: from next week on 17:30 UTC
by Georg Koppen 25 Mar '19

25 Mar '19

Hi everyone! We'll switch our weekly meeting time to 17:30 UTC starting from April 1st (after the weekend where the EU is doing the daylight saving time thing, too). The location, #tor-meeting2 on the OFTC IRC network, is unchanged, though. See you there, Georg

1 0

Tor Browser 8.x and Letterboxing
by Georg Koppen 21 Mar '19

21 Mar '19

Hello! tjr asked during our last meeting whether we would consider testing Letterboxing[1] in Tor Browser even if it still were on ESR60. Here are a bunch of questions he had and we can think about in this thread: Q: If it was ready in a 60-based Alpha would you ship it then or would you want to wait until 68? I think we could easily test it in 9.x alphas being still on ESR60. This might in fact be a good idea as we got quite some pushback last time when we tried to fix #14429 (which, admittedly, has been a couple if years ago). One thing to worry about is how complicated the backport would be. If not really that problematic, then bonus points for that plan from my side at least. Q: What is the minimal viable product user experience wise? Q: Does the margin needed different color or watermark? I don't think so. Q: Do you need a button to disable it globally or after an individual resize? I'd be fine with a preference being exposed. Q: Do you need it to work on mobile? No. Q: For very low resolution - under 100 pixels in a dimension - does it need to do something intelligent or just not do any margins at all? I am not sure I understand the question, could you elaborate? Q: Does it need a user walkthrough explainer? (Probably I think... maybe you can start thinking of how that would look?) I think that sounds like a good idea. It could be another example for the general task of how to introduce new features (tracked in #29768). One idea could be that we want to have different strategies depending on how invasive a feature is: there might be features that are okay getting introduced with our onboarding and others that might need a different treatment. There are probably cons to this idea, though, like we would start training users to look at different places for getting to know whether there are new features or not. But on the other hand, we probably don't want to put everything into the onboarding either... Georg [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1407366

2 2

CAPTCHA in TBB vs Tails
by airtel＠cock.li 20 Mar '19

20 Mar '19

Hi I have noticed this behavior for some time already. If I boot into a Live Linux, download TBB and use Google, I will encounter reCAPTCHA for c.89% of the time. If I boot into Live Tails, use the installed TBB, I have yet to encounter any reCAPTCHA for Google Search. Anyone has the same issue, as the former reCAPTCHA requires ~10-15 puzzles to solve for each visit? -- Sunil

1 0

A proposal for verifying http downloads
by Tom Ritter 14 Mar '19

14 Mar '19

Third of three. This one is definitely the least fleshed out. The short version is verify most types of files downloaded over a potentially insecure connection. -tom

1 1

A proposal for stopping users from copying potentially-edited cryptocurrency addresses
by Tom Ritter 14 Mar '19

14 Mar '19

The second of three proposals. This one basically stops the user from copying a cryptocurrency address to the clipboard if the address was delivered in a way the exit node could have tempered with it. -tom

1 1

Firefox/NoScript bug with major downstream effects
by Erik Moeller 11 Mar '19

11 Mar '19

Dear TBB developers, I wanted to make sure you've seen this issue regarding uploads and NoScript's "Sanitize cross-site suspicious requests" option: https://bugzilla.mozilla.org/show_bug.cgi?id=1532530 https://github.com/hackademix/noscript/issues/64 https://github.com/freedomofpress/securedrop/issues/4078 https://github.com/micahflee/onionshare/issues/899 As far as we've been able to tell, this option, which is enabled by default and intended to guard against XSS attacks, is causing large uploads in non-JS upload forms to break intermittently. This may ultimately be due to a bug in Firefox itself (the first link). The only reason the SecureDrop and OnionShare issues are closed is that we've implemented ugly workaround instructions for now, and NoScript considers it an upstream issue in Firefox. Since this impacts Tor browser users much more than Firefox users, perhaps some folks on this list may be able to help bring this to a resolution. In any case, I wanted to flag it to this group given the impact his issue is having. Warmly, Erik -- Principal Project Manager Freedom of the Press Foundation

2 5

A Proposal for Double-Checking self-signed certificates
by Tom Ritter 07 Mar '19

07 Mar '19

Attached is one of three user safety proposals I'm trying to write. This one in particular deals with self-signed and similar certificate errors, and basically double checks the cert over a new circuit. If they match, the user can bypass the certificate error page. If they don't, they can't bypass it. -tom

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

tbb-dev March 2019