18:58:24 #startmeeting tor-browser-vision 03/01 18:58:24 Meeting started Fri Mar 1 18:58:24 2019 UTC. The chair is pili. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:58:24 Useful Commands: #action #agreed #help #info #idea #link #topic. 18:58:27 \o\ 18:58:46 #agreed 18:58:57 Hi everyone, thanks for making the time to attend this meeting :) 18:59:20 Last time we concentrated on really big long term things 18:59:58 This time it would be good to think about what we want to achieve during 2019 19:00:09 And next year also 19:01:15 This could be what we want to be working on or also what state we want Tor Browser to be in 19:01:38 Who wants to start? :) 19:02:08 mingw-clang and esr68 are necessities I think... 19:02:09 (Virtual beer for the first idea) 19:02:42 I think one thing that's sorely needed that I've discovered from my work on #25658 (security level redesign) is that we have a lot of 'fit and finish' type things to take care of 19:02:46 isabela: your email with the background was very helpful! 19:02:49 A stable TBA release (should be soon, right?) 19:03:04 mismatched colors, about:preference settings that shouldn't be visible, that sort of thing 19:03:12 pospeselr: We never seem to find enough time for polish 19:03:19 mcs: we hope! :) 19:03:22 sstevenson: tx 19:03:30 soooooooooon 19:03:39 pospeselr, yes! lets fix all the things 19:03:55 So, are we being too ambitious? 19:03:57 things you don't really notice until you have to actually look at the UI for awhile :p 19:04:34 What would it take for us to feel like something is done-done? 19:04:46 * antonela saw that pixel icon since the zero day 19:05:19 pili, nothing is done-done, but we can improve on each iteration. Features for example will improve based on testing. 19:05:34 it needs to feel like a cohesive product, rather than a conglomeration of disparate parts 19:05:46 the new circuit display is a huge improvement for instance 19:06:09 antonela: yes, we iterate as we go and that’s perfectly fine 19:06:10 killing thesecurity slider and moving it to about:preferences will be another 19:07:10 walking through user journeys and discover more appropriate ways to display warnings, will be next 19:07:23 woo 19:07:56 During the 2nd half of 2019 or so, it would be good to think about adding more automation for config, e.g., #29590 and the desktop counterpart tickets. 19:08:04 mcs +1 19:08:43 maybe think about small steps we can take soon that will lead to bigger steps later. 19:10:04 i think a large problem is we're hacking on firefox so it better meets our needs, while also adding new features and UI/UX improvements so Tor Browser mets our needs, on the whole 19:10:25 so i'm not sure if there will eer be enough time for something to be done-done 19:10:34 *ever 19:10:36 I think it would be cool to think about what we can do for better and more usable fingerprinting resistance. Letterboxing, maybe deploying something for canvas like software rendering, and an incremental redirect protection 19:10:39 another item to throw into the discussion: sandboxing analysis / planning was also on our roadmap. 19:10:44 yeah, and we'll always be playing catchup with the esr releases as they change things 19:11:12 Mcs yes about sand boxing 19:11:21 yeah sandboxing 19:11:42 yeah,"soon" :) 19:12:19 We need to find a good finder for it 19:12:25 Funder 19:12:44 mcs: although if we want to do smoething a la yawning's stuf 19:12:45 f 19:12:54 it most likely means a new position 19:13:11 so, this is probably not relevant to the browser work at hand 19:13:21 even though it might influence each other 19:13:26 GeKo: Fair enough. Funding is definitely an issue. 19:13:36 s/it/both/ 19:14:09 There are some interdependencies with other teams for 2019 too, e.g., some browser work needs to be done related to PTs and censorship circumvention. Snowflake and friends. 19:17:07 where''s a good outcome from this discussion? 19:17:17 err, *what's 19:17:25 or helpful outcome, maybe 19:18:17 i think a picture where we are in 2 years 19:18:25 or where we want to be 19:18:51 sysrqb: also I get ideas to come up with a number of “strands” that we can weave into different funding narratives 19:18:52 do we want to be still on the esr train in 2 years? 19:19:11 okay, i'll throw out that we should be working with other organizations, in addition to Mozilla, within the next two years :) 19:19:14 (who say "no" has to do all the work :D ) 19:19:25 GeKo: lol 19:19:36 *says 19:19:49 sysrqb: which other organizations are you thinking of? 19:19:55 what does "working with" mean? 19:19:58 GeKo: but that is a good question 19:20:06 GeKo: esr train one 19:20:14 yeah, and a tough one 19:20:23 maybe Apple? Maybe Chromium? i'm not entirely sure 19:20:38 but putting all out eggs in the Mozilla basket seems risky 19:21:24 sysrqb: tentatively agree 19:21:35 Apple seems like a better option between them and Google 19:21:40 especially if we actually want other browsers providing a private browser mode based on our design doc 19:21:58 i wouldn't rule out Chromium, the open source side 19:22:13 Chrome, specifically, i'm less optimistic about 19:22:26 I am not sure if the other browser projects are open enough for us to be able to work with them effectively. 19:22:48 well, brave is doing it, maybe being more closer? 19:22:49 maybe, but have we tried? 19:22:50 and I imagine it could be a lot of work just to get to the same stage we are at now 19:23:01 (e.g., how independent of Google is Chromium? I don’t know) 19:23:35 sysrqb: where do you see the risk at mozilla's side? 19:23:36 pili: yes, but i don't think they'll start implementing somethign comparable unless we give them a little push 19:23:45 and try getting involved and advocating for it 19:23:48 _especially_ compared to chrome and apple's stuff 19:23:56 GeKo: either they change their mind 19:24:13 GeKo: or in two years we haven't made any progress compared with now 19:24:13 sysrqb: so it's more to get them to raise their game? ;) 19:24:34 pili: yeah 19:24:36 progress in what regard? 19:24:50 progress in them shipping a tor mode 19:25:01 or, even shipping tor in the background 19:25:05 whatever that means 19:25:21 (for telemetry or updates pings, etc) 19:25:35 the ideal situation would be things like brave does that work on including tor themselves in the browser and work with us on what they need for that 19:25:43 i'm not sure we should assume they will follow through on this plan 19:25:52 sysrqb: it does seem like apple is doing a lot of great work on anti-fingerprinting stuff, and we don't talk to them much. do we even know who they are? 19:26:09 arma1: they sure are, and i don't think we do 19:26:15 maybe GeKo has a contact? or tjr? 19:26:26 but i don't think we communicate with them, in general 19:26:27 i have written an email to to john wilander who implemented their anti-tracking stuff 19:26:27 i assume moz has contacts 19:26:32 I can maybe discuss some contacts offline 19:26:32 What is the goal in working with another browser? To try to replicate some percentage of TB (like Brave has done) or to promote things like antifingerprinting/fpi? 19:26:35 (e.g. the redirect handling) 19:26:41 and did not get anything back 19:27:19 one goal of expanding to other browsers is indeed to promote changing the whole ecosystem. that is, to get everybody using our goals and priorities from tor browser. 19:27:22 tjr|emailifneeded: i'd say to start talking advocating some feature parity 19:27:42 and maybe discussing how we can work toward similar goals 19:27:50 From discussions at Mozilla and other folks, my feeling is that the biggest bottleneck to using Tor the network is performance and bandwidth 19:28:00 a secondary goal would be to reduce the barriers to being able to jump to another browser if we end up needing to 19:28:00 yes 19:28:06 and that's being worked on 19:28:10 Anyone larger than Mozilla and you're going to run into the same "The tor network can't handle our load"concerns 19:28:31 That depends on the application though 19:28:55 There are some applications for the Tor network that wouldn't require as much bandwidth 19:29:30 i don't tihnk we, as a organization and with the current funding, can handle supporting multiple applications right niow 19:29:33 *now 19:29:48 sysrqb: definitely not :) 19:29:58 and i'm not sure that's such a smart idea for the next two years 19:30:02 but I like the idea of networking and sharing ideas 19:30:07 and making contacts 19:30:16 and slowly "converting" people 19:30:22 yeah :) 19:30:29 while we carry on doing our thing with Tor Browser 19:30:39 i think we're in isolated right now, and we wonly really talk with mozilla people 19:30:51 *we're isolated 19:31:02 *don't really 19:31:11 err, only really 19:31:18 do westill talk with Brave? 19:31:24 and the only brave person is on the network team side, we could be closer to product people too 19:31:36 we do, a little 19:31:49 and i own them a follow up email on something 19:31:55 *owe 19:32:02 sysrqb: uhh that is true 19:32:08 went very down on my list 19:32:17 https://github.com/brave/brave-browser/labels/feature%2Ftor 19:32:42 isabela: yeah 19:32:56 but i think we can work with other browsers more, if we want to have more of an impact 19:33:40 and for sure the priorites are working on the Tor network to improve performance and bandwith to be able to get it integrated in other browsers 19:34:02 this may help us in general, if we ever get involved in the standardization stuff 19:34:16 so, to summarise, we want to keep developing based on ESR, and at the same time keep up relationships with Brave and Cliqz as well as establishing new relationships with other Browser vendors 19:34:36 opera? safari? 19:34:43 pili: that sounds reasonable :) 19:34:49 is a balance of priorities tho 19:34:51 and capacity 19:34:52 :) 19:34:57 pili: the latter has always been on my list but got down on the prio list 19:34:57 for sure 19:35:03 isabela: exactly 19:35:05 and in order for that to be an effective conversation we should make way on the network performance improvements 19:35:06 because we need to do that while doing our thing on our browser 19:35:18 have we considered if there are other, non-browser clients that have a comelling use case for integrated tor? wget or curl or some other commonly scripted tool that would provide users with good anonymity? 19:35:30 An MTA? 19:35:31 the "good news" is that this sort of thing doesn't necessarily need to take up developers time 19:35:58 but yes, everyone's time is limited and there are other priorities 19:36:11 tjr|emailifneeded: yes, but i think this is maybe another discussion, too 19:36:27 i wonder about what is already in the oven 19:36:38 and what would the next batch after that look like 19:36:48 for example, i'm increasingly becoming convinced that applications sharing a single tor client is better than every application bundling their own 19:37:04 but that's not really possible right now (easily) 19:37:14 for instance, onion services proposal, anti censorship proposal, current ux changes we are doing or is in the next in line to do -> after all that what would be next 19:37:17 and i hesitate pushing this idea without a solution 19:37:42 isabela: sandboxing? :D 19:37:57 well, folks mentioned that involved hiring 19:38:36 yup, true 19:38:43 idk i wonder - if our prototype to fix onion names works 19:38:46 will we go for it? 19:39:10 we'll test it out i think 19:39:11 after fixing notificatiosn, do we want to make a list of things to polish? 19:39:19 in the sense hat we ship alpha release with it at least 19:39:37 *releases 19:39:48 new identity review, ephimerous sessions in tba and desktop 19:40:03 anti-censorship work we wrote about incorporating ooni data as a feedback to users if they cant connect to tor 19:40:11 what is "ephimerous sessions"? 19:40:11 dare I say encrypted bookmarks? :) 19:40:12 where do we want to take tor launcher to? 19:40:12 we have alt-onion in OTF, that is part of this/next year work 19:40:16 pili: lol 19:40:34 GeKo: yeah 19:41:07 isabela: is part of what mcs named at the start, review bootstraping, we are doing a bit in TBA, we have an ongoing discussion triggered by Briar 19:41:15 yeah 19:41:27 GeKo, yeah, i can pitch you later haha 19:41:37 there is a next-step after that, how we make bootstrappign trasparent 19:41:41 *transparent 19:41:50 yes 19:41:55 lets organize these steps and where we want to get 19:42:02 without putting the user at risk 19:42:32 oh, and there is all the tracking and fingerprinting resistance work we are currently not doing because due to other stuff 19:42:49 and which we might want to do because that's been the reason for tor browser's existence 19:43:04 just that? :P 19:43:04 hehe 19:43:05 yeah, tjr mentioned some of that earlier 19:43:07 i am kidding 19:43:14 we should list that too 19:43:25 i'd be happy if it were just that, yes :) 19:43:37 hehe 19:43:48 something that could be useful is plan releases based on which features/improvements we are going to release, so we have 8.5 now, 9 later, 9.5 later later and we know what we are going to do on each release, incrementally 19:44:21 that would be very helpful for funding requests 19:44:29 if we could break down what we are calling fingerprint work into tasks or steps or something, same w/ boostrapping stuff 19:44:32 that may be a good discussion during the next in-person meeting(?) 19:44:36 yes we could 19:44:52 roadmapping :) 19:45:01 ;) 19:45:04 * ailanthus lurks supportively :) +1 to not putting all eggs in Mozilla basket. What are their longterm intentions w/ us? 19:45:10 isabela: look at tbb-fingerprinting tickets and start work from the highest prio 19:45:19 that list of steps is what folks on fundraising can use to make sure proposals are align w/ it 19:45:31 or maybe step 0 19:45:38 yeah 19:45:49 finally assess all the new fingerprinting vectors that came with esr53 and esr60 19:45:53 *52 19:46:10 and put them at the proper prio 19:46:35 (and soon esr68) 19:46:42 yes 19:47:02 that's our core stuff we have neglected to do in the past months 19:47:35 I'll throw out a new/crazy idea: user safety work against malicious exit nodes. Block executable downloads over HTTP; do some work on bypassed SSL warnings (maybe some perspectives-style cert consistency checking); even let users block HTTP entirely. 19:47:54 (Detecting when bitcoin addresses are copied on an insecure page) 19:48:17 so my idea after this meeting is to go through all these comments again and attempt to put a number of "projects" together based on all the different discussions we've had 19:48:27 we've got 10 minutes left, is there anything we're forgetting? 19:48:34 I've got to bounce, glhf y'all 19:48:39 o/ 19:48:40 o/ 19:48:40 o/ 19:48:47 o/ 19:49:35 o/ 19:49:52 pili: your idea sounds good 19:50:07 i've debated looking at the ticket about enabling Safe Browsing 19:50:22 yup, then I'll share it with the list again and we can refine if necessary 19:50:36 Actually, the more I think about that last idea the more I like it. I'm going to try and write a proposal (hah) but to get the idea out right away: on the 'bypass a self-sign certificate' warning page, we don't let the user bypass the warning until we confirm over a separate tor circuit that the same self-signed cert is presented. 19:50:36 that's something firefox and Chrome already provide, but we discable because it may not be safe 19:51:33 tjr|emailifneeded: yeah, i like that. mike thought about something like that with multi-path confirmation some years ago, too 19:51:47 i think there may be an existing prop for consensus download (?) 19:51:55 i don't complete remember 19:52:21 pili: thanks :) 19:53:22 what else? ) 19:53:24 :) 19:53:52 i guess 19:54:02 the dev meeting sessions ideas 19:54:05 like longer vision 19:54:17 take notes on those 19:54:22 sure, I can extract those as well 19:54:24 for when we are building our schedule 19:55:36 ok 19:55:51 any other final words? 19:56:20 thanks for organizing it pili o/ 19:56:26 +1 19:56:35 +1 19:56:43 yess, thanks pili 19:56:53 cool, I'll take that as a no more to discuss :) 19:57:01 thanks everyone for your ideas and your feedback 19:57:21 You’re welcome. It is good to spend some time on this stuff. 19:57:40 and with that, I'll end the meeting :) 19:57:43 #endmeeting