18:00:57 #startmeeting tor-app-dev 18:00:57 Meeting started Mon Jul 20 18:00:57 2015 UTC. The chair is mikeperry. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:00:57 Useful Commands: #action #agreed #help #info #idea #link #topic. 18:01:43 hello everyone, and welcome to the first Tor Applications Team meeting. Hopefully this goes smoothly. Not sure how many additional people we have today 18:02:20 or if it will just end up being a TBB-dev meeting pretty much 18:02:28 anyway, let's get started 18:02:39 I'll go first 18:02:42 Last week, I wrote patches for #16316 and #16528 (#16528 still needs review). I also merged #16522, and reviewed #16429, but would like a second review on #16429 before merge. 18:02:59 I also discussed website traffic fingerprinting a bit more with mjuarez, and sent several long e-mails on various tor-dev an dinternal discussions and proposals, as well as the "Tor Applications Team" welcome mail (which hopefully you all got) 18:03:30 This week, I'm going to be preparing for the HTTP workshop (https://httpworkshop.github.io/), which I leave for on Saturday and was asked 18:03:33 to give a talk at. 18:03:46 I also hope to wrap up #16005, and it looks like https://trac.torproject.org/projects/tor/query?status=!closed&keywords=~TorBrowserTeam201507 needs a triage in general. There are a few rebasing tickets that seem to be just sitting open for some reason? 18:04:52 mikeperry: Kathy and I will review #16429 soon. 18:05:09 ok 18:05:12 thanks 18:05:13 that's it for me btw 18:07:04 oh, and reminder that we're still tentatively shooting for a Tor Browser 5.0 code freeze this Friday, but I also want to talk to/hear from GeKo about that 18:08:20 mcs: (also, welcome back!) 18:08:37 * amoghbl1 here for updates on Orfox, ready to go next 18:08:50 mcs: thanks! 18:08:54 mikeperry: thanks. 18:09:18 Managed to finally get rid of the Get_Accounts permission 18:09:35 Quit button added to the list of options 18:09:54 Made a few changes in the settings menu 18:10:19 The main stuff we need to figure out next is porting torbutton to android 18:10:42 n8fr8 sent a mail out to tbb-dev and the conversation continues there 18:10:43 oh, that is one of the really long mails I failed to get to last week. sorry :/ 18:11:46 it is currently at the top of my todo list, but I suspect several time-intensive emails also arrived over the weekend. hopefully I will have something for you soon 18:12:43 OK mikeperry 18:13:05 But that's it from me, there's a lot more androidy stuff coming up next 18:14:20 I can give a short update 18:14:47 I just came back and waded through a ton of emails today and trying to get back on track 18:15:25 this week there are a bunch of reviews and things planned to get Tor Browser 5.0 more in a stable direction 18:15:29 that's all for now 18:15:32 GeKo: also welcome back! 18:15:38 thx :) 18:16:17 I can also give a quick report. 18:16:24 Last week, Kathy and I were on vacation. 18:16:31 This week we will strive to finish #16495. 18:16:36 We will review the patch for #16429. 18:16:41 GeKo: we should try to sketch out how we want to handle doing a release during/before/after the HTTP workshop, perhaps at the end 18:16:50 yes 18:16:52 After that, if time permits, we will look at #14205. 18:17:00 And we will help with any other 5.0 issues. 18:17:03 That's all for us. 18:18:28 * arthuredelstein can go 18:18:29 mcs: If you have time, #16523 might be something to look in to? I might also flag a couple others for your attenion, if that's ok. 18:18:56 depending on how #16495 shakes out. it seems a bit troublesome :/ 18:18:57 mikeperry: sure, we can take a look. 18:19:49 OTOH, #16523 might also be somehting that bisecting is best for. GeKo is pretty quick at that 18:20:23 I guess we can figure all that out later 18:20:30 arthuredelstein: go ahead 18:20:35 Last week I wrote a patch for #16572. 18:20:41 And I revised my patches for #16429. 18:20:55 And I spent most of the week on #13313, which is just about ready for review. I’m currently building binaries so people can test. 18:21:05 That’s it for me. 18:21:35 nice! 18:21:38 arthuredelstein: cool. what fonts did you use for #13313? 18:21:50 and how big are they? Do they work on all 3 platforms? 18:21:51 The Google Noto font family 18:21:57 ah you just updated the ticket 18:22:00 They are ~15 MB 18:22:27 They are cross-platform fonts 18:23:24 arthuredelstein: 15MB after compression? yikes 18:23:38 Yeah :( It's almost entirely because of Chinese/Japanese/Korean 18:23:53 (and vietnamese) 18:23:56 is that 288 languages? where did you stop on the https://meta.wikimedia.org/wiki/List_of_Wikipedias#All_Wikipedias_ordered_by_number_of_articles list? 18:24:17 Yes, all 288 except Aramaic and Gothic. 18:24:29 Yawning: true! 18:24:33 (sorry, being pedantic) 18:24:46 Many fonts cover more than one language, obviously 18:24:59 even CJKV shouldn't be that bad because of Unihan 18:25:06 when dcf1 tested this, he cut it off at one of these base-10 orders of magnitiude and got 3MB.. 18:25:17 maybe the 100k article mark? 18:25:32 That's not going to help, because it's virtually all from CJK. 18:25:44 (CJKV, sorry) 18:26:47 If we use Droid Sans Fallback as dcf1 did, then we end up using the Simplified Chinese character style for Japanese, Korean, Vietnamese, and Traditional Chinese. (Which is wrong.) 18:27:04 I swear there was a comment that the droid fonts he was lookng at were only 3MB, but I can't find the comment 18:27:07 ah 18:27:27 (WHich will make a lot of people Really Really Mad) 18:28:41 One possibility would be to download the CJK font dynamically the first time it's needed. 18:29:12 I'd like to avoid this complexity 18:29:24 Sorry im late for the applications meeting, if its happening today, reading backchat. 18:30:12 Phoul1: it is and welcome! 18:30:38 GeKo: Yes, I tend to agree 18:30:39 yeah, that complexity would be problematic I bet.. the first time you visit the facebook or wikimedia landing page, it just takes forever because there's ALL THOSE CHARSETS ALREADY RIGHT THERE 18:30:47 caps lock fail :( 18:31:02 (though it seems to fit ;) 18:31:09 indeed, haha 18:31:24 GOOD POINT! 18:31:30 lol 18:32:40 ok, well hopefuly we can get ahold of dcf1's glyph testing code/page once we have some builds 18:32:59 Yeah, that would be great. 18:33:16 it used to live on a hidden service, but that was for a controlled study. it may be down 18:35:42 ok, I am a bit nervous about making our downloads approach the 75MB mark, but if it works, I guess it is worth it 18:36:01 who wants to go next? 18:36:30 * boklm can go next 18:37:13 To verify that our regression test fail without our patches (#16577) I moved tests to separate branches in my split repo and submited them to Mozilla Try. 18:37:22 I did that first on a previous version of the patches based on 38.0.1esr: https://trac.torproject.org/projects/tor/ticket/16577#comment:5 18:37:37 I improved the 'tbgit' script I'm using to manage this repo to add a command to rebase/autosquash all branches on a new firefox release, 18:37:41 and then used it to update my repo from 38.0.1esr to 38.1.0esr and synchronise it with the tor-browser-38.1.0esr-5.0-1 branch 18:37:53 I wanted to push the rebased branches to Mozilla Try for #16577 but dit not do it yet because of https://bugzilla.mozilla.org/show_bug.cgi?id=1185429 18:38:06 I added a patch to #15864 to use the new filenames in the build process. 18:38:25 While doing a build of 4.5.3, I also noticed that verification of tor-browser and torbutton tags are not working because GeKo's key is expired (I had to comment them to make the build). 18:38:55 This week I'm planning to push the updated branches to Try. Then look why #13749.2 and #15502 tests are failing. 18:39:04 There is also a Tor Messenger meeting with instantbird developers planned on Thursday/Friday this week. 18:39:14 That's all for me. 18:39:59 boklm: Thanks for doing this! 18:40:16 boklm: #15502 should be fixed by my branch in #16429 (under review currently) 18:40:34 arthuredelstein: ok 18:41:11 Not sure about #13749 18:43:53 boklm: yes, this looks great. thanks much 18:47:20 We also need some test cases for #16448, btw. I wasn't sure if I should file a new ticket for that or not, so I marked it needs_revision even though it is merged 18:47:40 anyone else have an update they want to give? 18:49:58 ok, I think that means we should discuss the future release plans 18:50:21 Phoul1: you still around? #16268 still needs a transifex tweak, I believe 18:50:45 * Phoul1 looks 18:51:19 mikeperry: how is #6540 moving along? 18:51:23 that one is probably a tricky one to fix 18:52:16 GeKo: I have all the info I think. I need to figure out what credit card to put into the thing 18:52:28 aha! 18:52:38 progress then, nice 18:53:02 hola, tor browser questions accepted or other chanel? 18:53:03 yeah, I've been mailing roger+wedy. roger just sent another mail about it today 18:53:33 mikeperry: re: #16268, the comment by mcs states that the en version is OK, while the ar version has the issue with the non-breaking space. However, both copies seem to be the same at the moment. Unless im missing something. 18:54:12 css media queries block already was implemented in 38? 18:54:56 Oh, wait, the en version must be getting pulled from Transifex too.. doesnt appear thats the actual source of the strings. Nevermind. 18:55:06 Phoul1: ENTITY project.start "&brandShortName; is developed by " vs ENTITY project.start "&brandShortName; is developed by " 18:55:29 Phoul1: it seems transifex is blindly converting & into & :/ 18:56:08 Yeah, checking on the Transifex side to see what it sees. I was looking at the wrong english set. 18:56:19 (I wonder what it does with &? does it become &amp;?) 18:56:35 It shouldn't, we have that in other resources without issue, afaik. 18:58:01 heyo: we alter the behavior of some media queries, and block the mozilla extensions.. though it's not mpossible there was a regression or something new added that we missed in 5.0a3? 18:58:59 mikeperry: Will contact the Transifex people about this. Looking through their editor, it looks correct... only gets the & when we pull it. 18:59:15 mikeperry: i dont know, I just looking for commit that modify media queries in tor browser for merge it to my build 19:00:33 heyo: there are a couple commits IIRC. and some related ones that do similar things to the Javascript APIs for the same resolution info 19:01:03 GeKo: what do you estimate your ability to sign+upload a release during the http workshop will be? 19:01:22 mikeperry: what does your freeze plan imply for http2/website traffic fingerprinting defenses for Tor Browser 5.0? 19:01:25 GeKo: and does this mean we should code freeze on this Friday, or July 30th? 19:03:06 GeKo: I am not super-excited about Tao's defense. I have a lot of questions, the most pressing one being "did you actually disable pipelining, or still allow it in half-duplex mode", and second to that being "how often did you see server pipelining support in your test set", and third being "did you test anything other than front pages of the Alexa N" 19:03:29 mikeperry: how can i find them? i not very familiar with tor repo 19:03:37 all of those questions could drastically alter that 9% slowdown number they noticed 19:05:02 ok. thus, it seems this is not in scope for 5.0 (I have not had a chance to read the paper yet) 19:05:11 which leaves the http2 things 19:05:32 GeKo: as for HTTP2, it may actually be best to try to grab a Mozilla Enginineer or someone at the workshop to ask some questions, as well. I noticed some odd things in the source, and there is a lot of shared code with SPDY 3.1.. but I think they actually properly scope the SETTINGS frame for HTTP/2 to the connection. I am not sure about SPDY tjough 19:05:37 I actually had some hopes to talk to the http folks and especially to mcmanus next week 19:05:44 and it looks like we have to enable both HTTP/2 and SPDY if we want either 19:05:48 yes 19:07:52 heyo: they shoudl be in https://gitweb.torproject.org/tor-browser.git/log/?h=tor-browser-38.1.0esr-5.0-1. but boklm has a better organized patch set. arthuredelstein should also be able to point you at specific commits 19:08:14 mikeperry: I think it might make sense then to freeze next friday to get the mozilla feedback wrt http2 in 19:08:28 heyo: Here's the main commit: https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-38.1.0esr-5.0-1&id=b40a0a3eee7fcd65c7c285ae67ecdcd7b663a0e8 19:09:21 heyo: And there are regression tests at https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-38.1.0esr-5.0-1&id=8f556ceba043a7bdc9ff1c07bff3d6f89dce8f32 and https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-38.1.0esr-5.0-1&id=452f870c8dff8089f759c9052960ad7fc73866a0 19:09:53 arthuredelstein, mikeperry thanks my gods:3 19:11:34 mikeperry: but that on the other hand would mean two releases within two weeks which does not make much sense 19:11:35 GeKo: Ok. so then we aim for a release on August 4th for 5.0 (or 5.0a4?), and pretty much turn around after that for 5.0.1, starting builds on Aug 6th or 7th or so? 19:11:52 hrm... 19:11:55 and hope that we just have to rebase and not fix a lot of things? 19:12:30 do you think we could get that osx signing going if we try to release next week? 19:12:46 I definitely like to test it somehow first 19:14:35 osx signing might just be too hard to finish / too risky for 5.0 at this point in time 19:15:02 I spoke to mike tigas (the onionbrowser guy), and it seems like the abiliuty to 'unsign' packages is a complete unknown 19:15:17 apple has DRM in addition to signing, and its not clear how to get one without the other, even 19:15:47 DRM encrypts the executable with a user-specific key, IUC. it may be app-store only though 19:15:57 that was my impression, yes 19:16:35 I can forward you his mail. he did say it was very tricky to test 19:16:47 yes, please 19:16:50 because once you allow an app, it's hard to unallow it.. and he's had several botched releases as a result 19:17:40 ok. 19:18:07 because he actually signed it with the wrong/invalid key, but his testing OSX box didn't care because it had already allowed the app 19:19:47 I think getting feedback wrt http2 is worth waiting another week 19:19:54 GeKo: will you be capable of signign the windows packages from at the http workshop? or do you think that's a bad idea 19:20:04 I could 19:20:26 but I am a bit reluctant to carry around all the equipment all these days 19:21:15 so I am in favor of doing the August 4th thing for 5.0 19:21:23 and doing the 5.0.1 a week later 19:21:54 mikeperry: (out of context, but in case it's helpful): there is no DRM for non-appstore signed OS X bundles. And there are commandline tools you can use to verify the signature properly 19:22:37 special: ok. are you on the tb-dev mailinglist? I just asked mike tigas if I can forward his mail there. perhaps you can enlighten us with more details in response to it? 19:22:44 I'm not 19:23:18 https://lists.torproject.org/cgi-bin/mailman/listinfo/tbb-dev. how about tor-dev? 19:23:49 mikeperry: another plan might be to get the http2 bits ready for a release next week 19:24:09 I am on tor-dev. See these two commands: https://github.com/ricochet-im/ricochet/blob/master/packaging/osx/release_osx.sh#L52 19:24:26 and use the http workshop to get rid of rough edges in them and release that in 5.0.1 on August 11th 19:24:47 that might get us a week more for testing 5.0 19:25:48 might make more sense 19:28:23 I think we're going to want #16495 at least for 5.0. also, will you be OK signing that then? or would you be hoping to get the signing done before departing for the workshop? 19:29:46 yes, we want that, too 19:30:11 probably also #16528, which I think is ready, but is rather hacky in terms of the fix 19:30:48 i would need to sign all the stuff during the workshop 19:31:42 should be doable 19:32:07 although I am not happy about it; but I am not happy about just having one week of testing the final tor-browser either 19:32:14 so, hey :) 19:33:06 yes, I knew this workshop was going to be bad news for our release timing :/ 19:33:58 should we call this thing 5.0a4, or 5.0? and maybe if we can tag it early enough, you can try to sign before you leave? 19:35:48 we want to have #13313, too, I guess? 19:36:43 if we include #13313, we should call the thing 5.0a4. we may want to drop that for several reasons in a stable channel release 19:36:56 agreed 19:38:18 I think it is not realistic to have everything ready for signing by friday 19:38:31 given the things we want to review and include 19:39:29 thus, let's aim for friday as freeze date getting as much stuff in as we can 19:39:46 and then let's try to release 5.0a4 next week 19:42:55 So here's a smaller menu of the tbb-5.0a things for 5.0a4: https://trac.torproject.org/projects/tor/query?keywords=~tbb-5.0a4&status=!closed&order=priority 19:43:05 I took them off of https://trac.torproject.org/projects/tor/query?keywords=~tbb-5.0a&status=!closed&order=priority 19:43:37 some of the tickets are actually dups of other stuff (#16312 and #15703 both have alternate tickets where the work is actually happening, for example) 19:44:02 so I will work on cleaning that up today 19:44:19 but how does that list look otherwise? 19:44:20 this list looks good to me 19:44:54 agreed 19:45:12 + #16523 19:45:54 GeKo: do you have time to try some bisecting fot #16523? 19:46:00 s/fot/for/ 19:46:01 yes, I can do that 19:46:34 GeKo: thanks. 19:46:59 GeKo: can you document your bisecting steps in https://trac.torproject.org/projects/tor/wiki/doc/TorBrowser/Hacking#PartialBuilds if possible? 19:47:15 yes 19:47:18 I imagine you hack up a TBB using a pre-existing bundle and partial firefox builds, yes? 19:47:27 yes 19:48:18 ok, perhaps just add a small section on bisecting our patches using that process then while you do it. then other people will be able to help us find bugs easier, too 19:48:44 sure 19:50:28 (we probably have quite a few tbb-usability-website bugs that would be useful to crowdsource with bisecting) 19:51:13 ok. I think we have a plan, then 19:54:07 any other questions/issues? 19:56:08 ok, I think that wrapps it up for this meeting.. *phew* 19:56:47 I have no idea what GeKo and my schedule will be like next week. I hope we can find some time to sneak away for the meeting 19:57:45 it should be possible, unless the dinner runs late. I imagine it shouldn't 19:58:33 but it is the mozilla dinner... 19:59:29 I wonder if moving the meeting to tuesday might be smarter if that works for everybody 20:00:03 this meeting starts at 8pm in that timezone? 20:00:03 I think Tuesday is OK for me next week. 20:00:12 Tuesday is fine for me 20:00:34 mikeperry: yes 20:01:05 and on tuesday there is no such dinner scheduled yet 20:01:27 ok. yeah, I guess there is a chance that it will run late, and we should probably aim for Tuesday since nothing is scheduled in the evening then 20:02:21 Tues is fine for me 20:03:06 i <3 tor browser 20:03:41 ok. hopefully boklm can confirm as well. but I think it's time to end the official meeting. it's gone on long enough :) 20:03:55 * boklm is going to be mostly offline during next week 20:04:05 oh, because of the instantbird meeting? 20:04:25 for vacation 20:04:58 ok. have fun! 20:05:04 sounds like Tuesday it is then 20:05:29 see everyone at the same time on Tuesday the 28th! 20:05:34 #endmeeting *baf*