19:00:26 <mikeperry> #startmeeting
19:00:26 <MeetBot> Meeting started Mon Jan 26 19:00:26 2015 UTC.  The chair is mikeperry. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:00:26 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
19:00:52 <mikeperry> ok, let's get started.
19:00:53 <arthuredelstein> hi everyone
19:00:56 <mikeperry> Last week, when I wasn't travelling I was mostly dealing with Tor organizational issues, as well as responding to some Tor performance and traffic analysis researchers.
19:01:22 <mikeperry> This week, I should finally be done travelling and should hopefully come back to full productivity. I have a bunch of odds and ends to take care of, including filing some bugs and finally sending those mails to Mozilla and Chrome (ugh).
19:01:34 <mikeperry> I am also looking forward to the UX sprint in Berkeley. I should be able to attend most of it.
19:02:04 <mikeperry> I think that's it for me. Now, to try to get Tor Browser back on this freshly wiped and reinstalled laptop ;)
19:02:32 <meejah> baumanno: is it possible to query a "details" doc for a single relay with OnionPy?
19:02:43 <GeKo> mikeperry: I sent the mail to the chrome people
19:04:25 <mikeperry> ah. they also mention somewhere in their doc that no browser is currently defending against cache and DOM storage identifier tracking
19:04:32 <mikeperry> I want them to fix that oversight :)
19:04:47 <mikeperry> I can reply to that thread
19:05:30 <GeKo> sure. I just wanted to get the discussion going. I must have overlooked that bit :(
19:06:58 <mikeperry> no worries
19:09:35 <GeKo> ah, you mean "There is no concept of blocking “third-party” cache objects in any browser known to the authors of this document"
19:09:45 <mikeperry> yes
19:09:53 <GeKo> well, we don't block them strictly speaking
19:10:00 <GeKo> but anyway
19:10:05 <GeKo> here is what I did:
19:10:18 <GeKo> I wrote a bunch of emails pushing above all the Windows signing and Disconnect
19:10:18 <GeKo> things forward. I fought with #11236 and succceeded at least partly.
19:10:18 <GeKo> I also started looking at the prop 227 implementation but am not done yet.
19:10:35 <GeKo> Next week I'll work further on #9387, finish reviewing the prop 227 implementation, give the double keyed cookie patch a test (finally) and do the clean-up for #11236.
19:10:45 <GeKo> I might work on the Windows signing bug as well.
19:10:52 <GeKo> That's it for now.
19:13:31 <mikeperry> ok. who wants to go next?
19:13:57 * MarkSmith can go next.
19:14:04 <MarkSmith> This past week Kathy and I committed Michael's fix for #9701,
19:14:10 <MarkSmith> we tested signed updates in 4.5a3 (GeKo gave us some signed MAR files for testing),
19:14:16 <MarkSmith> and we started our review of #10395.
19:14:25 <MarkSmith> For #10395, there is a lot we need to learn, e.g., understanding the tor code,
19:14:30 <MarkSmith> understanding how the consensus works,
19:14:35 <MarkSmith> figuring out how to retrieve consensus info via the control port.
19:14:46 <MarkSmith> This week we will try to finish the #10395 review and begin to look at #13900 and #13406.
19:14:51 <MarkSmith> That's all for now.
19:14:52 <mikeperry> I am happy to answer questions there
19:15:52 <boklm> I haven't much to report this week. I have worked on something for #12222 which is almost ready.
19:15:57 <boklm> This week I'm planning to deploy and document it.
19:16:02 <MarkSmith> mikeperry: thanks.  After the meeting, we can ask you a few things.
19:16:05 <boklm> That's all for now.
19:17:58 <arthuredelstein> This week I've been working on #13670. Getting closer to a fix. Also https://bugzilla.mozilla.org/show_bug.cgi?id=436344 landed, which caused some consternation among addon developers. Looks like a followup fix should solve their problems. This week I'll be working more on #13670 and heading to the UX meeting.
19:18:12 <arthuredelstein> That's it forme
19:20:22 <mikeperry> ok. do we have a suport summary, or anything else to report?
19:21:55 <GeKo> I don't have anything.
19:22:17 <msvb-lab> Me neither.
19:22:41 <GeKo> how is it going with your mochitest?
19:22:57 <msvb-lab> Complicated, since a data flavor URI doesn't trigger the problem.
19:23:12 <msvb-lab> Need to use HTTP and a local server for that.
19:24:08 <GeKo> hm...
19:24:21 <meejah> wow, Vagrant is like super-democratic: even an 8-core, 64GB ram machine runs it slowly!
19:24:28 <arthuredelstein> If you open a tab to http://example.com, mochitest provides an HTTP server
19:24:47 <msvb-lab> ...I think running on port 8888, right? Found that coincidentally.
19:25:06 <msvb-lab> But now I'm trying to figure out how to dump a 1Mo JS var to file in the right place to serve it.
19:25:11 <msvb-lab> ...so complicated.
19:25:20 <msvb-lab> arthuredelstein: You know where files are served from?
19:25:58 <msvb-lab> Ehsan suggested doing this all in script via sjs logic.
19:26:00 <arthuredelstein> Mochitest runs a lightweight local http server
19:26:24 <arthuredelstein> You can just write your own html page.
19:26:57 <arthuredelstein> See for example, https://trac.torproject.org/projects/tor/attachment/ticket/13749/0001-Bug-13749.1-regression-tests-for-first-party-isolati.patch
19:27:41 <msvb-lab> arthuredelstein: Yes cool, I'll check it out. Right in the middle of finding the best solution to the data/http prob.
19:27:50 <msvb-lab> ...hoping to get it in by ESR38 cutoff.
19:28:07 <msvb-lab> Next week no other plans by the way, due to other obligations.
19:28:12 <msvb-lab> And that's all for me.
19:28:36 <arthuredelstein> One possibility might be to write an html page with a small script that produces 1 MB of text.
19:29:23 <msvb-lab> arthuredelstein: Yes, the only certainty is producing the data dynamically. To avoid committing a thick blob to HG.
19:30:18 <arthuredelstein> true :)
19:35:07 <mikeperry> ok. so I guess the remaining discussion is the consensus upgrade authentication mechanisms
19:38:14 <MarkSmith> I have basic questions, such as how can I retrieve info that is contained in cached-microdesc-consensus over the control port?
19:38:39 <MarkSmith> e.g., client-versions
19:39:05 <MarkSmith> (I assume the method will be similar for the new package lines)
19:39:54 <mikeperry> so I am looking at control-spec.txt, and I think "getinfo ns/all" should give you what you want, but it seems brittle and possibly subject to change..
19:40:05 <mikeperry> depending on if microdescs are enabled or not.. trying to do a test now
19:40:53 <mikeperry> actually, that appears to not be the full consensus document..
19:41:29 <MarkSmith> yes, it appears to include the OR info but not other items.
19:41:34 <MarkSmith> (I think)
19:43:03 <mikeperry> hrmm. I really thought there was a way to get the consensus from the control port..
19:43:13 <MarkSmith> I see GETINFO dir/status-vote/current/consensus
19:43:32 <MarkSmith> but it says "552 Unrecognized key "dir/status-vote/current/consensus"
19:43:48 <mikeperry> yeah, maybe that's what I used. you have to have a dirport or set some magic option to be a dir mirror to see that I think
19:46:09 <MarkSmith> OK.  I guess my tor has a copy of the microdesc consensus but not a full one… which is where things start to go beyond my Tor knowledge.
19:47:00 <MarkSmith> E.g., microdescriptor vs. full descriptors (I assume the latter has all details about each OR while a microdescriptor has just enough info for clients to use)
19:47:15 <mikeperry> yep
19:47:55 <mikeperry> I wonder if Tor should parse this field for us, and give us a single control port command to get it
19:47:58 <mikeperry> or an event
19:49:26 <MarkSmith> Why would we want an event?  So we know when new consensus info arrives at the client or ?
19:51:29 <mikeperry> yeah
19:52:20 <Yawning> whens's the next 4.5 alpha?
19:52:33 <MarkSmith> OK.  I think Kathy and I will review more of nickm's work for #10395 and maybe start some discussion there about control port access.
19:52:38 <Yawning> (rough is fine)
19:52:45 <GeKo> Yawning: end of february
19:52:54 <mikeperry> yeah, I think I will add a comment right now asking about control port stuff
19:53:01 <GeKo> week before the dev meeting/the dev meeting week
19:53:04 <Yawning> k
19:54:04 <MarkSmith> mikeperry: thanks
19:54:28 <msvb-lab> Will there be a post about the upcoming UX testing?
19:54:40 <msvb-lab> We've had some considerable UI change plans come up recently.
19:54:43 <asn> MarkSmith: are you guys attending the valencia meeting btw? :)
19:54:56 <MarkSmith> asn: unfortunately no.
19:55:04 <asn> oh. pity :(
19:55:07 <jsha> Where can I find docs on how the Transifex -> git integration works?
19:55:19 <Yawning> why does the whonix developer think that we don't package pluggable transports for debian
19:55:31 <mikeperry> MarkSmith: how about the usability sprint at the end of this week?
19:55:36 <jsha> In particular, there's a branch for https_everywhere, and one for https_everywhere_complete. What's the distinction, and which one (as HTTPS Everywhere maintainer) should I be pulling from?
19:55:37 <mikeperry> I see Brade down as a maybe
19:55:54 <MarkSmith> mikeperry: Kathy was planning to attend the UX sprint but those plans fell through as well :(
19:56:10 <mikeperry> ok, no worries. I think arthuredelstein and I will both be there
19:56:19 <MarkSmith> brade says she forgot to update the wiki page
19:56:50 <MarkSmith> We have offered to help analyze data and/or work on summarizing afterwards if that makes sense.
19:57:32 <msvb-lab> asn: I'll see you in Valencia, but arriving on the last day.
19:58:14 <asn> msvb-lab: ah good! pity you are coming on the last day (?)
19:58:25 <asn> dgoulet: i'm afraid i won't be able to read this email before wednesday night,.
19:58:36 <dgoulet> asn: no worry
19:58:43 <msvb-lab> I'm at MWC Barcelona (in paralllel) until then, that's why.
19:59:41 <mikeperry> ok, I think that wraps up the TBB meeting today then
19:59:56 <mikeperry> until next time!
19:59:59 <mikeperry> #endmeeting *baf*