19:00:15 <mikeperry> #startmeeting even
19:00:15 <MeetBot> Meeting started Mon Jan 12 19:00:15 2015 UTC.  The chair is mikeperry. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:00:15 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
19:01:15 <mikeperry> ok. so lets get started.
19:01:34 <arthuredelstein> hi all
19:01:52 <mikeperry> I guess I will go first, as I have a few things to set direction
19:02:02 <msvb-lab> Hello folks.
19:02:15 <mikeperry> Last week, I was sick and then distracted by extraordinarily bad internet. I did work on some non-tbb things (some more work on a couple prototypes, and some org stuff).
19:02:35 <mikeperry> Today, though, I went through the list of issues pending review this month, and selected a subset that seem like good candidates for 4.5-alpha-3, which we need to put out this week (as soon as we get 4.0.3 out): https://trac.torproject.org/projects/tor/query?keywords=~tbb-4.5-alpha-3
19:02:50 <mikeperry> For the next week, my plan is to personally review #13788 and #13749 and generally help shepard 4.5-alpha-3. More eyes are always good, of course.
19:03:07 <mikeperry> For the rest of the tickets in that tag, I think Pearl Crescent should review #13857, GeKo should review #13015, and boklm should review #10125.
19:03:14 <mikeperry> If you folks can do that within the next 24-48 hours, that would be ideal.
19:03:25 <mikeperry> If that's not possible, let me know and I will shuffle some things around. I would like to get 4.5-alpha-3 rebased onto FF31.4.0ESR and out the door by Thursday/Friday.
19:04:02 <mikeperry> Oh, also as a point of process, I think we should pre-write our status updates, to reduce the total time spent in the meeting waiting for folks to type.
19:04:09 <mikeperry> I appologize for not specifying this earlier. It occurred to me that many of you were doing this already, and if we all do it, these meetings will go much faster.
19:04:40 <mikeperry> wow, that took me two full minutes.. cutting and pasting over tor+ssh is still tricky and slow ;)
19:04:43 * MarkSmith Will review #13857 (just haven't gotten to it yet)
19:04:55 <mikeperry> (bad internet + tor + ssh)
19:04:58 <GeKo> #13857 is already reviewd by me I think
19:05:05 <MarkSmith> Even better ;)
19:05:06 <boklm> it should be ok for me to review #10125 in the next 24-48h
19:05:07 <GeKo> what is missing is only the update of the ReleaseProcess
19:05:14 <mikeperry> yes
19:05:17 <GeKo> I don't have access to the repo
19:06:07 <GeKo> re 4.5-alpha-3 it would be cool if we could have all things ready by tomorrow evening in order to start building
19:06:52 <GeKo> and I think the trivial Torbutton env things can make it into the alpha as well
19:06:57 <mikeperry> right, which means we need to review+merge these tickets asap.
19:07:12 <GeKo> I planned to do that tomorrow, too
19:07:18 <GeKo> and #13998
19:07:25 <GeKo> will be ready tomorrow as well
19:07:48 <mikeperry> feel free to add stuff to the tbb-4.5-alpha-3 tag then, and make sure someone has a clear responsibility to review+merge for you
19:07:49 <GeKo> so, mikeperry if you could save some review/answering time for that one as well that would be nice
19:07:56 <mikeperry> ok
19:09:23 <mikeperry> are you going to take the env patch review+merges?
19:09:34 <GeKo> yes
19:09:46 <GeKo> (if no one esle is dooing that)
19:09:47 <GeKo> *doing
19:10:08 <mikeperry> I now have #13788, #13749, #13857, and #13998
19:11:23 <GeKo> MarkSmith: what about #13818?
19:11:42 <GeKo> sounds like a thing for you :)
19:12:21 <MarkSmith> I think Kathy and I can review and merge the fix for #13818.
19:12:41 <MarkSmith> Also maybe #14122
19:12:55 <MarkSmith> (unless people think #14122 is a bad idea)
19:13:16 <GeKo> I'd be interested in the tests you did for that one. (#13818, that is)
19:13:23 <GeKo> I think #14122 is okay
19:14:09 <MarkSmith> It has been a couple of weeks but we can add info to #13818 about the testing we did.
19:15:32 <mikeperry> I am worried about #13818. there are a series of Firefox bugs related to ::IsCallerChrome() bugs due to the wrong context being used.. In fact, the WebWorkers useragent leak bug was due to this
19:15:37 <GeKo> thanks. the whole thing that content can access chrome SVG seems pretty scary to me
19:16:23 <MarkSmith> I am not sure why Mozilla allows such access at all....
19:16:50 <GeKo> but at the moment by not fixing #13818 we have some fingerprinting vector
19:20:31 <MarkSmith> Without fixing it, do we have a fingerprinting vector or just ugly tabs?  (I am trying to remember the details)
19:20:50 <mikeperry> that bug is really hard to follow in terms of when the fingerprinting vector was introduced. I am not comfortable rushing this one unless it is easier to understand exactly what is going on
19:21:10 <mikeperry> if it is a fingerprinting bug, it needs a better title, and perhaps a new summary, just for bugtracker hygene reasons
19:21:16 <MarkSmith> Then let's wait and make sure we understand it ;)
19:21:24 <mikeperry> I think just ugly tabs
19:21:51 <mikeperry> I think attempts to fix this thing resulted in fingerprinting bugs, from my read
19:22:04 <MarkSmith> Fingerprinting came up because Kathy and I were concerned about introducing a vector.
19:22:05 <MarkSmith> Yes.
19:22:06 <GeKo> hrm...
19:22:09 <mikeperry> so I felt this ticket needs more time to bake.
19:22:42 <mikeperry> #13169 and #9701 are also in the "hrmm, almost but not quite" pile
19:24:38 <mikeperry> so can everyone make sure to tag the tickets they plan to review for 4.5-alpha-3 with both tbb-4.5-alpha-3 as well as their name review tag, for coordination purposes?
19:24:44 <mikeperry> here's mine: https://trac.torproject.org/projects/tor/query?keywords=~MikePerry201501R
19:25:12 <mikeperry> since GeKo wants to start a build in like a day or two, I think we want solid agreement on who is doing what by then
19:25:31 <mikeperry> (well, he said one day, I said two :)
19:25:56 <GeKo> you said 24-48 hours
19:26:00 <GeKo> ;)
19:30:59 <mikeperry> ok, so is anyone else ready to give an update, or did I just distract you all with a pile of trac tags? :)
19:31:36 <vlad902> mikeperry: Hey, I saw your 31c3 talk. Does the work you've done (as well as dh_stripdeterminism) work with clang or are there gcc-specific things that had to be done for deterministic builds?
19:32:23 <vlad902> Been interested in investigating some of the new clang security flags being added for tor, not sure how much that would affect you (or how tightly coupled tor is to gcc overall)
19:33:01 <GeKo> ok, here is what I did:
19:33:20 <GeKo> I started working on the signing token for authenticode signing
19:33:52 <mikeperry> vlad902: GeKo is looking into hardening flags as part of #10599. gcc-4.9.1 supports most of what we're interested in atm, but I'm sure he will be happy to discuss after the meeting or on the ticket?
19:34:07 <GeKo> then I reviewed #13857
19:34:20 <GeKo> I prepared stuff for 4.0.3
19:34:46 <GeKo> and spent the rest of my time working with NoScript code (mainly due to #13998)
19:35:02 <vlad902> mikeperry: Oh man, releasing with ASAN would be damn awesome
19:35:19 <vlad902> didn't realize it was supported in gcc
19:35:32 <GeKo> UBSan as well
19:35:47 * GeKo gets back to meeting business
19:35:59 <vlad902> I'm partial to clang myself, but ASAN is probably the most useful protection that can be added
19:36:05 <mikeperry> vlad902: yes, it is not perfect. SoftBounds is way more complete in terms of attack mitigation, but as far as a reliable compiler, it is not as good as ASAN or UBsan
19:36:12 <vlad902> maybe some of the CFI stuff whenever it actually gets mainlined
19:36:32 <GeKo> this week I hope we can get all the new Tor Browser things out
19:36:43 <GeKo> tomorrow I plan to finish all that is need on my side
19:37:08 <GeKo> then I plan to write some tests for the NoScript and Seucrity Slider things
19:37:25 <GeKo> not sure what else I will get done this week
19:37:29 <GeKo> that's it for now
19:37:36 <vlad902> I haven't seen UBsan bu it looks somewhat orthogonal to the dynamic mem management problems you'll encounter in browsers
19:38:40 <GeKo> tackles pa different set of issues happening in browser code, too
19:38:48 <GeKo> s/pa/a
19:39:09 <vlad902> that's true, I could see it being useful for certain classes of bugs that might cause RCE or info leaks
19:39:58 * MarkSmith can give a quick status report.
19:40:13 <MarkSmith> This past week Kathy and I reviewed and merged the fix for #13835.
19:40:21 <MarkSmith> We triaged some Torbutton / Tor Launcher / Tor Browser bugs and participated in various discussions within the tickets, e.g., #14100, #14118, #14122, etc.
19:40:38 <MarkSmith> This week we will focus on review and merge of fixes for TB 4.5-alpha-3.
19:40:43 <MarkSmith> We will also take another look at #13818 (Active tab looks ugly) for post 4.5-alpha-3.
19:40:54 <MarkSmith> Finally, we still plan to learn more about electrolysis (https://wiki.mozilla.org/Electrolysis)
19:41:01 <MarkSmith> so we can help fix Torbutton and Tor Launcher to work when it is enabled.
19:41:05 <MarkSmith> (we did not get to that last week).
19:41:10 <MarkSmith> That's all for us.
19:41:59 * arthuredelstein can go next
19:42:16 <arthuredelstein> Last week I wrote a patch for #13788. I wrote another revision to my patch for https://bugzilla.mozilla.org/show_bug.cgi?id=436344, and I started work on #13670. So this week I will continue on #13670. Also, I thought I might try helping with porting our patches over for https://bugzilla.mozilla.org/show_bug.cgi?id=418986, as Sid seems enthusiastic. That’s all for me.
19:43:18 <GeKo> I thought about that, too. I am still not sure what he wants :)
19:43:42 <GeKo> Maybe we would be even more helpful if we gave him a patch against mozilla-central
19:43:50 <GeKo> I think I gonna ask him
19:43:54 <arthuredelstein> Yes, I think ultimately that's what he wants :)
19:44:18 <arthuredelstein> Also we need to bind those things to a pref, probably
19:45:18 <GeKo> if that helps moving this (rapidly) forward I am all for it
19:47:55 <arthuredelstein> I wonder if we could bind it to the "privacy.donottrackheader.enabled" pref :)
19:48:21 <GeKo> ah, I just saw you already gave him the info he wants, thanks
19:48:30 <MarkSmith> Best to avoid the entire Do Not Track mess ;)
19:50:47 <mikeperry> arthuredelstein: yes, I think you're right. thanks for picking that up!
19:53:40 <arthuredelstein> No problem. Sid also recently asked about https://bugzilla.mozilla.org/show_bug.cgi?id=232227 which seems quite doable at this point with our existing patch
19:55:01 <arthuredelstein> Though we don't have regression tests for it yet
19:56:21 <mikeperry> ok. I suppose that weird tab coloring issue we discussed earlier is also relevant to this
19:56:35 <mikeperry> well, to https://bugzilla.mozilla.org/show_bug.cgi?id=232227 at least
19:57:13 <mikeperry> so that sounds good. Progress on this front is useful, thanks for doing it
19:58:01 <mikeperry> is boklm next? mttp/support?
19:58:44 <arthuredelstein> One thing that isn't clear to me is how Mozilla plans to use these patches. Do they want to tie them to private browsing mode, for example?
20:00:08 <arthuredelstein> Or a checkbox in the Privacy tab of the Preferences dialog?
20:01:01 <msvb-lab> This is a question for us as well, since I'm not sure a UI tying together the party isolation pieces neatly exists yet.
20:01:22 <msvb-lab> Mike made a cool new design a while back, but it probably needs revision?
20:02:03 <msvb-lab> GeKo's JavaScript slider could be applied in broader ways, couldn't it?
20:02:06 * boklm is back. Sorry, I lost my connection at the begining of the meeting :/
20:02:56 <mikeperry> arthuredelstein: it is indeed strange to see them suddenly intetrested in fingerprinting defenses. that is orthogonal to the third arty tracking pref, I think, but they may want it bound to the Private Browsing Mode state
20:03:01 <mikeperry> I guess we see what they decide
20:03:16 <mikeperry> I think they were leanding towards pref, but that causes problems with concurrent private browsing mode windows
20:04:24 <arthuredelstein> If they want it bound to private browsing mode, then we can introduce a three-state pref similar to privacy.thirdparty.isolate
20:04:51 <mikeperry> personally, I think there should be a whole new mode, "network adversary mode", or similar
20:05:10 <mikeperry> and then you could overlay that with normal browsing (that records history) or with private browsing (which does not)
20:05:24 <arthuredelstein> aka tor mode
20:05:32 <mikeperry> that is effectively how TBB is hacked together ;)
20:06:28 <GeKo> it is hard to sell different "private" browsing modes
20:06:39 <mikeperry> well, yes, but I think it is also important to commoditize Tor, so that it can be replaced. To me, this will make it more compelling from Mozilla's perspective, and I think competitors will be good for us, too
20:07:39 <GeKo> yes, agreed, but I don't see why this can't be in a single private browsing mode
20:07:46 <mikeperry> if multiple entities all want the same type of privacy properties from Mozilla, perhaps we can all cooperate on the web bits, and then be more able to spend our development efforts on our own innovations in our networks, or other offerings
20:08:35 <mikeperry> well, you store disk records in TBB, right? I think this is a very commonly used option
20:09:17 <mikeperry> binding all of the privacy stuff *just* to private browsing mode means that everyone who wants network privacy also has to suffer local amnesia in terms of disk records
20:09:24 <mikeperry> which seems kind of silly (side channels notwithstanding)
20:09:58 <SpencerOne> I could use the seperation  : )
20:11:03 <msvb-lab> Private browsing mode has other problems as well. Am I right that its config populates a nsChannel rather than preference?
20:11:07 <mikeperry> I think this means we may want most fingerprinting stuff to be a wholly separate thing.. to me, the third party tracking stuff still makes sense as a pref, because there already is the third party cookie pref
20:11:16 <mikeperry> and you probably want that same type of behavior in both modes?
20:11:59 <arthuredelstein> So the question would be, do we want some windows with fingerprinting defense enabled, and some not, or do we assume it's a global pref?
20:14:08 <mikeperry> frankly, I was not expecting them to suddenly move on fingerprinting defenses
20:14:13 <mikeperry> I need to think about this one :)
20:14:22 <arthuredelstein> Cool :)
20:14:26 <GeKo> indeed
20:15:20 <arthuredelstein> While I agree with the idea that Tor should have competitors, I still think Mozilla should embed Tor in standard Firefox by default. Unless a superior network suddenly shows up.
20:15:59 <arthuredelstein> I wouldn't want to encourage Mozilla to be satsfied with leaving Tor as an optional extension.
20:16:52 <mikeperry> yep. we will crush the competition, I expect.. but I think it will also say a lot of we don't require lock in either. I suspect it will be a net win for development capacity towards solving privacy problems
20:17:49 * MarkSmith Likes the idea of keeping things open while crushing the competition.
20:17:56 <mikeperry> anyway, I think a multi-window approach is better for fingerprinting defenses, in part because what makes them good is that the fingerprints are similar between the two modes.. but at the same time I don't like the idea of forcing people who want fingerprinting defenses not to store disk records
20:18:36 <arthuredelstein> By multi-window you mean a global pref?
20:18:57 <mikeperry> "makes them good" == "makes fingerprinting attacks good"
20:19:33 <mikeperry> no, I mean a property of the channel, like with PBM (as msvb-lab pointed out)
20:20:08 <mikeperry> I guess I need to email a bunch of Mozilla people and ask
20:20:13 <mikeperry> I will put this on my TODO list
20:20:37 <GeKo> could you put me in Cc?
20:20:40 <mikeperry> sure
20:20:57 <arthuredelstein> Me too? ;)
20:21:44 <mikeperry> yeah, I will pile you all on
20:22:00 <arthuredelstein> I guess what worries me about a per-window mode is that it multiplies the number of window types.
20:22:33 * boklm can give his update next
20:22:36 <mikeperry> I like the idea of my TBB fingerprint being fairly unrelated to my Firefox fingerprint (on the few occasions that I use non-Tor firefox)
20:22:41 <arthuredelstein> anti-fingerprint + PBM, anti-fingerprint alone, PBM alone, nothing
20:22:44 <mikeperry> I feel like this is a good property to maintain, somehow
20:22:58 <mikeperry> even in a world where there is only one firefox process doing both
20:23:59 <mikeperry> or rather, a single sandboxed multiprocess app
20:24:08 <arthuredelstein> On the other hand, would you ever want to disable fingerprinting defenses?
20:24:25 <mikeperry> maybe not?
20:24:33 <mikeperry> they may break random things
20:24:41 <mikeperry> we aren't that great at gathering such analytics
20:25:00 <mikeperry> https://trac.torproject.org/projects/tor/query?keywords=~tbb-usability-website is the graveyard of websites we may have broken at some point, somehow
20:25:01 <arthuredelstein> true
20:25:56 <msvb-lab> Gotta go soon, can I give a status and ask questions?
20:26:04 <mikeperry> msvb-lab: sure
20:26:09 <msvb-lab> Last week:
20:26:10 <msvb-lab> Implemented #9701 according to a conditional preferences requirement.
20:26:15 <msvb-lab> Considered #14061 where GeKo had a good idea to amputate Mike's UI design from cookie specific work.
20:26:33 <msvb-lab> For next week I'm ramping down since:
20:26:34 <msvb-lab> #9701 is 'almost but not quite' like Mike says.
20:26:41 <msvb-lab> If there's a consensus about which condition to implement I can change the implementation, though.
20:26:48 <msvb-lab> Nearly all of #3246 and child tickets are explicitly or implicitly 'needs_info'.
20:26:57 <msvb-lab> Incidentally, the Mozilla natives are restless regarding cookie control.
20:27:05 <msvb-lab> A few new comments last week after years of inaction, and 34 watchers.
20:27:10 <msvb-lab> https://bugzilla.mozilla.org/show_bug.cgi?id=565965
20:27:36 <msvb-lab> My questions are mostly about how to obey PBM without a nsChannel?
20:27:53 <msvb-lab> ...which seems to be what GeKo suggested to do with clipboard turds.
20:28:30 <mikeperry> msvb-lab: for #9701 I agree with GeKo I think that this definately is a disk-records thing, and so therefore should be tied to PBM and not the privacy.thirdparty.isolate pref..
20:29:38 <msvb-lab> The data caching routines used in nsTransferrable (clipboard turds) do not have access to channels or their properties.
20:29:58 <msvb-lab> ...so if I implement PBM there I'll have to break backwards compatability in a basic data structure API.
20:30:03 <msvb-lab> Is that acceptable?
20:31:05 <msvb-lab> There are slimier alternatives by the way, like ignoring PBM and obeying privacy.trackingprotection.enabled or some other similar pref.
20:31:10 <arthuredelstein> Isn't PBM state bound to the chrome window somehow?
20:31:47 <msvb-lab> I looked for a way to drill down the Window but didn't find a channel.
20:32:06 <msvb-lab> ...you can get one from a Document but not a Window.
20:32:26 <arthuredelstein> Somewhere the window itself must know the PBM state, because it is decorated with PBM appearance.
20:33:03 <msvb-lab> arthuredelstein: That would be excellent, then I'll check it out again.
20:33:28 <GeKo> http://mxr.mozilla.org/mozilla-central/source/toolkit/modules/PrivateBrowsingUtils.jsm
20:33:40 <GeKo> isWindowPrivate()
20:33:53 <msvb-lab> GeKo: Okay, thanks.
20:34:00 <GeKo> I would start from that one
20:34:03 <msvb-lab> (blush.)
20:34:10 <GeKo> https://developer.mozilla.org/EN/docs/Supporting_per-window_private_browsing
20:38:45 <boklm> So this week, I checked that #13015 still makes senses and rebased it on master
20:38:56 <boklm> I worked on the setup of the testsuite on Windows, and we should have it running tonight or tomorrow on 4.0.3
20:39:13 <boklm> This week I plan to review #10125, and help on #13015 and #13857 for the 4.5a3 release
20:42:37 <mikeperry> ok great. so then we should be all set? can everyone make sure they tag their tickets to review in https://trac.torproject.org/projects/tor/query?keywords=~tbb-4.5-alpha-3?
20:43:19 <mikeperry> this will make it easier for us to see at a glance what is done in the next day or two, and plan for accordingly, so we can get everything into the build in the next two days
20:44:21 <mikeperry> I think that's it for the meeting otherwise? anything else from anyone else?
20:44:27 * MarkSmith Has tagged #14122 with PearlCrescent201501R
20:47:42 <mikeperry> ok. the meeting is now over. hopefully next week we can dial down the meeting time by pre-writing our updates, and sticking more closely to https://lists.torproject.org/pipermail/tbb-dev/2014-February/000000.html
20:48:24 <mikeperry> I will do my best to enfore this with my e-gavel next time. there may be random in-meeting *bafs* to restore fascism^Worder
20:48:46 <mikeperry> and with that, *baf*, this meeting is so over.
20:48:49 <mikeperry> #endmeeting