18:01:06 <GeKo> #startmeeting application team
18:01:06 <MeetBot> Meeting started Mon Sep 21 18:01:06 2015 UTC.  The chair is GeKo. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:01:06 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
18:01:10 <GeKo> yes
18:01:33 <GeKo> okay, mikeperry might make it to the meeting but i think we can start right now
18:02:01 <anadahz> hi weasel, is it possible to change trac not to auto-assign owner (hellais) in trac for the OONI component?
18:02:13 <GeKo> this week i was mostly occupied with release related things. it seems we are on track after the alpha building was a bit bumpy
18:03:13 <GeKo> additionally i tried to figure out #13419, #13819 and worked a bit on #15578
18:03:32 <GeKo> thanks to mcs and brade who pushed #13419 big steps forward
18:04:03 <GeKo> this week i plan to help with the releases as needed and continue working on #13419 and #15578
18:04:07 <mcs> I think I ran into the problem you encountered due to #16909 a couple of days before you did but I thought it was "just me"
18:04:22 <mcs> (or something with my Linux set up)
18:04:22 <GeKo> you were not alone, mike did also
18:04:57 <GeKo> i think this was just a test of you guys: "How will he react if he has to fix this on the weekend?" :)
18:05:06 <GeKo> i hope i passed :D
18:05:29 <mcs> With flying colors, I'd say!
18:05:41 <GeKo> ah, yes, getting the final bits for #16909 done is on my plate as well
18:05:49 <GeKo> ha
18:05:56 <GeKo> that's it for me now
18:06:55 * mcs can go next
18:07:02 <mcs> Last week, Kathy and I finished #16735 and #16937.
18:07:07 <mcs> We spent some time looking at #16874 and the related ticket #13419 (not resolved yet).
18:07:12 <mcs> We reviewed assorted fixes for the TB 5.0.3 and 5.5a3 releases and created a last minute patch for #16906.
18:07:17 <mcs> We did not get a chance to revisit #16753, so we will try to do that soon.
18:07:23 <mcs> This week, we will be spending a lot of time on non-Tor work in order to clear the way for me to travel to Berlin.
18:07:29 <mcs> We so plan to help with #16874/#13419 and we will work on a design for #16940 soon.
18:07:32 <mcs> That's all for us.
18:07:46 <GeKo> yay for berlin
18:08:04 <mcs> It will be great to meet a lot more Tor people in person.
18:10:11 * arthuredelstein can go
18:10:21 <arthuredelstein> Last week I worked on a JS patch for #16874.
18:10:40 <arthuredelstein> Did some testing and a fixed a bug mcs and brade found in my patch for #16983.
18:10:50 <arthuredelstein> Did a little research and ran some tests for #17046.
18:10:54 <arthuredelstein> Wrote a patch for #16855.
18:11:03 <arthuredelstein> And wrote patches for crashes in #17097 and #17102.
18:11:22 <arthuredelstein> This week I'd like to go back to #16672, and maybe write a pref for #17009.
18:11:52 <arthuredelstein> And get on a plane :)
18:11:55 <arthuredelstein> That's it for me
18:13:44 <huseby> i'll go
18:16:12 <huseby> http://bgz.la/232227 system color stand-ins is ready, just doing the r?->r+ dance, i'm going to be really bugging people today
18:17:07 <huseby> http://bgz.la/962358 net:prune-all-connections for TorButton is r+, will land today
18:18:16 <huseby> http://bgz.la/962326 thirdPartyUtils API bug I went through the code and met with tanvi and kristof to talk about the implementation
18:18:40 <huseby> both of them worked on the loadInfo stuff late last year, early this year and we think that the thirdPartyUtils API can go away
18:19:05 <huseby> the loadInfo class has all of the required info and can be retrieved from channel/doc and can be walked all the way to the root
18:19:32 <huseby> i'm meeting with arthuredelstein after this to make sure that all corner cases are covered by loadInfo
18:19:54 <GeKo> yeah, i was wondering about browser sourced requests e.g.
18:20:11 <huseby> GeKo: loadInfo should cover all of that
18:20:17 <GeKo> like OCSP, favicons and stuff?
18:20:18 <huseby> as for the other "isolate" bugs
18:20:20 <GeKo> nice
18:20:35 <huseby> e.g. tor#6564
18:20:44 <huseby> tor#5742
18:20:58 <huseby> tor#15502
18:21:02 <huseby> etc
18:21:31 <arthuredelstein> So, just to clarify, you would still be isolating to url bar domain, but obtaining the domain by a different method?
18:21:32 <huseby> my proposed solution is to add a new "generic" attribute to the origin attributes system
18:21:43 <huseby> arthuredelstein: correct
18:22:07 <huseby> the loadInfo data should be considered the source of truth on what is being loaded and by whom
18:22:34 <arthuredelstein> What object contains the "origin attributes"? Is it loadInfo?
18:23:12 <huseby> no
18:23:15 <huseby> origin attributes is separate
18:23:24 <huseby> well, y'know what? i don't know
18:23:46 <huseby> the origin in the origin attributes will have the same info as the root loadInfo
18:23:53 <huseby> as far as i understand it
18:24:00 <huseby> loadInfo was to refactor the way security checks were done
18:24:12 <huseby> they were/are done really early
18:24:26 <huseby> and we needed a way to get all of that info into the channel
18:24:34 <arthuredelstein> Another object I was looking at is nsIPrincipal, as a possible place to store the first party domain.
18:24:42 <huseby> so that we could do mixed content and csp checks after redirects
18:25:24 <arthuredelstein> Because very frequently we are passing a "firstPartyKey" string and a principal through several functions in tandem.
18:25:34 <huseby> arthuredelstein: doesn't nsIPrincipal have that info already?
18:25:52 <huseby> o i c
18:26:19 <huseby> yeah, so I don't fully grok the relationship between the loadInfo class and the nsIPrincipal class
18:26:24 <arthuredelstein> Me neither :)
18:26:31 <huseby> i'm hoping to streamline things by switching to loadInfo
18:26:54 <GeKo> one corner case that migth be interesting to think about is getting the certificate after hitting the cert error page
18:27:42 <GeKo> the dialog popping up is actually breaking the URL bar domain binding
18:27:53 <GeKo> (we don't have a bug for that yet)
18:28:20 <GeKo> but i think the cert should get fetched over the same circuit as the original request
18:28:36 <arthuredelstein> GeKo: Definitely. Good catch.
18:28:51 <arthuredelstein> Sounds similar to favicons and ocsp.
18:29:06 <GeKo> dunno, maybe
18:31:29 <huseby> GeKo: I just made a note about that
18:31:46 <huseby> will follow up with kristof
18:31:47 <Yawning> hm
18:32:05 <GeKo> thanks
18:32:31 <huseby> arthuredelstein: so I think the thing to do is to take one of the "isolate" bugs and confirm that it can be solved with loadInfo + origin attributes
18:32:48 <huseby> if we can confirm that with all of them
18:32:56 <arthuredelstein> huseby: The current Tor Browser approach is basically a util function, GetFirstParty(channelOrDocument). It sounds to me like you are just changing the implementation of that function, correct?
18:33:00 <huseby> then the thirdPartyUtil API can go away
18:33:17 <huseby> arthuredelstein: yes, that's the plan
18:33:24 <huseby> instead of doing all that you do in that function
18:33:34 <huseby> we'll just grab the loadInfo for the data
18:33:49 <huseby> so I guess the API will stay
18:33:58 <huseby> well maybe not
18:34:03 <Yawning> (I have something for the browser people, let me know when a good time will be)
18:34:17 <GeKo> will do
18:34:19 <huseby> instead of calling GetFirstParty(), it can call the GetLoadInfo() instead
18:34:39 <huseby> Yawning: what's up? we'll pause
18:34:54 <arthuredelstein> huseby: Let's continue the discussion here after the meeting.
18:35:15 <Yawning> is there a ticket for "need to remove the tor patch and edit the torrc the next time the alpha tor tag is bumped"?
18:35:31 <huseby> arthuredelstein: agree'd
18:35:38 <GeKo> Yawning: not yet
18:35:46 <Yawning> cuz the circuit dirtyness thing is in master as a disabled-by-default (ew...) SocksPort option
18:36:13 <Yawning> k, figure I'd remind people that one is needed so they start a build and have it puke
18:36:42 <GeKo> thanks. i'll file one later
18:37:17 <Yawning> that's it, thanks for pausing
18:37:17 * boklm can go next
18:37:23 <Yawning> *crawls off to bed*
18:37:44 <boklm> This week I made builds of the new releases, I rebased my split branches repo on 38.3.0esr and pushed it to Mozilla Try
18:37:48 <boklm> I added more tests to the ignore list and sent current results to tbb-dev (but it seems to be awaiting moderator approval because it's more than 40KB)
18:37:59 <boklm> This week I'm planning to look at fixing or ignoring more tests. And I'm also getting on a plane to Berlin end of this week.
18:38:07 <boklm> That's all for me.
18:39:15 <GeKo> boklm: so, the tests for the releases...
18:40:52 <GeKo> it seems we need to adapt some for the changes in the alpha
18:41:41 <boklm> yes, for the alpha the settings test needs some change for the homepage change
18:41:44 <GeKo> as far as i see all broken settings tests can be explained by bugfixes
18:42:56 <boklm> yes
18:44:21 <GeKo> okay. someone else with a status report?
18:44:59 <sukhe> I can report for Tor Messenger
18:45:29 <sukhe> so it turns out that it is possible to disable GTK3 for the builds using a build flag
18:46:05 <sukhe> so we are now back to where we were and planning a release before the dev meeting
18:47:25 <sukhe> it took a while mostly because we have not streamlined how to match the build process with Instantbird (comm-central) which builds on mozilla-central
18:47:36 <sukhe> this is something we plan to fix at the dev meeting
18:47:48 <GeKo> what are the options/plans?
18:48:50 <sukhe> the idea right now is to release a public beta and get feedback
18:49:12 <sukhe> some people felt that Ricochet is better suited and we don't disagree but Tor Messenger has its own purpose
18:49:43 <sukhe> namely for people who want to use Gtalk, Facebook, IRC, XMPP and don't care about metadata
18:49:48 <sukhe> or using a centralized service
18:49:58 <sukhe> (this all will go in the blog post)
18:50:14 <GeKo> ok, sounds good.
18:50:53 <kernelcorn> I'd like to report for OnioNS if sukhe is done
18:51:11 <sukhe> kernelcorn: please go ahead
18:51:15 <kernelcorn> all right
18:51:41 <kernelcorn> I have been working hard on adding security and cryptography into the OnioNS communication
18:52:09 <kernelcorn> servers are now hidden by hidden services, like Ricochet, so the traffic is now encrypted over the wire due to Tor circuits
18:52:38 <kernelcorn> OnioNS servers would be a great candidate for single-onion services, but for now they are using the normal double-onion services
18:53:01 <kernelcorn> servers now manage Ed25519 keypairs and save their state to disk, so nothing is lost on restart
18:53:34 <kernelcorn> I'm also finishing infrastructure that should prevent name servers from lying to clients
18:53:55 <kernelcorn> spoofing information or falsely claiming that a domain doesn't exist, all that
18:54:12 <kernelcorn> I have also fixed many bugs regarding communication and the like
18:54:28 <kernelcorn> I'm hoping to get a new beta release this week if I can
18:54:39 <kernelcorn> that's basically it, in summary
18:56:55 <kernelcorn> overall I don't require any changes to tor in order to allow OnioNS to work on the Tor network
18:57:23 <GeKo> ok, thanks. anybody else? or do we have things to discuss (i have two in fact)?
18:58:50 <GeKo> so, the first thing i am wondering is related to our new locale we ship in the alpha bundles
18:58:59 <huseby> I've got the follow up with arthuredelstein about loadInfo
18:59:04 <huseby> nsILoadInfo to be specific
18:59:28 <GeKo> on OS X this is *ja-JP-mac.dmg or .mar
18:59:50 <GeKo> i think we should move that to *.ja.mar and *.ja.dmg respectively.
19:00:05 <GeKo> can we do that safely with the next alpha?
19:00:21 <GeKo> or do we need to rebundle to not break some updater thing?
19:01:24 <GeKo> huseby: yeah, but i think we could do that straight after the meeting
19:01:46 <mcs> I think the updater will be OK if you rename the .dmg and .mar files (as long as the update manifest/XML points to the correct mar)
19:02:04 <huseby> GeKo: sure
19:03:55 <boklm> what is the value of %LOCALE% when replaced in the app.updat.url ?
19:05:15 <GeKo> good question
19:06:51 <mcs> I am not sure but I (or someone) could check.
19:07:34 <GeKo> my guess is it won't be "ja-JP-mac" :) so i am optimistic here
19:08:09 <mcs> (I am checking)
19:08:54 <GeKo> the other thing that is bothering me is a font defense for stable users
19:09:16 <GeKo> I imagine getting things sorted out on the alpha channel will take a while
19:09:40 <GeKo> is there something we could meanwhile do for stable users?
19:09:57 <GeKo> should we?
19:10:32 <GeKo> s/font defense/font fingerprinting defense/
19:10:43 <arthuredelstein> One possibility is to re-introduce a patch that limits the number of font queries.
19:10:50 <arthuredelstein> Per first-party domain
19:11:05 <boklm> looking at gitian/descriptors/mac/gitian-bundle.yml it looks like we need to rebundle
19:11:18 <boklm> we have this line:     echo "pref(\"general.useragent.locale\", \"$LANG\");" >> defaults/preferences/000-tor-browser.js
19:11:48 <GeKo> aha! indeed
19:11:51 <mcs> boklm is right. The locale really is set to ja-JP-mac, which means that is what is sent in the update URL.
19:12:23 <mcs> (I just tested with 5.5a3-build4)
19:12:55 <mcs> And we probably do not really want -mac in the locale (I assume Mozilla does not use that inside Firefox)
19:13:08 <GeKo> ok. I'll get that going after the meeting, thanks
19:13:54 <huseby> arthuredelstein: why would reducing font queries protect you?  isn't there one call to get all installed fonts?
19:14:02 <huseby> or do you have to iterate?
19:14:18 <arthuredelstein> I'd say the two things that need to be worked out with the alpha font patches are (1) whitelisting and bundling the right set of fonts for each OS, and (2) Making linux rendering more homogeneous. But perhaps only (1) prevents us from introducing the existing patches into stable.
19:14:36 <arthuredelstein> huseby: You have to iterate, as far as I know
19:14:56 <GeKo> yes, i think so, too
19:15:21 <huseby> arthuredelstein: k, (i'm ignorant and want to not be) why ship different fonts for different platforms?
19:15:58 <arthuredelstein> huseby: We're trying to make the fonts as close as possible to what users expect. So websites don't look ugly
19:16:11 <huseby> won't we, at some point, want to hide the platform at some point--either by lying and all saying Windows or by not saying anythign at all?
19:16:52 <arthuredelstein> At this stage, no, we're not attempting to hide the OS, because it's that's too difficult and is retrievable by many methods besides fonts
19:17:28 <mcs> (interestingly, Firefox uses ja-JP-mac as the locale)
19:17:50 <GeKo> really? wow.
19:20:15 <huseby> arthuredelstein: sure, my thinking is we'll never try to hide it, we'll just try to get all browser to lie and say the exact same thing
19:20:27 <huseby> thus creating a massive cohort of browsers that are indistinguishable from each other
19:21:04 <arthuredelstein> huseby: I don't understand the distinction between hiding platform and lying about the platform.
19:21:49 <huseby> arthuredelstein: to me, hiding is removing the OS from the UA and any platform specific info from graphics queries and font lists etc
19:21:52 <GeKo> so maybe we should leave ja-JP-mac for now. maybe otherwise something breaks with the language pack
19:22:15 <huseby> lying is just figuring out what is already the most common values for the different platform detection vectors and then making all browsers report the same thing
19:22:54 <huseby> sure, that's hiding, but hiding by lying, not hiding by omission
19:22:56 <mcs> Yes, it sounds like we should leave the internal locale alone at least. There is a little background here: https://bugzilla.mozilla.org/show_bug.cgi?id=418485#c3
19:23:29 <arthuredelstein> huseby: I think it's very difficult to hide platform specific info from graphics queries and font lists, particularly if you want to maintain a high degree of usability.
19:24:26 <GeKo> mcs: thanks for the pointer! good, no rebundling. *phew*
19:24:29 <arthuredelstein> huseby: In an early version of the font bundling patch, I did attempt to use the same fonts for every platform. But nobody liked it! And in any case, it still was easy to distinguish the platforms.
19:24:56 <GeKo> avoiding platform fingerprinting is reaaaaally hard
19:25:14 <GeKo> ok. so, I think we should keep the stable users in mind
19:25:44 <GeKo> and if there is something we can do here or speed things up to get the defense to the stable series i am all for it
19:26:03 <GeKo> maybe we can hash something out during the dev meeting
19:26:10 <arthuredelstein> GeKo: I think if people are reasonably happy with the aesthetics of the font defense in the upcoming alpha, then I would be relatively comfortable with moving it to stable.
19:26:20 <GeKo> ok, nice
19:26:36 <arthuredelstein> But it's better to wait for feedback, because I tend to be overly optimistic. ;)
19:26:50 <GeKo> sure, sure :)
19:27:11 <GeKo> okay due to the dev meeting i guess we won't have the meeting next Monday
19:27:11 <arthuredelstein> Even after it reaches stable, I'm sure we will want to make tweaks to handle corner cases. And I still want to figure out how to get all linux flavors to render fonts the same.
19:27:59 <GeKo> but mike or i will write an email to tbb-dev to confirm this
19:28:15 <GeKo> anything else?
19:28:32 <huseby> GeKo: I'm aware of how difficult it is.  I'm just curious
19:29:09 <huseby> arthuredelstein: what's the bug(s) for the "upcoming alpha font defense"?
19:29:49 <arthuredelstein> huseby: https://trac.torproject.org/projects/tor/query?status=!closed&keywords=~tbb-fingerprinting-fonts
19:30:09 <arthuredelstein> Better: https://trac.torproject.org/projects/tor/query?status=accepted&status=assigned&status=closed&status=needs_information&status=needs_review&status=needs_revision&status=new&status=reopened&keywords=~tbb-fingerprinting-fonts&order=priority
19:30:36 <GeKo> mainly #13313, #16672 and #16707 (OTOH)
19:31:17 <GeKo> alright. thanks everybody! *baf*
19:31:20 <GeKo> #endmeeting