17:59:51 #startmeeting tor browser 17:59:51 Meeting started Mon Jun 19 17:59:51 2017 UTC. The chair is GeKo. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:59:51 Useful Commands: #action #agreed #help #info #idea #link #topic. 17:59:55 hi all! 18:00:04 hi 18:00:04 new week new tor browser meeting 18:00:19 let's start with the usual status updates? 18:00:23 hi everyone 18:00:25 who wants to go? 18:00:28 hi 18:00:33 tagged a new sandbox release 18:00:41 probably the last one for the foreseeable future 18:00:45 the end 18:01:10 my tentative plan is to cease support in the 7.5 stable timeframe 18:01:29 okay. but thanks for the work, yawning, really appreciated 18:02:15 who is next? 18:03:34 * arthuredelstein can go 18:03:44 This week I worked on #22343 and #21999. Unfortunately these patches both have issues so I need to keep working on them. 18:03:44 go 18:03:53 I reviewed some bugzilla.mozilla.org anti-fingerprinting patches and did some more investigation of #22584. And I took 2 days off. 18:04:15 This week I will take M,Tu,W off and work Thursday and Friday. My plan is to continue revising my patches and review a bunch more Mozilla patches. And next week I will be at the all-hands Mozilla meeting to discuss uplift etc. 18:04:24 That's it for me 18:05:50 who is next? 18:06:23 * mcs will go 18:06:29 Last week, Kathy and I did some manual updater testing in preparation for the release of Tor Browser 7.0.1. 18:06:35 Specifically, we tested updates from Tor Browser 6.5.2 to 7.0.1 and from 7.0 to 7.0.1. 18:06:41 We also did some testing of the 7.0.1 updater by tricking the browser into doing a 7.0.1 to 7.0.1 “update.” 18:06:46 We did not find any problems. 18:06:50 We then spent most of our remaining time on #18913 (and we did confirm that resolving that ticket will also fix #21948 and #22535). 18:06:58 Changing about:tor to run with content privileges and to always open in a content process when e10s is enabled turns out to be a somewhat large task, but we are nearly done. 18:07:05 Last week we also helped with bug triage and reviewed some patches, as usual. 18:07:12 This week, we plan to finish the work for #18913 and publish a patch for review. 18:07:16 We also have some non-Tor work to catch up on this week, but if we have time we will work on other tickets marked with tbb-regression or tbb-7.0-issues. 18:07:20 That’s all for us. 18:08:55 * boklm can go next 18:09:06 This past week I helped publish the new releases. I made some patches for #22585 and #22656. 18:09:23 I fixed the svg-enable test in the testsuite and investigated why the Windows marionette tests fail with a timeout on the test server but work in my test VM, but didn't find the solution yet. 18:09:42 This week I'm planning to try fixing the Windows testsuite setup, and work on #22586 and #22587. 18:09:54 That's it for me. 18:10:17 thanks. 18:10:21 i can go: 18:10:41 i spent more time managing bug comments/resulting tickets than i thought 18:10:52 but i think we have them all on file now 18:11:05 (actually one is missing but i'll file that one afterwards) 18:11:19 i did look at patches for #21999 and #22343 18:11:39 i fixed up my patch for #22560 18:11:48 and i worked on #16010 18:12:08 i got the code compiled with sandoxing enabled and it is not exploding in my face 18:12:34 i found stuff that is not working due to the sandboxing patch i applied which is good as it gives me something to start with 18:12:46 this will be one of the main task in the remaining days 18:13:17 other than that i plan to start updating the design doc for tor browser 7 18:13:32 and try to resolve some loose ends before i start my vacation 18:13:37 that's it for me 18:13:58 I can go 18:14:04 oh, i actually updated the relase doc as well 18:14:11 (#21249) 18:14:16 tjr: go! 18:14:29 I have been occupied by high priority non-Tor tasks mostly 18:14:58 The next thing to work on is still the fxc stuff. I'm sure you're not enthused about adding Wine to the reproducible builds but I don't see another way. 18:15:08 (Wine plus the random MSFT dll...) 18:15:25 boah 18:15:27 :( 18:15:42 the binary blobs come faster than we can get rid of them :/ 18:15:53 Jacek just worked through several bugs for us, including the winpthread one so I will work on those next after fxc 18:16:06 Technically you were already trusting this binary blob, you just didn't know it. 18:16:15 yeah, jacek is a hero 18:17:15 well, uhm, i meant the stuff we need for building 18:17:21 Sure 18:17:49 If you wanted to keep wine out of things, you could always build this locally and inject the bytecode into the build (as was done before) - but that's not very transparent :) With wine at least you can say "Well we're building with open source tools and a microsoft signed dll you can reverse engineer or at least confirm it's the same one everyone in the 18:17:49 world is using" 18:18:27 Other than that, no update. Mozilla all-Hands next week, so I will miss this meeting due to travel. 18:19:23 thanks 18:19:33 do we have anyone else for a status update? 18:20:17 let's move on to the discussion part then 18:20:31 i have three items 18:21:03 1) there is this ask-me-anything on reddit at 11am edt this friday 18:21:14 if any of you could make that that would be neat 18:21:17 not really reddit 18:21:24 it's on a slack imitator 18:21:29 oh, okay 18:21:33 "mattermost" 18:21:48 it is organized for the translators on transifex 18:21:52 anyway, i can't and i think it would be neat if anyone of use can be there 18:22:03 so i bet some of the questions will be "what is this string for" and "can you make tor browser do this instead" 18:22:05 I should be able to make that, but haven't seen any details can you send them to me? 18:22:31 I could be there but would also need the details. 18:22:32 (Thats the same time as the Crash Reporter meeting actually, which I didn't mention but is progressing okay) 18:22:32 colin and i will be there as helpdesk and "general tor person" respectively 18:22:37 I might be able to attend as well. I am not 100% sure though. 18:22:55 armadev: could you distribute the details you have? 18:23:11 (or whoever has them= 18:23:14 ) 18:23:32 to arthur, mark, and tom. ok 18:23:37 thanks 18:23:46 2) next meeting time 18:23:59 i won't be there next monday and the monday after that one 18:24:30 if you want to meet here and discuss things and do the usual status updates 18:24:40 that would be perfectly fine 18:25:31 in addition to that (or otherwise) we could do a sync on july 5 1800 UTC 18:25:39 would that work for everyone? 18:26:05 Kathy and I may not be available the week of July 3rd. 18:26:26 Next week is okay for us, but it sounds like several people will be missing 18:26:59 okay. then july 10 and we all do smart things meanwhile? 18:27:45 ah, I'm planning to be afk the week of july 10 18:28:25 Maybe everyone who can should sync up on July 5th? Either way, not everyone will be at a meeting for a while :) 18:29:24 okay, let's do july 5 for a sync 18:29:42 july 5 works for me 18:29:50 if you want to meet before feel free to do do and announce it on tbb-dev :) 18:30:34 or better, let me know until friday 18:31:05 if i don't hear anything about having a meeting earlier i'll announce the next one for july 5 18:31:26 3) the external helper app dialog mess 18:31:58 so, we barely made downloading things usable that need an external helper app 18:32:38 but there are a number of follow-up issues we need to fix to get us to the same feature level as we had with 6.5.2 18:32:51 and some of the fixes are very likely non-trivial 18:33:06 if the external helper app blocker thing is disabled by a pref (if it can be) 18:33:10 will the issues go away 18:33:33 it can and i think the most of the issues should go away 18:33:39 but it is a hack 18:33:41 because if so, I'm gonna disable that shit in the sandbox, because there are no external helpers 18:33:48 what's the pref 18:33:50 to avoid proxy bypass issues 18:34:07 there's no internet access in the sandbox either 18:34:41 extensions.torbutton.launch_warning 18:34:44 thanks 18:35:24 I guess I just tagged so I shouldn't add that to the sandbox, but I'm about:configing it for me >.> 18:35:44 mcs: so what would you suggest? 18:35:47 It may be the case that some of the fixes we made to try to fix the e10s problems will cause issues even when thst pref is set to false. I am not sure though. 18:36:09 as long as the pref, makes trying to download shit less annoying 18:36:15 I'll use the pref 18:36:24 Yawning: less annoying, yes. 18:36:29 Perfect, no. 18:36:36 i was wondering whether we should follow a hybrid approach of getting the most important issue fixed and then focus on solving the underlying problem 18:36:45 mcs: if i wanted perfect, I'db e using chrome 18:36:48 :P 18:36:54 it seems without the latter we won't be happy in the future 18:37:19 are there important issues that can be fixed without ugly hacks that just add technical debty 18:37:28 As far as the larger issue goes, one question is whether it is a requirement that the download pause while the prompt is displayed. 18:37:32 that will come back to bite us later when we want to fix things? 18:37:54 mcs: as long as the open step only happens when they click on things 18:37:59 and if they click cancel, it cleans up 18:38:02 I don't think it matters 18:38:08 whoop de doo, wasted a bit of bandwidth 18:38:23 Also that saves time for the user as well I guess. 18:38:45 mcs: the problem is not pausing the download per se but that external apps might get used without a way to prevent that 18:38:49 That is what Mozilla’s prompts do: entire file may be downloaded,but it is left in a file named random.exe.part 18:39:40 GeKo: Right. I asked because if we decide to rely on Mozilla’s prompt or another one like it, the prompt interaction will be asynchronous (so no pause) 18:40:01 generally that seems not to be a problem to me 18:40:15 guess it'll suck if your box is running a bunch of background crap that's internet away 18:40:17 *aware 18:40:26 that picks up the partial download and does random shit 18:40:33 before you can cancel out 18:40:40 So then we could just rely on Mozilla’s prompt if we trusted that it would always be displayed/ 18:40:52 Yawning: yes, that's true 18:41:13 mcs: i think so 18:41:16 didn't gnome's audio indexer or whatever have issues in this area recently 18:41:30 but, that's still probably preferable to "everything is bsted" 18:41:39 In the past, there were concerns that Mozilla’s prompt was not always displayed although we could try auditing the code and fixiing any problmes (or ask Mozilla to fix them) 18:43:20 In other words, do we need our own prompt? 18:43:55 could be, dunno 18:44:17 i'd like to avoid having an own prompt, though 18:44:33 we should have that fixed in mozilla's code instead 18:44:38 Even if we are pausing the download, there's still a danger that the partially downloaded file is present on disk, correct? 18:46:08 i think this should be no issue for smaller pieces 18:46:18 but am not sure 18:46:29 arthuredelstein: yes, although that is probably why Mozilla gives it a *.part extension during the download (harder for someone to open by mistake) 18:47:03 GeKo: what do you mean by “no issue for smaller pieces”? 18:47:21 i thought they wee kept in memory until a certain size 18:47:26 were 18:47:50 but i have not checked the code for that 18:48:33 I’m not sure but I’ve tested with a 344 byte zip file on OSX and it does show up on disk 18:48:49 okay 18:49:13 mcs: so what about the following plan: 18:49:23 we try to get #22471 fixed 18:49:33 and ignore the other less important pieces 18:49:53 trying instead to figure out how we can get the underlying issue fixed properly 18:49:55 ? 18:50:39 So maybe one approach is to keep or add a .part extension until the user decides to keep the file, even if the whole file has completed downloading. 18:51:15 GeKo: That sounds OK but we may need help from some Mozilla networking people if we can’t figure out how to fix the problem. 18:51:39 arthuredelstein: I think that is what happens today in Firefox when the user is prompted. 18:52:31 mcs: well the alternative would be to avoid wasting even that time and resources and fix the underlying problem right away 18:52:39 mcs: Ah, OK. 18:53:02 mcs: i am actually fine with that approach as well 18:53:12 we already burned weeks on this issue :/ 18:53:28 GeKo: Kathy and I would prefer to spend a little time pursuing the longer term fix and see what we learn 18:53:42 sounds good 18:53:57 maybe what Mozilla has is already close to meeting our requirements 18:54:06 maybe make a new ticket and add stuff you learn? 18:54:13 OK 18:54:45 well there is https://bugzilla.mozilla.org/show_bug.cgi?id=440892 still open 18:54:59 and i recently test the issue and it's still there 18:55:09 *tested 18:55:23 yes, maybe we can create a patch for that :-) 18:55:37 but there might be better shortcuts than the one we have right now... 18:55:45 would be a good first step, yes 18:55:49 ok. 18:55:58 anything else for discussion today? 18:56:35 the blog is full of people who can't run the new tor browser 18:56:43 is that all trusteer rapport whatever 18:56:47 or is there some underlying problem? 18:57:15 GeKo: I assume there is no further action needed on my part regarding the two sandboxing issues I was notified of 18:57:35 the pulseaudio setting in the config now has a huge "(UNSAFE)" warning 18:57:38 and there's the x monstrosity 18:57:43 so far i am inclined to think that's the usual antivirus thing that happens when a new major version comes up 18:57:47 armadev: ^ 18:58:18 that has been tested to the point of "I can open a bunch of tabs and watch stuff on youtube" 18:58:43 Yawning: no, that should be fine 18:58:59 geko: yuck. ok. wonder if next time we should get a crack team of advocates to run the heck out of everything as early as possible, to make antivirus companies more ok with it. 18:59:30 yes, sounds like a good idea 18:59:51 okay, thanks for the meeting all *baf* 18:59:54 #endmeeting