tbb-dev

tbb-dev@lists.torproject.org

447 discussions

Changes to plist on Mac may affect disk leakage
by Tom Ritter 04 Dec '17

04 Dec '17

spohl (cc-ed) let me know that he's going to be reverting https://bugzilla.mozilla.org/show_bug.cgi?id=967970 and landing https://bugzilla.mozilla.org/show_bug.cgi?id=1405577 to address issues like https://bugzilla.mozilla.org/show_bug.cgi?id=1418903 In particular, reverting the first issue prevent window title disk leaks, but the new patch should still address that need. -tom

3 4

Exposing TB as Tor Browser
by Tom Ritter 27 Nov '17

27 Nov '17

Background: Firefox added the Canvas Permission Prompt, people turned it on. They discovered that blog.mozilla.com was triggering it, investigated. Tracked it down to Wordpress, by default, using canvas to figure out if the user has emoji support. Fairly innocuous use, not for tracking. Wordpress would like to detect Tor Browser so it doesn't perform the check and therefore doesn't pop the prompt. This would significantly reduce the number of prompts Tor Browser users are seeing. The (old) ticket is here: https://trac.torproject.org/projects/tor/ticket/18195 Other links: Original WP ticket: https://core.trac.wordpress.org/ticket/32138 Mozilla Ticket: https://bugzilla.mozilla.org/show_bug.cgi?id=1413182 New WP Ticket: https://core.trac.wordpress.org/ticket/42428 Is this something TB would take as a patch? -tom PS: Unless FF with privacy.resistFingerprinting identified itself as Tor Browser, this wouldn't help FF, just TB. But maybe FF _should_ identify itself as TB if TB starts identifying itself as TB?

4 6

[tag] sandboxed-tor-browser-0.0.16.
by Yawning Angel 24 Nov '17

24 Nov '17

Hello, I just tagged sandboxed-tor-browser-0.0.16. Changes in version 0.0.16 - 2017-11-24: * Bug 24171: Create the `Caches` directory properly. This is a bugfix release. Normally I'd sit on this some more, because one minor change doesn't usually justify a release, but with the current pace of development, I might as well tag a release and get it over with. Regards, -- Yawning Angel

1 0

Bug: plugin-container exhausts memory leading to thrash and/or crash
by astian 24 Nov '17

24 Nov '17

(Re-sending after subscribing to the list.) STR --- 1. Run one of the platforms affected by the recent "tormoil" vulnerability (I tested this on a GNU/Linux distro). 2. Under Tor Browser 7.0.10's installation directory, create `Browser/TorBrowser/Data/Browser/profile.default/chrome/userContent.css` with the following content (you can use whatever you want here, just adjust the next steps accordingly): body { background-color: blue !important; color: white !important; } 3. Start Tor Browser. 4. Confirm that the content background looks blue. 5. Right click the blue background on an empty spot (body element) and choose "Inspect Element". 6. Wait until the Inspector window shows up. Observe memory consumption of process "plugin-container" continually rise. Analysis -------- I think this regression is caused by the workaround [0] for the recent critical vulnerability [1], but it has exposed what looks to me (not being privy to the details of "tormoil") like another bug, this one in javascript code. 0: https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-52.5.0e… 1: https://trac.torproject.org/projects/tor/ticket/24052 `newChannelForURL` in DevToolsUtils.js (packed inside `Browser/browser/omni.ja`) will recursively call itself when `NetUtil.newChannel` raises an exception, prepending "file://" to the input URL: /** * Opens a channel for given URL. Tries a bit harder than NetUtil.newChannel. * * @param {String} url - The URL to open a channel for. * @param {Object} options - The options object passed to @method fetch. * @return {nsIChannel} - The newly created channel. Throws on failure. */ function newChannelForURL(url, { policy, window, principal }) { var securityFlags = Ci.nsILoadInfo.SEC_ALLOW_CROSS_ORIGIN_DATA_IS_NULL; let uri; try { uri = Services.io.newURI(url, null, null); } catch (e) { // In the xpcshell tests, the script url is the absolute path of the test // file, which will make a malformed URI error be thrown. Add the file // scheme to see if it helps. uri = Services.io.newURI("file://" + url, null, null); } [...] try { return NetUtil.newChannel(channelOptions); } catch (e) { // In xpcshell tests on Windows, nsExternalProtocolHandler::NewChannel() // can throw NS_ERROR_UNKNOWN_PROTOCOL if the external protocol isn't // supported by Windows, so we also need to handle the exception here if // parsing the URL above doesn't throw. return newChannelForURL("file://" + url, { policy, window, principal }); } } With the mentioned patch, the call to `NetUtil.newChannel` raises an exception. This results in infinite recursion coupled with rapid (though linear) memory consumption. Thus, `plugin-container` will, in just a few seconds, exhaust all available memory. Partial fix ----------- AFAICT, the current patch for "tormoil" is just a hurried stop-gap workaround and as such it is acceptable, and somewhat expected, for it to cause other, less severe, kinds of breakage. However, ISTM that the code in `newChannelForURL` is buggy regardless: the recursion has no (evident) termination condition. The comment before the recursive call says that it is needed due to some tests for which `newChannel` can raise `NS_ERROR_UNKNOWN_PROTOCOL`. So maybe it should only catch the exception (and make the recursive call) if the error is that one and `url` does not already start with "file://". The attached patch does this. It does not fix the regression (the Developer Toolbox still fails to show the appropriate styles and stylesheets), but at least fixes the DoS caused by the runaway memory allocation. Cheers. PS: How about fixing your bug tracker? It's impossible to register an account. Bloody google captchas? Free labour for google from the tor community courtesy of tor inc., isn't that lovely (never mind the fact that they require javascript, and even then never actually work). Ridiculous.

2 1

FYI: Removing --disable-crashreporter
by Tom Ritter 23 Nov '17

23 Nov '17

https://bugzilla.mozilla.org/show_bug.cgi?id=1402519 Replacing it with a dummy crash reporter that just doesn't do anything.

1 0

[roadmap process] follow up with other teams
by isabela 20 Nov '17

20 Nov '17

Hi Tor Browser team! This Friday Nov 17 is the when the 'chatting' time ends and we start with execution. This is just symbolic, of course you will not stop talking with other people! But hopefully by this Friday you and the teams who wrote questions related to the Tor Browser team roadmap, has either addressed them and all is good, or made a plan on how to stay in touch as you work on stuff. I am sending a similar note to all teams. I also would like to call your attention to Services and UX Team roadmaps that were added to the pad: https://storm.torproject.org/shared/m-IG6BIam2M9tF6rLDKFpBtIaUoTABiXLN17N97… If you have questions for them, there is an section for them at the questions pad: https://storm.torproject.org/shared/6_vKbNygWaF8WcG6xz3lTW6RWbJzlBdm8ZezRYW… Finally, below are the questions other teams wrote to Tor Browser team, please take a look at them and follow up with whatever is necessary: Questions/Comments for Tor Browser (mobile and desktop) roadmap: https://storm.torproject.org/shared/roevbMxlBi5rxSAh57iRjy8w1MB2HZArEmM2Jek… [Network] These descriptions are pretty terse; we may have missed something. [Network] Can you put anything on your roadmap about Rust build adoption? [GeKo: It's not explicitly there yet as this is done during the ESR 59 transition. And the important part where we usually adapt the toolchains to the new ESR requirements starts in March when the roadmap ends. That said we could think about starting earlier this time for the tor case.] [NM: I'd recommend that you start getting Rust build experience ahead of schedule to identify issues.] [Network] Can you say more about "QA infrastructure" and "release process planning"? How do they affect us? [Network] Should our improvements to bootstrap UX be on your radar? [GeKo: They should. And I looked over the items on the network team map] [Network] Should our improvements to mobile app development API be on your radar? [Network] Please remember to start testing our outputs sooner than you need them: it's easier to fix problems the earlier we find out about them! [Community] We should have regular checkins about support (actually as I'm typing this I see that you flagged it under our roadmap too). [OONI] When will the new launcher UI be shipped?

2 1

Fwd: [community] Computer forensics & Tor (Was: (no subject))
by Tommy Collison 17 Nov '17

17 Nov '17

Good call, thanks teor. TC On 11/17/17 2:05 PM, teor wrote: > > Hi Tommy, > > This might be best directed to the Tor Browser team? > (Or both network and Tor Browser teams.) > > I hope the OS used is Windows, as it's our most popular. > Or Linux, as it's the one that our ultra-secure distributions are based upon > (TAILS, Qubes, Whonix…) > > T > >> On 18 Nov 2017, at 05:59, Tommy Collison <tommyc(a)torproject.org> wrote: >> -------- Forwarded Message -------- >> Subject: [community] (no subject) >> Date: Tue, 14 Nov 2017 20:34:27 +0000 >> From: Scott Ainslie <scott(a)scottainslie.me.uk> >> To: tor-community-team(a)lists.torproject.org >> >> Hello, >> >> I'm intending to publish a term paper. I'm in the midst of outlining >> its remit, but I hope that the outcome benefits the organization and >> users from the standpoint of computer forensic science. >> >> I specialize in digital forensic science, and hold a Certificate of >> Higher Education in Digital Forensics, and a CERT Digital Forensics >> Professional Certificate from Carnegie Mellon University's Software >> Engineering Institute. >> >> Its been half a decade since the organization published a term paper >> assessing the Web browser from the standpoint of computer forensic >> science, and I feel that undertaking it again might be beneficial. I >> intend to refer to it as a basis for the term paper I'm authoring, as >> there are aspects of it I feel I can embellish. >> >> I feel it might be best if I focus upon a single platform because I'll >> be able to conduct more in-depth research. I'm also able to access a >> lot of resources that I hope might enrich the term paper. >> >> I thought it might be useful and beneficial to coordinate the >> independent research I'm undertaking and I'd be grateful for >> cooperation and topics for discussion. >> _______________________________________________ >> tor-community-team mailing list >> tor-community-team(a)lists.torproject.org >> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-community-team >> <0xA78300BD.asc> >> _______________________________________________ >> network-team mailing list >> network-team(a)lists.torproject.org >> https://lists.torproject.org/cgi-bin/mailman/listinfo/network-team

1 0

The next meeting is on Tue, November 21 at 1900 UTC
by Georg Koppen 16 Nov '17

16 Nov '17

Hi all! As a one-time outlier we moved the next Tor Browser meeting to Tuesday next week (November 21 1900 UTC). As usual we'll meet in #tor-meeting. See you there, Georg

1 0

Resolving file url handling issues
by Yuki S 16 Nov '17

16 Nov '17

Hi, I'll be brief What is the stance on fixing the issues (pre/post). How optimistic is it that the bug can be fixed by Mozilla in a reasonable amount of time? Is it really a priority (as Mozilla pushes Quantum) when the issue primarily impacts groups like the TPO community who need a proxy shared on a multi-process design (rhetorical maybe), and doesn't impact the (current) target audience. Mozilla already matches donations so I wonder if it would be fair unless this is a bug not originally present in Mozilla's recent e10 re-architecture. The latest TPO could expect to transition to any Quantum code is July 2018, and earliest in March. >From looking at tickets, and comments in the blog, 2 tickets which reference post-workaround issues are 24243, 24136. So I wonder if it would be worth it to fix the original design issue, which might impact TBB users until mid-2018, or wait for Mozilla to (maybe) fix a flaw that primarily impacts TPO community. I do realize it's not a huge priority for core-developers though. Thanks folks ys

2 1

Fwd: Intent to require Python 3 to build Firefox 59 and later
by Tom Ritter 13 Nov '17

13 Nov '17

FYI ---------- Forwarded message ---------- From: Gregory Szorc <gps(a)mozilla.com> Date: 10 November 2017 at 17:27 Subject: Intent to require Python 3 to build Firefox 59 and later To: dev-builds <dev-builds(a)lists.mozilla.org>, dev-platform <dev-platform(a)lists.mozilla.org> For reasons outlined at https://bugzilla.mozilla.org/show_bug.cgi?id=1388447#c7, we would like to make Python 3 a requirement to build Firefox sometime in the Firefox 59 development cycle. (Firefox 59 will be an ESR release.) The requirement will likely be Python 3.5+. Although I would love to make that 3.6 if possible so we can fully harness modern features and performance. I would love to hear feedback - positive or negative - from downstream packagers and users of various operating systems and distributions about this proposal. Please send comments to dev-builds(a)lists.mozilla.org or leave them on bug 1388447. _______________________________________________ dev-platform mailing list dev-platform(a)lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform

3 2

← Newer
1
...
17
18
19
20
21
22
23
...
45
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

tbb-dev