18:03:11 <mikeperry> #startmeeting
18:03:11 <MeetBot> Meeting started Mon Sep 15 18:03:11 2014 UTC.  The chair is mikeperry. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:03:11 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
18:04:12 <mikeperry> ok, so I almost finished my Firefox networking code review. I still need to finish grepping through the XPCOM usages of sockets
18:04:31 <mikeperry> but then I went off to the OTF meeting, and that consumed the rest of the week.
18:04:55 <mikeperry> I met a lot of helpful people. I plan to write up a trip report today
18:05:45 <mikeperry> I think this week we shoudl consider trying to get out a 4.0a3 with #13049 in it
18:06:19 <GeKo> sounds good, maybe we get other updater related things squeezed into it?
18:06:23 <mikeperry> and any other minor fixes on 4.0/FF24.8 ESR
18:06:37 <mikeperry> yeah, are there other things?
18:07:28 <MarkSmith> brade and I are working on #13047 (should be done today I think)
18:08:02 <GeKo> and #13091
18:08:31 <MarkSmith> Yes, could include #13091.  I think the changes are safe.
18:09:24 <mikeperry> ok
18:09:45 <mikeperry> make sure to tag those with MikePerry201409R when ready. I will keep an eye out for them
18:09:53 <arthuredelstein> Unrelated, but we could add https://trac.torproject.org/projects/tor/ticket/12998 fixup.
18:09:54 <mikeperry> ah, I see #13091 is already tagged
18:10:01 <GeKo> yes
18:10:04 <mikeperry> yeah.
18:11:52 <mikeperry> ok, who is next?
18:14:03 * MarkSmith can go next
18:14:15 <MarkSmith> Last week, Kathy Brade and I reviewed the ESR31 canvas patch and made a few improvements.
18:14:25 <MarkSmith> We also asked a few questions in #13021 about whether we need to worry about some other canvas features (no response yet).
18:14:33 <MarkSmith> We also reviewed the ESR31 DOM Storage patch and found no issues with it.
18:14:44 <MarkSmith> We tested Tor Launcher with an ESR31-based Tor Browser and found no issues.
18:14:51 <arthuredelstein> MarkSmith: I believe I added all your improvements, but let me know if I'm missing anything.
18:14:55 <MarkSmith> We found and created a fix for #13138 (needs to be reviewed and merged).
18:15:11 <MarkSmith> arthuredelstein: OK
18:15:44 <MarkSmith> We created patches for #13091 (needs to be reviewed and merged, as already mentioned).
18:15:51 <MarkSmith> And I already mentioned that we are working on #13047 (remove OS version, etc. from update URL); we are not quite done yet.
18:15:59 <MarkSmith> This week, we plan to finish #13047 and do some testing of the updater inside an ESR31-based Tor Browser.
18:16:07 <MarkSmith> Let us know if there are other ESR31 items we should work on.
18:16:11 <MarkSmith> That's all for us.
18:17:27 * arthuredelstein can go next
18:17:33 <GeKo> mikeperry: a comment on #13047 would be good
18:17:36 <GeKo> MarkSmith: ^
18:18:01 <GeKo> I am bit unsure aboubt the proposed solution given the discusions we had and have wrt to dropping 32bit OS X builds
18:18:05 <GeKo> *about
18:19:27 <arthuredelstein> Last week I worked on getting our patch for SSL session tracking into mozilla-central: https://bugzilla.mozilla.org/show_bug.cgi?id=967977 . It seems ready to land as far as it goes, but there are other types of SSL session tracking that we should probably consider first.
18:20:32 <arthuredelstein> I also worked on rebasing patches for  #12523, #11955 and #13033 to ESR31. They all compile, but all need some work still.
18:21:10 <arthuredelstein> (Anyone have thoughts on which of these is highest priority?)
18:21:34 <arthuredelstein> Also I've been working on #5926, which is getting close, I think
18:21:49 <GeKo> #11955
18:22:24 <arthuredelstein> and finally I rebased my C++ patches for #3455, which I will post to Mozilla soon to see what they think
18:23:19 <GeKo> although #13033 is a deliverable...
18:23:32 <mikeperry> I agree that pinning is the top priority. we want to be able to pin addons.mozilla.org
18:24:04 <arthuredelstein> The main issue there is that there are a lot of Mozilla patches that may need to be included.
18:24:09 <arthuredelstein> for #11955
18:24:27 <mikeperry> well, #13033 is not strictly a deliverable. The actual deliverable was to improve HTTPS-Everywhere security.. that seemed like a good fit..
18:24:53 <GeKo> ah, good
18:25:56 <arthuredelstein> OK, so I'll probably concentrate on #13033 before the other two.
18:26:13 <arthuredelstein> Hopefully we can get some advice from Camilo.
18:26:29 <arthuredelstein> That's it for me
18:26:42 * tjr will slide in before he has to take a phone call...
18:27:01 <mikeperry> ok
18:27:07 <tjr> I'm working on 64 bit Mac builds.  I'm pretty close.  I have all the utils, tor, TorBrowser built and working, with full aslr on 64bit Mac
18:27:14 <tjr> PT's broke, I'm working on that part
18:27:19 <GeKo> woot!
18:27:26 <tjr> You'll ahve to think about if you want 32 bit mac builds :)
18:27:34 <tjr> That's all I've got
18:29:14 <GeKo> here is waht I did:
18:29:20 <mikeperry> cool. I am thinking that we release one FF31ESR for 32bit mac, and then warn people we're going to stop
18:29:30 <mikeperry> and see what happens
18:29:43 <GeKo> sounds good
18:30:18 <GeKo> I fixed the remaining build issues for windows and os x. Thus, we could start releasing ESR 31 stuff.
18:30:35 <mikeperry> awesome
18:30:51 <GeKo> and I worked on my Torbutton patch for the new drag and drop observer code
18:30:57 <mikeperry> did you merge your changes? they're not going to interfere with 40a3, right?
18:31:16 <GeKo> I did not yet as they would interfere with 40a3
18:31:30 <mikeperry> ah, ok
18:31:44 <mikeperry> yeah, then we should try to get this 4.0a3 release out asap :)
18:32:29 <GeKo> this week I'll clean-up the patches and comment everything properly, then I'll finish the drag and drop observe related pacth and then I start looking for things in need for ESR 31
18:32:43 <GeKo> that's it
18:34:33 <mikeperry> ok
18:35:36 * boklm can go next
18:36:08 <boklm> Last week I found why many mochitests were failing with "Test timed out" errors. It was because they were run with xvfb and no window manager.
18:36:28 <GeKo> aha!
18:36:37 <boklm> So I updated the testsuite to run an Xorg server with the dummy driver and a window manager, instead of using xvfb, and launched a rebuild.
18:37:42 <boklm> Now the most common errors in mochitest are caused by the patch "Block Components.* from content", and the tests that include this file which uses Components.*:
18:37:52 <boklm> https://gitweb.torproject.org/tor-browser.git/blob/refs/heads/tor-browser-24.8.0esr-3.x-1:/testing/mochitest/tests/SimpleTest/EventUtils.js#l26
18:39:03 <boklm> I also started working on a mozmill test to load various video types, to check with mbox that there is no network leak when the video is playing
18:40:18 <arthuredelstein> I suppose we could patch those mochitests as well to make them shut up.
18:40:38 <arthuredelstein> I believe that everything in Components.* exposed in content is available with a standard web api as well.
18:41:24 <boklm> ah, maybe
18:41:42 <boklm> I will look at this
18:42:15 <boklm> that's it for me
18:43:58 <gacar> * can go next*
18:44:01 <arthuredelstein> Here's the map of Components.interfaces to web API methods: https://trac.torproject.org/projects/tor/ticket/2874#comment:15
18:45:17 <boklm> arthuredelstein: thanks
18:47:30 <gacar> I worked on fingerprinting tests, client side part is in good shape, thin, easy to extend. Modelled after Modernzr.
18:47:41 <gacar> still tens of tests to add.
18:48:03 <gacar> It collects the FP and dumps a JSON. Then we'll process that from 1) QA tests to check if everything is OK, or 2) insert to DB
18:48:05 <gacar> and display to user
18:48:13 <gacar> and calculate entropy etc.
18:48:36 <gacar> i've 2-3 major problems which I'll seek feedback about.
18:48:59 <gacar> mostly the issue we discussed in EFF meeting w/ mikeperry
18:49:28 <gacar> maybe i'll ask at tbb-dev to get feedback.
18:49:47 <boklm> what are the issues ?
18:50:16 <gacar> mostly about undercounting entropy
18:50:46 <gacar> inn panopticlick (poc) they've cookies to prevent multiple entries from the same user
18:51:12 <boklm> ah, ok
18:51:45 <gacar> I'll ask feedback on tbb-dev
18:52:01 <boklm> ok
18:52:08 <gacar> also, if Flash is enabled, should we go and collect fonts etc.
18:52:13 <mikeperry> yeah, that is probably best. I am not sure what to do about it. the least invasive option seems to just ask users if they have submitted this TBB install before...
18:52:44 <gacar> ok, i'll think about it.
18:53:30 <gacar> also, may be a surface of attacks if we tell user :"some1 with your FP was here last sunday"
18:53:59 <gacar> Also some technical issue like organizing tens of tests result in DB efficiently
18:54:41 <gacar> Also sent a patch for testing default prefs in mozmill.
18:54:59 <gacar> For the webworker issue, FF side is silent.
18:55:35 <gacar> we can have a hotfix like, just returning constant values for unspoofed nav. properties.
18:56:02 <gacar> #13027
18:56:23 <GeKo> I am worried about the treatment as chrome callers.
18:56:25 <mikeperry> oh shit, I meant to email security-group about that but got distracted
18:56:27 <mikeperry> yes
18:56:47 <gacar> This week I'll work on the FP tests and think about backend.
18:56:47 <gacar> Also some analysis on panopticlick data.
18:56:53 <GeKo> And if there is still no reaction we should investigate it ourselves
18:57:46 <gacar> yes, one good thing is webworkers cannot interact with too many things
18:58:52 <mttp> I can go next
18:59:04 <mikeperry> I remember starting to dig though their access to eventhandlers and becoming worried
18:59:09 <GeKo> well, yes, but on the other hand you don't need many holes to get your browser p0wned :)
18:59:10 <mikeperry> but I will ask mozilla
18:59:32 <gacar> *that's all from me btw*
19:00:00 <mttp> so
19:00:09 <mttp> Users on 3.6.5 report that after using Tor Browser successfully once, they close it and try to open it again, but the next time Tor will load completely, but the browser never appears.
19:00:41 <mttp> I know this happens on Windows, not sure about other OSs
19:00:44 <GeKo> I bet this is #10804
19:01:21 <mttp> ooh ok I'll direct users to that ticket when it happens
19:01:42 <mttp> I've also seen a couple of these now: "Unable to save Tor settings, cannot connect to Tor control port". I wonder what that's from.
19:01:43 <GeKo> mttp: you could verify that if users want to repeat the experiment mentioned there
19:02:05 <mttp> GeKo: will look into that :)
19:02:55 <MarkSmith> When do they see "Unable to save Tor settings"?
19:03:33 <MarkSmith> Maybe tor has exited and they don't realize that has happened.
19:05:58 <MarkSmith> Actually, they should see a message if tor exits, assuming it was started by Tor Launcher.
19:06:53 <MarkSmith> If you have good info, please open a ticket about the unable to save issue (if not, wait for a pattern to develop ;)
19:09:04 <mttp> uh sorry for the long pause; I had a hardware hiccup
19:09:33 <mttp> The only other thing that I was going to bring up was that
19:10:02 <mttp> People think that Cloudflare is a new sucky componnet of Tor Browser that developers put in.
19:10:28 <mttp> so hopefully arma's "don't censor Tor" plan works out well
19:11:08 <mttp> MarkSmith: That message is usually seen at startup
19:12:13 <mttp> I'll see what other information I can get about that error, then open a ticket
19:12:23 <mttp> and that's it from me.
19:13:04 <MarkSmith> mttp: OK.   I see you just added tbb-helpdesk-frequent to #13138 but that can't be right (no one has an ESR31-based browser yet)
19:13:45 <mttp> Oh sorry -_-
19:14:13 <GeKo> (mttp is anticipating things...)
19:14:27 <mttp> I'll have to look further and see if there is a ticket for about:tor showing "Tor is not working in this browser" for earlier FF version
19:14:30 <mttp> s
19:15:07 <mttp> It's not that frequent to be honest, but I have seen it before
19:15:16 <mttp> Let me remove it...
19:18:24 <mikeperry> ok
19:18:36 <mikeperry> anything else?
19:19:37 <mikeperry> I just heard from Giorgio that apparently Mozilla is targeting Firefox 36 for their multiprocess+sandboxing work to land in time for Pwn2Own in March
19:20:06 <mikeperry> this is going to mess him up, because it will apparently break a lot of NoScript features, but I think is generally good news
19:20:15 <mikeperry> I couldn't find a primary source for this, though
19:20:31 <MarkSmith> Good for security, bad for developers (or good if you need something to do ;)
19:20:42 <GeKo> ha
19:22:08 <mikeperry> so hopefully this means that my gamble on Firefox implementing sandboxing before Chrome became privacy+Tor friendly is the right one. I was beginning to get nervous :)
19:22:42 <GeKo> nah
19:24:46 <sssheep> chrome was better for security
19:24:48 <sssheep> just not for privacy
19:24:58 <sssheep> firefox have the ethics that you want, it'll be here soon :)
19:25:09 * GeKo bites on his tongue to stop the urge to rant about chromium
19:25:34 <mikeperry> ok, I think that wraps up the meeting today. I will try to follow up on everything today
19:25:47 <mikeperry> #endmeeting *baf*