15:01:01 <mikeperry> #startmeeting
15:01:01 <MeetBot> Meeting started Fri Jun 27 15:01:01 2014 UTC.  The chair is mikeperry. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:01:01 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
15:01:04 <Yawning> ffffff
15:01:20 <mikeperry> The TBB meeting now hereby comes to disorder
15:01:23 <mjuarez> haha, ok, let's talk after the meeting..
15:01:44 <mikeperry> I can go first with my update
15:03:03 <Yawning> mjuarez: does the code on bitbucket build/work?
15:03:18 <Yawning> well work, I guess since it's scripts
15:03:19 <mikeperry> this week I worked on funding proposals, re-read a bunch of website traffic fingerprinting and padding defense papers and tried to distill them into a common set of padding+messaging primatives, reviewed Giorgio's work on NoScript's new url-bar based "cascading" script permissions, and prepped 4.0-alpha-1
15:04:14 <mikeperry> 4.0-alpha-1 will include the new NoScript changes, which I think will really help usability in terms of making it easier to run with scripts mostly disabled (for the security slider), but we'll want to watch closely for corner cases
15:05:07 <mjuarez> Yawning: yes, now should be working..
15:05:14 <Yawning> kk
15:05:50 <mikeperry> next week will be the dev meeting. looking forward to talking to a lot of people about a lot of things
15:05:53 <infinity0> asn: my student's code is giving this in obfsproxy 2014-06-27 16:07:30,273 [ERROR] Invalid SOCKS version: '4'
15:05:58 <infinity0> what do i do with that?
15:06:01 <mikeperry> I am also crazy enough to think that we can put out 4.0-alpha-1 next week
15:06:13 <mikeperry> I think that's it for me
15:06:29 <Yawning> infinity0: don't use SOCKS4?
15:06:41 <infinity0> i thought obfsproxy supported socks4?
15:06:45 <Yawning> no
15:06:49 <Yawning> it used to
15:07:03 <Yawning> but that changed months ago
15:07:09 <infinity0> oh, why did we get rid of it?
15:07:24 * MarkSmith can go next
15:07:37 <infinity0> oh i'll come back later sorry
15:07:45 <MarkSmith> This week, Kathy Brade and I triaged bugs and added TorBrowserTeam201406 and TorBrowserTeam201407 keywords.
15:07:52 <MarkSmith> We spent some time working on requirements for an update responder script/program for #4234.
15:08:09 <MarkSmith> We worked on assorted TBB bugs including #11023 (closed), #12454 (newly opened), and #11471.
15:08:19 <MarkSmith> For the last one, a general fix is difficult but we have a partial solution that will improve things;
15:08:21 <MarkSmith> we plan to land it on Tor Launcher master (for TBB 4.x) next week.
15:08:34 <MarkSmith> Next week we will not be at the dev meeting; we will be out of the office part of the week (due to a prior commitment).
15:08:40 <MarkSmith> We plan to share the #4234 update responder requirements with a few people.
15:08:42 <GeKo> :(
15:08:55 <MarkSmith> Yes, sorry.
15:09:04 <MarkSmith> That's it for us.
15:09:37 <asn> Yawning: mjuarez: hello. i'm not very intelligent today. jet lagged and undeslept; i'm practically a zombie.
15:10:02 <asn> Yawning: mjuarez: I understand how the "new class object per connection" model can be problematic for you
15:10:19 <mikeperry> oh, I also tagged a set of tickets for our team radar
15:10:20 <mikeperry> https://trac.torproject.org/projects/tor/query?status=!closed&keywords=~TorBrowserTeam201406
15:10:43 <mikeperry> if you're working on anything, try to tag it with a monthly tag like that so everyone can see it easily
15:11:05 <mikeperry> and we should consider tickets in that set to be a priority if you're looking for something random to fix
15:11:11 <asn> Yawning: a potential solution would be to save the transportConfig somewhere during setup(), and use it to carry permanent state?
15:11:28 <asn> Yawning: or just change obfssproxy completely to _not_ make a new object per connection?
15:11:32 <Yawning> asn: should only be one tls conection per channel anyway
15:11:40 <GeKo> #12237 sounds quiute ambitious for June :)
15:11:44 <Yawning> because that's what tor does
15:11:46 <GeKo> *quite even
15:12:00 <mikeperry> on monday/tuesday we'll shift those over to TorBrowserTeam201406
15:12:06 <mikeperry> err TorBrowserTeam201407
15:12:19 <GeKo> I can go next.
15:12:26 <mikeperry> GeKo: this tag will be a rolling thing
15:12:42 <boklm> we'll rename TorBrowserTeam201406 to TorBrowserTeam201407 ?
15:12:42 <mikeperry> if we don't get to items, we just retag them at the end of the month if we still want to aim for fixing them
15:12:45 <mikeperry> otherwise just untag
15:12:47 <mikeperry> yes
15:12:53 <boklm> ok
15:13:13 <mikeperry> so each month we'll do a review of the set of things and add/remove things based on that discussion
15:13:22 <Yawning> asn: personally not too worried about it because the system ths is being prototyped for (hypotethcal modifications to the tor link protocol) won't have this issue
15:13:53 <GeKo> One major part of my work was getting VTV enabled builds to "work". Well, they do not crash anymore but the issues remain.
15:13:58 <mikeperry> we also can do that shift in this meeting if there is time, since some people won't be at the dev meeting next week
15:14:13 <GeKo> I though of debugging at least one to make MoCo engineers aware of them but failed so far
15:14:34 <GeKo> I am not sure yet why. Even the help of the VTV author did not make a difference yet
15:14:54 <mjuarez> Yawning: yeah, that's true..
15:14:57 <GeKo> but she is quite helpful and we are still looking for the cause of my failures so far.
15:15:45 <GeKo> the other thing hat consumed a lot of my time was getting the best out of the patch mess in #9268 and propose a new, better one.
15:16:07 <GeKo> I think I achieved that and there shuold only be corner-corner cases left
15:16:24 <mjuarez> Yawning: does managed or unmanaged make any different in this?
15:16:31 <GeKo> testing is welcome (especially on displays with a non-standard DPI value)
15:16:33 <mjuarez> *difference
15:17:16 <GeKo> then I started the "we-need-to-adapt-our-toolchain-for-Fx-XX-ESR"-dance
15:17:25 <GeKo> and filed first bugs
15:17:27 <Yawning> uh, I need to see how you're setting everything up for testing
15:17:42 <GeKo> GCC 4.4 is now definitely too old for Linux
15:17:55 <GeKo> so we need to a new compiler, I think ideally GCC 4.9.0
15:18:08 <GeKo> which we would use for our hardened builds as well.
15:18:30 <GeKo> might be wortwhilehaving that one for mingw-w64 based builds, too.
15:18:38 <mjuarez> Yawning: it's in the webfp_tests.py module
15:19:03 <GeKo> then I worked on #9531 and am currently testing a possible fix on as many platforms I can
15:19:15 <mjuarez> Yawning: I use the classes from tester.py to run the PT's client and server
15:20:04 <mjuarez> and then run tor proxy and tor bridge as in https://tor.stackexchange.com/questions/2157/how-to-run-pluggable-transports-in-unmanaged-mode
15:20:11 <GeKo> finally, I made a Mac OS X debug build for mrphs. Maybe we finally find out what is behind #10533.
15:20:43 <GeKo> Next week is dev meeting and we'll see how we (re-)prioritie (my) work if that is needed.
15:20:51 <Yawning> ah I see
15:21:03 <Yawning> shouldn't make a difference, but my brain is not fully booted up yet
15:21:24 <mjuarez> Yawning: okay, np.. :)
15:21:33 <GeKo> so no current plans for me besides testing my fix for #9531 further.
15:21:50 <mjuarez> Yawning: so, one issue is that since there are so many instances of the Transport
15:21:57 <GeKo> MarkSmith: I wonder whether we should fold #10804 into #9531 as it is actually the same issue I think.
15:22:05 <mjuarez> Yawning: each transports register one observer in the shim..
15:22:12 <GeKo> the latter has all the analysis at least
15:22:18 <mjuarez> and then I get multiple notifications for each event..
15:22:19 <MarkSmith> GeKo: probably
15:22:28 <GeKo> and I think about fixing the start-up thing, too.
15:22:34 <Yawning> mjuarez: yeah I can see the problem
15:22:41 <Yawning> hmm hmm hmm
15:22:44 <mjuarez> which I think it would make more sense having just one transport for the session
15:22:59 <GeKo> that's it from me for now.
15:23:04 <Yawning> *nods*
15:23:48 <mjuarez> Yawning: btw, I'm not unregistering the observer anywhere now..
15:24:17 * boklm can go next
15:24:25 <mjuarez> I was hesitant on where to do it
15:24:44 <boklm> This week I have been doing more ansible stuff: https://github.com/boklm/tbts-ansible
15:24:51 <boklm> And looked more at the issues to get the test suite working on windows
15:25:19 <boklm> next week, I will be at the dev meeting
15:25:43 <boklm> that's it for me
15:26:34 <isis> yay, ansible. awesome.
15:27:08 <mikeperry> yeah, that sounds really cool for helping people set up their own testing instances
15:27:23 <Yawning> mjuarez: there's a cirtuitDestroyed hook
15:27:24 <boklm> yes
15:28:06 <Yawning> *circuit
15:28:11 <mjuarez> Yawning: yes, I saw that. I played a bit with it.. it seems it's called multiple times
15:28:29 <Yawning> ffff
15:28:36 <mjuarez> while circuitConnected is only called once..
15:29:21 <mjuarez> (I guess..)
15:30:36 <mikeperry> ok, who's next?
15:30:37 <Yawning> hmm, keep track of if you removed already in your transport implementation
15:30:57 <mjuarez> Yawning: yes, okay, it makes sense
15:31:00 <Yawning> (or yolo it and just squelch the ValueError)
15:31:42 <mikeperry> support?
15:31:53 <GeKo> see tbb-dev mail
15:31:54 <mikeperry> did mttp say he was going to be out this week? I think he did
15:32:07 <mikeperry> ah, ok
15:32:56 <mikeperry> ok. sounds like we have a tbb-branding ticket
15:33:42 <GeKo> we have tickets for both issues
15:33:57 <mikeperry> ah, ok. are they already tagged with tbb-branding?
15:34:25 <mjuarez> Yawning: btw, I committed with some last changes. I moved the the shim subparser from pyobfsproxy, so that each specific defense would implement it if needed
15:34:50 <Yawning> ok
15:34:57 <mikeperry> for 4.0-alpha-1, based on this meeting, we have the following items to merge still:
15:35:02 <GeKo> #10864 not yet
15:35:07 <mjuarez> so, buflo it's now adding the subparser and creating the instance of the shim
15:35:12 <mikeperry> - https://trac.torproject.org/projects/tor/ticket/9268
15:35:13 <mikeperry> - Bind #10819's thirdparty pref to Torbutton UI
15:35:13 <mikeperry> - https://bugs.torproject.org/11471
15:35:47 <Yawning> mjuarez: sounds good to me, the integration was just an example, and that sounds better
15:36:01 <mikeperry> re #10864, the optimistic data SOCKS patch makes it hard for us to convey specific error info
15:36:16 <mjuarez> Yawning: ok, great :)
15:37:06 <GeKo> mikeperry: but we can pacth that error page depening on the URL bar domain.
15:37:13 <GeKo> *depending
15:37:22 <mikeperry> yeah, possibly
15:37:26 <GeKo> we can adjust the text if we have a .onion
15:37:52 <GeKo> I remember doing similar things for FoxyProxy back then
15:38:11 <GeKo> so that should not be that hard to do...
15:38:19 <GeKo> (famous last words)
15:38:23 <mikeperry> heh
15:40:46 <msvb-lab> Want to hear about #3246?
15:41:02 <GeKo> mikeperry: btw you merged #10819 already, no?
15:41:52 <GeKo> ah, yes, Torbutton UI, nvm
15:41:56 <mikeperry> are there any other tickets we should be adding to the (now july) radar?
15:42:04 <mikeperry> yes, I did. I will do the Torbutton UI bits
15:42:15 <mikeperry> msvb-lab: sure
15:42:24 <msvb-lab> This week I tested the rebased (to Dan Witte and Georg's) third-party cookie patch #3246 which failed to confirm what we want: cross origin identifier unlinkability with functional federated login.
15:42:27 <msvb-lab> I'll only be at the dev meeting for a couple days, so next week I hope to be able to find the root of the problem.
15:42:31 <msvb-lab> To do that, I'll examine the mozIThirdPartyUtil.getFirstPartyURI API and debug the rebased patch accordingly.
15:42:37 <msvb-lab> mikeperry: Can you think of any reason the getFirstPartyURI() function would be flawed? Seems it's not used anywhere.
15:42:40 <msvb-lab> Unless it's something in Mozilla-central that is rendering double-keyed logic in
15:42:43 <msvb-lab> effective.
15:42:45 <msvb-lab> Dan Witte (the originator of this logic) isn't available unfortunately, so if anyone has worked with Mozilla cookies and federated login they're welcome to give advice.
15:42:51 <msvb-lab> Anyway, I wasn't expecting the patch to fail after rebasing and 'should playing with it and see how it behaves for us.'
15:42:56 <msvb-lab> But I've tagged the bug 'TorBrowserTeam201407' which I assumes 'ready for integration by the end of July.'
15:43:01 <msvb-lab> Sorry for such a long winded ramble, that's it for me.
15:43:19 <n3d> Hello everyone, I’m writing an analysis tool for Tor malware. I’m interested to intercept the messages the malware sends through the tor proxy and read it in clear so that I can be able to reverse the communication protocol.
15:43:24 <GeKo> what's exactly the issue?
15:43:28 <n3d> I’m doing so injecting a DLL in TOR.exe and hooking a couple of functions. With connection_ap_handshake_rewrite_and_attach I am able to read the .onion. With connection_write_to_buf_impl_ I read some pkts but I think not all of them and some are also encrypted. Can someone help me?
15:44:01 <msvb-lab> GeKo: After patching the code to introduce double keys, federated logins act as if all third party cookies are rejected.
15:44:27 <msvb-lab> ...regardless of the network.cookie.cookieBehavior value.
15:44:54 <msvb-lab> Take away the rebased patch, and federated logins work as long as we allow third party cookies to transmit across domains.
15:45:04 <GeKo> what happens if you set it to allow all cookies and go to ip-check.info?
15:45:17 <GeKo> what does the cookie column say?
15:46:00 <GeKo> did you have some logs showing whether the cookies are sent in these contexts at all?
15:46:26 <msvb-lab> Wireshark was not helping, but...
15:47:02 <msvb-lab> ip-check.info states 'This web site may receive cookies from you, Rating: medium.'
15:47:10 <GeKo> ok
15:47:21 <msvb-lab> That's with the patch applied and network.cookie.cookieBehavior = 0 (allow all cookies)
15:47:31 <GeKo> good.you might wanto to use LiveHTTPHeaders
15:47:41 <GeKo> in your browser to log the requests
15:47:49 <GeKo> and look for associated cookies
15:48:27 <msvb-lab> Part of the 'Tools/Web Developer'? inspector or where do I find that?
15:48:52 <msvb-lab> Never mind, I'll figure it out. Thanks for the advice.
15:48:58 <GeKo> on AMO
15:49:11 <GeKo> https://addons.mozilla.org/en-us/firefox/addon/live-http-headers/
15:49:40 <msvb-lab> Anyway, the idea to integrate #3246 in 4.0-alpha-1 might be a litle ambitious considering the required debugging still needed.
15:50:07 <GeKo> there is always a next alpha :)
15:51:04 <mikeperry> do we have a dcf1? what should we doo about the meek tag? just go with 0.8?
15:51:50 <GeKo> mikeperry: I'd add #12460 to the July tasks. The experience with the last Fx upgrade told me to start early with this stuff.
15:52:11 <GeKo> even if not all patches are rebased by then.
15:52:25 <mikeperry> ok good call
15:52:48 <GeKo> I don't know if 0.8 works at all. I've sent him a mail today morning.
15:54:08 <mikeperry> ok.
15:54:10 <GeKo> I think we maybe can wait until Monday with a decision?
15:54:40 <mikeperry> yeah
15:55:08 <mikeperry> well, we should see if we can get a matching build first maybe
15:55:48 <mikeperry> like at your EOD today, we should just take what we have and both start a build
15:56:00 <mikeperry> with 0.8
15:56:12 <GeKo> fine by me.
15:58:30 <mikeperry> ok
15:58:37 <mikeperry> I think that pretty much wraps it up then?
15:58:49 <mikeperry> can't wait to see most of you next week
15:59:03 <GeKo> yeah, same here
15:59:08 <Yawning> not sure how to read the 'most'
15:59:10 <Yawning> :P
15:59:16 <mikeperry> hah
15:59:16 <GeKo> ha
15:59:35 <mikeperry> you know what I mean....
15:59:45 <mikeperry> #endmeeting *baf*