18:00:06 <mikeperry> #startmeeting
18:00:06 <MeetBot> Meeting started Mon Aug 18 18:00:06 2014 UTC.  The chair is mikeperry. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:00:06 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
18:00:22 <sysrqb> nickm: (that's the mail asn referred to, not sure if that's the one you were thinking about)
18:00:22 <mikeperry> ok, let's get started
18:01:20 <mikeperry> so last week, I started working on #12621, as well as cleaning up the getfirstpartyURI error logging
18:01:44 <mikeperry> I did another round of edits on the iSEC blog post. waiting to hear from tjr
18:02:30 <mikeperry> and then I did a bunch of non-TBB stuff (mostly Android, some gsoc, some literature review)
18:03:03 <mikeperry> this week I plan to finish the developer doc and undocumented ticket review for #12621 and post it there
18:03:31 <mikeperry> and then start chruning through MikePerry201408R
18:04:17 <mikeperry> I might also clean up #7265
18:04:45 <mikeperry> the patch is good, but I think it should log always, and log the script URL involved
18:05:19 <mikeperry> that's it for me
18:05:53 <mikeperry> (I probably will be distracted by more Android things also, fwiw)
18:06:28 <MarkSmith> always logging seems like a good idea (for consistency and debug-ability)
18:08:33 <mikeperry> yeah, I actually tested the patch and it seems like most of the popular canvas using sites (github, riseup's pad, etc) are actually doing it from first-party scrpts. I found some code to log the script URL, so I'll throw that in there too
18:09:47 <mikeperry> with this + isis's changes the canvas message should hopefully be a lot easier for normal people to understand, as well as for technical people to dig and find out what is actually happening
18:10:32 <mikeperry> oh, though that reminds me
18:10:47 <MarkSmith> Hopefully some of the recent press attention has raised awareness… I think a lot of sites are accessing canvas when they don't really need to (just a guess though)
18:11:15 <mikeperry> MarkSmith: are you aware how the Browser Console handles XUL filtering? should we be worried about XSS attempts when logging URLS and such?
18:11:48 <MarkSmith> Good question.  One of us should look at that issue.
18:11:49 <mikeperry> I assume they must do something, but I got a little worried when the control port logging had to use that old deprecated message
18:12:01 <mikeperry> err deprecated logging function
18:12:43 <MarkSmith> If you like, brade and I can dig into that area and report back.
18:12:44 <mikeperry> your work in #9516, using logStringMessage()
18:12:46 <MarkSmith> Or you can.
18:13:13 <MarkSmith> I think the #9516 issue is caused by Mozilla JSONifying everything.
18:13:36 <MarkSmith> But we did not trace through all of their code in the debugger.
18:15:29 <mikeperry> well I am most worried about this deprecation message: https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/Reference/Interface/nsIConsoleService
18:16:14 <mikeperry> both patches use logStringMessage from that service. I am worried that a) we may have issues in FF31, and B) they may do more filtering on the Web Console logging methods
18:16:34 <MarkSmith> At some point they did the work to route messages submitted via the old API to the new browser console
18:17:12 <MarkSmith> More filtering (or not) is an unknown to me though
18:18:54 <mikeperry> I can try logging some XUL tags and see what happens, and look into the beowser console window XUL
18:19:02 <MarkSmith> OK; sounds good.
18:19:22 <MarkSmith> It should be easy enough to try the old and new APIs.
18:22:18 <mikeperry> ok. who wants to go next?
18:22:35 * MarkSmith can go
18:22:47 <MarkSmith> This past week, Kathy Brade and I rebased our browser and builder patches for #4234.
18:22:57 <MarkSmith> We are now waiting for mikeperry and/or GeKo to review and (if all looks OK) land the changes.
18:23:08 <MarkSmith> We also sent boklm some info about changes that needed to be made to the script he created
18:23:15 <MarkSmith> for #12622; he has already made the necessary changes (thanks!)
18:23:28 <MarkSmith> For Tor Launcher, we landed a fixup for #11199 to improve the "Tor expectedly exited" prompts based on feedback from Lunar (thanks!)
18:23:41 <MarkSmith> This week we will help land the #4234 changes and look at some other TorBrowserTeam201408 bugs (probably #10804, #11405, and #12444)
18:23:57 <MarkSmith> That's all for us.
18:26:21 * nickm pipes up to ask for feedback on 8405. arthuredelstein has a patch, and my main question is whether the approach it takes would do what TorBrowser wants.
18:26:37 <nickm> It would be great to make progress here, and all we need is a tor-controller-protocol API review
18:27:38 * nickm has been begging for feedback since this time last month.
18:29:25 <mikeperry> nickm: yes, sorry, that one is bottlenecked on me, and I have been bottlenecked on writing proposals and blog posts. I think I finally have time to look at that this week
18:29:55 <nickm> ok.  are there any tbb-wants tickets that I should be looking at?
18:30:01 <mikeperry> arthuredelstein: it looks like there are 3 patches to review there, where one of them has been revised 3 times?
18:30:24 <nickm> mikeperry: I'm not asking for patch review; I can do that.  I only need review on the new interface.
18:31:04 <arthuredelstein> mikeperry: Actually, I think my latest patch is not even there. Please ignore all of those and I'll post the new one.
18:33:01 <arthuredelstein> The new interface I propose is described at https://trac.torproject.org/projects/tor/ticket/8405#comment:17
18:34:23 <mikeperry> do you still intend to make use of additional info on STREAM events? or will CIRC events be enough?
18:35:24 <arthuredelstein> I think CIRC events would be enough. Provided we can assume that isolation isn't modified after circuit launch.
18:35:40 <arthuredelstein> Which I think works for Tor Browser circuits.
18:36:49 <arthuredelstein> Most of the time, circuits are built pretty fast, so this is really a cosmetic improvement. The circuit diagrams can already be shown with the existing control port interface.
18:37:03 <mikeperry> I need to also make sure your code handles CIRC failure cases and STREAM reattachment OK
18:37:24 <mikeperry> that's why I think this might require more thorough review than just looking at the control protocol changes
18:37:33 <mikeperry> I need to see how we're using them
18:37:57 <arthuredelstein> Yes, I think STREAM reattachment might be a concern. Is this documented somewhere?
18:37:59 <mikeperry> which means reviewing most of the parent/related patches too
18:38:10 <arthuredelstein> I agree
18:39:50 * arthuredelstein can go next
18:39:55 <mikeperry> my memory is fuzzy on where it is documented, but in general streams can be DETACHED from one circuit and placed on another one all the way up to SUCCEEDED
18:40:34 <arthuredelstein> As long as the CIRCUITID is available, I think it should work
18:40:38 <arthuredelstein> But I haven't tested that.
18:40:41 <mikeperry> and circ construction can fail at any point, and CIRCs can even mysteriously die up to that SUCCEEDED call without affecting much as far as the app is concerned
18:40:57 <mikeperry> and Firefox may also retry in some cases even if the circ+stream fail after SUCCEDED
18:42:31 <arthuredelstein> Basically, my patch just monitors CIRC and STREAM events. STREAM gives a Circuit ID, and then Circuit gives node IPs. So I reconstruct a circuit, assuming that the first STREAM on a circuit indicates its "first party" domain
18:43:33 <mikeperry> hrm. that assumption may not hold if parts of the page are either cached, or sitting around in a tab long enough for the original circ to get closed..
18:43:53 <arthuredelstein> If the original circuit gets closed, then we have a new circuit and a new first stream
18:44:19 <arthuredelstein> But indeed if that assumption turns out to be wrong, then the #8405 patch will be cleaner (as well as a cosmetic improvement) because it directly ties the first party domain to the circuit, instread of indirectly through the first stream
18:44:52 <mikeperry> but that stream may be for some third party content that is sitting around doing AJAX or something
18:45:18 <arthuredelstein> That's OK, isn't it? We want it attached to the first party domain.
18:45:50 <tjr> (I just peeked in, haven't read all the backscroll, but can chime in on ctmalloc and coordinate with you, mikeperry, on getting this post out when you're able.)
18:46:13 <arthuredelstein> I guess you're saying, if the first CIRC dies, then a new circuit wakes up and does third-party AJAX.
18:46:46 <mikeperry> tjr: ok
18:47:05 <mikeperry> arthuredelstein: yes
18:47:42 <mikeperry> we probably want some way to tell Tor not to mark circuits dirty in the same way while this is in use
18:48:03 <arthuredelstein> That's a good point. So I think my #8405 proposal fixes the third-party AJAX problem.
18:48:09 <mikeperry> it shouldn't really close our circuits until NEWNYM under this mode.. or at least keep them around much longer
18:49:09 <arthuredelstein> Right.
18:51:04 <arthuredelstein> So, on another subject: last week I worked on #12620. I did a first pass through the TB patches and got all but one to compile on ESR31 (https://github.com/arthuredelstein/tor-browser/commits/esr31-port-tmp). This week I'll hope to start carefully testing the patches to confirm that they are working and try to write some unit tests.
18:51:06 <mikeperry> I suppose we can just set a higher MaxCircuitDirtiness in our torrc
18:51:27 <mikeperry> wow, awesome
18:52:33 <arthuredelstein> Just to be clear, that branch is definitely not ready for use yet.
18:53:19 <arthuredelstein> that's all for me
18:53:46 <mikeperry> ok. update that bug with any questions or patch issues
18:53:50 <MarkSmith> Impressive progress on ESR31 patches!
18:53:55 <mikeperry> #12620
18:54:21 <arthuredelstein> Will do. There's a laundry list
18:54:37 <arthuredelstein> thanks!
18:55:08 <mikeperry> we also need to make sure to get secondary closer reviewon the DOM storage and canvas patches especially. if memory serves, new APIs were scheduled to be added to those componenets by Mozilla
18:56:20 <arthuredelstein> we'll definitely need to inspect each patch carefully for regressions
19:00:00 <boklm> arthuredelstein: when you have a branch for which you are interested to see the results of unit tests on each commit, let me know and I can launch a rebuild
19:00:26 <arthuredelstein> thanks. will do
19:00:53 <mttp> I have a bad habit of asking users to open bug tickets so they can provide the most accurate responses to questions  like system information
19:01:07 <mttp> and they get intimdated and don't open them at all
19:02:29 <mttp> but it looks like one that I should have opened instead of asking a user to do it is "Can't use proxy with no PTs in Tor Browser 4.0-alpha"
19:03:41 <mttp> Interestingly, the log message indicated that the port number of his local proxy was incorrect, even though other applications could use it just fine.
19:04:00 <mttp> I have only seen this one user with this problem.
19:05:16 <boklm> which OS is he using ?
19:05:30 <mttp> Windows 7
19:05:42 <boklm> could it be a firewall issue ?
19:06:15 <mttp> I asked him to disable his firewall & antivirus, and he said that didn't help
19:09:45 <mttp> Anyways  I will open the bug when I find the ticket again.
19:10:11 <boklm> ok
19:10:17 * boklm can go next
19:10:26 <mttp> oh wait
19:10:35 <boklm> ah
19:10:59 <mttp> I also wanted to say that I have been bugging helix lately with many questions about Tor Expert Bundle.
19:11:15 <mttp> She told me it is actually built with gitian.
19:11:43 <mttp> I built one for the tor alpha release. There hasn't been a Windows Tor alpha in a while
19:12:25 <mttp> But I didn't know we were making the Windows Tor deterministic.
19:12:59 <mttp> It'd be cool if I could get access to a build machine so I can experiment with this further (I don't have one)
19:13:02 <mikeperry> ah, I am not sure where the descriptors live for the expert bundle. I haven't seen them
19:13:15 <mttp> tor/contrib/win32build
19:14:58 <mikeperry> in tor.git?
19:15:05 <mttp> I'd actually like to get more involved with this if possible.
19:15:09 <mttp> Yes.
19:15:46 <msvb-lab> Wierd, why is browser stuff in the proxy repo?
19:16:17 <msvb-lab> Or gitian even for that matter.
19:16:42 <mttp> msvb-lab: well it's not actually the browser. It's tor plus windows packaging.
19:17:05 <msvb-lab> mttp: Ok, I thought by 'bundle' it included the browser.
19:17:33 <boklm> it doesn't look like gitian stuff there
19:17:48 <mikeperry> yeah, I don't see it either
19:18:10 <mttp> the other bundle things do
19:18:12 <mttp> yeah the gitian requirement doesn't seem to be documented at all--that's based only on conversations I've had with Erinn
19:20:42 <mikeperry> ok, well I guess we will need to ask helix later
19:20:54 <mttp> One possibility could be to put non-deterministic Windows alpha tor on the website and then iterate on the deterministic part. It seems like Erinn still had some research questions unanswered about how to best incorporate gitian, so IDK
19:21:11 <mikeperry> we have an LXC build machine, but #12237 means that it may not produce matching builds
19:21:20 <mttp> As the browser meeting even the right place to ask these questions?
19:21:35 <mttp> s/As/Is/
19:22:19 <Yawning> mikeperry: is said lxc build bux sufficient for doing devel work?
19:23:16 <Yawning> I want to dust off my obfs4 patch to tbb in preperation for deployment and it'd be nice if I could save the vm setup time
19:25:44 <mikeperry> yes, I can give you guys accounts on that machine. though you probably shouldn't trust it :/
19:25:58 <mikeperry> lxc needs way more sudo access than kvm
19:26:50 <Yawning> yeah less a matter of trust and more "I want something I can use to update a set of msotly done descriptors"
19:27:32 <Yawning> mostly done with the obfs4 code changes I wanted to do so tbb integration and packaging it for bridge operators is next on my todo list
19:27:35 <mttp> The ideal solution is me saving up enough for a nice machine of my own. In the mean time though, access to resources is appreciated.
19:28:17 <Yawning> the 4.0 alpha branch has the go stuff from meek and uses tor 0.2.5.x right?
19:28:34 <tjr> I have successfully built TBB on AWS EC2.  Again, not a trustworthy machine, but works in a pinch if you're desperate
19:29:24 <Yawning> worst comes to worst I could install ubuntu on one of my extra laptops or setup the vm stuff again, but neither of those options are ideal :/
19:29:28 <mttp> also I promise not to do anything malicious or sinister
19:29:45 <pfm> i solemnly swear i am up to no good
19:30:34 <mikeperry> Yawning: yes, 4.0 uses 2.5.x and meek
19:30:45 <Yawning> excellent, should be mostly smooth then
19:32:31 <mikeperry> ok, I added making accounts in my TODO file. email me an ssh key you'd like to use
19:33:30 <msvb-lab> By the way, cookie tester has a prototype http://docookie-europalab.rhcloud.com/#setsimple_page
19:33:36 <msvb-lab> Might complement or be replaced by XPCShell style in the long run (for testing.)
19:34:01 <msvb-lab> For now it suits the purpose of figuring out when a cookie flow is correct.
19:34:07 <Yawning> mikeperry: thanks <3
19:35:48 <mikeperry> msvb-lab: is this for #3246?
19:35:55 <msvb-lab> That's right 3246.
19:37:15 <msvb-lab> Even Live HTTP headers wasn't easy to sort out, and we don't want HTTPS or keepalive rambles mucking up testing.
19:38:47 <msvb-lab> I'll be more vocal once it's in production and #3246 gets coded again to produce a new (not rebased) patch.
19:40:20 <mikeperry> ok, yeah, that was my next question.. how to test this, and against what
19:40:55 <msvb-lab> Against a canonical baseline, with use case scenarios according to Dan Witte's documented logic.
19:41:00 <msvb-lab> Kind of http://docookie-europalab.rhcloud.com
19:46:18 <mikeperry> ok, well let me know when we can test this and what we should look for
19:46:45 <mikeperry> boklm: you've been waiting for a while. ready?
19:46:49 <boklm> yes
19:47:02 <boklm> Last week I made a few changes to the update responses script for #12622
19:47:11 <boklm> I tried a build using the bug4234-02 branch within user/brade/tor-browser-bundle.git (from #4234), which produced some .mar files
19:47:52 <boklm> I made it possible in the testsuite to define some tests as known issues, so we can use it to ignore the meek binaries which are not PIE, with a bug number as reference to be displayed on the results page
19:48:16 <boklm> This week I plan to look at the mozilla mochitests included in firefox, to run them as part of our test suite
19:48:42 <boklm> that's it for me
19:50:54 <arthuredelstein> mochitests will be very useful. We'll be able to write our own JS fingerprinting regression tests.
19:51:28 <mikeperry> yeah
19:52:10 <arthuredelstein> I've written on in https://trac.torproject.org/projects/tor/attachment/ticket/2874/0001-fixup-Bug-2874.-Remove-the-Components-shim-introduce.patch
19:52:12 <arthuredelstein> *one
19:52:43 <boklm> nice :)
19:53:17 <mikeperry> ok, anyone else?
19:53:57 <msvb-lab> mikeperry: were your changes to getfirstpartyURI() revealing of anything?
19:54:06 <msvb-lab> Can't check myself, since Internet is fried in Munich today.
19:54:40 <mikeperry> favicons seem to always fail for that API
19:54:50 <mikeperry> as do some cases where sites are creating about:blank
19:55:05 <mikeperry> that latter bit is very concerning. we'll need to dig into that more
19:55:33 <mikeperry> https://gitweb.torproject.org/user/mikeperry/tor-browser.git/commitdiff/6d893177ee16b1305967319186e2d4506f9848d9
19:55:43 <mikeperry> I will be merging that into the next 4.0-alpha release
19:57:10 <mikeperry> I think that's it, then? man, we ran long today
19:57:24 <tjr> I can update on ctmalloc
19:57:32 <tjr> I'll be quick :)
19:57:34 <mikeperry> ah, ok, yes please do
19:57:47 <tjr> I got it working!
19:58:00 <mikeperry> you got my mail with the updated blog post, yes?
19:58:04 <mikeperry> awesome!
19:58:27 <tjr> The next thing I need to do is a) test it on all OS's b) do a performance comparison and c) improve it so it takes advantage of the partitions
19:58:47 <tjr> I didn't actually get the mail, but I checked your transient link and it looks good to me
19:59:07 <tjr> I will push the report to gihub, you can publish your blog post, and then we'll publish ours?
20:00:44 <mikeperry> shall I link to your post? can you email me a copy?
20:01:42 <tjr> I will email you my draft, but I can't publish my post until I have the link to your post. :-p
20:02:19 <arthuredelstein> deadlock ;)
20:02:46 <tjr> emailed.  I will push the report to our github so you can link to it when you tell me to
20:03:05 <mikeperry> heh, and I need a link to the final report to publish my blog post. lots of deadlock :)
20:03:33 <tjr> I can do that before (iSEC) does the blog post
20:03:59 <mikeperry> our blog post will be at https://blog.torproject.org/blog/isec-partners-conducts-tor-browser-hardening-study
20:04:48 <tjr> Okay, I think we're pretty set, should I push the report (but not blog post) then?
20:04:54 <mikeperry> we also found https://gcc.gnu.org/wiki/vtv while looking into hardening options btw
20:05:04 <mikeperry> possibly a better solution than the vtable final thing?
20:05:31 <tjr> Uh, we had recommended that... :-p
20:05:50 <tjr> VTV and VTable final are independent of each other, they're both good ideas
20:07:37 <naif> Is it possible to force Tor to publish a specific TorHS to *all* available HSDir of the network?
20:09:14 <mikeperry> oh, hrmm, I didn't see the VTV rec. anyways, it sounds like we're ready to go. I should be able to post this later today/tomorrow
20:10:26 <mikeperry> I think we're finally done for the meeting then?
20:12:03 <mikeperry> alright, *baf* time
20:12:10 <mikeperry> #endmeeting *baf*