18:00:47 #startmeeting tbb-dev 18:00:47 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 Useful Commands: #action #agreed #help #info #idea #link #topic. 18:02:49 ok, let's get started 18:02:58 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 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 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 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 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 I think that is it for me for now. we can discuss the release plans after everyone gives their update 18:07:58 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 Here is what I did: 18:10:14 I reviewed #15651, #15672 and #13576 + tried to fix our nightly builds #14730 via #15551 18:10:14 Then I worked on #4100, #15578, #15599, #15689 and #15539 18:11:10 I spent some time thinking about #15482 + #15670 18:11:26 it seems we don't actually need the latter and I reverted the patch 18:12:52 this week I plan to get the release moving forward; reply to tbb-dev wrt to the W3C things 18:13:44 and I'll work on #15578 given that we are running out of time there 18:14:10 we'll see what else fits 18:14:17 that's it for now 18:15:12 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 we can avoid that if we do the things the bitcoin people are doing 18:18:56 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 so, this might be our best option for now (the precise thing + the patch idea bitcoin is using) 18:20:17 ok, and wrt AppLocker, that still only affects some enterprise and server editions of windows? 18:20:41 oh, yes, I looked at that, too. 18:21:08 yes, I think so. and only if people restrict by publisher 18:21:41 restricting by hash which is more recommended is working fine (but it is cumbersome for the user) 18:22:11 GeKo: Care to elaborate on 'do the things the bitcoin people are doing'? 18:22:32 https://trac.torproject.org/projects/tor/ticket/15578#comment:1 18:22:44 in particular https://git.thwg.org/wozz/bitcoin/commit/ffc6b678b9d12a8f963ab362b952fd6b7e6c4ec7 18:23:56 we actually only need __fdelt_chk as far as my testing goes 18:25:56 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 Last week, Kathy and I created a revised fix for #11879 which mikeperry merged (thanks!) 18:27:01 We also found and fixed another Tor Launcher bug: #15704. 18:27:10 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 We also triaged some bugs and did some code reviews. 18:27:22 Finally, we made some progress on #14716. 18:27:30 We are now working on a revised patch after receiving some feedback from GeKo. 18:27:36 This week we will finish #14716 (hopefully today) and we will of course help with any other remaining 4.5 issues. 18:27:41 We should also have time to look at #14387 although I suppose it is not urgent. 18:27:47 That's all for us. 18:27:55 kernelcorn: hello 18:28:03 kernelcorn: the other day we were talking about your proposal 18:28:15 kernelcorn: and about where the DNS info gets stored 18:28:21 kernelcorn: (whether it's stored in the normal dirservers or not) 18:28:30 kernelcorn: what's the best document to answer this question and other similar ones/ 18:28:34 kernelcorn: your thesis is way too long 18:28:43 kernelcorn: do you have a small design document? 18:28:48 kernelcorn: if not, can you make one? 18:29:23 kernelcorn: we should get these details done properly before the SoP starts. 18:29:51 * boklm can go next 18:30:05 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 I added an option to select the git repository url (to test a commit in a personal repo) 18:30:12 I have not sent an email to tbb-dev yet as it still need a few improvements before it's ready 18:30:20 This week I'm planning to: 18:30:27 - improve the result emails it's sending 18:30:40 - add an option to test all commits in a branch 18:30:43 - automatically run unit tests on the tag listed in gitian/versions{,.alpha,.nightly} 18:30:56 that's all for me 18:31:55 * arthuredelstein can go next 18:32:27 Last week I worked mainly on #14429. I agree with Mike that preffing it off is a good plan. 18:32:57 I also worked on #15502. Sadly I overlooked things in both attempts at a patch. 18:33:32 Regarding the [ChromeOnly] issue, we can apply it to individual methods in the interface instead. 18:34:12 And then createObjectURL throws `TypeError: URL.createObjectURL is not a function` (I just tested this) 18:34:29 Maybe that's good enough logging in the console? 18:34:43 does that appear in the browser console even if the content script catches the exception? 18:34:45 This week I plan to continue to polish #14429. 18:35:01 No, it probably won't 18:35:44 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 yeah, hrmm.. also a problem 18:36:37 In an alpha, we might want to break pages that way, but I'm not so sure about a release. 18:38:20 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 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 You mean they're a linking vector but not a tracking vector? 18:40:26 mikeperry: agreed 18:41:00 We could create a hybrid that takes createURLObject out of the webworker API. 18:41:05 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 Right 18:41:52 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 or both? 18:42:13 Both 18:42:41 Well, wait, not quite 18:43:22 I should inspect the results again 18:43:29 to make sure I can explain it correctly. 18:43:47 Definitely blob URIs created from webworkers were accessible from webworkers on any domain 18:44:23 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 IIRC 18:44:31 It seems likely that blob URIs not created by webworkers would not be accessible from webworkers. Maybe? 18:44:49 Yes, I think you're right. 18:45:00 (because they would have isolation domains but the webworker ones would not) 18:45:19 Right. The Webworker get and set effectively use "no-first-party" 18:46:22 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 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 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 That's it for me. 18:52:15 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 in the meantime, I can see if I can make weasel and his ilk happier with #15741 18:54:20 is everyone terrified of doing anything different for #15482 other than what we have in 4.5a5? 18:55:06 I respect the fears of GeKo and nickm ;) 18:55:29 mmph 18:56:55 Do we plan to take the latest and greatest fixes for #14429 and leave everything pref'd off? 18:56:56 I am even scared about the stuff we ship in 4.5a5 tbh 18:57:01 ok, I will abandon my insane quest and go to the tor patch workshop instead 19:00:03 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 I see your point. I am not so much worried about the effects for Tor Browser users 19:01:30 I think the benefits outweigh the risks here 19:01:54 but there are other non-Tor Browser uses-cases that are affected by this, too 19:02:27 and who knows what the effects of our change are there 19:03:32 I mean in detail for a particular user with a particular usage pattern etc. 19:04:10 GeKo: are ther? 19:04:21 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 the new behavior is only enabled when isolation is enabled right? 19:04:41 Yawning: yes 19:05:05 but you might get indirect results due to our change 19:05:12 (our hidden service code already updates timestamp_dirty on most usages of hidserv circs) 19:05:27 I think that people that use TBB's tor without understanding what patches are applied onto it, get what they serserve? 19:05:38 *deserve 19:05:43 mikeperry: yeah, maybe, maybe not 19:05:48 dunno 19:06:30 unlimited circuit lifespan kind of scares me 19:07:05 substantatively patched tor in tbb kind of scares me 19:07:20 heh 19:07:25 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 it's usually backports from master 19:07:43 mikeperry: oh that scares me too 19:08:36 everything scares me, guess I'll hide in bed 19:08:37 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 Yawning: haha 19:09:24 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 this is a good point 19:10:20 really, the people that need a tor.exe should be compiling it >.> 19:10:35 I thought we had a gitian descriptor that made a unpatched tor now 19:10:40 for the windows people 19:10:47 no 19:10:56 they get the full flavor, too :) 19:11:06 no? I thought I saw something patch-ish like that attached to one of the tickets 19:11:27 that was only the console issue -mwindows 19:12:22 ah I see 19:17:09 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 those known bad/dangerous behaviors aren't new, right? 19:18:10 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 I think the new behavior is an improvement fwiw 19:21:40 definitely for Tor Browser users, yes 19:24:29 onward and upward then, I say! :) 19:24:33 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 we'll see how it goes I guess, exciting 19:25:38 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 then we tag? 19:26:09 arthuredelstein: let us know if we can help. 19:26:12 can we expect to do that in 24 hours from now? or is it more likely to be 48? 19:26:14 what about #15689? 19:26:19 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 (I assume that nothing horrible has apparently happened with the new obfs4proxy tag) 19:26:49 mikeperry: 24hours should be enough I think (at least from my pov) 19:27:07 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 will do that, I pinged jsha about their plans 19:27:51 Yawning: probably not but we lack nightlies currently, so.... 19:27:52 special: In what sense do they not work properly and how does this new formulation fix the problem? 19:28:20 because microdescriptors don't contain the full exit policy 19:28:32 and the new thing is HS only 19:28:39 and because DNS . 19:29:02 so it's not directly comparable to something that was exit (real intertubes) only 19:29:07 mcs: thanks, will do 19:29:44 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 ok, anything else? 19:31:40 ok 19:31:52 not from me 19:32:06 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 Yawning: made #15743 19:32:41 ok. thanks everyone! 19:32:46 #endmeeting *baf*