14:59:48 #startmeeting Tor Browser release meeting May 12th 14:59:48 Meeting started Tue May 12 14:59:48 2020 UTC. The chair is gaba. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:59:48 Useful Commands: #action #agreed #help #info #idea #link #topic. 14:59:58 pad for the meeting: https://pad.riseup.net/p/tor-browser-release-meeting-keep 15:00:01 o/ 15:00:14 hello everyone! 15:00:19 please check discussion to see if there is anything to add/edit 15:00:21 hi :) 15:00:35 o/ 15:00:57 * ahf is here, but mostly observing i think 15:02:06 ok, done 15:03:51 ok 15:04:03 firs topic is about timeline 15:04:05 okay. before we entered this new world, we scheduled 9.5 stable as being released this week 15:04:11 :) 15:04:29 :) 15:04:44 (kinda here if im needed) 15:05:15 that timeline was delayed, and tentativively planned 9.5 stable at the beginning of June 15:05:28 it seems that makes sense to delay as we had to stop doing stuff for a few weeks 15:05:46 what is still needed to have it delayed so long? 15:05:50 we can release one, final, 9.5 alpha release for testing next week 15:06:02 GeKodelaying two weeks? 15:06:09 GeKo: 15:06:45 ? 15:06:55 june 2 is three weeks away 15:07:45 because back-to-back tor browser releases is not fun 15:07:50 :) 15:07:59 actually 15:08:03 and if we release a final alpha update next week, then 2 JUne is a reasonable time 15:08:18 right for my solar return 15:08:29 for us ( alsmith and me) is good too giving 20k things we are doing now :) and proposals deadlines 15:08:36 aha, next week. i was under the impression we release the alpha this week, okay 15:09:14 o/ 15:09:25 this is all part of today's conversation, too 15:09:28 cohosh: o/ 15:09:56 we're balancing a lot of priorities 15:09:56 to add another point for the timeline question 15:10:17 we used to release major stable not together with security updates if possible 15:10:29 because we have only a small amount of alpha users 15:10:55 and we have seen in the past issues that were severe but got only caught by the stable release 15:11:06 what is your suggestion GeKo? 15:11:12 so then the idea was to have major releases like a week before the security release 15:11:35 so that we have the option to fix major fallout together with the firefox security update 15:11:52 antonela: i don't have any suggestion yet 15:12:04 it seems we need to pin the next alpha release first :) 15:12:18 let's work backwards from there 15:12:26 ok 15:12:32 curently, we have nearly zero changes ready for the next alpha release 15:12:40 right 15:12:42 and we have a very long wish-list of items on the pad 15:13:16 and we have about 5 days to implement the additional features we want 15:13:19 i dont think the list in the pad is related strictly with development tho 15:13:29 not all, true 15:13:56 but, we currently don't have any onboarding functionality with the new onion services features 15:14:09 maybe that would be a smart thing to have for such a major feature 15:14:15 we should do the about:tor take over 15:14:19 to teach the user 15:14:32 well, onion-location has an explainer 15:14:48 and i also suggest _something_ to move foward with user updates 15:14:52 *forward 15:15:18 but yes, i mean, i think june 2 is a great date for stable and we can have an alpha in between 15:16:52 right. onion-location has some user interaction 15:17:35 but we should have something for onion naming 15:17:54 yes, agreed 15:17:58 i don't know how we should add that, because it is limited to securedrop 15:18:09 and not many tor browser users are going to securedrop instances 15:19:14 i'll create a ticket for that 15:19:19 and we can discuss our options 15:19:29 sounds good 15:19:31 ok 15:19:31 ok, sounds good 15:19:54 for onion-location, we need developer docs 15:20:02 right, is the next item in the agenda 15:20:03 who should write that? 15:20:21 sysrqb: do you mean onion service operator docs? 15:20:26 can i get a pad link (joined late sorry)? 15:20:33 https://pad.riseup.net/p/tor-browser-release-meeting-keep 15:20:35 https://pad.riseup.net/p/tor-browser-release-meeting-keep 15:20:35 if it's for integrating the feature on your website, i can help out there 15:20:49 "We need devs docs and end-users docs:" 15:20:55 i saw somewhere that antonela had already collected some notes on apache and nginx 15:20:58 for web server configs 15:21:04 yes, is in the pad 15:21:18 i think it would makese sense for ggus to be involved somehow 15:21:23 yes 15:21:32 but i'm not sure how we should coordinate 15:21:55 i assume acat or ahf or someone else should work directly with ggus 15:22:01 do we have a ticket for it? 15:22:10 i think so 15:22:19 someone who has experience configuring onion-location on webservers 15:22:22 at least 15:22:23 in trac, i guess 15:22:28 * antonela goes to find the ticket, again 15:22:45 we need: support site update, tor browser user doc update, community portal onion site operator update 15:23:43 ok. ggus, antonela, ahf: let's coordinate after the meeting 15:23:48 WFM. 15:24:25 great, thanks 15:24:28 ok, starting a pad https://pad.riseup.net/p/qsbCucp7rNSsZ7I39in4 15:24:50 regarding DDG using onion-location 15:25:11 i can follow up on the previous emails i have with them, too 15:25:33 they did not think their onion service could support all tor users 15:25:52 and they were adding to their roadmap scaling up their service 15:26:05 matt that could be ideal 15:26:23 i asked them about tor browser using their onion service by default, instead of ddg.com 15:26:31 what im thinking is: if the user first action is searching, they will get prompted by ddg onion just in the first flow 15:26:37 but onion-location is similar, if enough users click the button 15:26:50 yeah 15:26:51 sysrqb: let me try an email w/ them and copy u 15:26:52 i saw hiro had a ticket of getting it enabled on TPO's website too 15:26:55 so we have chances to get the opt-in super early 15:27:08 isabela: sure. i'm concerned they aren't ready yet 15:27:09 ahf: yes, ideally tpo is ready for the realease too 15:27:10 but we can ask 15:27:14 yep 15:28:21 okay. next item. onion-location...in Onion Browser? 15:28:31 antonela: is that happening? 15:28:38 it won't be available on Android 15:28:56 we'll implement that after the Fenix transition 15:29:07 i dont know! is an item carried from last meeting 15:29:45 hrm. okay, i see' 15:29:51 i can talk with guardian if we want it to happen 15:30:14 i would prefer keeping this simple 15:30:23 so if they aren't ready or if it isn't implemented 15:30:30 then we continue 15:30:41 i don't want to worry about coordinating with them 15:30:52 got it 15:31:03 but if they are ready and we can add it in our docs, then let's do it 15:31:30 so, yes, please. if you can ask them about their status, that will help 15:31:32 thanks 15:31:49 oka, will talk with guardian then 15:31:51 i have weekly meetings with them, but right now i think they have a lot of fires burning with their webkit battles 15:32:18 i wonder how much they know about it and where to point if they ask for developers docs 15:32:25 yeah, that was my understanding, but maybe their UI development is separate? idk. 15:32:28 but lets figure it out after chat with them 15:32:32 yeah 15:32:38 is fine, i can take it 15:32:39 they have one iOS person doing all of it 15:32:46 :) oh, good. 15:33:21 okay. antonela: onion-naming UI improvements 15:33:57 yes, so quickly 15:33:58 so. 15:34:09 i linked the suggestion fpf shared with us 15:34:20 yes 15:34:34 i think is gross to show the entire onion address with **bolds** as in our current version 15:34:51 maybe we can use the onion name in the doorhanger? 15:35:13 also, they are suggesting to link to some explainer page, i agree for sure 15:35:28 and maybe the doorhanger is the best place to locate that link, too 15:35:38 nina's version will not look at pretty for a v3 onion address 15:35:44 true 15:35:49 but i like her suggestion, too 15:36:16 i dont think we need to show the onion origin address two times, the circuit display should help on that 15:36:28 +1 15:36:47 i think the long bold address is not nice 15:36:48 but. step 1: show the human meaningful name at the "Site Information for" 15:36:49 i loke anto's suggestion 15:36:51 i agree w/ that 15:36:55 *like 15:37:09 me too 15:37:26 okay, good. acat, can you work on that improvement this week? 15:37:33 i think we need a new ticket for this 15:37:39 but anto or i can create it 15:37:44 i can do it 15:37:45 yes 15:37:49 thanks 15:38:18 sysrqb: sure, it's replacing the Site information url with the friendly one, right? 15:38:23 yes 15:38:23 i'll add both things, the update in the site info and also the link to more info 15:38:25 exactly 15:38:26 we can talk in the ticket 15:38:27 acat: yes! 15:38:46 acat: is doable? 15:38:54 should be :) 15:39:00 ha, awesome 15:39:12 fpf folks will be happy with this iteration as well 15:39:17 si 15:39:22 next 15:39:29 acat, ideally i'd like a patch by thursday 15:39:40 so we can get it into nightlies soon 15:40:10 just so you have an understanding of timing :) 15:40:13 good, no problem 15:40:48 okay, antonela: onion errors? 15:40:57 next item is also mine and i wonder if onion errors strings reached l10n at some point and in a more optimistic way, if that is ready 15:41:40 if is not ready, is fine, we have two weeks for pushing that but we should make sure that we are showing the english version if l10n is not ready 15:42:25 yes 15:42:29 they are localized 15:42:33 \o/ 15:42:38 (or in progress) 15:43:15 okey, if they are in the process we are fine 15:43:16 we can look at the percentage later 15:43:19 ye 15:43:42 ggus added onion auth which i forgot is going to reach stable now! 15:43:54 yes, we need docs for that and i added the tickets in the docs pad ggus 15:44:19 antonela: we have some docs for onion auth ready. cleopatra did it. 15:44:26 awesome, are they live? 15:44:35 live in a PR 15:44:49 cool, can you push them and close the tickets? 15:44:57 i pasted the numbers in the pad 15:45:07 ggus: do they need review? 15:45:17 we can gentile ask asn for review 15:45:41 gentile, kindly 15:45:51 yes, we need to review and see if the explanation makes sense (for the user and the service admin) 15:46:05 great 15:46:08 great. let's coordinate that 15:46:13 thanks ggus 15:46:33 okay, for informing users 15:46:40 i see antonela and isabela have some ideas :) 15:46:49 yes, you are going to open a ticket and we can discuss them there 15:46:51 yes :) 15:46:59 hehehe 15:47:13 oh. right :) 15:47:18 good, moving on... 15:47:41 urlbar formatting, is you? 15:47:44 * gaba reminds that we are 10 min for the hour of meeting 15:48:20 for onion naming, currently when you visit the site, the url bar highlights a part of the string 15:48:41 the suredrop naming scheme changed some over the last couple weeks 15:48:46 i opened #33992 15:48:57 but i think we shoudl delay this change until after 9.5 15:49:06 yes! and they removed the .com 15:49:11 yeah 15:49:17 sysrqb: i think is smart thinking about this after the release 15:49:24 so now the the entire domain name is highlighted 15:49:27 right now it looks good 15:49:28 yes 15:49:37 * antonela for lurkers https://twitter.com/micahflee/status/1259898204750938119/photo/2 15:49:52 before, in theintercept.come.securedrop.tor.onion, 'com.securedrop.tor.onion' was highlighted 15:50:03 sysrqb: are you good moving this for after stable? 15:50:09 now it it theintercept.securedrop.tor.onion, and the entire domain is highlighted 15:50:14 so it doesn't look as weird now 15:50:17 i think it was critical in the previous alpha 15:50:19 yes 15:50:20 yes, agreed 15:50:25 okay, good 15:50:34 new icons. 15:50:46 ggus: ? 15:50:46 i pasted the ticket 15:50:50 what is the question ggus? 15:50:52 ah 15:50:53 #32645 15:51:17 we have docs ready for support portal. we should add that to the blog post 15:51:37 oki, i remember working with cleo on that yes 15:51:44 cool 15:51:47 k 15:51:49 comms? 15:51:58 ggus: send to comms@ the urls for the docs we should mention 15:52:04 yep! 15:52:19 blog post, mailing list announcements, tweets, ... 15:52:24 yep 15:52:29 we will work on all that :) 15:52:31 we can coordinate this 15:52:31 we have this meeting with the otf learning lab this week and i think we can close that project in two weeks; a perfect timing for our release 15:52:33 new swag too 15:52:37 lol 15:52:43 ha 15:52:53 antonela: nice 15:53:10 where should i share the place where comms will be working on all of the above? 15:53:41 maybe internal isa? 15:53:54 where ever works best for you, i think 15:53:58 pad or doc? 15:54:01 is to review blog post mostly 15:54:09 i will have a doc 15:54:09 yes yes a pad or a doc is good 15:54:20 i mean where to share the url for folks to review the post 15:54:32 ah :) 15:54:41 yes that, ping matt or me or anyone else who wants to read and we will review 15:54:49 k 15:54:53 and we can forward to others 15:54:58 yes 15:54:59 k 15:55:08 ok, before moving onto the last few items 15:55:39 does the plan for squeezing these new features/improvements into a final release next week 15:55:45 make sense? 15:56:08 i understand GeKo's concern about releasing 9.5 stable at the same time as Mozilla release 68.9.0esr 15:56:26 it's not a concern so much 15:56:34 just how we used to do in the past 15:56:40 we *could* release 9.5 stable the following week 15:56:44 and 9.5 is less critical here than a 10.0 15:56:45 instead of the end of May 15:56:56 true 15:57:17 so how much programming and reviewing on browser folks side is involved in all of that? 15:57:39 we have the circuit display 15:57:49 and onboarding 15:57:55 or about:tor changes 15:58:08 i think they should only need a few days 15:58:27 for implementation and review 15:58:45 i am worried about the onboarding as this has been a timesink in the past 15:58:54 but if we have a clear plan here, fine with me 15:58:56 i hope. but onboarding/about:tor is still not decided 15:59:02 hrm 15:59:03 yes 15:59:18 which im trying to move outside the browser just to leverage devs work 15:59:29 but lets see 16:00:00 next item? snowflake? 16:00:06 sorry for passing the hour :/ 16:00:14 yeah. 16:00:19 so, cohosh :) 16:00:23 I also have another meeting now 16:00:24 but we'll do the alpha next week, right? 16:00:34 yes, i want these in the alpha 16:00:42 in an lpha, before we release stable 16:00:43 that was not my question :) 16:01:01 yes, in the alpha next week 16:01:12 hey 16:01:13 okay 16:01:28 are we ok to have snowflake in alpha next week? 16:01:33 yeah 16:01:36 (ah, i don't have another meeting now, good) 16:01:36 awesome 16:01:38 i think we should wait on stable 16:01:49 but moving to alpha is a progress cohosh :) 16:01:50 for all platforms? 16:01:59 i'd really like to get #34043 in alpha 16:02:11 nice 16:02:12 idk if we're ready for android to be in alpha yet though 16:02:14 antonela: we already have snowflake in the alpher series 16:02:16 for a while 16:02:19 that seems like it needs more testing? 16:02:21 what do you mean? 16:02:32 GeKo: yes but they have been working on that and they have updates 16:02:39 GeKo: did you want to put the android builds in alpha before we test them ourselves? 16:02:47 my understanding is alpha is very soon 16:02:49 GeKo: also for windows? 16:02:54 yes 16:02:55 and i'm not sure how much testing we need 16:03:00 ggus: ^ 16:03:15 cohosh: i am fine doing the yolo thing here 16:03:27 okay then great 16:03:27 i think the main issue will be getting this reviewed in time 16:03:42 let's prioritize #34043 for review 16:03:54 yes, that should make it next week 16:03:57 and then if we have time android? #34043 is more important 16:04:09 but to save us some sanity i think #30318 is something for 10.0a1 16:04:19 yeah 16:04:24 okay cool 16:05:10 with #34043, is snowflake ready for stable on win/macos/linux? 16:05:25 or do you want more testing in alphas before that? 16:05:54 or do you not know yet 16:06:07 16:02 <+cohosh> i think we should wait on stable 16:06:17 yeah i'm okay with waiting 16:06:18 but maybe that was meant for something else 16:06:34 we can find other ways to ramp up usage 16:06:40 before moving to stable 16:06:40 okay 16:06:42 cohosh: what are the blockers? 16:06:59 the blockers for stable are mostly child tickets of #19001 16:07:14 but also figuring out whether we can handle more clients 16:07:14 GeKo: it was, but #34043 was the qualifier for "waiting" :) i was curious about if that wsa the only blocker 16:07:26 we have tens of clients right now, not hundreds or thousands 16:07:33 :) 16:07:38 yep 16:07:38 okay, sounds good 16:07:42 so if we can ramp this up in alpha still, that would be a better stress test 16:07:52 that sounds like a find decision 16:08:15 we only have some thousands of daily users on alpha 16:08:33 but we can think about how we get more testing 16:08:46 cohosh: we could use social media to make a call for snowflake / alpha testers. 16:09:02 ggus: that would be great 16:09:10 only once #34043 is in though 16:09:19 so maybe after the next alpha? 16:09:20 :) 16:09:24 phw was thinking of a blog post 16:09:29 we can coordinate this 16:09:34 cool, thanks! 16:09:51 yep 16:10:07 i think tor-qa list is better, the problem to open call for alpha testing is that regular users download alphas and then they not switch channels 16:10:20 but yes, we can coordinate that 16:10:29 okay makes sense 16:10:49 cohosh: email comms to coordinate w/ us (gus, me anto) 16:10:56 will do 16:10:58 we can help 16:11:05 \o/ 16:11:13 very exciting 16:11:25 quickly for the remaining two items. 1) we have a weekly S58 meeting on Mondays now. that basically replaced the team meeting 16:11:51 2) we have a draft blog post for Tor's position on DNS-over-HTTPS 16:12:11 after micahflee tweeted about the intercept's new short onion name 16:12:17 +1 to keep regular release meetings 16:12:21 that are in irc open to everybody 16:12:32 +1 too 16:12:37 gaba: yes, we should keep release meetings 16:12:43 for their securedrop instance iheard some questions about why we're re-implementing dns for our thing 16:12:53 gaba: oooh. release meeting 16:12:55 sorry i misread 16:12:59 gaba: what does regular mean? 16:13:11 as regular the releases are GeKo 16:13:15 because i am actually against having like biweekly release meetings 16:13:19 as we used to have 16:13:20 so maybe we can do it monthly 16:13:22 like every two weeks 16:13:28 yes what antonela said 16:13:31 because that is overkill i think 16:13:39 given that we are essentially in maintenance mode 16:13:39 monthly would be fine 16:13:50 yes, every month is good 16:14:01 because we won't have (many) new features going into 9.5 16:14:09 please send an invite to comms when u decide the date for the next one :) 16:14:13 next one in a month then? 16:14:14 and we'll be focusing on fenix/78esr transition 16:14:25 into *10 you mean sysrqb 16:14:40 gaba: yes, let's try that 16:14:41 no 9.5 16:14:44 June 9th 16:15:01 * gaba adding it to the calendar... will send a reminder a few weeks before 16:15:04 and 10 16:15:04 a few days* 16:15:16 ok 16:15:30 anyway. i want to publish the DoH blog post 16:15:49