18:59:48 #startmeeting tor-browser 18:59:48 Meeting started Mon Feb 5 18:59:48 2018 UTC. The chair is GeKo. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:59:48 Useful Commands: #action #agreed #help #info #idea #link #topic. 18:59:57 hi all and welcome to a new meeting 19:00:01 hi everyone 19:00:20 :) 19:00:23 the meeting pad is asusual at https://storm.torproject.org/shared/tHoN4Ii7rLSjPE0OP4gydX4cMGadsXmRQNc-6lwru0N 19:00:41 please fill in your updates in case you did not have yet and read through the things mentioned there 19:00:44 o/ 19:00:56 good morning! 19:01:25 o/ 19:01:33 sorry i couldnt meet last wed 19:01:46 hi all 19:03:19 np -- are you better? 19:04:49 yes i am :) 19:06:00 alright 19:06:06 sysrqb: you are up 19:06:15 GeKo: yep! 19:07:13 so, small patches for running try builds 19:07:19 any objections to that? 19:07:30 i can open a ticket for review 19:07:48 but anything I should think about while I'm doing this? 19:08:08 So you're proposing patches so that tor-browser.git can pass try without many changes? 19:08:59 arthuredelstein: more like patches so the builds use our .mozconfig* 19:09:05 rather than the in-tree mozconfigs 19:09:12 which use different configure options 19:10:04 Hm 19:10:06 hm 19:10:09 :) 19:10:12 does that make sense? 19:10:17 This is for android I assume? 19:10:25 i was thinking about in general 19:10:51 Okay. So the intree config for mingw is https://searchfox.org/mozilla-central/source/browser/config/mozconfigs/win32/mingw32 and I maintain that 19:11:07 it seems like we'd want to run the test suite against the tor browser we're shipping 19:11:20 rather than a debug/release config that include the wrong options 19:11:29 Okay, so I think that's a different thing from modifying the mozconfig 19:11:48 We could (probably) get the Tor Browser build going in Try and then run the unit test suite with it 19:12:11 yeah 19:12:30 It would be a build off tor-browser.git; maybe using reproducible builds maybe not, but definetly using your toolchain 19:12:30 i have it nearly working now 19:12:40 hmm 19:12:44 a 19:12:45 ah 19:12:59 that would be a bit more involved than my plan 19:13:05 but maybe better 19:13:08 Isn't boklm doing something like this? 19:13:23 basically i was just thinkig we could run try builds using our mozconfigs 19:13:36 like, right now the gtk2 build fails on try 19:14:01 because on try, it builds with -Werror and there are some unused ariables 19:14:04 Oh boy, now we're going down a rabbit hole - what's the gtk2 build? And why does the mozconfig affect it? 19:14:05 variables 19:14:10 so small thinks like that 19:14:26 Tor Browser bulds with gtk2... 19:14:27 builds 19:14:36 sysrqb: i am not sure that's worth the effort 19:15:31 I.... don't think the mozconfig is controlling that. Well, unless your cascading through mozconfigs and picking up ac_add_options --enable-warnings-as-errors 19:15:33 it seems like runnign try builds with the wrong mozconfig could give a false result 19:15:59 tjr: seems like --enable-warnings-as-error defaults as true if MOZ_AUTOMATION=1 19:16:25 Yes, that's correct. You'll want to get ac_add_options --disable-warnings-as-errors in your mozconfig if you're building with MinGW 19:16:56 yeah makes sense 19:17:11 maybe this is a bit of a rabbit hole 19:17:38 If we want to run the test suite with Tor Browser though - I think we should replicate the torb browser build process as closely as possible though. Which would involve using the toolchain, stuff like the gcc spec thing you're doing: https://gitweb.torproject.org/builders/tor-browser-bundle.git/tree/gitian/descriptors/windows/gitian-utils.yml#n93 19:17:52 yeah 19:18:01 Right now I'm trying to get the MinGW build running without that type of toolchain stuff, using just a 'vanilla' mingw setup 19:18:21 And my hope is that this will knock one or two of the weird things you have to do off 19:18:21 sysrqb: i think we should revisit that once we start using esr60 19:18:24 I was looking for an easy win 19:18:27 Although the spec one probably not. 19:18:30 GeKo: okay, fine with me 19:18:39 to see how much is neede to get that going 19:18:43 Also trying to get jemalloc supporting in mingw 19:18:44 starting from a "clean slate" 19:19:00 and thinking whether the effort is worth it 19:19:08 yes, makes sense 19:19:26 tjr: cool 19:19:47 okay, point 2, we should create a roadmap for Tor Browser for Android 19:20:11 what functionality/qualities should it have before we release? 19:20:25 the key items are: 19:20:31 1) reporoducible builds 19:20:42 2) same day releases as desktop browser 19:20:55 3) same tracking/fingerprintin defenses as desktop 19:21:05 4) same security properties 19:21:27 (this includes things like showing the browser window only after tor got configured) 19:21:34 5) same usability 19:21:50 we could and should break those down, agreed 19:22:04 but I think the DRL proposal explained what we wanted 19:22:14 Okay, so integrating Tor Launcher is a requirement 19:22:24 okay, I haven;t seen the proposal 19:22:25 i wonder if i should send that around so that we can start thinking from that on 19:22:30 (might be useful) 19:22:39 yeah, can you please? 19:22:39 +1 19:22:46 i'll dig up the latest thing i have and send it to you folks 19:22:52 * GeKo makes a note 19:23:18 igt0 and I discussed las month whether we should ship the first release with requiring Orbot 19:23:31 or integrate Tor Launcher 19:23:44 we thought integrating TL would add a lot more time 19:23:57 I was thinking it would be useful for sysrqb and igt0 to write up a short document on their overall plan/design/roadmap to make sure we're all on the same page. 19:23:57 so using Orbot (as Orfox currently does) would allow us to ship earlier 19:24:19 but if TL is neded, then we'll put that as a blocker for shipping 19:24:23 *needed 19:24:27 sysrqb: feel free to argue for it 19:24:33 what arthur said 19:24:43 yeah 19:24:58 It would also remove the Guardian Project off the hook for maintenance sooner. 19:25:00 Froma usability perspective, I think using TL is good 19:25:01 i'd especially like to understand the benefits and disadvantages 19:25:09 of get them off the hook :) 19:25:12 mcs: that's a good point 19:25:15 yeah 19:25:30 I think working on a new mobile interface will take time 19:25:32 so, i general i would be amenable doing the first alpha with orbot 19:25:51 it's an alpha after all 19:26:07 and a bunch of the new stuff could already get tested while we are working on a tighter tor integration 19:26:13 I don't particularly like requiring Orbot, but it could be a small stopgap while we still work on the new integration 19:26:25 yeah 19:26:43 okay, that sounds good 19:26:52 so, write up what you have in mind with some analysis and post it to tbb-dev? 19:26:54 I'll work with igt0 on a roadmap 19:27:04 yes, we'll do that 19:27:11 It could be useful to think about what can be a "Minimum Viable Product", as distinct from final goals of perfect parity with tbb desktop 19:27:17 i'll send you guys the proposal i have and you can incorporate things from it 19:27:25 yes 19:27:26 arthuredelstein: exactly, agreed 19:27:36 GeKo: thanks 19:27:45 (maybe an MVP would just be an alpha; idk) 19:28:20 if we ship an alpha, then we can improve on that 19:28:26 but at least we have something out the door 19:28:45 but we can discuss this more on the mailing list 19:29:14 sysrqb: okay, your last item is for isabela? 19:29:45 (i don't want to consume all the meeting time on this topic, if there's more to discuss) 19:29:59 urg, lag 19:30:02 GeKo: yes 19:30:07 isabela: did you see that? 19:30:27 we can discuss that on the mailing list, too 19:30:51 i just want to make sure we're on the same page for UI work 19:30:58 sounds good 19:31:29 but i'm good, thanks 19:31:37 we can move on 19:31:41 k 19:31:59 igt0: re your issue 19:32:07 sysrqb: ops no 19:32:19 * antonela is lurking 19:32:33 sorry sysrqb 19:32:35 reading backlog 19:32:39 i think getting about:tor to work in mobile constraints sounds like a good idea 19:32:47 there is no design document for it 19:33:00 yes 19:33:04 if there are a bunch of changes needed we should talk to the ux folks 19:33:08 about:tor should be responsive design 19:33:18 Maybe do something minimal with about:tor for now while we await a Great New Design? 19:33:22 but we will redo all about:tor 19:33:28 mcs: +1 19:33:30 mcs: yes 19:33:34 that sounds good 19:33:50 we are taking that with the introduction of circuit displays new location 19:34:08 temporary fix till new about:tor is out there 19:34:53 great, the current about:tor page UX looks simple enough to fit in the mobile screen. (The two white boxes could be vertical aligned in the mobile version). 19:35:06 yep 19:35:09 +1 19:35:34 sysrqb: btw i also think is ok to get an alpha out there, i am happy to test apks too 19:35:44 the onion browser startup screens are super cute 19:35:45 isabela: thanks :) cool 19:35:55 ( antonela: hi! :) ) 19:36:03 arthuredelstein: +1 19:36:12 hi :) i was talking with igt0 about those 19:36:13 and I'd like to do something similar 19:36:26 but that'll take some time to port over to android 19:36:39 the circuit display? 19:36:41 and if we want a similar experience on desktop 19:37:13 that'll all go into a tor launcher redesign, i think 19:37:15 Maybe we could display some of the Onion Browser graphics on the Tor Launcher desktop progress screen since we have space :) 19:37:25 (someday) 19:37:36 yeah 19:37:36 so 19:37:40 about that 19:38:07 i think we should think about it a bit more because onion browser was fixing a problem with the restrains of a experience 19:38:21 yeah, for sure 19:39:15 but i think it's a nicer and more friendly experience than the current design 19:39:28 i think the idea is good but i would prefer to have better feedback on progress bar that leads to easily debugging from user 19:39:32 if they have issued 19:39:34 I think we will learn a lot from the TBA work and some ideas can be fed back into desktop later. 19:39:34 *issues 19:39:38 like we were moving on with. 19:39:48 yep 19:39:51 agreed on the progress bar feedback issue 19:40:13 I do too. I just liked the artistry in onion browser but I don't think we want to do exactly the same thing 19:40:36 and for onboarding i would like to talk about the product features and where they are how to use them 19:40:43 arthuredelstein: yes! 19:40:53 arthuredelstein: antonela is on process of getting tor illustrations ! 19:41:03 yay! :) 19:41:03 nice! 19:41:11 ux has been cooking a whole visual strategy for illustration 19:41:21 yes, is part of the website redesign work 19:41:23 Mmmm 19:41:57 so user can see a illustration and connect the dots, like where we talk about relays or bridges or onion services 19:42:26 i think we should for sure spend some time in rome talking about all this 19:42:42 sounds good 19:42:53 and make sure everyone is on the same page on things like this because I know ppl have tons of ideas too :) 19:43:21 okay 19:43:37 let's move on. it seems my item is the next one unanswered 19:44:01 so, it seems we have crashes exclusively on windows vista related to us enabling content sandboxing on windows 19:44:15 which is quite unfortunate even though vista is long EOL 19:44:35 i think we should fix that somehow and have been pondering what to do 19:44:48 do we have a ticket #? 19:44:57 Have we confirmed that disabling sandboxing avoids the crash? 19:44:58 #25112 19:45:05 thanks 19:45:14 i know from at least one user that the alpha is working for them 19:45:35 and the error messages we got as feedback strongly indicate some sandbox related issue 19:46:02 So our choices are to debug and fix it or disable the sandbox on Vista? 19:46:23 i think queation 1) would be if any of us has a vista system still around to confirm that from first hand 19:46:27 mcs: yes 19:46:45 if am torn to be honest 19:47:00 On the one hand the Vista people probably need a sandbox; on the other hand, they should upgrade their OS. 19:47:15 yes 19:47:25 is Vista even getting security updates anymore? 19:47:41 no 19:47:48 ewwwwww 19:47:56 nor does xp 19:48:02 But Windows 7 does? 19:48:04 yet both are supported with est52 19:48:05 yes 19:48:14 *esr52 19:48:42 well worse case scenario someone can always throw up a Vista VM to debug in 19:49:11 extended support for Win7 ends in about 2 years (so says https://support.microsoft.com/en-us/help/13853/windows-lifecycle-fact-sheet) 19:50:01 okay. does anyone of us feel like they want to look closer into that? 19:50:11 because i won't have the cycles 19:50:27 yeah I can do 19:50:33 awesome 19:50:55 ping me if you got things going and need some help with debugging 19:51:09 because debugging that on windows is not easy 19:51:19 for one debug builds are not running :) 19:51:48 but maybe i just don't know all those windows debugging sekrits... 19:51:52 thanks 19:51:56 heh 19:52:03 let's move on do the "discussion" 19:52:16 do we have symbols for windbg or am I gonna have to figure out how to use gdb on windows? 19:52:26 most importantly: which seesions do we want to have at the meeting day 19:52:29 pospeselr: the latter 19:52:34 awesome sauce 19:52:39 yeah 19:53:17 i worked around that by using mozilla's own logging without any debugger to get the sandbox build going 19:53:26 it might be faster that way 19:53:33 ok. meeting day 19:53:47 we have the roadmapping but what else 19:54:01 ux is free to hang out with yall 19:54:09 we will do our thing before the 11 19:54:22 Will we have any Mozilla coordination meetings that day? Will Mozilla people be there? 19:54:59 Some Mozilla people will be there 19:55:13 :) 19:55:14 assuming we want to start at 11am (i guess we could do 10am as well?) 19:55:16 (have we heard anything re Ethan and company?) 19:55:26 we have 6 slots 19:55:27 * isabela would suggest to leave roadmap for the end of the day as other discussions might actually help w/ it 19:55:40 or 5 if there are some short breaks 19:55:59 isabela: sounds good 19:55:59 hard stop at 5 - as folks will need a break before dinner thing 19:56:10 or go to the vegas meeting 19:56:16 :) 19:56:30 I am not sure if it makes sense for the team day, but I’d love for someone to teach me about Android vs. Deskop Firefox architecture/constraints/etc. 19:56:43 +1 19:56:47 (I guess teaching / chaulk talk could go both ways) 19:56:49 mcs: sure 19:56:54 we can do a run through that day 19:57:00 (or another day, if we're fully booked) 19:57:04 +1 19:57:14 another one we mentioned last time is a fingerprinting discussion 19:57:25 yeah 19:58:00 so i think 1) roadmapping 2) ux team coordination 3) fingerprinting 4) mozilla coordination should be on the list 19:58:10 then we'd have 1-2 additional slots 19:58:35 what about a retrospective meeting? 19:58:39 I'm not sure if security slider/noscript goes under ux 19:58:41 We might also think about “What could the Network Team do that would help us make Tor Browser better?” (and then talk to them later about the items we dream up). 19:58:43 is it worth having a discussion about anhardening? 19:58:51 (I will share a place to start drafting roadmap like we did before montreal) 19:58:51 Restrospective might be good to do. 19:58:53 about things that went well and what did not go well? 19:59:22 +1 on that 19:59:26 yes, +1 19:59:27 okay, let's try the retrospective one ad item 5) 19:59:36 *as 19:59:50 also +1 for meeting with the networing team 20:00:03 but may not be a long meeting 20:00:49 okay, thanks for the input i'll think a bit harder about it and then add the items we want to have 20:00:59 finall thing on the pad: next meeting 20:01:08 i'll be afk next week (i hope) 20:01:27 and i heard that the 19th is a public US holiday!1!! 20:01:45 sooo, i'd propose to move the meeting on tuesday 20th same time same place 20:01:54 does that work for everyone? 20:02:04 good for me 20:02:12 yep 20:02:25 works for me 20:02:38 works for me! 20:02:44 me too 20:03:00 great. tjr? sounds good too? 20:03:26 Sure 20:03:26 i'll send an update on the mailing list announcing the change 20:03:30 great 20:03:45 so, we are late but are there any items we forgot to talk about? 20:04:12 okay, if not, then *baf* and thanks for the meeting 20:04:17 #endmeeting