18:00:47 <mikeperry> #startmeeting tbb-dev
18:00:47 <MeetBot> Meeting started Mon Apr 20 18:00:47 2015 UTC.  The chair is mikeperry. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:00:47 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
18:02:49 <mikeperry> ok, let's get started
18:02:58 <mikeperry> Last week, I wrote a quick patch to allow users to register Tor browser as a desktop app (#15672), and then spent most of my time trying to improve #15482.
18:03:07 <mikeperry> Wrt #15482, I found a rather severe bug in circuit_is_better(), but that function only seems to be called in 1% of the cases of stream attachment, and the bug is actually in our favor in that it causes SOCKS isolated circuits to continue to be used rather than be selected based on purpose and circuit dirtiness.
18:03:17 <mikeperry> I posted a reduced version of that patch in https://gitweb.torproject.org/mikeperry/tor.git/commit/?h=bug15482-tbb-longer, but I could still be talked off the cliff and convinced to stick with what we have in 4.5a5.
18:03:47 <mikeperry> Wrt the rest of the release, it seems as though we're going to stick with Disconnect as our default search for 4.5 for now. We also need to make a last minute call to decide what to do about #15502 and #15741, and if we want to take the latest #14429 changes but leave them preffed off.  It seems that everything else is ready for release.
18:06:05 <mikeperry> Oh, I think I am going to leave #15514 alone, since it will require a torbutton patch to actually ensure the trimmed whitelist will apply to updated users
18:06:30 <mikeperry> I think that is it for me for now. we can discuss the release plans after everyone gives their update
18:07:58 <mcs> Regarding #15502, when I looked at the proposed patch I overlooked the fact that it affects the entire URL interface (I was thinking it was just blob stuff that was affected, but I was not looking at it correctly).
18:10:05 <GeKo> Here is what I did:
18:10:14 <GeKo> I reviewed #15651, #15672 and #13576 + tried to fix our nightly builds #14730 via #15551
18:10:14 <GeKo> Then I worked on #4100, #15578, #15599, #15689 and #15539
18:11:10 <GeKo> I spent some time thinking about #15482 + #15670
18:11:26 <GeKo> it seems we don't actually need the latter and I reverted the patch
18:12:52 <GeKo> this week I plan to get the release moving forward; reply to tbb-dev wrt to the W3C things
18:13:44 <GeKo> and I'll work on #15578 given that we are running out of time there
18:14:10 <GeKo> we'll see what else fits
18:14:17 <GeKo> that's it for now
18:15:12 <mikeperry> with #15551, are all the hardening issues solved by that pic hack? it sounded like we might also lose the stack protector?
18:17:31 <GeKo> we can avoid that if we do the things the bitcoin people are doing
18:18:56 <GeKo> I am still unsure about it but I guess we won't be able to switch our setup properly tested to debian in the next two weeks
18:19:31 <GeKo> so, this might be our best option for now (the precise thing + the patch idea bitcoin is using)
18:20:17 <mikeperry> ok, and wrt AppLocker, that still only affects some enterprise and server editions of windows?
18:20:41 <GeKo> oh, yes, I looked at that, too.
18:21:08 <GeKo> yes, I think so. and only if people restrict by publisher
18:21:41 <GeKo> restricting by hash which is more recommended is working fine (but it is cumbersome for the user)
18:22:11 <msvb-lab> GeKo: Care to elaborate on 'do the things the bitcoin people are doing'?
18:22:32 <GeKo> https://trac.torproject.org/projects/tor/ticket/15578#comment:1
18:22:44 <GeKo> in particular https://git.thwg.org/wozz/bitcoin/commit/ffc6b678b9d12a8f963ab362b952fd6b7e6c4ec7
18:23:56 <GeKo> we actually only need __fdelt_chk as far as my testing goes
18:25:56 <GeKo> oh and I forgot that I plan to get #15539 ready this week
18:26:23 * GeKo is really done now
18:26:40 * mcs can go next
18:26:55 <mcs> Last week, Kathy and I created a revised fix for #11879 which mikeperry merged (thanks!)
18:27:01 <mcs> We also found and fixed another Tor Launcher bug: #15704.
18:27:10 <mcs> We looked at #15145 and made a mockup.  More comments are welcome (this is not something we need for 4.5 though).
18:27:17 <mcs> We also triaged some bugs and did some code reviews.
18:27:22 <mcs> Finally, we made some progress on #14716.
18:27:30 <mcs> We are now working on a revised patch after receiving some feedback from GeKo.
18:27:36 <mcs> This week we will finish #14716 (hopefully today) and we will of course help with any other remaining 4.5 issues.
18:27:41 <mcs> We should also have time to look at #14387 although I suppose it is not urgent.
18:27:47 <mcs> That's all for us.
18:27:55 <asn> kernelcorn: hello
18:28:03 <asn> kernelcorn: the other day we were talking about your proposal
18:28:15 <asn> kernelcorn: and about where the DNS info gets stored
18:28:21 <asn> kernelcorn: (whether it's stored in the normal dirservers or not)
18:28:30 <asn> kernelcorn: what's the best document to answer this question and other similar ones/
18:28:34 <asn> kernelcorn: your thesis is way too long
18:28:43 <asn> kernelcorn: do you have a small design document?
18:28:48 <asn> kernelcorn: if not, can you make one?
18:29:23 <asn> kernelcorn: we should get these details done properly before the SoP starts.
18:29:51 * boklm can go next
18:30:05 <boklm> I added some documentation about how to request unit tests run: https://trac.torproject.org/projects/tor/wiki/doc/TorBrowser/Hacking#Requestingtestingofacustombuildusingthetbb-qa.ymlfile
18:30:09 <boklm> I added an option to select the git repository url (to test a commit in a personal repo)
18:30:12 <boklm> I have not sent an email to tbb-dev yet as it still need a few improvements before it's ready
18:30:20 <boklm> This week I'm planning to:
18:30:27 <boklm> - improve the result emails it's sending
18:30:40 <boklm> - add an option to test all commits in a branch
18:30:43 <boklm> - automatically run unit tests on the tag listed in gitian/versions{,.alpha,.nightly}
18:30:56 <boklm> that's all for me
18:31:55 * arthuredelstein can go next
18:32:27 <arthuredelstein> Last week I worked mainly on #14429. I agree with Mike that preffing it off is a good plan.
18:32:57 <arthuredelstein> I also worked on #15502. Sadly I overlooked things in both attempts at a patch.
18:33:32 <arthuredelstein> Regarding the [ChromeOnly] issue, we can apply it to individual methods in the interface instead.
18:34:12 <arthuredelstein> And then createObjectURL throws `TypeError: URL.createObjectURL is not a function` (I just tested this)
18:34:29 <arthuredelstein> Maybe that's good enough logging in the console?
18:34:43 <mikeperry> does that appear in the browser console even if the content script catches the exception?
18:34:45 <arthuredelstein> This week I plan to continue to polish #14429.
18:35:01 <arthuredelstein> No, it probably won't
18:35:44 <arthuredelstein> I guess what concerns me about leaving createObjectURL in, and logging from it, is that now pages can't properly fall back
18:36:18 <mikeperry> yeah, hrmm.. also a problem
18:36:37 <arthuredelstein> In an alpha, we might want to break pages that way, but I'm not so sure about a release.
18:38:20 <mikeperry> yeah. I really don't like the tagging properties of blob urls, but they don't appear to be a strict third party tracking vector, and your previous patch would at least handle the unconstrained script execution case..
18:39:05 <mikeperry> I am somewhat leaning towards taking the partial isolation patch for 4.5-stable, and trying to improve it later for WebWorkers
18:39:12 <arthuredelstein> You mean they're a linking vector but not a tracking vector?
18:40:26 <GeKo> mikeperry: agreed
18:41:00 <arthuredelstein> We could create a hybrid that takes createURLObject out of the webworker API.
18:41:05 <mikeperry> yeah, the use of GUIDs by themselves only lets you link a small set of users.. it's not like you get to control or predict what the guid values will be, so you have to maintain a list of all of the guids of users you want to track/link
18:41:29 <arthuredelstein> Right
18:41:52 <mikeperry> arthuredelstein: yeah. what was the nature of the failure? was it that bloob uri's created from webworkers were not properly isolated, or was it that webworkers could access all blob uris?
18:42:06 <mikeperry> or both?
18:42:13 <arthuredelstein> Both
18:42:41 <arthuredelstein> Well, wait, not quite
18:43:22 <arthuredelstein> I should inspect the results again
18:43:29 <arthuredelstein> to make sure I can explain it correctly.
18:43:47 <arthuredelstein> Definitely blob URIs created from webworkers were accessible from webworkers on any domain
18:44:23 <arthuredelstein> I think the patch does prevent a blob URI created on a page from being accessed by a web workers and vice versa.
18:44:26 <arthuredelstein> IIRC
18:44:31 <mcs> It seems likely that blob URIs not created by webworkers would not be accessible from webworkers.  Maybe?
18:44:49 <arthuredelstein> Yes, I think you're right.
18:45:00 <mcs> (because they would have isolation domains but the webworker ones would not)
18:45:19 <arthuredelstein> Right. The Webworker get and set effectively use "no-first-party"
18:46:22 <mikeperry> if that is the case, altering the idl to only disallow createObjectURL from webworkers and also taking the isolation patch seems like an OK stopgap
18:47:33 <arthuredelstein> Yes, I'll see if that's doable. I have the impression that fixing the web worker case will be easier in FF38.
18:48:52 <arthuredelstein> So I'll work on that patch this week, as well as more #14429, and anything else needed for the release. Also I'll look more at #15196.
18:49:18 <arthuredelstein> That's it for me.
18:52:15 <mikeperry> ok, my original goal was to have a build tag for 4.5-stable today, but it seems like it still may be another day or so. #15502 seems worth waiting for, as does #15539
18:53:27 <mikeperry> in the meantime, I can see if I can make weasel and his ilk happier with #15741
18:54:20 <mikeperry> is everyone terrified of doing anything different for #15482 other than what we have in 4.5a5?
18:55:06 <mcs> I respect the fears of GeKo and nickm ;)
18:55:29 <Yawning> mmph
18:56:55 <mcs> Do we plan to take the latest and greatest fixes for #14429 and leave everything pref'd off?
18:56:56 <GeKo> I am even scared about the stuff we ship in 4.5a5 tbh
18:57:01 <mikeperry> ok, I will abandon my insane quest and go to the tor patch workshop instead
19:00:03 <mikeperry> I think the vanilla behavior is much, much worse on balance.. it makes usability much worse, it exposes users to the whole exit population if they leave an AJAXy website tab open for too long, and opens them up to more forms of guard discovery attacks
19:01:18 <GeKo> I see your point. I am not so much worried about the effects for Tor Browser users
19:01:30 <GeKo> I think the benefits outweigh the risks here
19:01:54 <GeKo> but there are other non-Tor Browser uses-cases that are affected by this, too
19:02:27 <GeKo> and who knows what the effects of our change are there
19:03:32 <GeKo> I mean in detail for a particular user with a particular usage pattern etc.
19:04:10 <Yawning> GeKo: are ther?
19:04:21 <mikeperry> well, the 4.5a5 behavior is very similar to existing hidden service circuit usage.. so we may actually be giving those folks more cover from traffic analysis
19:04:23 <Yawning> the new behavior is only enabled when isolation is enabled right?
19:04:41 <GeKo> Yawning: yes
19:05:05 <GeKo> but you might get indirect results due to our change
19:05:12 <mikeperry> (our hidden service code already updates timestamp_dirty on most usages of hidserv circs)
19:05:27 <Yawning> I think that people that use TBB's tor without understanding what patches are applied onto it, get what they serserve?
19:05:38 <Yawning> *deserve
19:05:43 <GeKo> mikeperry: yeah, maybe, maybe not
19:05:48 <Yawning> dunno
19:06:30 <Yawning> unlimited circuit lifespan kind of scares me
19:07:05 <special> substantatively patched tor in tbb kind of scares me
19:07:20 <Yawning> heh
19:07:25 <mikeperry> I get differentiation, but I don't understand why vague fears of infinite circuit lifespan are more scary than hitting every exit in the network if you leavr your browser open overnight
19:07:30 <Yawning> it's usually backports from master
19:07:43 <Yawning> mikeperry: oh that scares me too
19:08:36 <Yawning> everything scares me, guess I'll hide in bed
19:08:37 <special> Yawning: arguably, it's a version of tor that gets less visibility/attention but is used by more people than mainline tor.
19:08:46 <GeKo> Yawning: haha
19:09:24 <nickm> My understanding is that for a bunch of windows people, the tbb tor.exe is the only tor.exe that they use.
19:10:15 <GeKo> this is a good point
19:10:20 <Yawning> really, the people that need a tor.exe should be compiling it >.>
19:10:35 <Yawning> I thought we had a gitian descriptor that made a unpatched tor now
19:10:40 <Yawning> for the windows people
19:10:47 <GeKo> no
19:10:56 <GeKo> they get the full flavor, too :)
19:11:06 <Yawning> no?  I thought I saw something patch-ish like that attached to one of the tickets
19:11:27 <GeKo> that was only the console issue -mwindows
19:12:22 <Yawning> ah I see
19:17:09 <mikeperry> I dunno, I am still inclined to take the minimal possible change that avoids several instances of known bad/dangerous behavior rather than hold back due to fears of the potential existence of unknown second-order/non-tbb side-effects..
19:17:32 <special> those known bad/dangerous behaviors aren't new, right?
19:18:10 <mikeperry> they were outside of our ability to address them prior to TBB 4.5, due to the lack of SOCKS u+p isolation
19:19:01 <Yawning> I think the new behavior is an improvement fwiw
19:21:40 <GeKo> definitely for Tor Browser users, yes
19:24:29 <mikeperry> onward and upward then, I say! :)
19:24:33 <blanu> So there's a lot of terminology discussion on tor-dev today about "direct onion" services. How is this different from an exit enclave?
19:25:11 <GeKo> we'll see how it goes I guess, exciting
19:25:38 <mikeperry> ok. let's wrap up this meeting. I will work on #15741, arthuredelstein will take #15502 (maybe with some help from mcs+brade?), and GeKo will prepare #15539
19:25:44 <mikeperry> then we tag?
19:26:09 <mcs> arthuredelstein: let us know if we can help.
19:26:12 <mikeperry> can we expect to do that in 24 hours from now? or is it more likely to be 48?
19:26:14 <GeKo> what about #15689?
19:26:19 <special> blanu: this proposal is about a different type of hidden services that trade server-side anonymity for performance/reliability, imagine facebookcorewwi.onion. exit enclaves had similar usecases, but they don't work properly (and haven't for a long time).
19:26:38 <Yawning> (I assume that nothing horrible has apparently happened with the new obfs4proxy tag)
19:26:49 <GeKo> mikeperry: 24hours should be enough I think (at least from my pov)
19:27:07 <mikeperry> GeKo: ah, yes. we can merge #15689 if it matches the eff.org xpis.. but we should keep an eye on that matching status
19:27:29 <GeKo> will do that, I pinged jsha about their plans
19:27:51 <GeKo> Yawning: probably not but we lack nightlies currently, so....
19:27:52 <blanu> special: In what sense do they not work properly and how does this new formulation fix the problem?
19:28:20 <Yawning> because microdescriptors don't  contain the full exit policy
19:28:32 <Yawning> and the new thing is HS only
19:28:39 <nickm> and because DNS .
19:29:02 <Yawning> so it's not directly comparable to something that was exit (real intertubes) only
19:29:07 <arthuredelstein> mcs: thanks, will do
19:29:44 <mikeperry> GeKo: I will also work on changelogs today. I guess we need to consolidate all changes since 4.0 for the blog post, too. I will take care fo that
19:30:37 <mikeperry> ok, anything else?
19:31:40 <GeKo> ok
19:31:52 <GeKo> not from me
19:32:06 <blanu> Yawning: I have several obfs4proxy issues to discuss with you, but I can no longer attend PT meetings since they were moved to a time when I cannot attend. Are you available to discuss now? Or do you want me to send you an email?
19:32:21 <asn> Yawning: made #15743
19:32:41 <mikeperry> ok. thanks everyone!
19:32:46 <mikeperry> #endmeeting *baf*