18:00:23 <mikeperry> #startmeeting tbb-dev
18:00:23 <MeetBot> Meeting started Mon Aug  3 18:00:23 2015 UTC.  The chair is mikeperry. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:00:23 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
18:00:41 <mikeperry> welcome to the tor applications team meeting, everyone
18:01:25 <mikeperry> as usual, we'll start with individual standups, reportbacks, and plans
18:01:38 <mikeperry> then we'll move on to discussion of things like the upcoming 5.0a4 and 5.0 releases
18:01:52 <mikeperry> and any other applications-related discussion
18:02:07 <mikeperry> I'll go first with my standup
18:02:22 <mikeperry> Last week, I attended the HTTP workshop and gave a talk about how we view privacy and anonymity with respect to HTTP/2, SPDY, QUIC, and TLS 1.3. I also reviewed merged the last few tickets for 5.0a4, and tagged and built the release, and posted it to tor-qa.
18:02:26 <mikeperry> This week, I need to catch up on mail, write our status reports, triage our tickets for August, review some funding proposals, and generally get distracted by bureaucracy.
18:02:34 <mikeperry> The tags for Firefox 38.2.0-esr should be appearing this week, so we'll also need to rebase and rebuild, and make the call on what to do with a couple things in 5.0a4 for 5.0 (like the font limiting, and IPv6).
18:02:51 <mikeperry> that's it for me for now
18:03:43 <huseby> i'll go, since i'm quick
18:04:21 <huseby> I received feedback on https://bugzilla.mozilla.org/show_bug.cgi?id=232227 and incorporated the changes.  i'm almost done writing the tests and will hopefully submit an updated patch for review today.
18:05:07 <huseby> I had some internal meetings about Mozilla's priorities re: uplifting patches.  Because of our "containers" project, I have prioritized the "isolate" bugs listed here: https://docs.google.com/spreadsheets/d/1rF4Gah_OEequYDfPedoQu3oETM5Gj4NagxDuKQG-IOk/edit?pli=1#gid=0
18:06:09 <huseby> track tickets: #6564 #5742 #13670 #15502 #16300 #13670 #15703 and #13742
18:06:55 <huseby> i'm still going through them to decide if they fit into the scope of our containers project
18:07:07 <huseby> and will need help from all of you on a few of them
18:07:25 <huseby> (to decide if they are in-scope or not of the containers project)
18:07:39 <arthuredelstein> huseby: I'd be happy to help with this
18:07:58 <huseby> next up is creating bz bugs for all of those and get them properly tagged and under the right meta bug
18:08:17 <huseby> oh, and I'll be AFK for the rest of the week for bsides/digital rights summit/defcon/partying
18:08:22 <mcs> Kathy Brade and I can also help.
18:08:22 <huseby> that's it for me
18:08:29 <huseby> mcs, arthuredelstein thanks!
18:08:34 <huseby> oh, one more thing
18:09:18 <huseby> I will be scheduling a meeting for sometime next week to talk specifically about the technical details and goals of our containers project and the "isolate" bugs
18:09:42 <huseby> I want us to work together so that the solution that lands in mainline will cover the union of Mozilla + Tor requirements
18:09:58 <huseby> now I'm done
18:10:53 <mikeperry> I have been needinfo on https://bugzilla.mozilla.org/show_bug.cgi?id=232227 for an embarassingly long time. I will add a secondary review after I dig out from under my mail and status report things
18:11:18 <huseby> mikeperry: sure, wait until I upload my new patch later today
18:12:39 <mcs> I can give a report.
18:12:46 <mcs> Last week, Kathy and I did more research and added a comment to #14205.  Today I filed #16715 to track a spinoff task for TB 5.0.
18:12:54 <mcs> We fixed #16488 (merged by GeKo for TB 5.0a4; thanks!).
18:13:02 <mcs> We did a code review for Mozilla #232227 (System colors for form elements used when browser.display.use_system_colors is set to false).
18:13:09 <mcs> We worked on #16607 but do not have a solution yet.
18:13:16 <mcs> We also did a little testing of TB 5.0a4 and posted our July status report to tor-reports.
18:13:25 <mcs> This week, we will create a patch for #16715 and we also plan to work on #13512.
18:13:36 <mcs> And of course we will help with any TB 5.0 issues that come up.
18:13:41 <mcs> We are also without power at our office at the moment (thunderstorm) but hopefully it will be restored in a day or two.
18:13:47 <mcs> That’s all for us.
18:14:42 <n8fr8> amoghbl1 and are here
18:15:12 <n8fr8> we are down to the last few tickets for our beta 1 release: https://dev.guardianproject.info/projects/orfox-private-browser/roadmap
18:15:20 <n8fr8> of Orfox... working on torbutton port to mobile now
18:15:30 <huseby> mcs: I'm interested in #16715, if you find cases where we're not using the threadsafe call when it should, i'm pretty sure that needs to be uplifted ASAP
18:16:03 <mcs> Sure.  I think we are mostly worried about our own Tor patches though.
18:16:08 <huseby> ah, k
18:16:14 <n8fr8> Our goal is to have a public beta of Orfox Android on F-Droid and Google Play in the next week.
18:16:21 <mcs> And it just seems like a safer call to use (the thread safe one).
18:17:03 <huseby> mcs: i think there's one that needs fixing in bz#232227
18:17:57 <n8fr8> The recent stagefright HTML5 video vuln is a concern, but since all media plugins are click to play, and it is largely an OS level issue, there isn't much we can do. Overall, Orfox is safer to use in the face of that still.
18:18:21 <mcs> huseby: That could be.  Of course your advice is welcome in that area.
18:18:53 <n8fr8> we'll report back to the tbb-dev list our progress on torbutton on android as we make headway today/tomorrow
18:19:01 <mikeperry> n8fr8: did you see my torbutton reply on tbb-dev? I tried to give you a fresh list of things that are important
18:19:04 <mikeperry> ah
18:19:07 <n8fr8> yes, that was perfect
18:19:22 <n8fr8> thank you
18:19:43 <n8fr8> amoghbl1, anything else?
18:20:06 <amoghbl1> I think that's about it ! torbutton stuff to work on next!
18:20:23 <n8fr8> Yes, getting this toolchain setup now: https://developer.mozilla.org/en-US/Add-ons/SDK/Tutorials/Mobile_development
18:20:27 <amoghbl1> And yes, the collaboration mail that huseby sent
18:20:47 <n8fr8> Oh yes, thanks huseby. Glad that is happening.
18:21:29 <amoghbl1> I didn't reply to that one, but I'm in constant contact with the #mobile team and try to push things upstream whenever possible.
18:24:04 <mikeperry> ok, who wants to go next?
18:24:09 * arthuredelstein can go
18:24:20 <arthuredelstein> Last week I worked on upstreaming https://bugzilla.mozilla.org/show_bug.cgi?id=1173171, which is our patch for #12430.
18:24:26 <arthuredelstein> I worked on improvements to #15646, opened #16672, and started working on #16686.
18:24:30 <huseby> n8fr8: really, i just need to know about any android-specific tor patches so that we can uplift them too
18:24:43 <huseby> I want a wholistic view of the delta
18:24:49 <arthuredelstein> This week I will work more on #16686, and look at font-fingerprinting issues in general.
18:24:57 <arthuredelstein> I also have an idea for landing part of #14429 in stable, which I will try to implement.
18:25:18 <arthuredelstein> That's all for me
18:26:11 <n8fr8> will do, huseby.
18:27:11 * boklm can go next
18:27:20 <boklm> Last week I was mostly offline.
18:27:25 <boklm> I launched a build of 5.0a4 which matched.
18:27:36 <boklm> Today I synced my split branches repo and pushed it to https://github.com/boklm/gecko-dev/
18:27:39 <boklm> and I posted a summary of test results on #16577: https://trac.torproject.org/projects/tor/ticket/16577#comment:7
18:27:47 <boklm> This week I'm planning to look at the failing integration tests we have on 5.0a4 and update them
18:28:01 <boklm> I will also send a summary of Try results with the current version of our patches to tbb-dev
18:28:09 <boklm> And work on a test for #16448
18:28:19 <boklm> That's all for me
18:29:32 <arthuredelstein> boklm: Thanks again for running thoses tests
18:33:09 <mikeperry> yes, very useful.
18:33:42 <mikeperry> gettting to the bottom of that isolation build error will be good, but the 5.0a4 test issues are probably more important tm
18:34:00 <mikeperry> s/tm/right now
18:34:04 <boklm> ok
18:34:42 <mikeperry> we're going to want to freeze for 5.0 this thursday/friday
18:37:38 <mikeperry> if folks can tag stuff that they think should be merged for tbb-5.0 with tbb-5.0 in addition to the normal review tags, that would be helpful
18:38:11 <Yawning> 5.0 stable will ship with 0.2.6.x right?
18:38:15 <mikeperry> esp if you can tag it before its ready for review, so we can have a good view of what everyone is working on this week
18:38:26 <arthuredelstein> If there are no more individual reports, it would be useful for me to have a short dicussion about font fingerprinting.
18:38:30 <Yawning> (yes, I asked before, makign sure that didn't change)
18:39:24 <mikeperry> Yawning: that's the plan. we're also going to grab your two patches, but I set the gitian descriptors to do that automatically already when tor is 0.2.6.x
18:39:51 <Yawning> ok
18:40:05 <Yawning> I'm fairly sure there's nothing else that needs to be cherrypicked
18:40:31 <Yawning> but my mind has been on meatspace concerns for the last bit so, I'd have to look
18:42:42 <arthuredelstein> So regarding fonts, the about:tor page looks ugly, which could potentially be fixed (see https://trac.torproject.org/projects/tor/ticket/16707#comment:1). But the main question is whether we want to go ahead with #13313 in 5.0, or instead find an alternative stopgap patch for limiting fonts.
18:43:35 <arthuredelstein> In other words, I could spend this week trying to improve #13313, or I could work on an alternative font limiter.
18:43:46 <arthuredelstein> My personal feeling is that #13313 is not too bad, but I'm biased ;)
18:45:25 <arthuredelstein> I've had some negative feedback about the appearance of fonts in #13313, but apart from the #16707 example, it hasn't been precise enough for me to know what needs to be changed.
18:45:53 <arthuredelstein> Or I should say the appearance of fonts in 5.0a4
18:45:59 <mikeperry> I think #13313 needs to whitelist the common OS fonts. what was that page that had the list of install rates of web-safe fonts?
18:46:40 <mikeperry> I am also nervous about increasing our bundle size for #13313 in 5.0, esp while we still don't fully understand its effects
18:47:02 <arthuredelstein> I'm not entirely comfortable with whitelisting common fonts, as it leaves some users who don't have those fonts exposed.
18:47:40 <arthuredelstein> I mean, maybe that's not enough entropy to matter too much, but I'm not sure.
18:48:48 <arthuredelstein> mikeperry: http://www.awayback.com/revised-font-stack/
18:49:30 <mikeperry> http://www.cssfontstack.com/ also has install rates
18:51:56 <mcs> It looks like those sites do not show install rates for Linux.  Do we care?
18:52:05 <mikeperry> I think these fonts with the very high 99% install rates are likely safe to whitelist.. the odd fractions of a percent might be due to things like people lying about useragent
18:52:25 <arthuredelstein> So, if we want to bundle Chinese/Japanese/Korean, then that will cause most of the size increase.
18:52:28 <mikeperry> I would say Linux should ship some free fonts
18:52:49 <mikeperry> I am also not happy with the aesthetics of Noto
18:53:35 <Yawning> ?
18:54:13 <mcs> I wonder if use of bundled fonts should be optional somehow.  I am sure there will always be some dislike for non-OS fonts.
18:54:16 <arthuredelstein> mikeperry: So we could switch to whitelisting Arial, Times, instead of Noto Sans and Noto Serif.
18:54:47 <arthuredelstein> Except on Linux.
18:55:06 <arthuredelstein> I think your point about useragent lying is probably correct.
18:56:05 <arthuredelstein> Maybe ideally we would detect if those fonts are missing and prompt to install...
18:56:56 <arthuredelstein> Yawning: It would be useful to hear your view on the Noto-CJK font in 5.0a4. How does the kanji look?
18:57:10 <Yawning> uh not using alpha >.>
18:57:15 <Yawning> gimmie a sec
18:57:18 <arthuredelstein> In other words, the default CJK font it uses.
18:57:27 <arthuredelstein> ja.wikipedia.org for example
18:58:18 <arthuredelstein> Anyhow, I'll give whitelisting the OS a try and consider dropping Noto-Sans/Noto-Serif (Latin chars) from the bundle
18:58:24 <mikeperry> I also feel like we don't yet understand the thigs we need to tweak for #13313. I am still getting different fingerprints for debian vs ubuntu, for example (though I did not try a fonts.conf yet)
18:58:34 <Yawning> https://2.bp.blogspot.com/-YkDV2eLCUcs/U8WOzqvr1LI/AAAAAAAAOew/vH4lBTFSvqo/s1600/jp-sentence-bold500-72ppi.png
18:58:40 <Yawning> that font right?
18:58:47 <Yawning> the CJKV one that google made
18:58:50 <huseby> arthuredelstein: i like the idea of prompting users to install missing fonts
18:58:58 <huseby> because if we can get all users to install the same fonts
18:59:02 <huseby> it reduces entropy
18:59:11 <huseby> makes the tor browser less obvious
18:59:14 <arthuredelstein> Yawning: I'm not sure.
18:59:48 <arthuredelstein> huseby: Yes, with #13313 we tried to bundle all the needed fonts so users don't have to manually install. But unfortunately then they have to be free fonts.
19:00:07 <arthuredelstein> Yawning: Google might be using a webfont.
19:00:16 <arthuredelstein> Yawning: I know ja.wikipedia.org does not use a web font.
19:00:16 <Yawning> https://en.wikipedia.org/wiki/Noto_fonts
19:00:47 <Yawning> I got that smaple off uh http://googledevelopers.blogspot.nl/2014/07/noto-cjk-font-that-is-complete.html
19:01:23 <Yawning> in which case it looks ok
19:01:41 <arthuredelstein> OK, thanks.
19:03:14 <Yawning> IPAMincho looks nicer but only covers japanse and the deb is 4 megs so
19:03:16 <Yawning> :P
19:05:39 <mikeperry> oddly my test of http://qfgbmpw3obwb3ix3.onion/fontfp has the same fingerprint for the single 6un case between debian and ubuntu, but the rest of the fingerprints differ for 5.0a4. I think until we understand that and other potential differences, it doesn't make much sense to throw these extra fonts at our users for 5.0, especially given the aesthetics
19:06:20 <mikeperry> I don't know if that means we should try to whitelist some system fonts for 5.0, or limit the number of glyphs per page, or what. it seems risky no matter which way we go
19:06:50 <uni> can you please do same font limiter for 38 as in old version:3 I waiting it whole months :3 its just great
19:07:59 <arthuredelstein> I found the old font limiter (1) didn't rebase well and (2) didn't account for iframes. But I could try to write a new font limiter this week instead.
19:09:30 <mikeperry> it also didn't account for glyph usage, which seems somewhat independent of font names that websites use (especially if they are using a generic)
19:10:04 <arthuredelstein> mikeperry: Can you clarify what you mean about glyph usage?
19:10:43 <arthuredelstein> Do you mean glyph availability in a given font?
19:10:59 <arthuredelstein> and/or glyph shape?
19:11:02 <mikeperry> the old font patch only limited the number of fonts you could list in CSS rules. Davd's unicode character enumeration test at http://qfgbmpw3obwb3ix3.onion/fontfp was not impacted by that limit at all, since the OS tends to pull in all sorts of random fonts for different unicode ranges
19:11:38 <arthuredelstein> Aha, makes sense.
19:11:42 <mikeperry> I believe he just measured glyph size for each code point
19:12:21 <arthuredelstein> I think that the whitelist part of my #13313 patch should help protect against that.
19:13:23 <arthuredelstein> So I don't want to detain everyone on this discussion.
19:13:44 <arthuredelstein> Maybe we should move on and discuss some more after the meeting for whoever has an opinion.
19:15:50 <mikeperry> yeah, ok. I will also test the fonts.conf thing later
19:15:58 <mikeperry> anything else for the meeting itself?
19:18:52 <mikeperry> ok, I think that wraps it up. please remember to tag stuff with tbb-5.0 and review tags for august. I will also be triaging tickets for august later today/tomorrow, so watch for any changes to tbb-5.0
19:19:28 <mikeperry> #endmeeting *baf*