19:00:41 <mikeperry> #startmeeting
19:00:41 <MeetBot> Meeting started Mon Dec 22 19:00:41 2014 UTC.  The chair is mikeperry. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:00:41 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
19:01:11 <mikeperry> ok, so I imagine this will be a short one due to the holidays
19:03:01 <mikeperry> last week I mostly spent travelling, preparing for CCC, and working on another super-sekrit prototype
19:03:53 <mikeperry> oh, I spoke with Giorgio about his latest changes to NoScript, and filed #13998
19:04:15 <mikeperry> this week, I won't be doing much other than finishing up my slides for CCC, and going to CCC
19:04:43 <mikeperry> I am not sure if the chaos at CCC will allow me to find time to make this meeting or not
19:05:26 <mikeperry> I think that's it for me. is anyone else around other than arthur, msvb-lab, and myself? :)
19:05:48 * GeKo is
19:08:17 <mikeperry> ok, who wants to go next then?
19:09:19 <armadev> i happen to be here in case anybody has questions for me about whatever
19:09:37 <GeKo> here is what I did:
19:10:30 <GeKo> I tsted the fix for #13379 a day or so and was eventually happy, nice work.
19:11:18 <GeKo> I created the MAR signing keys and put them into tor-browser. we can start signing with the next release
19:11:30 <GeKo> them = the certificates
19:12:12 <GeKo> then I spent quite some time on documentation stuff: the changes due to the signing got documented; the tor-browser key and MAR key generation
19:12:38 <mikeperry> where did you document this?
19:12:39 <GeKo> #13960
19:12:44 <mikeperry> the releaseprocess file?
19:12:56 <GeKo> no a new one, see the patch
19:14:17 <GeKo> the signing documentation is in fa3ac404e97e5dcb25e31e9ec7dfddf229714d22
19:14:50 <mikeperry> do you need commit to tor-browser-spec.git still?
19:15:00 <GeKo> yes
19:16:15 <GeKo> then I tweaked check-prerequisites.sh a bit to work with a pure Debian OS, too.
19:16:21 <GeKo> which is #10125
19:16:38 <GeKo> so we don't need Ubuntu as a host system anymore
19:17:18 <GeKo> I thought a bit about #9387 and played with makeing th slider horizontal but I fear that won't work
19:17:35 <GeKo> the main problem is that the language strings are too large
19:17:55 <GeKo> they start overlapping or being cropped.
19:18:09 <GeKo> maybe not in english but definitely in other languages
19:18:50 <GeKo> that's all I did as I spent the last days travelling
19:19:29 <GeKo> not sure if I get something done this week. If so, I'll work further on #9387 and the nsiprotocolproxy service patch if needed.
19:19:51 <GeKo> that's it for now
19:21:58 <mikeperry> were you able to reproduce the first list of issues I noted in the security slider?
19:23:11 <GeKo> yes, and it is quite embarassing actually. I am now convinced to write as much tests I can for the security slider :)
19:23:24 <GeKo> *as I can
19:24:45 <mikeperry> heh. I'm curious how you decide to write those tests, as torbutton currently has none other than boklm's
19:25:59 <GeKo> I think I'll write mozmill tests
19:27:27 <GeKo> it can test all the things that need to get tested here (working checkbox, taking new identity into account...)
19:27:59 <mikeperry> oh, there appears to still be a meek issue with 4.5-alpha-2. is this known? I vaguely remember you and dcf discussing some issue with the 4.5 series
19:28:17 <GeKo> yeah
19:28:28 <mikeperry> is there a ticket for it?
19:28:34 <arthuredelstein> #13788
19:28:36 <GeKo> #13788
19:30:10 <arthuredelstein> Looks like it might be my SOCKS patch -- I was thinking of looking into that next
19:33:14 <mikeperry> yeah, probably should be high priority for 4.5-alpha-3. meek is too awesome to leave broken ;)
19:33:29 <arthuredelstein> indeed!
19:33:44 <GeKo> and I promised dcf we will have it fixed by then... ;)
19:34:25 <arthuredelstein> Last week I worked on finishing up #13749.
19:34:58 <arthuredelstein> There are two patches -- the second has an annoying issue that I'm trying to work out. But it's basically working.
19:36:38 <arthuredelstein> I also took a look at the nsIProtocolProxyService patch for Mozilla and I did manage to fix one issue. I haven't run the full tests to see if there are remaining issues -- if so, I'll hand off my notes to GeKo who has offered to take a look
19:37:30 <arthuredelstein> So the next two things on my plate are #13788 and #13670
19:38:34 <arthuredelstein> With the goal of getting the domain isolation patches posted on Bugzilla for review in early January.
19:38:43 <arthuredelstein> We'll see... ;)
19:39:16 <arthuredelstein> that's all for me
19:41:50 <mikeperry> ok. when is our next upstream firefox release? Is everything pushed back one week forever more, or are they doing a 5 week cycle this release? the wiki says Jan 13 with an asterisk
19:42:15 <GeKo> I think Jan 13
19:42:20 <mikeperry> that is also our FF38 merge date, it seems?
19:42:34 <GeKo> no that is roughly 4 weeks later
19:42:39 <GeKo> or 5
19:43:02 <mikeperry> ah, as in we can probably merge until FF38 hits aurora
19:43:08 <GeKo> yes
19:43:11 <mikeperry> so Feb 23, according to the wiki
19:44:49 <msvb-lab> So stable FF (or whatever it's called) Jan 13, and ESR38 on Feb 23 right? I thought we were just interested in tracking ESR releases.
19:45:04 <msvb-lab> ...and merging to those.
19:46:22 <mikeperry> well, we will be doing a TBB stable and alpha release on Jan 13. But we need to try to get as much of our patches merged as we can by Feb 23
19:46:53 <mikeperry> we won't actually switch to FF38 until May/June at the earliest. it doesn't become ESR until Aug
19:48:11 <msvb-lab> Okay, so Feb 23 is code freeze and testing begins on ESR38. That better?
19:48:30 <armadev> are we hoping to move to the next esr before the last possible day, this time?
19:48:41 <mikeperry> we always hope that
19:48:46 <GeKo> indeeed
19:48:52 <GeKo> *indeed even
19:48:56 <mikeperry> reality ends up disagreeing with our hopes
19:49:14 <arthuredelstein> I am a little confused by https://wiki.mozilla.org/RapidRelease/Calendar#Future_branch_dates . Are the merge dates referring to the first or last day they merge to a given branch?
19:50:31 <mikeperry> I think mozilla actually has different policies for what can be merged into central, aurora, and beta for each merge date
19:52:17 <arthuredelstein> I'm just trying to understand if Feb 23 is really our deadline for merging stuff into ESR 38.
19:53:33 <GeKo> that's the day when esr38 being in nightly moves to aurora
19:53:36 <mikeperry> Feb 23 is when Mozilla feature-freezes 38. we'll have a harder time convincing them to accept our patches after that date
19:54:53 <arthuredelstein> OK. I'm convinced. :)
19:56:57 <mikeperry> for our own purposes, we should aim to have our patches rebased on top of FF38 probably around April, and start releasing alphas based on FF38 on May 19th
19:57:31 <GeKo> wow
19:58:35 <mikeperry> assuming the beta version of FF38 doesn't cause too much bitrot as it transitions to stable
19:59:47 <msvb-lab> Is there a ticket tag/URL to find patches needing FF38 rebasement?
19:59:56 <msvb-lab> ...erm 'rebasing'.
20:00:02 <GeKo> #12761 could be a fun bug. we'll see if we have things ready by then
20:00:48 <mikeperry> yeah, we can start rebasing patches before we have builds for all platforms. that will probably also help things move faster
20:01:20 <GeKo> sounds good
20:02:44 <arthuredelstein> msvb-lab: All tor-browser.git patches will need to be rebased
20:03:14 <msvb-lab> arthuredelstein: Okay, thought there might be a subset according to priority.
20:05:18 <msvb-lab> Is Mozilla that far along that they're clearly willing to integrate all rebased patches? Does that mean I should revisit #9701 to make it more paletable?
20:05:50 <msvb-lab> It's just a sucky (but functional) #ifdef right now.
20:05:53 <arthuredelstein> Ah, you're asking about what patches are needed for upstreaming
20:05:59 <msvb-lab> Yes.
20:06:20 <arthuredelstein> https://bugzilla.mozilla.org/buglist.cgi?quicksearch=ALL%20whiteboard%3A%5Btor%5D&list_id=11391446
20:06:31 <GeKo> msvb-lab: if you want to go ahead with that one that would be good
20:06:53 <msvb-lab> arthuredelstein, GeKo: Thanks guys.
20:06:56 <GeKo> binding it to the private browsing mode is the way to go I still think
20:07:13 <GeKo> and I am quite optimistic that Mozilla would be okay with that approach
20:07:17 <msvb-lab> GeKo: Yes, that was the last tip and the best one as well (even though there are alternatives.)
20:08:20 <arthuredelstein> msvb-lab: There's also https://docs.google.com/spreadsheet/ccc?key=0AroPYigJXMK4dFhzUGl5eFFkY09XbjBSTlNVS3o2SWc&usp=drive_web#gid=0
20:09:27 <msvb-lab> That's pretty good.
20:11:34 <msvb-lab> Any word on Polaris? Or is that on ice until 2015?
20:12:41 <mikeperry> I spoke with Mozilla briefly last Tuesday. forgot to mention that
20:13:14 <mikeperry> they are interested in the third party isolation patches. they agree that is a good first target for merge
20:14:00 <mikeperry> but they are also still planning on doing some kind of filtering and tracking analysis UI for normal FF users
20:15:43 <mikeperry> I forgot what the tracking analysis UI was called.. but it's something Sid Stamm has been working on for a while
20:16:30 <mikeperry> and there is another version of it in an addon already, the name of which also escapes me at the moment
20:16:34 <mikeperry> Collusion, I think?
20:16:49 <GeKo> yes
20:17:19 <GeKo> but "tracking" means just "third party cookies" here to keep that in context
20:17:33 <msvb-lab> Privacy UI is getting nasty even without new tracking analysis.
20:17:38 <msvb-lab> ...speaking of which:
20:17:40 <msvb-lab> Anyone have an opinion about how to logically modify network.cookie.cookieBehavior?
20:17:50 <msvb-lab> Currently: 0 = accept all, 1 = block third party, 2 = block all cookies.
20:18:02 <GeKo> what do you mean?
20:18:11 <msvb-lab> Double keying.
20:18:35 <GeKo> I don't understand "logically modify"
20:18:43 <msvb-lab> Like, leave 0/1/2 as is, but add another option to force 3rd party matches against originating URI.
20:18:57 <msvb-lab> ...or absorb the new double key logic in one of the existing choices.
20:19:47 <msvb-lab> ...for example (3 is already taken) 4 = send 3rd party according to 1st party pairing.
20:20:30 <msvb-lab> ...block 3rd party cookies sometimes (when not matched with double key originating URI) and send in other cases (double key matched.)
20:21:09 <mikeperry> I think that privacy.thirdparty.isolate should also cause double-keying of cookies, and then network.cookie.cookieBehavior can cause the browser to decide which cookie types to actually allow independently
20:21:47 <GeKo> +1
20:22:41 <msvb-lab> Okay sounds good, but I think double-keying will be done regardless. Just that the check will be dependent on privacy.thirdparty.isolate.
20:23:04 <msvb-lab> check == testing against both of dual-key parts, that is.
20:25:17 <mikeperry> yeah, that sounds OK
20:27:11 <mikeperry> Is that all for the meeting, then?
20:27:36 <msvb-lab> Is the addition of getFirstPartyURI ready?
20:27:43 <GeKo> I don't have anything more
20:27:52 <msvb-lab> Seems there's a question of it's status for upstreaming.
20:29:10 <arthuredelstein> I think before upstreaming it we need to get #13670 woring.
20:29:13 <arthuredelstein> *working
20:30:08 <msvb-lab> Won't it hold up other 3rd party isolation patches ready to merge?
20:31:06 <GeKo> mikeperry: when do we have our next meeting? Jan 5?
20:32:38 <nickm> armadev: thoughts on #14013 ?  Seems significant.  How far back should I backport the fixup IYO?
20:34:08 <arthuredelstein> msvb-lab: maybe... I guess we'll see how it goes.
20:34:38 <mikeperry> GeKo: I think that probably is the best plan. I am guessing between CCC and the holidays, most people won't be around
20:37:13 <mikeperry> ok, I think that should be it for today, then
20:38:09 <mikeperry> #endmeeting *baf*