17:59:51 <GeKo> #startmeeting tor browser
17:59:51 <MeetBot> 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 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
17:59:55 <GeKo> hi all!
18:00:04 <mcs> hi
18:00:04 <GeKo> new week new tor browser meeting
18:00:19 <GeKo> let's start with the usual status updates?
18:00:23 <arthuredelstein> hi everyone
18:00:25 <GeKo> who wants to go?
18:00:28 <boklm> hi
18:00:33 <Yawning> tagged a new sandbox release
18:00:41 <Yawning> probably the last one for the foreseeable future
18:00:45 <Yawning> the end
18:01:10 <Yawning> my tentative plan is to cease support in the 7.5 stable timeframe
18:01:29 <GeKo> okay. but thanks for the work, yawning, really appreciated
18:02:15 <GeKo> who is next?
18:03:34 * arthuredelstein can go
18:03:44 <arthuredelstein> 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 <GeKo> go
18:03:53 <arthuredelstein> 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 <arthuredelstein> 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 <arthuredelstein> That's it for me
18:05:50 <GeKo> who is next?
18:06:23 * mcs will go
18:06:29 <mcs> Last week, Kathy and I did some manual updater testing in preparation for the release of Tor Browser 7.0.1.
18:06:35 <mcs> 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 <mcs> 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 <mcs> We did not find any problems.
18:06:50 <mcs> 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 <mcs> 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 <mcs> Last week we also helped with bug triage and reviewed some patches, as usual.
18:07:12 <mcs> This week, we plan to finish the work for #18913 and publish a patch for review.
18:07:16 <mcs> 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 <mcs> That’s all for us.
18:08:55 * boklm can go next
18:09:06 <boklm> This past week I helped publish the new releases. I made some patches for #22585 and #22656.
18:09:23 <boklm> 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 <boklm> This week I'm planning to try fixing the Windows testsuite setup, and work on #22586 and #22587.
18:09:54 <boklm> That's it for me.
18:10:17 <GeKo> thanks.
18:10:21 <GeKo> i can go:
18:10:41 <GeKo> i spent more time managing bug comments/resulting tickets than i thought
18:10:52 <GeKo> but i think we have them all on file now
18:11:05 <GeKo> (actually one is missing but i'll file that one afterwards)
18:11:19 <GeKo> i did look at patches for #21999 and #22343
18:11:39 <GeKo> i fixed up my patch for #22560
18:11:48 <GeKo> and i worked on #16010
18:12:08 <GeKo> i got the code compiled with sandoxing enabled and it is not exploding in my face
18:12:34 <GeKo> 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 <GeKo> this will be one of the main task in the remaining days
18:13:17 <GeKo> other than that i plan to start updating the design doc for tor browser 7
18:13:32 <GeKo> and try to resolve some loose ends before i start my vacation
18:13:37 <GeKo> that's it for me
18:13:58 <tjr> I can go
18:14:04 <GeKo> oh, i actually updated the relase doc as well
18:14:11 <GeKo> (#21249)
18:14:16 <GeKo> tjr: go!
18:14:29 <tjr> I have been occupied by high priority non-Tor tasks mostly
18:14:58 <tjr> 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 <tjr> (Wine plus the random MSFT dll...)
18:15:25 <GeKo> boah
18:15:27 <GeKo> :(
18:15:42 <GeKo> the binary blobs come faster than we can get rid of them :/
18:15:53 <tjr> Jacek just worked through several bugs for us, including the winpthread one so I will work on those next after fxc
18:16:06 <tjr> Technically you were already trusting this binary blob, you just didn't know it.
18:16:15 <GeKo> yeah, jacek is a hero
18:17:15 <GeKo> well, uhm, i meant the stuff we need for building
18:17:21 <tjr> Sure
18:17:49 <tjr> 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 <tjr> world is using"
18:18:27 <tjr> Other than that, no update. Mozilla all-Hands next week, so I will miss this meeting due to travel.
18:19:23 <GeKo> thanks
18:19:33 <GeKo> do we have anyone else for a status update?
18:20:17 <GeKo> let's move on to the discussion part then
18:20:31 <GeKo> i have three items
18:21:03 <GeKo> 1) there is this ask-me-anything on reddit at 11am edt this friday
18:21:14 <GeKo> if any of you could make that that would be neat
18:21:17 <armadev> not really reddit
18:21:24 <armadev> it's on a slack imitator
18:21:29 <GeKo> oh, okay
18:21:33 <armadev> "mattermost"
18:21:48 <armadev> it is organized for the translators on transifex
18:21:52 <GeKo> anyway, i can't and i think it would be neat if anyone of use can be there
18:22:03 <armadev> 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 <tjr> I should be able to make that, but haven't seen any details can you send them to me?
18:22:31 <arthuredelstein> I could be there but would also need the details.
18:22:32 <tjr> (Thats the same time as the Crash Reporter meeting actually, which I didn't mention but is progressing okay)
18:22:32 <armadev> colin and i will be there as helpdesk and "general tor person" respectively
18:22:37 <mcs> I might be able to attend as well. I am not 100% sure though.
18:22:55 <GeKo> armadev: could you distribute the details you have?
18:23:11 <GeKo> (or whoever has them=
18:23:14 <GeKo> )
18:23:32 <armadev> to arthur, mark, and tom. ok
18:23:37 <GeKo> thanks
18:23:46 <GeKo> 2) next meeting time
18:23:59 <GeKo> i won't be there next monday and the monday after that one
18:24:30 <GeKo> if you want to meet here and discuss things and do the usual status updates
18:24:40 <GeKo> that would be perfectly fine
18:25:31 <GeKo> in addition to that (or otherwise) we could do a sync on july 5 1800 UTC
18:25:39 <GeKo> would that work for everyone?
18:26:05 <mcs> Kathy and I may not be available the week of July 3rd.
18:26:26 <mcs> Next week is okay for us, but it sounds like several people will be missing
18:26:59 <GeKo> okay. then july 10 and we all do smart things meanwhile?
18:27:45 <boklm> ah, I'm planning to be afk the week of july 10
18:28:25 <mcs> 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 <GeKo> okay, let's do july 5 for a sync
18:29:42 <boklm> july 5 works for me
18:29:50 <GeKo> if you want to meet before feel free to do do and announce it on tbb-dev :)
18:30:34 <GeKo> or better, let me know until friday
18:31:05 <GeKo> if i don't hear anything about having a meeting earlier i'll announce the next one for july 5
18:31:26 <GeKo> 3) the external helper app dialog mess
18:31:58 <GeKo> so, we barely made downloading things usable that need an external helper app
18:32:38 <GeKo> 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 <GeKo> and some of the fixes are very likely non-trivial
18:33:06 <Yawning> if the external helper app blocker thing is disabled by a pref (if it can be)
18:33:10 <Yawning> will the issues go away
18:33:33 <GeKo> it can and i think the most of the issues should go away
18:33:39 <GeKo> but it is a hack
18:33:41 <Yawning> because if so, I'm gonna disable that shit in the sandbox, because there are no external helpers
18:33:48 <Yawning> what's the pref
18:33:50 <GeKo> to avoid proxy bypass issues
18:34:07 <Yawning> there's no internet access in the sandbox either
18:34:41 <GeKo> extensions.torbutton.launch_warning
18:34:44 <Yawning> thanks
18:35:24 <Yawning> 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 <GeKo> mcs: so what would you suggest?
18:35:47 <mcs> 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 <Yawning> as long as the pref, makes trying to download shit less annoying
18:36:15 <Yawning> I'll use the pref
18:36:24 <mcs> Yawning: less annoying, yes.
18:36:29 <mcs> Perfect, no.
18:36:36 <GeKo> 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 <Yawning> mcs: if i wanted perfect, I'db e using chrome
18:36:48 <Yawning> :P
18:36:54 <GeKo> it seems without the latter we won't be happy in the future
18:37:19 <Yawning> are there important issues that can be fixed without ugly hacks that just add technical debty
18:37:28 <mcs> 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 <Yawning> that will come back to bite us later when we want to fix things?
18:37:54 <Yawning> mcs: as long as the open step only happens when they click on things
18:37:59 <Yawning> and if they click cancel, it cleans up
18:38:02 <Yawning> I don't think it matters
18:38:08 <Yawning> whoop de doo, wasted a bit of bandwidth
18:38:23 <arthuredelstein> Also that saves time for the user as well I guess.
18:38:45 <GeKo> 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 <mcs> 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 <mcs> 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 <GeKo> generally that seems not to be a problem to me
18:40:15 <Yawning> guess it'll suck if your box is running a bunch of background crap that's internet away
18:40:17 <Yawning> *aware
18:40:26 <Yawning> that picks up the partial download and does random shit
18:40:33 <Yawning> before you can cancel out
18:40:40 <mcs> So then we could just rely on Mozilla’s prompt if we trusted that it would always be displayed/
18:40:52 <GeKo> Yawning: yes, that's true
18:41:13 <GeKo> mcs: i think so
18:41:16 <Yawning> didn't gnome's audio indexer or whatever have issues in this area recently
18:41:30 <Yawning> but, that's still probably preferable to "everything is bsted"
18:41:39 <mcs> 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 <mcs> In other words, do we need our own prompt?
18:43:55 <GeKo> could be, dunno
18:44:17 <GeKo> i'd like to avoid having an own prompt, though
18:44:33 <GeKo> we should have that fixed in mozilla's code instead
18:44:38 <arthuredelstein> 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 <GeKo> i think this should be no issue for smaller pieces
18:46:18 <GeKo> but am not sure
18:46:29 <mcs> 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 <mcs> GeKo: what do you mean by “no issue for smaller pieces”?
18:47:21 <GeKo> i thought they wee kept in memory until a certain size
18:47:26 <GeKo> were
18:47:50 <GeKo> but i have not checked the code for that
18:48:33 <mcs> 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 <GeKo> okay
18:49:13 <GeKo> mcs: so what about the following plan:
18:49:23 <GeKo> we try to get #22471 fixed
18:49:33 <GeKo> and ignore the other less important pieces
18:49:53 <GeKo> trying instead to figure out how we can get the underlying issue fixed properly
18:49:55 <GeKo> ?
18:50:39 <arthuredelstein> 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 <mcs> 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 <mcs> arthuredelstein: I think that is what happens today in Firefox when the user is prompted.
18:52:31 <GeKo> mcs: well the alternative would be to avoid wasting even that time and resources and fix the underlying problem right away
18:52:39 <arthuredelstein> mcs: Ah, OK.
18:53:02 <GeKo> mcs: i am actually fine with that approach as well
18:53:12 <GeKo> we already burned weeks on this issue :/
18:53:28 <mcs> GeKo: Kathy and I would prefer to spend a little time pursuing the longer term fix and see what we learn
18:53:42 <GeKo> sounds good
18:53:57 <mcs> maybe what Mozilla has is already close to meeting our requirements
18:54:06 <GeKo> maybe make a new ticket and add stuff you learn?
18:54:13 <mcs> OK
18:54:45 <GeKo> well there is https://bugzilla.mozilla.org/show_bug.cgi?id=440892 still open
18:54:59 <GeKo> and i recently test the issue and it's still there
18:55:09 <GeKo> *tested
18:55:23 <mcs> yes, maybe we can create a patch for that :-)
18:55:37 <GeKo> but there might be better shortcuts than the one we have right now...
18:55:45 <GeKo> would be a good first step, yes
18:55:49 <GeKo> ok.
18:55:58 <GeKo> anything else for discussion today?
18:56:35 <armadev> the blog is full of people who can't run the new tor browser
18:56:43 <armadev> is that all trusteer rapport whatever
18:56:47 <armadev> or is there some underlying problem?
18:57:15 <Yawning> GeKo: I assume there is no further action needed on my part regarding the two sandboxing issues I was notified of
18:57:35 <Yawning> the pulseaudio setting in the config now has a huge "(UNSAFE)" warning
18:57:38 <Yawning> and there's the x monstrosity
18:57:43 <GeKo> 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 <GeKo> armadev: ^
18:58:18 <Yawning> that has been tested to the point of "I can open a bunch of tabs and watch stuff on youtube"
18:58:43 <GeKo> Yawning: no, that should be fine
18:58:59 <armadev> 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 <GeKo> yes, sounds like a good idea
18:59:51 <GeKo> okay, thanks for the meeting all *baf*
18:59:54 <GeKo> #endmeeting