tbb-dev September 2018

tbb-dev@lists.torproject.org

4 participants
8 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

"Peeling the Onion’s User Experience Layer: Examining Naturalistic Use of the Tor Browser"
by David Fifield 21 Sep '18

21 Sep '18

Kevin Gallagher posted his et al.'s paper on Tor Browser UX on the ux list. https://lists.torproject.org/pipermail/ux/2018-September/000427.html Some user quotations you may appreciate: Several participants perceived using the Tor Browser as a learning experience. For instance, some Tor Browser warnings made them aware of threats to anonymity they had not previously considered, such as HTML5 canvas data, window maximization, etc. “I really enjoyed that when you resize the Tor window, it notifies you that, while you may choose to do so, it actually makes your device more vulnerable. I had no idea that this was an issue and was very pleased that Tor let me know this.” – (P11, F, unspecified age, write-up) Similarly, participants found it illuminating to consult the circuit information, which many felt was well-presented and useful. “One really cool tool that Tor offers is the map of where the IP address is being rerouted — seeing that the circuit is being bounced around back and forth to other countries.” – (P1, M, 22, write-up) “I loved that I was able to see the circuit that the browsing session was being routed through and how it bounced around different countries.” – (P5, F, 19, write-up)

1 0

Tor Browser proposals
by Georg Koppen 21 Sep '18

21 Sep '18

Hi all! Some of you asked me about a more formal process to reason about implementing complex features, possibly with different teams involved. Or just documenting new and untested ideas more formally, easier accessible for everyone. I added a proposals dir[1] for that, borrowing heavily from the Tor proposal process. 001-process.txt explains what this is all about and the first two proposals made it already in. I think that's a good start, but we probably can fine-tune this whole idea and process to fit more into our workflow and to our needs. Let me know what you think and which changes we should make. Georg [1] https://gitweb.torproject.org/tor-browser-spec.git/tree/proposals

1 0

No meeting on 9/24
by Georg Koppen 20 Sep '18

20 Sep '18

Hi! Just a reminder that we won't have our weekly Tor Browser meeting on Monday 9/24. We'll have enough meetings that week and the one after it that we skip this one. See you all in Mexico, Georg

1 0

Spoofing Window Dimensions without Letterboxing
by Arthur D. Edelstein 20 Sep '18

20 Sep '18

Hi everyone, I have been discussing options for mitigating viewport-dimension fingerprinting with the Mozilla uplift team and I came up with a proposal for a non-letterboxing approach that might have some advantages over letterboxing: https://docs.google.com/document/d/1Pww4_gY59SPIK5dMxJchpevPs-MeeY5_mkxAKZd… Maybe this is something we can discuss in Mexico City. I'd be interested to hear your thoughts. Thanks, Arthur

1 0

Pad for State of the Onion talks
by Georg Koppen 18 Sep '18

18 Sep '18

Hi! I created a pad where we can share ideas for the State of the Onion talks during our dev meeting: https://pad.riseup.net/p/G6ToSghBgWhG I added an idea and some steps how to get there. I am happy if we want to focus on something else instead. Georg

1 0

Future Tor Browser for Android milestones
by Georg Koppen 12 Sep '18

12 Sep '18

Hi all! Our first alpha for Tor Browser for Android is about to go live and we could have a short meeting about the big picture for the things to come until we call it stable. I outlined my thoughts in https://pad.riseup.net/p/nlhgUPXcS8SK. Please add things I forgot or rearrange them. I think our MUST and SHOULD format went well for the first alpha which is why I kept it. Georg

1 2

Tor Browser 8.0 Retrospective
by Tom Ritter 11 Sep '18

11 Sep '18

<mozilla hat> Hey Tor, Can we have a retrospective on the 8.0 release and how things went from an uplift perspective? What was good (hopefully the windows build had few hiccups?), bad (reviewing networking code), unexpected bugs (permission+canvas patch interaction), etc? We can do it over irc if that's preferable, and I'd suggest doing it similar to the existing meetings where we add to the pad before-hand). Timing-wise, ideal time would probably be 8 AM PDT / 3 PM UTC. Any later than that and it will be too late for the Berlin folks; any earlier and it'll be too earlier for the Pacific folks. But if that time doesn't work, we could still push it later in the day. When doesn't matter much. Sometime in the next few weeks? Maybe it would be better to do it in Mexico City? (Only disadvantage is I won't be there (and I have the most context on the MinGW build stuff...) I want us to figure out how we can make subsequent releases of Tor Browser much easier. -tom

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

tbb-dev September 2018