- tbb-dev - lists.torproject.org

Updating TB and Orfox for Meltdown and Spectre?
by Nathan Freitas 08 Jan '18

08 Jan '18

Not sure if there is an open ticket I should be monitoring, or a meeting I missed, but just saw the Firefox update to address Meltdown and Spectre: https://www.mozilla.org/en-US/firefox/57.0.4/releasenotes/ Are Tor Browser and Orfox vulnerable these attacks? Has this been covered somewhere else? Thanks, and just figuring out if my week ahead is going to be spent on an urgent Orfox release or not! +n

3 5

Cloudflare's OPRFs
by Jeff Burdges 08 Jan '18

08 Jan '18

I wrote to the Taler list <taler(a)gnu.org> about certificate concerns with CloudFlare's OPRFs but never informed you guys. https://blog.cloudflare.com/privacy-pass-the-math/ I'll re-edit the relevant email from 10 Nov 2017 below: There are shades of a "bug door" in [CloudFlare's] no certificates arguments : - "The only thing edge to manage is a private scalar. No certificates." - The edge's public key xG is "posted publicly [similar] to a Certificate Transparency Log [and] "verifiable by all users and so the deanonymization attack above would not be possible." In other words, there is no plan for the Tor Project to control any certificate authorizing the edge's public keys, ala an auditor key in Taler. There aren't even any promises made about any particular certificate transparency scheme being employed to keep edges from employing unique keys. I think their client software could track the public keys they see themselves easily enough, but if different edge servers use different keys then this becomes mostly useless. If for example the transparency log posts 256 keys supposedly used concurrently by 256 different edge servers, but secretly all edge servers used all keys, then your edge public key adds 8 bits of identifying information, but nothing looks suspicious in the transparency log. I do think a certificate transparency scheme could address this concern, but it's not exactly what one normally means by certificate transparency. Jeff

2 1

Crowdsourcing (more) guidelines for what it means to make a web site "Tor-friendly"
by Allen Gunn 05 Jan '18

05 Jan '18

Hello friends, After checking with GeKo, I'm cross-posting this request from tor-project earlier this week. It's both FYI, and I'm also hoping that folks on this particular list might have a minute or two to contribute your tbb-specific knowledge... So for those who aren't aware, my NGO, Aspiration, advises other NGOs and activists on technology as part of our core mission. And a common piece of advice we proffer is "make sure your web site works well with Tor Browser", i.e., doesn't use Flash or overly depend on Javascript. The more I have given that advice, the more I have wondered if it was documented anywhere what it actually takes to be a "Tor-friendly" site. Big thanks to GeKo, who first confirmed for me that no such documentation seems to exist. And then for helping me to bootstrap this page: https://pad.riseup.net/p/torfriendlysite We've gotten some decent input from the tor-project responses, but I think there is likely more to be captured... I'm writing to ask folks on this list to both add any thoughts you have on the matter, and to correct or comment on anything that's already there and doesn't seem quite right. Any contributions, both to the pad or emailed to me directly, are most appreciated. This is especially true if you know of relevant documentation anywhere else that I should be looking at. Once folks have weighed in, I will figure out where to post this on the Tor wiki and elsewhere in order to make it more broadly and reliably available. And if for any reason you think this is an ill-informed endeavor, I welcome that feedback as well :^) thanks & peace, gunner -- Allen Gunn Executive Director, Aspiration +1.415.216.7252 www.aspirationtech.org Aspiration: "Better Tools for a Better World" Read our Manifesto: http://aspirationtech.org/publications/manifesto Twitter: www.twitter.com/aspirationtech

1 0

Fwd: Announcing the next Extended Support Release of Firefox - ESR60 with policy engine
by Tom Ritter 23 Dec '17

23 Dec '17

---------- Forwarded message ---------- From: Sylvestre Ledru <sylvestre(a)mozilla.com> Date: 20 December 2017 at 09:42 Subject: Fwd: Announcing the next Extended Support Release of Firefox - ESR60 with policy engine To: "dev-platform(a)lists.mozilla.org" <dev-platform(a)lists.mozilla.org>, mobile-firefox-dev <mobile-firefox-dev(a)mozilla.org> Hello, Earlier today, we announced on the enterprise ML several changes to ESR. First, as Dave Camp mentioned during the Firefox All Hands, we are started some developments to improve our support for enterprise users. More information can be found on the wiki: https://wiki.mozilla.org/Firefox/EnterprisePolicies Second, we will branch ESR from 60 instead of 59. This will give us more time to work on the Enterprise policies. Also, In parallel, this means that we will have more time to delete old/dead code before branching. As a disguised advertisement, I am using this email to remind that Marco Castelluccio's tool https://marco-c.github.io/code-coverage-reports/ is your best friend to find dead code [1]. Last but not least, we also warned our enterprise users that ESR52.9 (EOL August 28th) will be the last release supporting legacy add-ons. The wiki and the ESR FAQ have been updated: https://wiki.mozilla.org/RapidRelease/Calendar https://www.mozilla.org/en-US/firefox/organizations/faq/ Sylvestre PS: Also, for people on these two MLs who are still using Windows XP, you'll get a few more weeks to update ;) [1] meta bug https://bugzilla.mozilla.org/show_bug.cgi?id=1415819 -------- Forwarded Message -------- Subject: Announcing the next Extended Support Release of Firefox - ESR60 with policy engine Date: Wed, 20 Dec 2017 14:06:57 +0100 From: Sylvestre Ledru <sylvestre(a)mozilla.com> To: enterprise(a)mozilla.org <enterprise(a)mozilla.org> The Firefox ESR (extended support release) is based on an official release of Firefox desktop for use by organizations including schools, universities, businesses and others who need extended support for mass deployments. Since Firefox 10, ESR has grown in popularity and many large organizations rely on it to let their employees browse the Internet securely. We want to make customization of Firefox deployments simpler for system administrators and we’re pleased to announce that our next ESR version, Firefox 60, will include a policy engine that increases customization possibilities and integration into existing management systems. What is the policy engine? The Policy Engine is a project to build a Firefox desktop configuration and customization feature for enterprise users. The policy engine will work with any tool that wants to set policies and we intend to bring Windows Group Policy support soon. We’ll be initially supporting a limited set of policies but this will be evolving through user feedback. More details on the policy engine can be found here. <https://wiki.mozilla.org/Firefox/EnterprisePolicies> Bug reference <https://bugzilla.mozilla.org/show_bug.cgi?id=1419102> What’s the plan? In order to accommodate the group policy implementation, we are making Firefox 60 our next ESR version and will be following this plan: * May 8th - ESR 60.0 released (we’d love feedback from early adopters at that point and will be sharing a feedback form through the enterprise mailing list) * July 3rd - ESR 60.1 released * August 28th - End of life for ESR 52 and release of ESR 60.2.0. No further updates will be offered for ESR52 and an update to ESR60.0.2 will be provided through the application update service Also please keep in mind that Firefox 57, released last month, supports only add-ons built with theWebExtensions API <https://developer.mozilla.org/en-US/Add-ons/WebExtensions>. This means that Firefox 52 ESR is the last release that will support legacy add-ons. If you developed an add-on that has not been updated to the WebExtensions API, there is still time to do so.Documentation <https://developer.mozilla.org/en-US/Add-ons/WebExtensions/Porting_a_legacy_…>is available, and you can ask questions by emailing dev-addons(a)mozilla.orgor joining the #webextensions channel atirc.mozilla.org <http://irc.mozilla.org>. If you are supporting users who use add-ons, now is a good time to encourage them tocheck if their add-on works <https://support.mozilla.org/en-US/kb/frequently-asked-questions-firefox-add…>with Firefox 57+. Erin, Felipe, Jeff, Kev, Mike Kaply, Romain, Shell & Sylvestre _______________________________________________ dev-platform mailing list dev-platform(a)lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform

3 3

XUL Tor Launcher EOL?
by anonym 13 Dec '17

13 Dec '17

Hi, Basically, when do you plan to remove the XUL-based Tor Launcher from the stable Tor Browser series? Background: since Tails likely won't be able to switch to the WebExtension version easily [0], my hope is that you will continue to ship the XUL version throughout the 7.0-series, based on 52esr, and only switch to the WebExtension once Tor Browser is based on 59esr (which I suppose will happen either with 59.0 in March or, or 59.1 in May). I.e. that we in Tails still have plenty time to find a solution [1]. :) Cheers! [0] We run it as a stand-alone XUL application, not a browser extension. [1] FWIW: the solution could be to run a locked down browser dedicated to the Tor Launcher WebExtension *only*. Or switch to Whonix' anon-connection-wizard: https://www.whonix.org/wiki/Anon_Connection_Wizard

2 3

update
by Richard Pospesel 12 Dec '17

12 Dec '17

Hey Browser Devs, Flew into Austin yesterday for the Y'all Hands. This past week I've been investigating the root cause of #17933 and #15599 (pdf loads going to the default circuit rather than the first party domain). Technically speaking #17933 is now no-repro as it dealt specifically with the download button which now doesn't make any network requests. As explained in the comments of #15599 the default circuit is being used by XMLHttpRequests made by pdf.worker.js. The offending requests occur in the context of a Web Worker. For some reason, requests created in the context of the Worker inherit the global default nsIPrincipal (which the first party domain is derived from) which has an empty first party domain (which ultimately forces use of the --unknown-- circuit) I've verified that requests from the pdf.js 'foreground' (?) context is associated with the correct circuit. My preliminary reading suggests that there is a one-to-one mapping of Web Workers to Tabs (ie there's no sharing between tabs, unlike with Shared Workers or Service Workers) so there doesn't seem to be any web-standards reason why pdf.worker.js 'context' shouldn't share a nsIPrincipal with the calling pdf.js 'context.' My next line of inquiry is to learn about/investigate of nsIPrincipal's work and determine whether we can fix Workers to inherit their caller's nsIPrincipal. I would imagine there's some thread-safety considerations to be made here, since Workers allow for background concurrent js. Need to see if in practice the get their own thread or if they operate on the same thread as the js 'UI' thread. best, -Richard

1 0

status report
by Arthur D. Edelstein 12 Dec '17

12 Dec '17

Hi Everyone, Here's what I worked on over the past week: I tracked down and wrote a patch for https://trac.torproject.org/18859 Not strictly a TBB bug, but should improve performance for users, I hope. Also on the subject of performance, I did a small manual test to try to understand the benefits (if any) of enabling HTTP2: https://trac.torproject.org/projects/tor/ticket/14952#comment:24 Indeed it seems the multiplexing feature of HTTP2 can offer us some useful speedups. So at Mozilla I hope to talk to the Mozilla folks about what, if anything, might still be a tracking vector in HTTP2 that we need to fix before we can safely enable it in Tor Browser. I worked on MPX (https://trac.torproject.org/16352) and made some progress, but it turns out there are more issues with building some of the Firefox components that I need to solve before I have a final patch. I also spent quite some time on https://trac.torproject.org/23930. I wasn't able to reproduce the problem -- it seems there may be something special in font set that was originally reported by the user. In any case, I have a guess at what is happening, and a possible fix. I'm going to build a Tor Browser for the user to test. I wrote again to a number of exit operators with bad DNS to ask them to upgrade their tor version. The overall average DNS timeout rate is now down to 4.5%. I'm hoping it will continue to fall and in the near future we can apply a badexit flag to remaining exits showing high DNS timeouts. So this week I will be meeting with Mozilla and Tor folks for planning the future uplift work, discussing the proxy, browser sandboxing, mobile work, etc.. When I get back I will continue to work on various bits of unfinished business including crashes (#23930 and #24145), #18101, #22343. And I might look into one or two performance-related things. Arthur

1 0

missing meeting
by Arthur D. Edelstein 11 Dec '17

11 Dec '17

Hi Everyone, I'll be missing the meeting today because I'm flying to the Mozilla meeting. I'll send a status report this evening. Arthr

2 1

Tor Browser proxy settings
by Tom Ritter 07 Dec '17

07 Dec '17

Hey folks, nmago is continuing work on the crash reporter, and ran into some proxy problems. He's trying to get the proxy settings inside the crash reporter tool but the crash reporter tool can't read Firefox's proxy settings! Upstream this is talked about in https://bugzilla.mozilla.org/show_bug.cgi?id=1388897 https://bugzilla.mozilla.org/show_bug.cgi?id=1333125 and he asked here: https://groups.google.com/forum/#!topic/mozilla.dev.platform/opiD1Rz-e68 I'm wondering if in Tor Browser we can run around Firefox' lack of support here and: A) If we hardcode the proxy settings (fixed port) than nmago can just hardcode it in the crash reporter OR B) If we choose a random port, if we can make that information available to the crash reporter somehow. If we do (B), is the port chosen written out into a torrc file he could read? Or is it determined on startup and only held in memory? This gets tricky because we don't really want to write anything to disk and other IPC mechanisms (Environment Variables) are concerning... (but maybe acceptable from our threat model?) -tom

3 3

New scheme for weekly Tor Browser IRC meetings
by Georg Koppen 07 Dec '17

07 Dec '17

Hi all! As discussed recently on our Monday meetings we want to try a different meeting format for the future. That's mainly due to scalability issues but I've also made good experiences with the proposed scheme. Here it is: 0) We'll be using a pad for meeting notes which can be found on https://storm.torproject.org/shared/tHoN4Ii7rLSjPE0OP4gydX4cMGadsXmRQNc-6lw…. 1) Everyone is writing their updates on the pad before the meeting starts including what they want to work on in the coming week. 2) Items that should get discussed during the meeting should be marked as *bold*. 3) At the meeting start (or ideally before) everyone is looking over the notes of other team members to get up to speed and mark those items as bold which they want to discuss during the meeting. This should not take up more than 5 minutes of the meeting time. 4) The meeting procedes with discussing the bold items top to down from the meeting pad. Resolutions to the bold items get added to the pad. 5) That's it. We can try 0)-5) for a while and if we think we need to refine some of the steps then we should do that. Georg

1 0