18:02:45 #startmeeting app-dev 18:02:45 Meeting started Mon Aug 24 18:02:45 2015 UTC. The chair is mikeperry. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:02:45 Useful Commands: #action #agreed #help #info #idea #link #topic. 18:02:53 Last week, I mostly worked on non-TBB things (#16861). I've been wanting to write some Tor patches for a while, and needed a break after FF38, and that one called to me. 18:03:28 This week, I have to dig myself out from under a mountain of paperwork and email that has been building up, plan travel/purchase a bunch of plane tickets for Sept+October, and have some meetings scheduled as well. I might not be too useful. :/ 18:04:06 I heard rumor that there might e a Firefox out-of-cycle release coming up, butI haven't seen anything solid yet 18:04:21 And hopefully everyone has seen this: https://blog.mozilla.org/addons/2015/08/21/the-future-of-developing-firefox-add-ons/ 18:04:57 brave new world! 18:06:28 we'll want to keep an eye on that. I'm more worried about Tor Launcher than Torbutton, since we want to be moving Torbutton into patches anyway 18:06:45 yes, me too 18:06:59 but the XUL bits of Torbutton may need a new home.. 18:07:25 esp the circuit status + menu 18:08:09 The most worrying thing (other than dev time to rewrite things) is the danger that APIs we need will not be available. 18:08:20 yeah 18:08:23 (first baby step torward moving most of torbutton into mainline: https://bugzilla.mozilla.org/show_bug.cgi?id=962358 ) 18:08:39 mcs: that's why I'm here... :) 18:08:56 it is my job to make your lives easier 18:09:03 Right. Well, we (on the Tor side) need to get engaged and figure out what is lacking. 18:10:08 A lot of Firefox internals run on XPCOM. Getting rid of it sounds like a very major project to me. 18:11:05 arthuredelstein: I think it is just XPCOM add-ons that are being deprecated 18:11:14 yeah, the question will be can we use them if Tor Launcher remains an addon, though. I imagine they will still be there if we bake Tor launcher into the browser proper, though we'll need to be careful about using them 18:11:26 once Servo takes off (and it seems they're doing more and more with it) they will want a replacement anyway 18:11:33 AFAICT, we're just trying to sandbox add-ons better...with XPCOM, add-ons have full access to FF's internals 18:11:41 and then, it would be sad for things like Thunderbird 18:13:10 ok, well we should continue on with status updates 18:13:18 I see. So if Mozilla is willing to expose lots of things that were formerly exposed through XPCOM, but more safely, then maybe it won't be such a big problem. 18:15:50 * mcs will give a status update 18:15:55 Last week, Kathy and I completed fixes for #16842 and #16781. 18:16:02 We developed a patch for #16775 but it looks like it may need more work. 18:16:08 We did some more work on #13512; additional testing is needed before we can be sure it is ready for TB 5.5 alpha. 18:16:14 arthuredelstein: I'm guessing that the API surface area will be up for negotiation. I imagine TBB has some of the greatest amount of influence over it than most other groups. So I'm not worried, you shouldn't be either. 18:16:15 We also completed a code review for #16860 and triaged some incoming TB 5.x bugs. 18:16:21 This week we plan to finish #16775 and #13512. 18:16:24 And if we have more time we will work on #16753 (which affects the TB 5.5 alpha series). 18:16:31 That’s all for us. 18:18:34 * ilv can go next 18:18:45 I spent most of last week on adding support for requests via OTR in the XMPP bot. I'm leaving it as a separate branch until I get review. 18:19:04 I also spent some time working on #16551, but boklm was faster than me and submitted a nice patch for it! We're now waiting for review. There are still some concerns from evilaviv3, but I'm not sure we can do it the way he suggests. 18:19:25 This week I'll be mainly finishing the Twitter bot (should definitely be easier) and deploying work from past weeks. 18:19:40 that's it for me! 18:21:11 here is what i did: 18:21:39 i mainly tried to get as much reviewed and merged as i could anticipating another emergence release 18:21:55 and i spent a bit on #15493 18:22:25 moreover i filed all the bugs i wanted to file due to our new Tor Browser 18:22:35 things i found on the blog and noticed while testing 18:23:15 this week i'll try to understand #16874 18:23:32 it bothered me that this is only failing on windows which is kind of weird 18:24:01 then I hope to get merged/reviewed the remaining stuff that is in needs_review state 18:24:18 and i plan to continue with the windows signing on linux machines task 18:24:24 that's it so far 18:25:19 * arthuredelstein can go next 18:25:26 Since my last meeting, I worked on fixing #16771. 18:25:33 I did some work on trying to homogenize fonts in Linux (#16672). 18:25:45 I started working on extending keyboard defenses to odd characters (#15646). 18:26:02 And this morning I've been trying to come up with a fix for the race condition GeKo found in #15493. 18:26:07 That's all for me. 18:26:45 Woops -- forgot my plans: this week I want to keep working on #16672 and #15646 mainly. 18:27:21 arthuredelstein: #16855 may be related to the blob isolation patches. can you take a look at that if you get a chance? 18:27:45 Will do. 18:28:08 I think right now fixing annoying regressions for people for 5.0 is a bit higher priority 18:28:49 though mrphs did want to talk to you about #16672 and making it easier to whitelist whole font families by family name for testing 18:29:03 Yes, it would be good to discuss with mrphs and anyone else. 18:29:35 * huseby can go next 18:29:40 I'll look into regressions this week as well. 18:30:52 Do we know when we might start 5.0.2 builds? Or are we waiting to see what emergency fixes come up? 18:32:29 I have no info on the release. I think it may have been postponed. good thing we ignored it and release 5.0.1 early :) 18:32:35 i think if there are no emergency fixes there is no need for a 5.0.2 right now 18:33:06 GeKo: OK. So we will fix as many regressions as we can so they are ready to go in the next release. 18:33:07 right 18:33:15 yes 18:33:23 Thanks. Back to status reports. 18:33:45 so i've been gone most the last three weeks for bsides/defcon and vacation 18:34:05 I did get https://bugzilla.mozilla.org/show_bug.cgi?id=232227 r+ and read to land, thanks for the reviews 18:34:30 I also have approval to land https://bugzilla.mozilla.org/show_bug.cgi?id=962358 as-is...the difficulty with that is the xpcshell unit test 18:35:09 hopefully today i can get a clean try run and land bz 232227 18:35:30 that's my #1 priority right now followed by the unit test for 692358 18:36:11 I need to set up a meeting for this week to talk about the "isolate" patches and the containerization/origin attributes project with you and moz engineers 18:36:33 is there a time this week that would be good for mikeperry and arthuredelstein and anybody else? 18:36:54 i want to make sure our containerization stuff meets the requirements of both projects so that it doesn't increase the size of the patch set 18:37:00 that's it for me 18:37:50 My week is pretty much open. 18:37:59 huseby: what are usual meeting times for it? west coast business hours? 18:39:19 GeKo: yes 18:39:50 arthuredelstein: I also want to add your #16672 and #15646 patches to my list 18:40:05 Wednesday is no good for me. I may lose another day for something else I still need to schedule, too 18:40:08 ok, wednesday is not so good for me 18:40:09 I've been asked to become a subject matter expert on fingerprinting/tracking 18:40:22 s7r: hello 18:40:22 husbey: Cool. They're still in progress, though. Also #16672 is really an extension of #13313. 18:40:27 s7r: are you talking about this change: https://gitweb.torproject.org/user/asn/torspec.git/commit/?h=shared-rng-draft-2&id=6e74f12a1b5e66b07e16d0ee715297cc1dbd509a ? 18:40:37 thursdays are pretty wide open for me 18:40:46 thursday? 10am PST? 18:40:51 or should we do afternoon? 18:41:28 arthuredelstein: my plan was to just add them to my list and when you get them landed, do the same on my end. 18:41:29 11am PST would be better for me but not the afternoon 18:41:40 alright, 11am PST? any objections? 18:41:57 Works for me. 18:42:01 on IRC? here/#tor-project? 18:42:24 * mrphs is in da hauz and happy to talk to anyone needed after the meeting :) 18:42:35 mikeperry: yes, we'll do it here I guess 18:42:54 I'll send out an email with links and dump them in here 18:43:01 I have not set up a Vidyo client or whatever you call it... thought about putting it on a throwaway android, but they're all in various stages of disrepair 18:43:04 to read before we have the meeting 18:43:32 mikeperry: yes, it is very sad that there aren't any good quick-n-dirty video/voice conferencing solutions 18:43:53 Does Firefox Hello do video conference? 18:44:06 arthuredelstein: it does, but only 1:1 18:44:11 not groups 18:44:21 and I get hives thinking about using google hangouts 18:44:31 join.me is windows/mac only 18:44:50 skype...well, um, might as well use video.nsa.gov 18:45:17 vidyo is what mozilla uses, and I can give you all a link to join my video room 18:45:24 it works well enough on most platforms 18:45:35 mikeperry: is there a way to use xmpp for this? 18:45:44 or do a mumble call? 18:46:08 talky.io seems like a possibility 18:46:17 It uses WebRTC and supports groups. 18:47:14 But I'm OK with IRC as well. 18:47:41 I think we should perhaps just do IRC for now. I'm likely not going to have time to investigate/set up these things this week 18:47:59 mikeperry: that's fine, IRC it is 18:48:09 if IRC ends up sucking, we can try for Vidyo/some other thing next time 18:48:16 arthuredelstein: i'll check out talky.io 18:48:51 and when we said "11am PST" we really meant "11am PDT" I assume ;) ? 18:49:08 arthuredelstein: maybe https://jitsi.org/ ? 18:49:23 there's Tox 18:49:28 mcs: yes...11am pacific time *this week* :) 18:50:24 jitsi has been working with mozilla for full firefox support: https://hacks.mozilla.org/2015/06/firefox-multistream-and-renegotiation-for-jitsi-videobridge/ 18:53:13 ok, so anything else for today's meeting? 18:53:22 * boklm can go next 18:53:42 This week I made a patch for #16551, fixed #16866 and #16661, helped on #13512 18:53:53 I synchronised my split branch repo and pushed all branches to Mozilla Try: https://lists.torproject.org/pipermail/tbb-dev/2015-August/000303.html 18:54:03 This week I'm planning to look at #16888 and #16758 18:54:09 That's all for me 18:55:11 boklm: How do you sync your split-branch repo? Is it automated? 18:55:44 arthuredelstein: no, I manually look at the new patches and cherry-pick them in the right branch 18:56:16 I see ... thanks for doing it! :) I want to try to help with fixing up the broken tests in the near future. 18:56:39 (Or just dropping the broken tests.) 18:57:05 not much progress to report on in Tor Messenger land. sukhe is traveling for personal reasons. I wrote a shim to use nss instead of libgcrypt for otr (a requirement for landing the otr extension upstream) but am struggling a bit getting libgpg-error to compile with mach. need to find some time to put my head down there. other than that, almost at the point of signing the webrtc PT contract 19:00:08 arlolra: I wanted to talk about the webrtc thing a bit. one of my main wishes is that we be able to use webrtc for connections to obtain bridges from bridgedb.. so as an alternative to domain fronting, email, etc 19:00:29 I think just making it into another PT is not as useful as making it into a way to get bridges of all types. 19:00:50 pour que no los dos? 19:01:11 I'm kind of suspicious of the reliability/usability of "Just keep this tab open for Tor users to use you as a bridge" flashproxy model.. it seems like it will just end up with lots of people being randomly disconnected from Tor all the time 19:01:39 * GeKo has the same feeling 19:01:58 we could make a cut down standalone thing 19:02:13 "run this and be a useful bridge, no messing with firewalls" 19:02:14 mikeperry: i had a talk with ekr about how to fool TBB to use the Tor proxy for webrtc signaling so that you can trick the webrtc stack to route all traffic through tor 19:02:29 with a minimalistic UI 19:02:45 and somebandwidth throttling 19:03:07 in practice though, has that been a complaint? 19:03:12 flashproxy is deployed 19:03:15 if I were pitiching this to a funder I'd call it Freedom.exe 19:03:17 no one uses it 19:03:23 ah 19:03:40 and Freedom.exe will have like a huge american flag and a mp3 of the national anthem with a bald eagle icon 19:03:48 ha 19:03:59 problem with flash proxy is that it requires client side nat traversal 19:04:10 which is essentially undeployable (IMO) because it would be a huge clusterfuck of suck 19:04:46 otherwise you end up with what we have now, where no one uses it becaue th eout of the box experience is terribad 19:05:26 (sorry to randomly chime in) 19:05:41 always welcome 19:05:42 I suspect that even with the NAT traversal problem solved, unless people are running these WebRTC bridges on dedicated hardware, we're just going to find out that the next barrier of suck is bridge uptime, and also obtaining bridges 19:05:59 mikeperry: maybe, depends on how smart we make it 19:06:18 we could make the protocol that's tunneled over webrtc resilient to transient failures 19:07:09 I thought flashproxy already did that 19:07:12 huseby: we're talking about using WebRTC for censorship circumvention.. as a Tor transport. However, if you have solid ideas about how we can deploy WebRTC in TBB, you can dump them in #16221 19:07:18 If we do something like uh. Client->Freedom.exe->Bridge or w/e 19:07:23 arlolra: not sure how smart it is 19:07:31 it might just reconnect 19:08:02 it keeps a bunch of connections lying in wait 19:08:05 which is ok-ish for normal browsing, but kind of suck for ssh 19:08:25 ah, ok 19:08:54 dcf1 can comment more 19:11:14 ok. well hopefully there is room in the contract to handle bridge distribution via WebRTC as well, at least somehow 19:12:04 for sure. we can talk more once I get started there 19:12:06 that is our main weakness now. we can't actually get bridges to people. simply making more PTs without at least thinking about that aspect of it is kinda..silly 19:12:09 ok 19:13:16 (IMO I think our biggest problem with webRTC anything will be convincing people, "no, webrtc an really be used for more stuff that 'leaking your identity' and 'some ranodm bullshit checker is wrong about the status of your privacy'" 19:13:19 ) 19:13:43 that might be indeed a point 19:15:14 mikeperry: thanks...I'll take a look 19:15:49 alright, well anything else for the meeting then? 19:16:22 if you could comment on #16778 that would be nice 19:16:43 i am not so sure if we really need to look that sync thing farther away 19:17:14 given that the bar is already quite high for a user shooting herself accidentally in the foot with it 19:18:25 hrmm 19:18:44 it basically costs us a patch and makes it trickier for people who really, really want to use it (for whatever reason) 19:21:23 I think Sync is no longer end-to-end encrypted in terms of user data storage on mozilla's servers? 19:21:47 they had a bunch of password recovery problems with the end-to-end version, and that was a major factor in the new version 19:22:24 that aspect makes me want to hide it more, though I'm not sure what the right level of hidden is. I also see "Set up sync" in my Tools menu on Linux 19:22:51 ah 19:23:04 https://support.mozilla.org/en-US/kb/firefox-sync-upgrade-frequently-asked-questions#w_are-there-any-security-concerns-with-upgrading-to-the-new-system 19:23:48 "industry-leading security", hrm... 19:24:02 well, I guess it depends on what "securely derived" means.. Mozilla may still be able to derive it during password reset, etc 19:24:03 probably with military-grade encryption, right? 19:24:12 yeah.. hrmm 19:24:15 quadruple ROT13 19:26:37 I guess my answer for #16778 really depends on that password recovery flow, and if that means Mozilla can still derive the Sync storage key if compelled to do so 19:26:44 and I don't know the answers there 19:27:05 fair enough 19:28:25 I will update the ticket with that I suppose 19:28:32 sounds good 19:28:34 maybe someone will help us find out 19:30:08 anything else then? 19:32:46 ok, let's wrap 'er up! 19:32:57 #endmeeting *baf*