19:00:06 <mikeperry> #startmeeting
19:00:06 <MeetBot> Meeting started Mon Jan 19 19:00:06 2015 UTC.  The chair is mikeperry. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:00:06 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
19:00:11 <mikeperry> ok, lets get started
19:00:18 <mikeperry> Last week, I worked on some non-tbb things, was slowed due to choppy internet seas, and helped Georg organize and release TBB 4.5a3.
19:00:24 <mikeperry> This week, my plan is to help with the project coordinator interview process, make sure everything is OK for people to get contracts, and also be distracted by travelling.
19:00:30 <mikeperry> There are a few more things I want to merge with respect to release processes, and file some tickets for the next release of the alpha.
19:00:35 <mikeperry> Notably I think we should get an omnibox plugin for disconnect.me into the alpha, and switch the Torbutton-based update menu to cause the browser to follow the MAR-based update procedure. According to some of weasel's statistics, a large number of people (especially windows users) are still downloading updates manually: https://www.palfrader.org/volatile/2015-01-14-aTZpQXulSo8/stdin
19:00:41 <mikeperry> (Now that we have signed MARs, I think it's safe to start steering people towards in-browser updates for the alpha series).
19:00:45 <mikeperry> Relatedly, nickm is looking for TBB people to review https://trac.torproject.org/projects/tor/ticket/10395. It's probably good to have Pearl Crescent take a look at this, to make sure they agree its sane, and understand how we expect to use it.
19:00:51 <mikeperry> FYI: I may or may not miss the meeting next monday, depending on how travel goes. I will try to notify everyone, but I may not finish reinstalling my computers by then (crossing borders is such fun!).
19:00:56 <mikeperry> That's it for me.
19:02:38 <mikeperry> who wants to go next?
19:02:50 <GeKo> I can
19:03:13 <GeKo> so, I was mainly busy doing release related things
19:03:30 <GeKo> then I started testing the Disconnect search plugin
19:03:58 <GeKo> and I filed a bunch of ticket most notably those that make use of ioerro's SocksSocket option
19:04:07 <GeKo> seems to be a good fit for the hardened bundles at least
19:04:13 <GeKo> err ioerror's
19:04:51 <GeKo> then I started a mail for tbb-dev inspired by the private browsing mode discussion in our last dev meeting
19:05:14 <GeKo> I hope it will be ready and starts an in-team discussion
19:05:27 <GeKo> might help for Mike's mail to Mozilla wrt to their fingerprinting plans
19:05:30 <GeKo> we'll see
19:05:45 <mikeperry> (oh crap, I have a huge pile of mail to send.. the mail to mozilla about fingerprinting feature control and private browsing mode behavior among them. those mails are all in my TODO list. I should have mentioned that)
19:05:59 <GeKo> next week I plan to work harder on #9387
19:06:22 <GeKo> resume my work on the windows signing given that we have more and more users complaining about issues with win 8.1
19:06:58 <GeKo> I want to take a look at nickm's consensus patch for us
19:07:27 <GeKo> and thought about taking a look at #11236
19:07:38 <GeKo> given that we think about testing the Disconnect plugin
19:07:47 <GeKo> in all locales we ship
19:08:07 <GeKo> if there remains some time I plan to take a look at the double-key cookie patch
19:08:12 <GeKo> that's it for now
19:08:18 <arthuredelstein> What's in the Disconnect plugin?
19:08:37 <GeKo> it's a search plugi, no extension
19:08:38 <mikeperry> one of these: http://mycroftproject.com/search-engines.html?name=disconnect
19:08:43 <GeKo> *plugin
19:08:50 <mikeperry> to search https://search.disconnect.me/
19:08:59 <arthuredelstein> Oh, just a search option?
19:09:07 <GeKo> yes
19:10:01 <mikeperry> they have something in addons.mozilla.org, too, but that is too heavyweight
19:10:23 <mikeperry> and probably does weird things to about:home expecting i to be the homepage, and likely won't help us anyway
19:10:45 <mikeperry> ok, who wants to go next?
19:11:00 * MarkSmith can go
19:11:09 <MarkSmith> This past week Kathy and I made a revised patch for #14122 (thanks to GeKo for merging the fix).
19:11:23 <MarkSmith> We took another look at #13818 and commented in Trac (short summary: we think the patch attached to that bug should be accepted).
19:11:32 <MarkSmith> We did a code review for #9701.
19:11:41 <MarkSmith> We did a little updater testing for 4.0.3 and 4.5a3.
19:11:46 <MarkSmith> We also started to experiment with running Torbutton, Tor Launcher, etc. in a Firefox that has electrolysis enabled.
19:11:52 <MarkSmith> Of course various things are broken by post-ESR31 Firefox changes and the fact that we are not running with a patched Tor Browser… so it will take a little time to sort our the e10s issues from other noise.
19:12:02 <MarkSmith> We will have more to report after we work on it some more.
19:12:07 <MarkSmith> This week we will review #10395.
19:12:16 <MarkSmith> (I forgot to ask about that last week, but mikeperry just reminded me.)
19:12:21 <MarkSmith> It is probably a good idea for us to look at it even though GeKo plans to also review it.
19:12:26 <MarkSmith> And we will do more e10s research.
19:12:32 <MarkSmith> That's all for us.
19:12:33 <arthuredelstein> Is it possible to enable electrolysis in the ESR31-based Tor Browser?
19:13:07 <GeKo> MarkSemith: I have no plans to review the patch yet (definitely not without seeing the code ;) )
19:13:08 <MarkSmith> I am not sure. SInce e10s is a moving target / work-in-progress, we decided to work with a nightly build (very bleeding edge though).
19:13:26 <GeKo> I just had some comments on the prop 227 in the past and want to see what eventeually got into the code
19:13:40 <GeKo> *eventually
19:14:47 <GeKo> arthuredelstein: I don't think so. IIRC there is too much e10 related code missing in ESR 31
19:14:53 <MarkSmith> I thought when you said "I want to take a look at nickm's consensus patch for us" that you meant "code review"  Now I am confused.
19:15:06 <MarkSmith> Anyway, Kathy and I will look at it too.
19:15:25 <mikeperry> MarkSmith: realistically, e10s may not be of any use for us until FF45ESR, so it may be premature to sink too much time into it now
19:15:36 <mikeperry> so you could push that back a bit I think
19:15:45 <MarkSmith> For e10s, the good news is that our add-ons mostly do not access content pages directly.  At least I don't think so.
19:16:10 <MarkSmith> mikeperry: OK.  We did not plan to sink a lot of time but you are right about timing.
19:16:15 <mikeperry> at best, it will be optionally enabled in FF38ESR I think, and that probably won't get us much sandboxing benefit at that point unless we're ready to do a lot of backporting
19:17:05 <MarkSmith> At some point it will be good for all of us to klnow if we will have a lot of work to do or only a little (for e10s).
19:18:02 <mikeperry> right. things may also change though as Mozilla adds more e10s glue to support other addons, too though
19:18:30 <MarkSmith> Agreed.  It is definitely a moving target.  So we will put it on the back burner.
19:19:14 <mikeperry> there are some things in https://trac.torproject.org/projects/tor/query?status=!closed&keywords=~TorBrowserTeam201501 you could pick up instead, and I will be filing that Torbutton Update Menu thing soon
19:19:57 <MarkSmith> OK.  Will the update menu change be for 4.0.x or just 4.5?
19:20:02 <mikeperry> just 4.5
19:20:11 <MarkSmith> Sounds good.
19:20:44 <arthuredelstein> Is #13406 the same issue as the Update Menu?
19:21:47 <mikeperry> oh yes, great
19:21:49 <GeKo> MarkSmith: #13900 seems pretty useful as well
19:22:09 <GeKo> as part of our third party isolation thingy
19:22:58 <MarkSmith> For #13406, we will have to decide how things should work… but we can discuss that in the ticket or later.
19:23:46 <MarkSmith> We can look at #13900.
19:24:53 * arthuredelstein can go next.
19:24:59 <arthuredelstein> Last week I worked on #13670. I've made progress with both favicons and OCSP, and I hope I can get both caching and network isolation for those two working soon. Also, I'm wondering if we should suggest landing the patch here: https://trac.torproject.org/projects/tor/ticket/8405#comment:25
19:25:04 <arthuredelstein> That's it for me.
19:26:33 * boklm can go next
19:26:40 <GeKo> I think it should somehow make it into mainline 0.2.6
19:27:47 <boklm> This week I reviewed #10125
19:27:49 <boklm> I made a patch for the ReleaseProcess file after the #13015 changes: #14212
19:28:00 <boklm> An other patch to fix the $TORBROWSER_VERSION -> $TORBROWSER_BUILDDIR symlink: #14221
19:28:11 <boklm> So now we have a different directory for each build, with a symlink $version -> $builddir updated after each build.
19:28:20 <boklm> In the last comment on #14221, GeKo is wondering if it is a good idea, or if we should switch back to one directory. I am not sure about this.
19:28:36 <boklm> Today I also fixed some problems in the testsuite that prevented the tests on 4.5a3 to start. They are beeing at the moment (on Linux and Windows).
19:28:46 <boklm> This week I'm planning to do some improvements on the Windows testsuite.
19:28:53 <boklm> that's it for me
19:29:09 <GeKo> do we see the test results on Windows somewhere?
19:29:25 <GeKo> there is no mail for it yet, right?
19:29:40 <boklm> they should be a mail when it finish running
19:29:43 <boklm> there
19:29:50 <GeKo> ah, okay
19:29:55 <boklm> and uploaded at the same place as the other results
19:34:44 <arthuredelstein> Regarding #8405, I can comment on the ticket, but I think Nick would be more persuaded to land the patch by a comment from Mike or GeKo. :)
19:35:09 <mikeperry> arthuredelstein: I am wondering if maybe we want to exempt our updater pings from domain isolation
19:35:31 <mikeperry> we probably actually want those going out over varied circuits
19:35:50 <arthuredelstein> What are they doing now?
19:36:24 <arthuredelstein> Are they running over the "no-first-party" circuit?
19:36:39 <MarkSmith> Probably that (no-first-party circuit).
19:36:42 <mikeperry> they may actually respect domain isolation, which is Ok with 10 minute circuit lifetimes, but perhaps not with https://trac.torproject.org/projects/tor/ticket/13766
19:36:49 <MarkSmith> I have not checked though.
19:37:34 <arthuredelstein> So the design would be to run over a new circuit with each ping?
19:38:06 <msvb-lab> Does that force thrashing of circuits for other traffic as well?
19:38:28 <mikeperry> arthuredelstein: I think so. perhaps maybe we do this by setting a different nonce for the password field?
19:38:46 <arthuredelstein> Yes, that should work.
19:39:38 <arthuredelstein> Is there a danger in using the same circuit over multiple pings for a long time?
19:40:33 <GeKo> good question: what is the threat model here, mike?
19:40:54 <federico3> https://bradleyf.id.au/nix/shaving-your-rtt-wth-tfo/  TCP Fast Open (Tor users could benefit from this)
19:41:05 <mikeperry> hold-back/freeze attacks from that exit.
19:41:17 <federico3> mkstn?
19:41:28 <mkstn> federico3: right here
19:41:28 <GeKo> yes
19:41:29 <mikeperry> Firefox will complain if it goes a few days without being able to hit the update responses, but using more circuits will also reduce the risk
19:41:48 <federico3> mkstn: oh, did I got your email address right?
19:42:05 <mkstn> federico3: yep, I got your mail
19:42:18 <arthuredelstein> Just brainstorming: Would a hidden site make sense for the update service?
19:42:56 <mikeperry> we discussed that before, and armadev thinks it won't scale yet. we would need the SponsorR scaling+reliability work to be deployed first, probably
19:43:41 <arthuredelstein> I see.
19:45:24 <arthuredelstein> Well, the nonce strategy should work. The only issue is how to get that working with the updater. Possibly the domain isolator could simply recognize the update ping URI(s) as special.
19:46:00 <mikeperry> hrm. we may need to think harder about this. we also don't want to let websites perform guard discovery attacks :/
19:46:13 <mikeperry> (see my comment on #7870)
19:47:29 <mikeperry> and so we do *not* want to magically exempt https://www.torproject.org/projects/torbrowser/RecommendedTBBVersions with a new nonce, if for example, we website decides to make a ton of <script src> tags to that url
19:48:09 <arthuredelstein> Ah, very good point.
19:48:21 <mikeperry> s/we website/a website
19:48:32 <arthuredelstein> The request needs to be strictly from the TBB updater.
19:48:40 <GeKo> yes
19:49:22 <MarkSmith> I think the update service uses XMLHttpRequest for everything although I would need to double check that.
19:51:24 <MarkSmith> I wonder if the domain isolation code can somehow distinguish internal requests from those generated by web pages?
19:51:59 <mikeperry> if the updates really are from "no first party" this is perhaps not that complicated
19:52:33 <mikeperry> and the password nonce solution may work
19:53:12 <arthuredelstein> A new nonce for every "no first party" request seems like pretty good idea.
19:53:50 <mikeperry> yes, I think so
19:54:17 <arthuredelstein> Provided, as you point out, that there is no trick a web page can use to generate many such requests.
19:57:55 <mikeperry> ok, anything else to discuss?
19:58:33 <msvb-lab> If you've built TBB for alpha3 and have build stats, please document on the wiki.
19:58:44 <hotstuff> I need a large pepperoni pizza extra cheese.
19:58:57 <xk11coleco> hotstuff, I got you covered.
19:59:11 <mikeperry> yay, we made it in under an hour this time. good work everybody, and please remember to (keep) pre-typing your reports, and trying to save extended discussion for the end of the meeting
19:59:33 <MarkSmith> 1 hour is awesome!
19:59:34 <hotstuff> Tor bring back vidalia
19:59:39 <GeKo> no
19:59:56 <mikeperry> #endmeeting