January 2020 - tbb-dev - lists.torproject.org

Re: [tbb-dev] [tor-packagers] torbrowser: problems with 9.0.1 source tarball
by Nicolas Vigier 17 Mar '20

17 Mar '20

Hi! I think the best list to discuss Tor Browser build problems is the tbb-dev(a)lists.torproject.org list, so I'm anwsering there. On Fri, 15 Nov 2019, Thomas Klausner wrote: > Hi! > > I wanted to build firefox-tor-browser-68.2.0esr-9.0-1-build2 > (torbrowser 9.0.1) on NetBSD from the source tarball, but I stumbled > over a couple problems. > > The first one, .mozconfig contains --disable-eme but configure doesn't like it: > > mozbuild.configure.options.InvalidOptionError: --disable-eme is not available in this configuration > > Is this a NetBSD-specific issue or more general? In our linux, windows, macOS .mozconfigs we have the line: ac_add_options --disable-eme But I don't remember seeing this error, so it looks NetBSD-specific. > The second one: > > --- begin --- > The error occurred while processing the following file: > > /scratch/security/tor-browser/work/firefox-tor-browser-68.2.0esr-9.0-1-build2/browser/extensions/moz.build > > The underlying problem is we referenced a path that does not exist. That path is: > > /scratch/security/tor-browser/work/firefox-tor-browser-68.2.0esr-9.0-1-build2/browser/extensions/tor-launcher/moz.build > > Either create the file if it needs to exist or do not reference it. > --- end --- > > > The directory browser/extensions/tor-launcher does not exist in the > tarball, which looks like a problem with the tarball to me. This is a change from this ticket: https://trac.torproject.org/projects/tor/ticket/28044 So you can either download tor-launcher, and extract it under browser/extensions, renaming the tor-launcher-$version directory to tor-launcher: https://dist.torproject.org/torbrowser/9.0.1/src-tor-launcher-0.2.20.2.tar.… https://dist.torproject.org/torbrowser/9.0.1/src-tor-launcher-0.2.20.2.tar.… Or you can build without tor-launcher by adding "ac_add_options --disable-tor-launcher" to the .mozconfig. Nicolas

5 6

How Tails is special in its use of Tor Browser
by intrigeri 18 Feb '20

18 Feb '20

Hi, we've improved our documentation about how Tails is special in its use of Tor Browser: https://tails.boum.org/contribute/design/#tor-browser I hope it helps your team keep our "special needs" in mind :) If anything is unclear, please let me know. Cheers!

3 3

Proposal process improvements
by Georg Koppen 15 Feb '20

15 Feb '20

Hello! We had been talking about potential improvements to our proposal process back at our meeting in Stockholm. We should not drop that topic (even though it looks like we did :) ) and I thought it would be smart to have a further discussion per email. To recap: Tor Browser proposals are a way to think about large/impactful browser features in a more formal way, including all stakeholders. That is, by describing those new features, what motivates them, the pros/cons, potential security/privacy issues etc. The idea is to both have a proposal to better reason about complex improvements and to document what we actually did. The proposal process started in September 2018[1] borrowing heavily from the Tor proposal process, although adapting it to Tor Browser needs. Re-reading my notes from our retrospective session it seems folks would like to see that we think differently about proposals and their lifetime and suggested specifically that Tails' blueprint system could help here. I remember not really understanding the different ways between how we think about proposals now vs. how we should. So maybe we should try to spell those perceived differences out to get a better understanding about what is lacking (it might be helpful to use actual proposals for illustration). An additional way to move the discussion forward might be to get to a common understanding about how the Tails' blueprint system works and how it could be adapted to our needs. Georg [1] https://lists.torproject.org/pipermail/tbb-dev/2018-September/000914.html

2 1

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

fission meeting notes
by Richard Pospesel 28 Jan '20

28 Jan '20

What fission is and why we do it: multi-process model of gecko change currently: each tab in own processes fission: each 'origin' within a tab has own process ie 1st party domain in one, iframes loading 3rd party things in another why? unclear if 1st-party domains in multiple tabs are same proc for security, helping sandbox untrusted code from ads, etc help mitigate spectre, meltdown, things of this nature better security through process boundary woop woop possibly better performance, but primarily security concerns driver here Architecture: cross-process Navigation DocumentChannel load starts in one proc, but we don't know where it will end (ie which content process loaded contnet needs to be run in) Session History thing that allows forward/back navigation global thing per tab currently lives in the content process fission: moved to parent process since so child content can access it (not landed yet) invisible change to consumers Remote WindowProxy needed for accessing 'windows' (like iframes) which now live in different procs should be an invisible change to consumers chrome code can no longer use 'x-ray vision' to change internal thingies Browsing Context and Window Context nsIDocShellTreeItem cannot be used post-fission world as things are corss-proc relevant methods renamed with 'InProcess' 'InChildAt' suffixes WindowContexts like BrowsingContext, but not persistent across navigation SyncedContext handles syncing of context state IPC Browsing Context Group 'closure' of all reachable browsing contexts list of all 'reachable' browsing contexts Syncing state: FIELD macro allows for syncing state between contexts, implication that it is SAFE to share data between contexts CanSet, DidSet methods can be overwridden If you do not implement CanSet, then procs will all have write access by default Do not add new state to nsDocShell determine if state needs to survive navigation if so use BrowsingContext if not use WindowContext Do not need to necessarily check principles everywhere if a browser context does not have a principle, that implies it is different from yours JS Window Actors registered in a few places (damn you fast slides) grep for JSWindowActorChild/JSWindowActorParent Window Actors only receive messages from their child/parent so don't need to namespace your messages (ie: Foo:FunMessage becomes FunMessage) Schedule MVP start 2021 until then feature-based milestones M5 -> Nightly dogfoodable with fission M6 -> Enable for small % of Nightly users Contacts: Dev Lead: Nika Layzell <nika(a)mozilla.com> #fission channels on Slack and Matrix Q&A: Will fission be mandatory when everything is finished? -> Short story Yes, Long story No We're not going to add a 'make my security worse' button to about:preferences for users Basically we can't expect process allocation model to be as described above on all platforms Android for instance has a cap on # of procs Also constrained platforms in terms of memory so lots of procs might suck Interesting fact, on android chromium isolates based on login credentials existing (ie if you have credentials for a site then it should be in its' own proc) tldr: don't write code with the assumption that the implmentation details are exaclty as described What are the potential perf benefits? Parellelism (duh) tldr; it's complicated (in ways you'd expect from talking about multi-process perf) so i won't go into every point in these notes, but it's *potentially* a win for some scenarios interestingly, switching tabs is faster as we only have to wait for the top-level content process to finish painting, so child iframes we don't have to wait to finish Question about security principles and some discussion about it: Don't spray principles around everywhere anymore The general assumption now for objects that if you don't have access to a thing, then you are not allowed to read/write it To test fission: prefs: fission.autostart gfx.webrender.all Links: docs: https://firefox-source-docs.mozilla.org/dom/Fission.html

1 0

Tor Browser Team Meeting This Week
by Matthew Finkel 20 Jan '20

20 Jan '20

Hello team! Today is a U.S. holiday, so we should reschedule this week's team meeting. Let me know if tomorrow at 18:30UTC does not work for you. If I don't hear about conflicts then I'll see you then :) Thanks, Matt

1 0

Fwd: Fwd: Introducing the W3C Privacy Community Group
by Richard Pospesel 17 Jan '20

17 Jan '20

-------- Forwarded Message -------- Subject: Fwd: Introducing the W3C Privacy Community Group Date: Fri, 17 Jan 2020 10:37:02 -0800 From: Tanvi Vyas <tanvi(a)mozilla.com> To: browser-privacy-workshop(a)googlegroups.com Just in case some of you are not on the w3c lists this was sent to, here are the details of our new Privacy Community Group. Thanks! ---------- Forwarded message --------- From: *Erik Anderson* <Erik.Anderson(a)microsoft.com <mailto:Erik.Anderson@microsoft.com>> Date: Fri, Jan 17, 2020 at 10:30 AM Subject: Introducing the W3C Privacy Community Group To: public-privacy(a)w3.org <mailto:public-privacy@w3.org> <public-privacy(a)w3.org <mailto:public-privacy@w3.org>>, public-privacycg(a)w3.org <mailto:public-privacycg@w3.org> <public-privacycg(a)w3.org <mailto:public-privacycg@w3.org>>, public-webappsec(a)w3.org <mailto:public-webappsec@w3.org> <public-webappsec(a)w3.org <mailto:public-webappsec@w3.org>> Cc: Tess O'Connor <eoconnor(a)apple.com <mailto:eoconnor@apple.com>>, Tanvi Vyas <tanvi(a)mozilla.com <mailto:tanvi@mozilla.com>> Hi,____ __ __ We're very happy to announce the creation of the Privacy Community Group <https://privacycg.github.io/>. The group will work on proposals for new privacy-focused web platform features intended to be widely implemented in browsers, and will also work on modifications of existing web platform features aimed at improving user privacy on the web.____ __ __ If that sounds interesting to you, please join us <https://www.w3.org/community/privacycg/join>! We welcome participation from browser vendors, privacy advocates, web application developers, and other interested parties.____ __ __ We'll primarily conduct our work in various GitHub repositories <https://github.com/privacycg/>, and we will also have regular teleconferences and face-to-face meetings.____ __ __ Our first **kickoff telecon** will be on Thursday, January 23rd at noon EST (9 AM PST, 5 PM UTC). The agenda may be found here:____ https://github.com/privacycg/meetings/blob/master/2020/telcons/01-23-agenda… __ __ After the kickoff, we will meet the 2nd and 4th Thursday of every month. Call-in details will be posted in our meetings repository <https://github.com/privacycg/meetings/>, and are also listed below.____ __ __ Warm regards,____ Erik Anderson ____ Theresa O’Connor ____ Tanvi Vyas____ __ __ __ __ Join Zoom Meeting____ https://isoc.zoom.us/j/120054739____ __ __ One tap mobile____ +16699006833,,120054739# US (San Jose)____ +16465588656,,120054739# US (New York)____ __ __ Dial by your location____ +1 669 900 6833 US (San Jose)____ +1 646 558 8656 US (New York)____ Meeting ID: 120 054 739____ Find your local number: https://zoom.us/u/acFNApXL9t____ __ __ For minutes: https://cryptpad.w3ctag.org/code/#/2/code/edit/ZrkcuhmVbx1OGyWlTX5L0j8T/____ __ __ -- You received this message because you are subscribed to the Google Groups "browser-privacy-workshop" group. To unsubscribe from this group and stop receiving emails from it, send an email to browser-privacy-workshop+unsubscribe(a)googlegroups.com <mailto:browser-privacy-workshop+unsubscribe@googlegroups.com>. To post to this group, send email to browser-privacy-workshop(a)googlegroups.com <mailto:browser-privacy-workshop@googlegroups.com>. To view this discussion on the web visit https://groups.google.com/d/msgid/browser-privacy-workshop/CALC7Gs5BtG2LA9y… <https://groups.google.com/d/msgid/browser-privacy-workshop/CALC7Gs5BtG2LA9y…>. For more options, visit https://groups.google.com/d/optout.

1 0

Idea: hidden service in tor browser
by arj03＠pm.me 12 Jan '20

12 Jan '20

Hi The browser is a great platform target because it is cross platform and with all the changes coming to browsers it is easier and easier to write applications that can have the same functionality as desktop applications. This includes P2P applications and this is where I think the tor browser can really shine, because if it would be possible to create hidden services inside the browser, then it would be possible to build applications where the nodes are communication directly with each other. I know that there are security implications of running a browser and a hidden service in the same process. I'm wondering if it might be possible to create this hidden service for only a specific tab (and site)? Maybe the security could be improved further by make it so this tab could only create tor connections outgoing connections? These applications are already there. Shameless link[1] to own app, which is a secure scuttlebutt (SSB) application where messages are gossipped between peers, running in the browser. SSB desktop clients can already run over tor, by using the deamon as proxy so it would be quite natural fit for this. [1]: https://github.com/arj03/ssb-browser-demo

3 2