19:00:12 #startmeeting tor browser 19:00:12 Meeting started Tue Feb 20 19:00:12 2018 UTC. The chair is GeKo. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:00:12 Useful Commands: #action #agreed #help #info #idea #link #topic. 19:00:16 hi all! 19:00:40 this week is the meeting everyone was longing for i guess :) 19:00:46 yay GeKo is back! and no chemspills in the interim :) 19:00:49 hi 19:00:57 o/ 19:01:01 heh 19:01:02 good morning! 19:01:02 hi 19:01:12 the pad is, as usual, at https://storm.torproject.org/shared/tHoN4Ii7rLSjPE0OP4gydX4cMGadsXmRQNc-6lwru0N 19:01:20 ! 19:01:27 please fill in your items and start reading over the ones already written 19:01:37 mark those you want to discuss in bold 19:04:47 hi everyone! 19:06:25 alright 19:06:30 let's start 19:06:36 it seems tjr is first today 19:06:51 GeKo: is there a discussion part of the pad? 19:06:53 I fill in my stuff over the course of the week and then everyone fills in below me :( 19:07:00 isabela: not yet :) 19:07:03 hehe 19:07:16 it seems there is not much for that up yet this week 19:07:17 So in -central we have a patch that 'fixes' the keyboard layout leak 19:07:39 Except it turns out it doesn't work well and still leaks (Bug https://bugzilla.mozilla.org/show_bug.cgi?id=1438795) 19:08:08 And it turns out it breaks Copy/Paste shortcuts on what I presume are (some?) non-US-lang keyboards: https://bugzilla.mozilla.org/show_bug.cgi?id=1433592 19:08:17 People asked that it be backed out because of that actually 19:08:39 This seems like something we need to get fixed so ESR meets TB's acceptence criteria 19:09:06 Except I don't know anything about this keyboard layout stuff, so I'm hoping someone can walk me through it and/or help with it. Not during the meeting I don't think though. 19:09:53 i think arthur would indeed be the candidate for doing that 19:10:22 Cool 19:10:29 Next one: the MinGW Build on -central doesn't run. 19:10:38 This is also important to get fixed for TB :) 19:11:05 I looked below about the Vista debugging Richard did 19:11:17 Am I correct in thinking it was all printf-based? No windbg or gdb-on-windows? 19:11:20 (glad to discuss keyboard layout stuff right after this meeting) 19:11:38 tjr: yeah apparently there's another flag i need to pass to my mozconfig for symbols not get stripped out 19:11:46 tjr: so i had the feeling dmajor helped you with that 19:11:57 so i've been doing traces with env variables like a chump 19:11:59 where are you and what help would you need? 19:12:29 Yea, dmajor has been really helpful in showing us _where_ the crash is, and everyone once in a while what it is. But basically I've been really lucky so far in that him, jacek, or someone else does a driveby with "Oh this is the problem" 19:12:43 And now my luck's run out I think. So I know where it's asserting, but no idea why. 19:13:33 okay. did you do some debugging with gdb so far? 19:13:45 like using a non-debug build with symbols 19:13:54 So I've never been able to get gdb on windows to work, so I'm curious if you can! 19:14:08 yes 19:14:12 I use a mingw gdb.exe I download (not one from cygwin) 19:14:31 But the error I get early on is https://searchfox.org/mozilla-central/source/xpcom/build/PoisonIOInterposerBase.cpp#226 19:14:31 there are precompiled things, yes 19:15:08 Which I believe is entirely unrelated to anything I'm working on, and is just some debugging helper thing that assumes if you're debugging on Windows you're not doing something weird like mingw 19:15:25 Have you hit that before? It seems old enough that it's in esr52 too 19:15:28 weird, i did not hit that with mingw gdb 19:15:41 everything 'worked' just didn't have symbols 19:15:54 built with rbm nightly-windows-i686 19:16:00 granted this is on Vista 19:16:29 tjr: no. so, that's with --enable-debug? 19:16:42 Yes. You know I bet it's something that's only in debug builds. 19:16:54 what happens with --disable-debug? 19:17:05 that would be my first start to test 19:17:30 given that the bug you are working on is orthogonal to debug/non-debug 19:18:26 Yea. I just set up opt non-debug builds in Tc today so it'll be easy to get builds 19:18:41 but, yes, i can try to help if you are still stuck 19:19:15 Dumb question but might save me some time, pospeselr can you pastebin a printf line? e.g. are you fprintf to a file or printf to a console, or something? 19:19:44 lol yeah one sec 19:20:00 Other than that, there is a draft help page for Mozilla's Fingerprinting Protection page, if anyone wants to read/comment on it 19:20:08 That's it for me. 19:20:28 tjr: https://pastebin.com/ZpBZhCN2 basically paste this at the top of whatever module I'm in and go 19:20:43 mcs: you are up 19:21:19 I am not sure why the #19910 text is bold... 19:21:25 tjr: i've been using a log module recently and then doing MOZ_LOG() where needed 19:21:40 iirc i looked for an easy example on MDN and it worked for me 19:21:41 So I don’t really have anything to discuss. 19:21:44 I wanted to ask about #19910 19:22:02 it seems this likely causes a performance regression, right? 19:22:23 it could be, yes 19:22:44 So wondering if there were thoughts about what we can do. Should we be working on #5915? Or is there a way to fix the tor browser patch so it no longer has a race condition? 19:24:09 arthuredelstein: i think comment:22 in #19910 is the way to go 19:24:24 the backout won't hit stable before august 19:24:38 and meanwhile we should have a 0.3.4 with this stuff fixed 19:25:11 0.3.4 with a 5915 fix? 19:25:36 Sounds good to me, thanks 19:25:52 well, that would be my plan 19:26:18 i think we should ask networking people about it and make sure it's on their radar 19:26:35 Agreed. I’d feel better if an owner was assigned :) 19:26:42 right 19:27:12 true, but i am not sure how the networking folks are dealing with that 19:27:16 I do wonder if the 3875 patch might be fixable (I haven't looked carefully), because the proposed 5915 fix also has potential problems 19:27:21 maybe a keyword is enough? 19:27:49 So we might want to look into that in parallel with the network team 19:27:59 i bet a proper fix for #3875 is pretty complicated 19:28:14 from the browser side that is 19:28:26 moreover, it's not just a thing the browser wants 19:28:35 but other applications as well 19:29:21 arthuredelstein: i guess we could ask mozilla's necko folks about what they think? 19:30:03 we could. I actually would prefer a 5915 fix for the reason you give. But I worry it has bad UX. 19:30:18 how so? 19:31:10 Well, the most naive solution is just shutting the down the socket if the server doesn't respond. But the browser reacts not by showing an error message, but seemingly waiting forever. 19:31:15 At least that's what happened when I tried it. 19:31:53 yeah,ideally the application explicitly supports sending opportunistic data and handles the failure gracefully 19:32:14 we had it in the old version of torsocks, too 19:32:21 We could serve our own error message HTML page from the tor proxy, but that requires design, translations, etc. And then we're back to a browser-specific solution again. 19:32:22 but we haven't added it into the new version yet 19:32:33 because it's also a pain implementing it transparently 19:32:46 hm, i see 19:33:10 sysrqb: Maybe there's a way for tor to send a protocol-level error message to the browser such that it correctly display a "failed to connect" error? 19:33:26 That would be ideal rather than duplicating the browser's error page in the tor proxy. 19:33:43 arthuredelstein: maybe? that could work 19:33:55 but tor won't know all the protocols it's proxying 19:34:06 so that won't scale well, in general 19:34:25 but i guess it could support all the official Tor Project applications? 19:34:30 I guess I'm not sure when a socket closes if there's any way to return an out-of-band error message. But this is probably a discussion for after the meeting. 19:34:37 but that could get messy... 19:34:57 i think the control socket is the way to detect that 19:34:58 arthuredelstein: agreed 19:35:06 sure 19:35:10 Could it return an error in a message in the socks protocol. A message backwards compatible such that correctly-implementing socks protocol clients will ignore it? 19:35:45 tjr: nah, everything after the handshake completes is only application protocol 19:35:50 socks is done after that :/ 19:35:57 okay, i have reviews marked bold 19:36:08 i need two small ones for tomorrow to get the release going 19:36:22 it's for #25000 and #25215 19:36:58 Kathy and I tried to review #25000 but so far we can’t make the problem go away even when NoScript is disabled :( 19:36:59 boklm: and if you could look at #22612 that would be good as well 19:37:08 GeKo: ok 19:37:21 mcs: do you have 5.1.8.4 installed? 19:37:31 because that's what i needed 19:37:48 it seems giorgio fixed some edges cases i hit 19:38:12 Yes but shouldn’t the test add-on work if NoScript is disabled? (I fear I don’t understand the bug although it seems somewhat simple). 19:38:48 Anyway, Kathy and I will keep looking at #25000 19:39:02 aha! so what i tested is the https-everywhere preferences on about:addons 19:39:10 they are fixed with the patch 19:39:15 Okay. We can test that :) 19:39:28 and i duped that over because i thought those were the same issues 19:39:41 (and see if more than one problem is going on) 19:39:44 i guess i'll look again at the extension 19:39:45 thanks 19:39:51 sysrqb: you are up 19:40:26 Okay, last week we briefly started discussing the future of Orfox 19:40:49 and whether we should start releasing Orfox in parallel to Tor Browser 19:40:58 while we continue working on Tor brwoser for Adnroid 19:41:07 there is some risk here 19:41:15 in that any bugs in Orfox become our problem 19:41:33 but the current roadmap has TBA release in July/August 19:41:42 which is not soon 19:42:08 and the Guardian Project will be maintaining Orfox until then 19:42:19 (assuming we don't take over) 19:42:25 how much work is involved in that? 19:42:42 I don't think it is much work 19:42:53 I think we can rebase the current patches onto tor-browser.git 19:43:07 and we can create our own releases 19:43:16 they won't be reproducible 19:43:29 well we need some build setup and need access to the google app store etc 19:43:33 but maybe we can easily identify what causes differences and account for that 19:43:49 yes, i think we can get that information form n8fr8 19:44:00 but i haven't talked with him yet 19:44:08 i wanted the team's opinion first 19:44:17 let's do that in rome and then come up with a plan? 19:44:24 sure, we can do that 19:44:29 that is soon anyway 19:44:35 yep 19:44:43 cool 19:44:58 ok. igt0 you are up 19:45:41 hey, so are we going to disable the sync background service in the TB mobile? 19:45:47 (pospeselr: i assumed i answered your question; feel free to ping me if there is still stuff needed) 19:46:33 GeKo: yep I'm good, trying it out now :) 19:46:44 sysrqb: i forgot to ask: what's up with the orfox patch merge into tor-browser? 19:47:00 it seems we are close for a couple of weeks now :) 19:47:45 GeKo: ah, yes, they are done, and working on ESR52 19:47:55 igt0: well, i guess we want to do the same as we do on desktop to start with 19:48:05 GeKo: but we moved the goal post :) 19:48:23 now we will probably skip ESR and go straight to nightly 19:48:50 ok. we had this as deliverable in our DRL proposal 19:48:52 but I stopped working on that until igt0 and I finish the mobile design doc/roadmap 19:49:07 and i just want to make sure this is not falling through the cracks 19:49:21 hmm 19:49:41 what would it hurt having those patches in tor-browse.git 19:49:45 okay, so wehould we finish esr rebase and merge that before moving onto m-c? 19:49:57 especially if we are thinking to provide orfox maintenance 19:50:05 i think only they're not reproducible 19:50:17 i don't see much other harm 19:50:35 you mean they would cause reproducibility issues for desktop? 19:50:42 no, only mobile 19:50:47 well, that's okay 19:50:57 they don't touch much oustide mobile/ 19:51:02 *outside 19:51:07 okay 19:51:18 i can work with igt0 and finish that 19:51:18 GeKo, okey, so the https://bugzilla.mozilla.org/show_bug.cgi?id=942652 is a requirement for TB mobile. 19:51:42 so, i think if it's not too much work, post a patch in the ticket and we just merge them to tor-browser and are done 19:51:57 okay, sgtm 19:51:57 and can make a check behind the deliverable 19:52:08 and we would be prepared to take over orfox 19:52:30 okay 19:54:03 igt0: i think i am not following. let's talk about that after the meeting? 19:54:14 GeKo, yep 19:54:28 arthuredelstein: you are up 19:55:22 I wanted to ask if anyone has any particular comments about patches remaining for uplift. See list at https://torpat.ch/short 19:55:35 One question I have: Do we want to try to get 1382359 (our 21321) done for ESR60? 19:55:56 There is no need to uplift #22614 (Mozilla already removed the API in Firefox 56 that we pref’d out). 19:56:19 arthuredelstein: yes, iam working on that one 19:56:22 mcs: thanks, good to know. So we won't need it in TBB/ESR60 either, right? 19:56:28 i have a patch that is working 19:56:31 correct 19:56:37 GeKo: OK, sounds good. 19:56:44 i just need to find the time to write the additional tests 19:57:06 my plan is to get this finally done this week 19:57:21 and then rebased onto m-c 19:57:21 Another question for mcs and brade is that in my hands the unit test for #18912 seems to be failing when I rebase it to mozilla-central. 19:57:45 It's looking for a certain error code, but maybe that's changed. I don't know where the error code is used by us, though. 19:59:14 We can maybe discuss that later though. 19:59:18 sounds good 19:59:22 isabela: you are up 19:59:26 ok! 19:59:38 really quick - i think we should start organizing our life in rome! 19:59:39 :) 19:59:56 specially for team meeting day, so i want to create pads for agendas etc 20:00:08 thanks, please do 20:00:09 just want to let folks know and i can continue this via email too 20:00:50 that was it :) 20:01:00 do we have a schedule document for Rome somewhere? 20:01:07 Does everyone know the mozilla attendee list? ethan, tim, gary, steven e., patrick mcmanus 20:01:20 arthuredelstein: we do for the team meeting day 20:01:24 let me get it for you 20:01:24 okay, regarding the group nick discussion tbb-team sounds fine to me 20:01:30 tjr: no, thanks 20:02:02 tjr: you meant tom, not tim right? 20:02:07 :) 20:02:20 arthuredelstein: https://ethercalc.org/zil3cf5nm9ge 20:02:22 No; Tim. As in I'm not going, but Tim Huang is 20:02:27 isabela: thanks! :) 20:02:28 i mean organize the agendas of these meetings 20:02:51 tjr: so what's the state of the folks from the uplift team 20:03:00 as i am seeing ethan on the list, too 20:03:12 (assuming it's the same ethan) 20:03:30 same ethan, tim and gary :) 20:03:33 I'm not entirely sure; but I think Ethan might be in the 'apply for a work visa' stage. I believe he's not allowed to work while apply for that. 20:03:55 I think Ethan was going to be the guinea pig for the process, and tim and gary would follow? Not 100% sure. 20:04:02 But yea, all same people as Arthur said. 20:04:07 ok, neat 20:04:18 do we have anything else for today? 20:05:00 sounds not. thanks all for the meeting that lasted a bit longer than an hours :/ *baf* 20:05:04 #endmeeting