- tbb-dev - lists.torproject.org

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

Rescheduling the Team Meeting on Monday, 11 November
by Matthew Finkel 08 Nov '19

08 Nov '19

Hello, This coming Monday is a company holiday (U.S. holiday). We probably shouldn't have a meeting on that day. I propose we reschedule it on Tuesday at 18:30 UTC. Please let me know (here or irc or telegraph) if this doesn't work for you. Thanks, and sorry for the late notice. - Matt

1 0

How to enable window.performance.timing on TBB
by Zhao Zhang 07 Nov '19

07 Nov '19

Hi there, Sorry I have a silly question, currently I'm preparing some timing analysis on TorBrowser and find that it looks like most of window.performance info has been disabled (I think, for security reasons). It returns all 0s for executing script "window.performance.timing", and returns empty [] for executing window.performance.getEntries(). I've looked through about:config, tried modifying devtools.dom.enabled;true dom.enable_performance;true but looks still no effect. So where is the proper way to enable performance timing? Thanks. Yours sincerely, Zhao Zhang

3 3

New Tor Browser Team Meeting Time
by Matthew Finkel 31 Oct '19

31 Oct '19

Hello! Due to North America and Europe[0] changing their timezones, we are changing the time at which we meet for the weekly Tor Browser Team Meeting. Beginning this Monday (04 November, 2019), we'll begin meeting at 18:30 UTC, in #tor-meeting2. Some specific timezones are documented on the Application team wiki page[1], as well (please correct the local times if they are wrong). See some of you at the meeting! Matt (sysrqb) [0] Some places in some of the countries on the continents. [1] https://trac.torproject.org/projects/tor/wiki/org/teams/ApplicationsTeam#Co…

1 0

Fwd: [Mozilla Enterprise] Moving Firefox to a faster 4-week release cycle!
by Georg Koppen 22 Sep '19

22 Sep '19

FYI: Georg -------- Forwarded Message -------- Subject: [Mozilla Enterprise] Moving Firefox to a faster 4-week release cycle! Date: Fri, 20 Sep 2019 13:16:53 -0700 From: Ritu Kothari <rkothari(a)mozilla.com> To: enterprise(a)mozilla.org We’re excited to announce <https://hacks.mozilla.org/2019/09/moving-firefox-to-a-faster-4-week-release…> that we’re adjusting Firefox release cadence to increase our agility, and to bring you new features more quickly. Starting Q1 2020, we plan to ship a major Firefox release every 4 weeks. Shorter release cycles provide greater flexibility to support product planning and priority changes due to business or market requirements. It allows us to be more agile and ship features faster while applying the same rigor and due diligence needed to ship a high-quality and stable release. *Major updates to ESR* (Extended Support Release <https://www.mozilla.org/en-US/firefox/enterprise/> for the enterprise) *will remain yearly, as they do now*. There will be a 3 months support overlap between new ESR and end-of-life of previous ESR version. The next two major ESR releases will be ~June 2020 and ~June 2021. This change will be deployed gradually starting with Fx71, achieving 4 week release cadence by Q1 2020. You can refer to https://wiki.mozilla.org/Release_Management/Calendar for the latest release dates and other information. As we slowly reduce our release cycle length, from 7 weeks down to 6, 5, 4 weeks, there will be close monitoring of aspects like release scope change; developer productivity impact (tree closure, build failures); beta code churn (uplifts, new regressions); overall release stabilization and quality (stability, performance, carryover regressions). Our main goal is to identify bottlenecks that prevent us from being more agile in our release cadence. Appropriate mitigations will be put in place should our metrics highlight an unexpected trend. If you have any questions or concerns, please email release-mgmt(a)mozilla.com Thanks, Ritu Kothari

1 0

Next weekly Tor Browser meeting on 9/3 1730 UTC in #tor-meeting2
by Georg Koppen 29 Aug '19

29 Aug '19

Hello! There won't be a meeting on next Monday, 9/2, due to a public US holiday. We therefore moved our weekly sync to 9/3 1730 UTC in #tor-meeting2. See you there, Georg

1 0