18:59:22 <GeKo> #startmeeting tor-browser 11/19
18:59:22 <MeetBot> Meeting started Mon Nov 19 18:59:22 2018 UTC.  The chair is GeKo. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:59:22 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
18:59:30 <GeKo> hi everyone!
18:59:36 <pospeselr> good morning/afternoon/evening!
18:59:42 <GeKo> let gets started with out weekly meeting
18:59:50 <antonela> o/
19:00:03 <GeKo> https://storm.torproject.org/shared/tHoN4Ii7rLSjPE0OP4gydX4cMGadsXmRQNc-6lwru0N is the pad you will be interested in
19:00:06 <GeKo> please add your items
19:00:16 <mcs> hi
19:00:25 <igt0> o/
19:00:58 <pili> hi
19:01:13 <sisbell> hey
19:03:04 <arthured1lstein> hi everyone
19:03:21 <pospeselr> hmmmm
19:03:25 <pospeselr> an imposter
19:03:46 <sysrqb> sneaky
19:03:48 <pospeselr> you're number 1 in our hearts arthur
19:04:02 <sysrqb> hi hi
19:04:31 <GeKo> alright, let's get started
19:04:34 <arthuredelstein> pospeselr: :)
19:04:51 <GeKo> i just realized this week is thanksgiving for the us folks
19:05:03 <GeKo> might not be the best time for releasing things
19:05:06 <GeKo> but, hey
19:05:17 <GeKo> pospeselr: you are up
19:06:05 <pospeselr> hey hi everyone
19:06:26 <pospeselr> so some open questions regarding #25702
19:06:36 <pospeselr> some design related, some technical
19:06:40 <pospeselr> i'll guess i'll start from teh top
19:07:30 <pospeselr> so long story short, we can direct the firefox build to different directories containing branding info (strings, icons, assets, etc) by adding an override to the mozconfig
19:08:17 <pospeselr> what's the preference for modifying tor-browser-build to account for this? My first instinct is to just update the build script to dynamically insert the appropriate string into the current mozconfig based off of make target
19:08:46 <pospeselr> but that may seem a bit magical
19:09:04 <GeKo> what does that overwrite look like?
19:09:07 <sysrqb> can you addit on the mach configure line?
19:09:14 <sysrqb> (*add it)
19:09:16 <pospeselr> ac_add_options --with-branding=browser/branding/nightly
19:09:33 <pospeselr> or official or alpha
19:09:59 <GeKo> should be doable in the respective mozconfig files?
19:10:05 <pospeselr> sysrqb: if we can add ac_add_options to mach, than yes
19:10:16 <pospeselr> GeKo: right but if we do that we would need to triple the number of mozconfigs
19:10:24 <pospeselr> since we would need a different path for alpha, release and nightly
19:10:32 <pospeselr> (since they have different icons)
19:10:34 <boklm> could it be set using an environment variable that we define in the build script?
19:10:56 <sysrqb> i think it's simply add '--with-branding=browser/branding/nightly' along with the other ./mach configure options we pass within the build tor-browser-build build script
19:11:47 <pospeselr> boklm, sysrqb: ok that makes sense
19:11:59 <pospeselr> ok next up
19:12:19 <pospeselr> the windows NSIS installer uses a older generic onion icon
19:12:46 <pospeselr> thinking we should probably also update that with an appropriate release icon
19:13:05 <GeKo> would be good, yes
19:13:19 <pospeselr> which is easily enough done, but what do y'all think about updating the installer's default install directory per release?
19:13:41 <pospeselr> so you could have alpha, nightly, and release intalled side-by-side without stomping over each other's shortcuts in desktop and start menu?
19:13:59 <pospeselr> (ie is there a privacy/security reason that we don't already do this?)
19:14:09 <GeKo> fine with me, but let's do it in a different bug
19:14:12 <GeKo> no
19:14:42 <GeKo> (and we should think more about possible implications in that bug)
19:15:03 <pospeselr> ok and finally probably a side-effect of legacy interactions between tor-browser and tor-button
19:15:39 <pospeselr> I've updated torbutton's About dialog (this one: https://share.riseup.net/#GouAI9HHZkLR9HbbVxviOg ) to point to an asset added by tor-browser
19:15:57 <pospeselr> used to be the old tor-browser icon that was packaged in the torbutton extension
19:16:22 <pospeselr> should we have a bug to migrate the entire dialog back into tor-browser?
19:16:37 <pospeselr> kind of deals with the long term plan of torbutton
19:17:31 <GeKo> sounds good to me
19:17:40 <pospeselr> torbutton doesn't know what release it's packaged with, so rather than informing torbutton at build time, I'm just having the dialog reference tor-browser's packaged asset
19:17:44 <pospeselr> ok good excellent that's all from me
19:18:04 <GeKo> thanks!
19:18:14 <GeKo> igt0: you are next it seems
19:18:36 <sysrqb> i bolded that
19:18:43 <sysrqb> so i can take it
19:18:58 <antonela> is this the relevant ticket? #28507
19:19:04 <sysrqb> yes
19:19:32 <sysrqb> in summary, i'm worried about how the app interacts with Android's app model
19:20:16 <sysrqb> specifically, if we expect that the app should forget/clear all tabs and state when the user switches to antoerh app and then switches back to TBA
19:20:28 <sysrqb> or if the app should clear its state only when it is "quit"
19:20:53 <sysrqb> i think part of the confusion is that most android apps don't have a "quit" option
19:20:54 <pospeselr> sysrqb: can we steal firefox-focus' model with the perma-notification that let's you clear your current session?
19:21:10 <sysrqb> yes, we have a ticket for that, as well
19:21:16 <pospeselr> sysrqb: true and many users don't know you can quit by swiping them away in the switcher
19:21:23 <sysrqb> well...
19:21:28 <GeKo> sysrqb: i think clear once it quits sounds like a decent start
19:21:44 <sysrqb> i tihnk we need to define what we mean by "quit"
19:21:47 <GeKo> and, of course, once we do new identity later on
19:21:59 <sysrqb> there is an explicit "quit" button in the browser menu, at the bottom
19:22:23 <sysrqb> any other quit-like action does not actually quit
19:22:25 <GeKo> yeah, i was thinking of that one
19:22:36 <GeKo> as a decent start
19:22:38 <igt0> so right now, when the user closes the app using the swipe gesture. It goes in a different code path.
19:22:58 <sysrqb> and i think igt0's patch for #28507 is good, but it will be confusing for users
19:23:25 <GeKo> is orfox addressing this issue somehow?
19:23:29 <sysrqb> because, if i understand it correctly, it closes all tabs and clears history after switching apps
19:23:32 <sysrqb> but not explicitly quitting the app
19:23:40 <sysrqb> GeKo: no
19:23:58 <sysrqb> orfox has the same quit button
19:24:08 <sysrqb> but it doesn't have another solution for this
19:24:40 <mcs> On Android, can we tell the difference between “app was closed due to something the user did” vs. “app was closed by the system?”
19:24:50 <sysrqb> (igt0's patch actually clears it when the app restarts, but to the user it'll seem like the state was lost when they switched apps)
19:25:08 <sysrqb> mcs: yes, in some cases
19:25:13 <mcs> but not all?
19:25:53 <sysrqb> actually, i can't think of any cases where we can't differentiate between them
19:26:03 <sysrqb> so, i guess "yes"
19:26:33 <sysrqb> the "user swipped away the app" is the hardest one
19:27:02 <igt0> the tricky part here is when the app is closed by the system, we don't have "time" to call gecko (the event dispatcher doesn't work in the onDestroy method), thus we can't clean the data.
19:27:05 <sysrqb> but i think the notification we get is unique to a user action
19:27:44 <sysrqb> hrm.
19:27:54 <mcs> “user swiped away” should be treated he same as if the user did a quit from within the app. Unfortunate that we can’t clean up on the way out.
19:28:59 <sysrqb> i wonder if we can do soemthing that the application level, rather than at the activity level
19:29:29 <sisbell> sometimes you need to clear state when app starts (assuming it is persistent state)
19:29:33 <sysrqb> but i agree "swipping away" is probably an indiciation the user wants to "quit"
19:29:48 <igt0> sisbell, yep, it is what we are doing in the patch :/
19:29:52 <sisbell> I'm not sure of details here, just talking in general
19:31:10 <GeKo> okay, so do we think we shouhld think harder about this before doing anything?
19:31:16 <sysrqb> i'm simply worried that clearing previous state whenever GeckoApp:onCreate() is called will be confusing
19:31:17 <GeKo> *should
19:31:36 <GeKo> yeah, could be
19:31:46 <sisbell> also keep in mind on some devices swipe away kills apps in others it just backgrounds them for later resume
19:31:54 <GeKo> i think i am fine either way
19:32:37 <GeKo> i just realized that folks would see our about:tor banner much more often if we had a clean state to "start" with
19:33:42 <sysrqb> should we open about:tor when a new tab is open, too?
19:33:55 <sysrqb> s/open/use/
19:34:16 <igt0> sysrqb, yep
19:34:35 <antonela> that is a fair question, once i did a review with Princeton's Marshini, she pointed it out
19:35:02 * mcs really likes his new tabs to be empty
19:35:02 <antonela> we are not open about:tor in a new tab at desktop
19:35:15 <sysrqb> yeah
19:35:18 <antonela> but the major browsers do it
19:35:32 <pospeselr> yeah currently it's just a blank white page
19:35:46 <GeKo> that works for me
19:36:00 <igt0> on mobile, it would be the activity stream
19:36:12 <GeKo> we should think harder about showing about:tor on Ctrl+t
19:36:34 <antonela> https://www.notion.so/Princeton-Marshini-Aga-Review-10e04cd4826a4ecd86f0c1cbd541f6fc#ce172892ea2c4b68bd4847969237dd58
19:36:42 <mcs> I would want to make sure I could disable that behavior like I can in Firefox… but maybe I am weird.
19:36:52 <GeKo> (or however folks are opening their new tabs)
19:37:32 <igt0> mcs, yep, you can!
19:37:58 <GeKo> sysrqb: igt0: so what should be the plan here?
19:38:11 <GeKo> in particular for the upcoming release
19:38:32 <sysrqb> ok, i think igt0's may be good enough
19:38:40 <sysrqb> i hope
19:38:47 <sysrqb> at least we can try it
19:39:06 <GeKo> okay
19:39:21 <sysrqb> in theory, Android should not kill the app if the user switches apps
19:39:22 <GeKo> antonela: you are up
19:39:41 <antonela> thanks! anything else on my side for security settings?
19:40:02 <antonela> what is left? I covered the latest comments, we have an icon, i think we are groot!
19:40:27 <GeKo> explaing that the https-e and noscript icons are gone?
19:40:30 <GeKo> *explaining
19:40:36 <GeKo> do we have that covered?
19:41:14 <antonela> not yet, if we are ok with the changes i'll go through the onboarding
19:41:28 <antonela> also, do you want to update the proposal to make it reflect what we are doing?
19:41:36 <GeKo> and we might want to explain a bit better why we think the user should restart after switching a level
19:41:51 <antonela> yep
19:42:02 <antonela> 3.x Restore Default Security Settings and 2.1.2.X Change Security Level and Restart to Apply Changes
19:42:09 <antonela> are the sections we should add
19:43:04 <GeKo> but apart fromt that i think we are good
19:43:16 <antonela> awesome
19:43:26 <GeKo> i think i can start to work on that once we have the new releases out this week
19:43:36 <GeKo> and we address further things while we are going
19:43:51 <antonela> perfect, i'm focusing on TBA this week
19:44:01 <sysrqb> \o/
19:44:04 <GeKo> sounds good
19:44:04 <sysrqb> :)
19:44:14 <antonela> so i'll probably have the onboarding iteration to introduce this changes the week after
19:44:25 <GeKo> wfm
19:44:36 <antonela> yes! i invited fabby from guardian to the ux meeting tomorrow to discuss the user flow together
19:45:01 <antonela> she has been working in orbot/orfox before and i'm sure she has opinions :)
19:45:11 <GeKo> great
19:45:18 <sysrqb> awesome
19:45:21 <antonela> also, we will be sharing a session in IFF about Tor Mobile \o/
19:45:33 <GeKo> i guess #28329 is the ticket to follow along at home?
19:45:40 <antonela> yep
19:46:21 <sysrqb> congrats!
19:46:53 <GeKo> antonela: anythign else for the group
19:46:54 <GeKo> ?
19:47:08 <antonela> nope thanks!
19:47:20 <GeKo> arthuredelstein: just one quick think about the permissions patch
19:47:45 <GeKo> what is the plan here? are you shepherding it until it lands on m-c?
19:47:51 <GeKo> should we do it?
19:48:08 <GeKo> and what about backports for tor browser?
19:48:08 <arthuredelstein> good question. it probably makes sense for me to shepherd it if I can
19:48:39 <arthuredelstein> but if it turns out that's not practical, then I guess I can try to hand it off
19:48:47 <arthuredelstein> maybe we can wait and see?
19:49:08 <arthuredelstein> I mean start with me attempting to shepherd? :)
19:49:23 <GeKo> sounds good. i am in particular interested in possible esr60 backports
19:49:34 <arthuredelstein> yes, that makes sense
19:49:37 <GeKo> as at least the growl-like notification bug should get fixes that way
19:49:46 <arthuredelstein> right
19:49:59 <GeKo> i have not looked but maybe just picking that one on top of our stuff we have would be easy?
19:50:29 <arthuredelstein> yes, that's a good suggestion
19:50:50 <GeKo> okay. do we have other status updates?
19:51:37 <GeKo> okay, discussion time
19:51:47 <GeKo> are we good with our release plans?
19:51:56 <GeKo> or should we postpone stuff?
19:52:19 <sysrqb> i think yes, but we have a lot that still must be finished/merged
19:52:49 <sysrqb> end-of-week is possible, i think
19:53:01 <GeKo> yep
19:53:20 <GeKo> i hope we have everything in tor-browser-build by eof tomorrow
19:53:29 <GeKo> and then have some nightly builds
19:53:39 <sysrqb> that'd be very nice
19:53:44 <GeKo> *eod
19:53:58 <sisbell> I think there are just a few minor issues left on the build
19:54:01 <GeKo> but we'll see what pops up :)
19:54:11 <GeKo> sisbell: i agree
19:54:14 <sysrqb> heh, indeed
19:54:29 <GeKo> (although i have not looked closely at the orbot integration yet)
19:54:32 <GeKo> ;)
19:54:45 <GeKo> so, final topic from me
19:54:58 <GeKo> do we already have ideas for the mozilla all hands meeting?
19:55:12 <GeKo> we should brainstorm a bit
19:55:33 <GeKo> or at least start with ideas today and think over that topic over the coming week
19:56:08 <GeKo> tjr had two ideas: sandboxing and what mozilla can help in particular looking at our efforts on linux
19:56:10 <sysrqb> i think continuing the sandboxing discussion is good
19:56:20 <GeKo> which we'll likely to start focusing on
19:56:47 <GeKo> and what could mozilla help with wrt to torbutton/tor-launcher integration into our tor-browser code base
19:56:59 <GeKo> both seem worthwhile to think about
19:57:23 <sysrqb> yes. i'm trying to focus my thoughts on how I feel about our decision to base TBA on 60esr
19:58:16 <sysrqb> so i hope i can have a discussion with mozilla about that future and whether we should continue with this plan
19:58:27 <GeKo> which reminds me about the topic, yes, that
19:58:30 <GeKo> :)
19:58:42 <arthuredelstein> One idea I had suggested was a discussion about Firefox's Tracking Protection, Applie's ITP and TBB's RFP/FPI. Can we cross-pollinate the various approaches?
19:58:44 <sysrqb> :)
19:59:42 <GeKo> arthuredelstein: good idea.
20:00:33 <GeKo> might actually be interesing to see mozilla's plans here in the near/medium future
20:00:50 <arthuredelstein> yes!
20:00:53 <GeKo> and our position in that regard
20:00:59 <GeKo> and where we can/should help
20:01:31 <GeKo> okay, that's another two topics
20:01:58 <GeKo> i guess we can keep brainstorming over the week and come up with some "final" list next monday
20:02:14 <GeKo> do we have anything else to discuss today?
20:03:06 <arthuredelstein> other subjects from tjr included: networking (QUIC), brand study, rust build, UI/UX, extensions
20:04:15 <GeKo> ah, okay, i did not see those (just the mail i replied)
20:04:18 <tjr> brand study is/should happen; as will QUIC. UI/UX antonela asked for, so that's happening too
20:04:30 <tjr> rust stuff I am still talking to ted about
20:04:35 <GeKo> so, not sure. but, yes, QUCI def
20:04:45 <GeKo> *QUIC
20:04:48 <antonela> re:ui/ux ethan send me an email about to do one sync, and i said yes !
20:04:49 <tjr> the mail I sent to GK was just the meetings I wasn't sure about :)
20:04:50 <GeKo> great, thanks
20:05:00 <GeKo> hah :)
20:05:14 <GeKo> anyway, i think that's it for today
20:05:18 <GeKo> thanks all *baf*
20:05:22 <GeKo> #endmeeting