18:29:54 <sysrqb> #startmeeting Tor Browser Team Meeting, 9 December 2019
18:29:54 <MeetBot> Meeting started Mon Dec  9 18:29:54 2019 UTC.  The chair is sysrqb. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:29:54 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
18:30:02 <sysrqb> hello everyone
18:30:06 <boklm> hi
18:30:12 <Jeremy_Rand_Talos> hello!
18:30:17 <pili> hi
18:30:20 <GeKo> o/
18:30:47 <brade> jhi
18:30:49 <brade> hi
18:31:36 <pospeselr> o\
18:31:36 <mcs> hi
18:31:43 <pospeselr> hi
18:31:47 <sisbell> hi
18:31:55 <antonela> hello
18:32:56 <sysrqb> okay, let's see
18:34:55 <sysrqb> sisbell: you got openssl and libevent building? is that in tor-browser-build or only locally?
18:35:10 <sisbell> thats in tor-browser-build
18:35:27 <sysrqb> neat
18:35:46 <sysrqb> are you still seeing reproducibility issues with openssl?
18:36:16 <sysrqb> if you don't know, then that's okay for now
18:36:27 <sisbell> The way its built has changed with the latest version
18:36:40 <sisbell> So I not sure about the repro yet
18:36:45 <sysrqb> okay
18:37:53 <sysrqb> are you planning on creating branches for review for each of these projects?
18:38:20 <sisbell> Yes, I plan to get tor building this week and then push a branch with the 3 changes
18:38:23 <sysrqb> i'd be happy to review child tickets for each one and get them merged when they are ready
18:38:36 <sysrqb> okay
18:39:10 <sysrqb> if you run into any problems with building tor, please let us know
18:39:49 <sisbell> yes, will do thanks
18:40:12 <sysrqb> tjr: thanks for taking care of the form boundary patch, very much appreciated
18:40:20 <tjr> np
18:40:26 <tjr> acat did all the work :-p
18:40:53 <sysrqb> even so :)
18:41:16 <sysrqb> okay, i don't see any bolded items for the weekly updates
18:42:22 <sysrqb> some more people on the team are going on holiday at the end of this week
18:42:35 <sysrqb> so our team capacity is slowly shrinking
18:42:36 <sisbell> I have a couple of issues up for review I hope to get in before holidays
18:42:54 <sisbell> #32516
18:43:41 <sisbell> But if its lower priority its fine for after new year
18:43:50 <sysrqb> sisbell: i hope i'll be able to review those this week
18:44:07 <sysrqb> but it is not my top priority
18:44:10 * Jeremy_Rand_Talos just added a minor bolded item responding to one of GeKo's items
18:44:27 <sysrqb> and i also worry about putting much time into improving TOPL/tor-android-services
18:44:44 <sysrqb> because we don't know if we'll continue using these libraries long-term
18:45:05 <sysrqb> but I'm okay iwth making small, easy improvements
18:45:13 <sisbell> I think the settings part we will continue using
18:45:24 <sisbell> But yeah the bootstrap part will be changed a lot
18:47:00 <sysrqb> yeah
18:48:00 <sysrqb> Jeremy_Rand_Talos: most of it is in (and child tickets of) https://trac.torproject.org/projects/tor/ticket/32173
18:48:26 <sysrqb> but i think there are still some pieces that need documentation
18:49:13 <GeKo> Jeremy_Rand_Talos: the gist is that we need to think about ways to deal with necessary network requests during signing
18:49:42 <GeKo> yet our macos signing setup is trying hard to be reachable by the internet
18:50:05 <boklm> to not be?
18:50:12 <GeKo> yeah
18:50:17 <GeKo> what boklm said
18:50:40 <GeKo> and now we need to think how we can get both properties ideally
18:51:04 <Jeremy_Rand_Talos> GeKo, so, my understanding is that the Bitcoin Core devs are running into similar issues.  Might be useful to compare notes with them, so that solutions can cross-pollinate where applicable.
18:52:17 <GeKo> i expect the signing setups are not really comparable so i am a bit skeptical but once we have settled on a solution we sure should document it
18:52:43 <Jeremy_Rand_Talos> +1
18:53:26 <sysrqb> okay, discussion time.
18:53:52 <sysrqb> tjr: are the first items yours? or is that GeKo ?
18:53:58 <GeKo> mine
18:54:04 <GeKo> both
18:54:09 <sysrqb> okay
18:54:33 <GeKo> i have been thinking for a while bringing the first one up
18:54:48 <GeKo> because there might be users out there using aarch64 windows machines
18:55:07 <GeKo> and they would download tor browser from our website and would probably not have much fun
18:55:27 <mcs> are such machines common?  does Mozilla provide a download of Firefox for aarch64 ?
18:55:32 <GeKo> (i actually expected that one of the bugs we got from a windows 10 users is due to that
18:55:37 <tjr> We put a lot of effort into making aarch64
18:55:47 <GeKo> but the user did not respond yet)
18:55:50 <GeKo> yeah
18:55:50 <tjr> And I think a large justification of that effort was to build a relationship with qualcomm (speculation)
18:56:35 <tjr> This seems like one of those things where if it worked after X amount of invested effort - yay, otherwise document where you got and put it on a shelf....
18:56:47 <GeKo> but the aarch64 one is probably just the most prominent example given that this is a tier one platform
18:56:52 <GeKo> but there are others too
18:58:00 <GeKo> would we take patches for them and keep maintaining those at least?
18:58:04 <mcs> I don’t see that architecture on the Firefox download page. Maybe it is distributed a different way.
18:58:32 <sysrqb> if there is a need for them, then it seems like we should have the goal of building/providing them
18:59:36 <Jeremy_Rand_Talos> In the case of GNU/Linux ARM and POWER targets, I don't feel strongly about Tor committing to maintain them (community members such as me are probably fine with doing that maintenance), but those communities would definitely like Tor to build and distribute binaries (even if the community is responsible for fixing bugs)
18:59:37 <sysrqb> *BSD is a difficult platform, so i'm happy with only providing tarballs at this point
19:00:22 <sysrqb> but Windows aarch64 seems like it should be a supported platform for us
19:00:33 <mcs> The other side of the argument is that our team is already stetched thin providing the binary releases we provide now.
19:00:35 <sysrqb> i have no idea about PPC, at this point
19:01:12 <GeKo> mcs: yeah
19:01:23 <Jeremy_Rand_Talos> sysrqb, POWER9 is a popular platform among security-conscious users because its firmware is entirely libre.  So it meshes well with Tor's intended audience.
19:01:49 <sysrqb> what computers/brands ship that cpu?
19:02:16 <boklm> maybe we could start with building them only in the alpha release, with no guarantee that we'll continue providing updates if becomes too difficult
19:02:16 <Jeremy_Rand_Talos> sysrqb, Raptor Computing Systems (raptorcs.com) is the main vendor.
19:02:37 <GeKo> sysrqb: yeah, i think *bsd should be an easy decision here (and i concur with yours)
19:03:13 <GeKo> boklm: yeah, but that's already some non-negligible maintenance and release burden
19:03:25 <sysrqb> mcs: GeKo: i think this fits into our longer-term plans, in particular how we continue supporting all of these platforms after we transition to the fast release
19:03:39 <sysrqb> Jeremy_Rand_Talos: thanks, that's good to know
19:03:40 <GeKo> yep
19:04:10 * Jeremy_Rand_Talos is actually talking to you in this chat from a POWER9 machine
19:04:26 <GeKo> i don't think we settle it today but we'd ideally have a tier-thingy, too, clearly specifying what we support at which tier
19:04:44 <GeKo> like binaries etc. for tier one
19:04:57 <GeKo> maybe just patches included for tier two
19:05:11 <sysrqb> it seems wise for us to decide on a similar model to Mozilla's tier system, and how the network team have a list of supported platforms
19:05:12 <GeKo> and then tier three like *bsds would just use tarballs we provide
19:05:17 <GeKo> or something
19:05:24 <GeKo> yeah, that's what i meant :)
19:05:30 <sysrqb> yeap :)
19:05:32 <mcs> +1 for defining a policy for tier 1, tier 2, etc.
19:05:37 <sysrqb> *yep
19:06:02 <sysrqb> pili: we should have a discussion about this at some point
19:06:17 <pili> sure :)
19:06:43 <sysrqb> GeKo: thanks for bringing up this topic
19:06:47 <GeKo> the other item i had came up today when helping a user
19:06:48 <GeKo> sure
19:07:16 <GeKo> we have https://aus1.torproject.org/torbrowser/update_3/release/downloads.json
19:07:52 <GeKo> so users/devs can check whether there are new updates for tor browser and can then do their thing with it
19:08:05 <GeKo> but we don's have this documented somewhere
19:08:27 <GeKo> we got some requests for easy access to such information (the .json) file in the past
19:08:39 <GeKo> and therefore made this available
19:09:02 <GeKo> arma is right that we should document it somewhere but i am not sure where
19:09:48 <sysrqb> creating a spec for it sounds reasonable
19:10:06 <sysrqb> and we can link to it from a wiki page, so it's easier to find
19:10:18 <GeKo> (antonela: you might want to put your all hands item to the discussion part otherwise we might lose it)
19:10:40 <pili> this is a nice detail that could also go into the developer portal
19:10:53 <GeKo> pili: yeah, i thought abuot that, too
19:10:56 <Jeremy_Rand_Talos> sysrqb, +1 on linking to it from the wiki
19:11:28 <GeKo> sysrqb: what spec do you meant?
19:11:31 <GeKo> *mean
19:11:48 <GeKo> like a proposal describing what we did with motivation and such?
19:12:00 <sysrqb> yes
19:12:20 <antonela> GeKo: thanks, seems like we _already_ have an agenda -- anyways, if you have any topic that you would like to open during the next meeting in person with firefox devs, please add those to the pad https://pad.riseup.net/p/h_AP8p92R9AhcDaxAUxk
19:12:35 <sysrqb> usually, in tor-spec, there are proposals, and then those proposals become official specifications
19:12:49 <GeKo> okay, i guess that works for me although i felt it being weird as proposals are for future stuff
19:13:07 <GeKo> sysrqb: yeah, we have this too in tor-browser land :)
19:13:19 <sysrqb> or we could jump direction to ducmentatoin what we currently use in a specification
19:13:30 <sysrqb> *documenting
19:13:39 <sysrqb> and skip the proposal stage
19:13:47 <GeKo> well, that because we already have the thing worknig
19:13:50 <GeKo> *working
19:14:33 <GeKo> okay, i'll file the ticket with the outcome of our discussion, thanks
19:14:56 <sysrqb> writing a specification for the current format we provide seems like the most reasonable solution
19:15:05 <sysrqb> but i'm happy to see more discussion on this
19:15:15 <boklm> #16551 was the ticket from when we did this
19:15:44 <sysrqb> thanks boklm
19:16:13 <sysrqb> i added the next discussion item.
19:16:33 <sysrqb> when we used storm, the pad became very slow when it contained multiple weeks of notes
19:16:43 <sysrqb> so we began deleting older notes
19:17:15 <sysrqb> now we're using a riseup pad, and we aren't seeing much slowness (yet), and we'll likely move to nextcloud soon
19:17:47 <sysrqb> i'm curious if any of you would prefer we delete older notes
19:18:07 <sysrqb> or should we keep them wait until we start seeing a performance impact?
19:18:20 <sysrqb> i don't know what our retention policy should be
19:18:25 <mcs> I think it makes sense to delete older notes once they have been sent to the tor-project list. We could decide to keep one or two weeks back in the pad.
19:18:28 <antonela> if we send those to the list, then we can remove them
19:18:31 <Jeremy_Rand_Talos> sysrqb, the notes end up getting archived on a mailing list anyway, right?
19:18:34 <antonela> mcs :)
19:18:57 <mcs> slowdown + cognitive overload will happen :)
19:19:04 <brade> I like to be able to go back one week
19:19:08 <sysrqb> the only informatoin loss is when text is bolded or formated in a non-plain-text way
19:19:26 <sysrqb> but, except for that, the mailing list documents previous notes
19:19:44 <brade> but if it is removed from the pad, I can keep the most recent email
19:19:51 <sysrqb> but i'm happy to maintain the previous week's notes, and delete anything older
19:20:10 <Jeremy_Rand_Talos> ah.  Hmm, is there a straightforward way to archive them on the mailing list in Markdown format or something similar, so that boldness gets preserved?
19:21:05 <sysrqb> i'll require me manually adding formatting in the text
19:21:13 <sysrqb> which i can do, it's simply more manual effort
19:21:20 <sysrqb> but maybe we don't care about bolding
19:21:47 * Jeremy_Rand_Talos wonders if the Etherpad devs would be able to easily add a feature that does that automatically
19:21:54 <sysrqb> this has always be the case, as far as i know
19:22:08 <sysrqb> and i don't know if it being a problem historically
19:22:28 <boklm> or we could use some keyword like [discuss] to indicate a line we want to discuss instead of bolding it
19:22:52 <sysrqb> we can try that
19:23:27 <sysrqb> let's try using that next week, instead of bolding
19:23:32 <sysrqb> does that sound okay for everyone?
19:23:39 <Jeremy_Rand_Talos> +1
19:23:44 <brade> +1
19:23:52 <sysrqb> place it at the beginning of the line, after the '-'
19:23:57 <sysrqb> so i see it :)
19:24:02 <mcs> maybe [discuss] and bold so I can spot easily? :)
19:24:12 <sysrqb> sounds good to me
19:24:21 <Jeremy_Rand_Talos> sounds good
19:24:44 <sysrqb> great, thakns for everyone input on this.
19:24:49 <sysrqb> pili:  i think you have the last one :)
19:24:57 <pili> yup, just a reminder :)
19:25:13 <pili> storm is being shutdown end of January iirc
19:25:25 <pili> so please move any documents you own and/or want to keep
19:26:09 <sysrqb> any questions about this?
19:26:34 <sysrqb> (it only applies for those who have access to storm)
19:27:15 <sysrqb> okay, any last questions/comments/concerns we should talk about in this meeting?
19:27:42 <sysrqb> *crickets*
19:28:03 <sysrqb> thanks everyone! have a good week
19:28:08 <sysrqb> o/
19:28:08 <antonela> thanks!
19:28:10 <GeKo> o/
19:28:13 <Jeremy_Rand_Talos> thanks!
19:28:13 <sysrqb> #end-meeting
19:28:20 <sysrqb> #endmeeting