19:00:52 #startmeeting tor-browser 12/10 19:00:52 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 Useful Commands: #action #agreed #help #info #idea #link #topic. 19:01:09 hello everyone! 19:01:29 please add your items to the pad (https://storm.torproject.org/shared/tHoN4Ii7rLSjPE0OP4gydX4cMGadsXmRQNc-6lwru0N) 19:01:37 and mark those bold you want to talk about 19:02:15 hello 19:04:51 let's get started 19:05:14 sysrqb: you are first 19:05:35 cool 19:06:06 at the all-hands some of us started discussing the Android UI for "tor-launcher" 19:06:15 (or what is effectively tor-launcher on Android) 19:06:23 :) 19:06:48 and we began thinking about whether we want to replicate the flow same flow as desktop 19:07:03 or provide a "smarter" interface 19:07:43 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 not a loading screen 19:08:08 i looked for a similar ticket for desktop, but i didn't see it 19:08:31 for the immediate future, we can implement something similar to desktop, with a loading screen and a configuration screen 19:08:41 Arthur mentioned that idea somewhere… I think there is a ticket somewhere. 19:08:43 or we can try experimenting with a smarter one 19:09:09 I am not sure how “smarter” and “show a browser window” go together. 19:09:31 antonela: already created a mockup for a tor-launcher-like flow on android 19:09:52 mcs: true 19:10:04 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 decision-making... 19:10:28 #27476 maybe? 19:11:34 that seems related 19:11:47 tjr: yeah, that would be part of it 19:11:53 (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 That’s the ticket I was thinking about. 19:12:45 right, I had two goals with this discussion 19:13:11 1) should we replicate desktop's loading screen or should we make that more transparent? 19:13:29 2) should we try being a little smarter when we configure tor? 19:13:47 I think 2) is longer term, and we don't really need to discuss/decide this now 19:13:53 i agree 19:14:05 how is that tight to orbot as we have it right now? 19:14:10 *tied 19:14:26 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 currently on Android we open "Orbot" directly, but that isn't necessary 19:15:27 we can control tor on our own, without using Orbot's home-screen 19:16:37 orbot shows the bootstrapping messages, but we can show a progress bar and our own UI 19:16:48 yes 19:16:49 like https://trac.torproject.org/projects/tor/attachment/ticket/28329/mockups-1.1.2.png 19:17:11 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 or we can maybe show about:tor and a prorgess bar, or something 19:17:19 if we discard orbot anyway later on 19:17:21 ah, right 19:17:36 it isn't very tightly coupled 19:17:43 good 19:17:57 we simply receive some bootstrap message and react to it 19:18:02 i think that would be ideal prescind of the connect button 19:18:28 more of what is happening in ios right now 19:18:56 somethign else i'd like to prevent is re-implementing the about:tor UI as a native Android UI 19:19:18 which would be necessary if we implement the current mockup 19:19:35 the duplication wouldn't be ideal 19:19:43 i see, about:tor and a progress bar is something that we can explore 19:20:35 and brade, i agree, and i think that is easier on android than on desktop 19:20:36 i am fine with trying out 1) if we don't tackle 2) now 19:20:49 because we have more control over when gecko loads 19:20:55 ideally, the best flow is the flow where the user open the app and the browser is ready to run 19:21:01 sure 19:22:16 okay, antonela can you try sketching something like this? based on using about:tor? 19:22:54 of course, this creating more problems with preventing network connections before tor loads because we need gecko for about:tor 19:23:14 but if there aren't any proxy-bypass bugs, this shouldn't be a problem 19:23:14 yep 19:23:42 great, thanks! 19:24:42 okay, i think that's it for me 19:24:50 great, thanks! 19:25:01 pospeselr: i think we should start making progress on #3600 again 19:25:14 which leads to tjr's question 19:26:18 pospeselr: i'll hopefully get up to speed again on that tomorrow/on wednesday 19:26:34 so we had a meeting that relates to 3600 at the all hands 19:26:44 ah, good 19:27:19 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 particularly enabling single sign-on while blocking all the other stuff 19:28:10 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 yeah, that's what i assumed 19:28:44 but this needs disk access to work, right? 19:28:53 how would that work in PBM? 19:29:47 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 regarding disk access, I suppose it depends on the specifics 19:30:26 what does PBM stand for? 19:30:33 private browsing mode, sorry 19:31:09 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 okay thanks :) 19:31:35 i mean mozilla has not implemented indexeddb in private browsing mode yet 19:31:53 ah I see 19:32:12 so, i wonder how this will work with that storage api 19:32:13 then we may need to do that somehow, perhaps some sort of in-memory solution 19:32:34 what's the timeframe for that whole thing? 19:33:27 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 pospeselr: oh, and what exactly did they try regarding redirects and what broke? 19:34:12 like do they have exhausted all the things we might think about? 19:34:29 i mean we have different tolerances and requirements than mozilla 19:34:59 is there a writeup somewhere about methodology and tests they made 19:35:09 and percentage of broken sites etc.? 19:36:17 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 yeah, I don't remember a timeframe for this 19:37:02 but it wasn't immediate 19:37:09 okay, i see 19:37:21 it was discussed in the context of merging FPI and their tracker blocker stuff 19:37:31 and Mozilla, eventually, using FPI instead 19:37:52 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 i just looked for notes from the session, but I don't see them right now 19:38:21 i'll look harder after this meeting 19:39:05 pospeselr: okay, that makes sense 19:39:23 i'll look over what we have for ideas for #3600 this week 19:40:08 and maybe we can move forward with some tests/bits 19:40:43 i don't like the idea of waiting another couple of months years 19:40:53 maybe we can speed up things a bit :) 19:41:27 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 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 tjr: yeah agreed 19:41:57 their==mozilla's 19:42:14 yeah 19:42:34 iirc, the more I thought about your (tjr's) entry the more I like it 19:42:35 glad we are not a browser vendor :) 19:42:45 hah yeah thank god 19:42:47 haha 19:42:49 heh, right :) 19:42:56 yeah, what tjr said sounds like a reasonable start to me 19:43:14 (without properly remembering all the other options) 19:43:43 okay, let's move on i guess 19:43:54 i went over a lot of tickets today and last week 19:44:12 and have assembled a list for our next major mobile alpha milestone 19:44:27 it's tagged with TBA-a3 19:44:28 https://trac.torproject.org/projects/tor/query?status=!closed&keywords=~TBA-a3 19:44:57 neat, thanks! 19:44:59 if anyone working on mobile needs to find tickets to work on, please pick from that list 19:45:19 it should have all the recent serious issues (like crashers) popping up 19:45:26 and the things we need for sponsor8 19:45:56 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 sisbell: so, while i like us building tor ourselves for all number of reasons we have to postpone this a bit 19:47:16 the most important ticket here right now is #27609 19:47:34 Sure, i'll push those off for now 19:47:41 and for the build part #27210 and #28752 19:48:26 i'll leave the list as-is withuot much discussion but i guess we should schedule a meeting 19:48:42 to talk about it and maybe add/remove items so we are on the same page 19:48:51 I think #28752 will be a non-issue after we start building ourselves 19:49:14 But its good to know why the download is occurring in the first place for tor-binary 19:49:25 sisbell: that particular one probably, but: the point here is to understand what is wrong 19:49:49 and why this is happening at all even as we specify the offline resources to be used 19:50:15 that should not happen 19:50:43 so for a meeting time what would be good? 19:51:02 i think igt0 is afk up and including wednesday 19:51:13 so, should we say thursday 1900UTC? 19:51:19 hrm. okay. i won't suggest Weds :) 19:51:27 i can do that 19:51:41 and meanwhile we think about this list and how exactly we want to proceed? 19:52:05 sure 19:52:18 sisbell: would 1900UTC work for you on thursday? 19:52:24 yes, that works 19:52:46 okay, then let's hope igt0 can do this, too 19:52:57 pili: how about you? 19:53:02 would that work? 19:53:11 yup, that's fine 19:53:16 great 19:53:31 i'll send the list an email in case other folks want to show up as well 19:53:39 pili: you are up 19:53:59 just a reminder that we have the Tor Browser release meeting on Wednesday at 19:00 UTC ;) 19:54:16 I will send an email about it also 19:54:22 thanks. 19:54:29 anything else for status updates? 19:56:04 okay a bit of discussion time is left 19:56:09 mozilla all hands 19:56:14 how did it go? 19:56:22 do we have some highlights to share/discuss? 19:57:04 i think we have some notes we should compile into a document/email that is helpful 19:57:17 overall, i think it went really well 19:57:23 yeah it was a good one :) 19:57:51 and it sounds like isa's meeting with mozilla fancy-pants went well 19:57:54 pospeselr: want to collaberate on this? :) 19:58:03 yeah sounds like a plan 19:58:12 great, and yes, a document to reason about would be nice to have 19:58:20 there is the notes doc, we can expand it 19:58:32 okay, i'll start working with what i have 19:58:37 pospeselr: oh, great, i have not heard anything about that meeting yet 19:58:40 the tor branding study meeting was interesting, though I don't personally know how it can be applied 19:59:15 GeKo: ditto! 20:00:07 okay, anything else for today? 20:01:08 thanks all and have a nice week *baf* 20:01:11 #endmeeting