19:00:52 <GeKo> #startmeeting tor-browser 12/10
19:00:52 <MeetBot> Meeting started Mon Dec 10 19:00:52 2018 UTC.  The chair is GeKo. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:00:52 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
19:01:09 <GeKo> hello everyone!
19:01:29 <GeKo> please add your items to the pad (https://storm.torproject.org/shared/tHoN4Ii7rLSjPE0OP4gydX4cMGadsXmRQNc-6lwru0N)
19:01:37 <GeKo> and mark those bold you want to talk about
19:02:15 <sisbell> hello
19:04:51 <GeKo> let's get started
19:05:14 <GeKo> sysrqb: you are first
19:05:35 <sysrqb> cool
19:06:06 <sysrqb> at the all-hands some of us started discussing the Android UI for "tor-launcher"
19:06:15 <sysrqb> (or what is effectively tor-launcher on Android)
19:06:23 <antonela> :)
19:06:48 <sysrqb> and we began thinking about whether we want to replicate the flow same flow as desktop
19:07:03 <sysrqb> or provide a "smarter" interface
19:07:43 <sysrqb> the goal being the user wants to use a web browser, we should show them a web browser as the first sreen
19:07:46 <sysrqb> not a loading screen
19:08:08 <sysrqb> i looked for a similar ticket for desktop, but i didn't see it
19:08:31 <sysrqb> for the immediate future, we can implement something similar to desktop, with a loading screen and a configuration screen
19:08:41 <mcs> Arthur mentioned that idea somewhere… I think there is a ticket somewhere.
19:08:43 <sysrqb> or we can try experimenting with a smarter one
19:09:09 <mcs> I am not sure how “smarter” and “show a browser window” go together.
19:09:31 <sysrqb> antonela: already created a mockup for a tor-launcher-like flow on android
19:09:52 <sysrqb> mcs: true
19:10:04 <tjr> So IIUC OONI did some testing for us to determine where Tor was blcoked, and it was constsntly blocked in like 3 or 4 countries and consistently not blocked elsewhere. But that was presumably for residential or data center connections. Do we have any confidence the story is the same for cellular networks around the world?  That might guide the
19:10:04 <tjr> decision-making...
19:10:28 <GeKo> #27476 maybe?
19:11:34 <sysrqb> that seems related
19:11:47 <sysrqb> tjr: yeah, that would be part of it
19:11:53 <tjr> (Especially if we could key off locale or provider information on the phone to determine whether to be more aggressive about prompting for configuration....)
19:11:55 <mcs> That’s the ticket I was thinking about.
19:12:45 <sysrqb> right, I had two goals with this discussion
19:13:11 <sysrqb> 1) should we replicate desktop's loading screen or should we make that more transparent?
19:13:29 <sysrqb> 2) should we try being a little smarter when we configure tor?
19:13:47 <sysrqb> I think 2) is longer term, and we don't really need to discuss/decide this now
19:13:53 <GeKo> i agree
19:14:05 <GeKo> how is that tight to orbot as we have it right now?
19:14:10 <GeKo> *tied
19:14:26 <brade> The important thing for #1 is that the browser is prevented from launching and doing a host of network things before tor is loaded/configured
19:15:00 <sysrqb> currently on Android we open "Orbot" directly, but that isn't necessary
19:15:27 <sysrqb> we can control tor on our own, without using Orbot's home-screen
19:16:37 <sysrqb> orbot shows the bootstrapping messages, but we can show a progress bar and our own UI
19:16:48 <GeKo> yes
19:16:49 <sysrqb> like https://trac.torproject.org/projects/tor/attachment/ticket/28329/mockups-1.1.2.png
19:17:11 <GeKo> the point of my question was that i don't want to spend a lot of time making the orbot workflow shiny
19:17:13 <sysrqb> or we can maybe show about:tor and a prorgess bar, or something
19:17:19 <GeKo> if we discard orbot anyway later on
19:17:21 <sysrqb> ah, right
19:17:36 <sysrqb> it isn't very tightly coupled
19:17:43 <GeKo> good
19:17:57 <sysrqb> we simply receive some bootstrap message and react to it
19:18:02 <antonela> i think that would be ideal prescind of the connect button
19:18:28 <antonela> more of what is happening in ios right now
19:18:56 <sysrqb> somethign else i'd like to prevent is re-implementing the about:tor UI as a native Android UI
19:19:18 <sysrqb> which would be necessary if we implement the current mockup
19:19:35 <sysrqb> the duplication wouldn't be ideal
19:19:43 <antonela> i see, about:tor and a progress bar is something that we can explore
19:20:35 <sysrqb> and brade, i agree, and i think that is easier on android than on desktop
19:20:36 <GeKo> i am fine with trying out 1) if we don't tackle 2) now
19:20:49 <sysrqb> because we have more control over when gecko loads
19:20:55 <antonela> ideally, the best flow is the flow where the user open the app and the browser is ready to run
19:21:01 <GeKo> sure
19:22:16 <sysrqb> okay, antonela can you try sketching something like this? based on using about:tor?
19:22:54 <sysrqb> of course, this creating more problems with preventing network connections before tor loads because we need gecko for about:tor
19:23:14 <sysrqb> but if there aren't any proxy-bypass bugs, this shouldn't be a problem
19:23:14 <antonela> yep
19:23:42 <sysrqb> great, thanks!
19:24:42 <sysrqb> okay, i think that's it for me
19:24:50 <GeKo> great, thanks!
19:25:01 <GeKo> pospeselr: i think we should start making progress on #3600 again
19:25:14 <GeKo> which leads to tjr's question
19:26:18 <GeKo> pospeselr: i'll hopefully get up to speed again on that tomorrow/on wednesday
19:26:34 <pospeselr> so we had a meeting that relates to 3600 at the all hands
19:26:44 <GeKo> ah, good
19:27:19 <pospeselr> steven's team are working on tracking protection in general and a LOT of the problems they are running into are basically identical to the issues with #3600
19:27:40 <pospeselr> particularly enabling single sign-on while blocking all the other stuff
19:28:10 <pospeselr> it seems like one of the thing they are going to be pursuing is working with apple to get a standardized cross-website data storage API
19:28:26 <GeKo> yeah, that's what i assumed
19:28:44 <GeKo> but this needs disk access to work, right?
19:28:53 <GeKo> how would that work in PBM?
19:29:47 <pospeselr> so that mozilla can point to this 'standard' API as a way to properly do single-sign on and then once that is available, it would be much more palatable (for us at least?) to implement proper first party isolation that breaks the various solutions websites have come up with to do these things
19:30:15 <pospeselr> regarding disk access, I suppose it depends on the specifics
19:30:26 <pospeselr> what does PBM stand for?
19:30:33 <GeKo> private browsing mode, sorry
19:31:09 <pospeselr> and tjr: regarding your question you're not crazy, the last bit is not a finished product and I moved over to browser re-branding in the middle of it
19:31:22 <tjr> okay thanks :)
19:31:35 <GeKo> i mean mozilla has not implemented indexeddb in private browsing mode yet
19:31:53 <pospeselr> ah I see
19:32:12 <GeKo> so, i wonder how this will work with that storage api
19:32:13 <pospeselr> then we may need to do that somehow, perhaps some sort of in-memory solution
19:32:34 <GeKo> what's the timeframe for that whole thing?
19:33:27 <pospeselr> I don't recall any specific dates being dropped during that meeting (sysrqb ? )but given that it's a proposal for a new web standard I assume it would take awhile
19:33:55 <GeKo> pospeselr: oh, and what exactly did they try regarding redirects and what broke?
19:34:12 <GeKo> like do they have exhausted all the things we might think about?
19:34:29 <GeKo> i mean we have different tolerances and requirements than mozilla
19:34:59 <GeKo> is there a writeup somewhere about methodology and tests they made
19:35:09 <GeKo> and percentage of broken sites etc.?
19:36:17 <pospeselr> I would need to dig up the meeting notes to give you specifics, but there thing wasn't for redirects specifically, but third party tracking in general and I kind of realized midway through the meeting that they were describing a lot of the trade-offs that we have regarding #3600
19:36:54 <sysrqb> yeah, I don't remember a timeframe for this
19:37:02 <sysrqb> but it wasn't immediate
19:37:09 <GeKo> okay, i see
19:37:21 <sysrqb> it was discussed in the context of merging FPI and their tracker blocker stuff
19:37:31 <sysrqb> and Mozilla, eventually, using FPI instead
19:37:52 <pospeselr> I'll ping Steven for specifics, but the impression I got was that I should be comparing notes and working with them on this since we're trying to solve a similar problem
19:38:16 <sysrqb> i just looked for notes from the session, but I don't see them right now
19:38:21 <sysrqb> i'll look harder after this meeting
19:39:05 <GeKo> pospeselr: okay, that makes sense
19:39:23 <GeKo> i'll look over what we have for ideas for #3600 this week
19:40:08 <GeKo> and maybe we can move forward with some tests/bits
19:40:43 <GeKo> i don't like the idea of waiting another couple of months years
19:40:53 <GeKo> maybe we can speed up things a bit :)
19:41:27 <tjr> I hesitate to promote my own idea; but I think the 'drop set-cookies from redirecting domains we have no existing data for' is pretty low risk....
19:41:40 <sysrqb> yes, ideally, but their position is this can't be fixed browser-side, this must be something websites are forced into using a non-broken solution
19:41:44 <pospeselr> tjr: yeah agreed
19:41:57 <sysrqb> their==mozilla's
19:42:14 <GeKo> yeah
19:42:34 <pospeselr> iirc, the more I thought about your (tjr's) entry the more I like it
19:42:35 <GeKo> glad we are not a browser vendor :)
19:42:45 <pospeselr> hah yeah thank god
19:42:47 <antonela> haha
19:42:49 <sysrqb> heh, right :)
19:42:56 <GeKo> yeah, what tjr said sounds like a reasonable start to me
19:43:14 <GeKo> (without properly remembering all the other options)
19:43:43 <GeKo> okay, let's move on i guess
19:43:54 <GeKo> i went over a lot of tickets today and last week
19:44:12 <GeKo> and have assembled a list for our next major mobile alpha milestone
19:44:27 <GeKo> it's tagged with TBA-a3
19:44:28 <GeKo> https://trac.torproject.org/projects/tor/query?status=!closed&keywords=~TBA-a3
19:44:57 <sysrqb> neat, thanks!
19:44:59 <GeKo> if anyone working on mobile needs to find tickets to work on, please pick from that list
19:45:19 <GeKo> it should have all the recent serious issues (like crashers) popping up
19:45:26 <GeKo> and the things we need for sponsor8
19:45:56 <GeKo> and should be aligned with what we said should be in our third milestone when doing the roadmapping part a while back
19:46:12 * antonela checking TBA-a3 ux-team tickets
19:46:54 <GeKo> sisbell: so, while i like us building tor ourselves for all number of reasons we have to postpone this a bit
19:47:16 <GeKo> the most important ticket here right now is #27609
19:47:34 <sisbell> Sure, i'll push those off for now
19:47:41 <GeKo> and for the build part #27210 and #28752
19:48:26 <GeKo> i'll leave the  list as-is withuot much discussion but i guess we should schedule a meeting
19:48:42 <GeKo> to talk about it and maybe add/remove items so we are on the same page
19:48:51 <sisbell> I think #28752 will be a non-issue after we start building ourselves
19:49:14 <sisbell> But its good to know why the download is occurring in the first place for tor-binary
19:49:25 <GeKo> sisbell: that particular one probably, but: the point here is to understand what is wrong
19:49:49 <GeKo> and why this is happening at all even as we specify the offline resources to be used
19:50:15 <GeKo> that should not happen
19:50:43 <GeKo> so for a meeting time what would be good?
19:51:02 <GeKo> i think igt0 is afk up and including wednesday
19:51:13 <GeKo> so, should we say thursday 1900UTC?
19:51:19 <sysrqb> hrm. okay. i won't suggest Weds :)
19:51:27 <sysrqb> i can do that
19:51:41 <GeKo> and meanwhile we think about this list and how exactly we want to proceed?
19:52:05 <sysrqb> sure
19:52:18 <GeKo> sisbell: would 1900UTC work for you on thursday?
19:52:24 <sisbell> yes, that works
19:52:46 <GeKo> okay, then let's hope igt0 can do this, too
19:52:57 <GeKo> pili: how about you?
19:53:02 <GeKo> would that work?
19:53:11 <pili> yup, that's fine
19:53:16 <GeKo> great
19:53:31 <GeKo> i'll send the list an email in case other folks want to show up as well
19:53:39 <GeKo> pili: you are up
19:53:59 <pili> just a reminder that we have the Tor Browser release meeting on Wednesday at 19:00 UTC ;)
19:54:16 <pili> I will send an email about it also
19:54:22 <GeKo> thanks.
19:54:29 <GeKo> anything else for status updates?
19:56:04 <GeKo> okay a bit of discussion time is left
19:56:09 <GeKo> mozilla all hands
19:56:14 <GeKo> how did it go?
19:56:22 <GeKo> do we have some highlights to share/discuss?
19:57:04 <sysrqb> i think we have some notes we should compile into a document/email that is helpful
19:57:17 <sysrqb> overall, i think it went really well
19:57:23 <pospeselr> yeah it was a good one :)
19:57:51 <pospeselr> and it sounds like isa's meeting with mozilla fancy-pants went well
19:57:54 <sysrqb> pospeselr: want to collaberate on this? :)
19:58:03 <pospeselr> yeah sounds like a plan
19:58:12 <GeKo> great, and yes, a document to reason about would be nice to have
19:58:20 <antonela> there is the notes doc, we can expand it
19:58:32 <sysrqb> okay, i'll start working with what i have
19:58:37 <GeKo> pospeselr: oh, great, i have not heard anything about that meeting yet
19:58:40 <pospeselr> the tor branding study meeting was interesting, though I don't personally know how it can be applied
19:59:15 <tjr> GeKo: ditto!
20:00:07 <GeKo> okay, anything else for today?
20:01:08 <GeKo> thanks all and have a nice week *baf*
20:01:11 <GeKo> #endmeeting