15:01:58 #startmeeting S27 11/12 15:01:58 Meeting started Tue Nov 12 15:01:58 2019 UTC. The chair is pili. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:01:58 Useful Commands: #action #agreed #help #info #idea #link #topic. 15:02:13 o/ 15:02:15 o/ 15:02:19 hi! 15:02:22 I moved the pad here for now: https://pad.riseup.net/p/s27-meeting-keep 15:02:22 hi everyone 15:02:29 * GeKo is somewhat here 15:02:34 since we'll be decommissioning soon 15:02:47 hello all 15:03:17 decommissioning storm soon I should say 15:03:23 please add your notes 15:03:26 * asn doing 15:03:35 * antonela too 15:03:38 politeness question: if I have a blob of text that may need discussion later, does it get pasted into the channel, or into the pastebin? 15:05:30 dgoulet: i did the onionbalance part 15:05:47 alecmuffett: hmm i think it should probably get pasted into the channel 15:05:47 alecmuffett: best to put it in the pad :) 15:05:50 oh 15:05:53 ah ok please follow pili 15:05:57 depends when you want to discuss it! :D 15:06:17 if we're discussing it as part of a discussion point you can put it in the channel at that point 15:06:26 pili: we'll see how the discussion goes. I am still not sure what's happening. :-) 15:06:29 adding a brief description in the pad under Discussion seems like a good idea 15:06:34 mcs: +1 15:07:12 alecmuffett: so we have this onion services project that we're working on and we have a regular meeting to discuss progress and blockers 15:07:20 every so often we invite external stakeholders 15:07:37 and right now people are adding their updates to the pad: https://pad.riseup.net/p/s27-meeting-keep 15:07:54 sorry, I shouldn't assume everyone knows how these things work :) 15:08:21 we'll give a few more minutes for people to add updates and then we can start the discussion part of the meeting based on what's on the pad 15:08:26 < thank you :-) > 15:10:42 acat: hey thx for the demo! that's cool stuff!! 15:11:01 :) thanks 15:11:02 ok, I think we can start 15:11:51 so we'll start with discussion of Objective 2, Activity 3: Notify users if a current website they are visiting on Tor Browser has an onion service version 15:11:56 #30024 15:12:22 acat has been working on #21952 15:12:28 good stuff acat ! 15:13:00 yep i like his demo a lot! 15:13:03 antonela, acat is there any thing that you need to discuss regarding implementation or do you have any questions to resolve on this? 15:13:06 acat: +9k 15:13:07 is this a true thing or a mockup so to speak? 15:13:28 well, we should run a round of review 15:13:39 it works, it's the same branch i posted in the ticket 15:13:42 im going to be in vacs next week but i'll put it top prior when im back 15:13:44 i have questions 15:13:46 acat: epic 15:14:33 one of them is how we are going to manage the persistency, like will we allow users to opt-in via about:preferences and will we have a list? 15:14:53 (i dont need answers, just to share my first throughs) 15:15:06 persistency of automatic redirects settings, right? 15:15:11 yes 15:15:18 per-site or global? 15:15:22 both? 15:15:25 ack 15:15:47 and the second question is about performance, the demo loads so fast 15:15:58 hehe 15:15:59 can/are we re use the circuit? should we? should not? 15:16:40 potentially... maybe... probably we shouldn't... need to think more... unlikely for this sponsor... 15:16:47 something between the above 15:16:50 (it loads fast because the .onion and not-onion circuits were already created, that was cheating a bit) 15:16:55 :) 15:17:29 anyways, good stuff 15:17:37 yes good stuff 15:17:47 i see this as an experiemnt anyhow 15:17:52 it is 15:18:01 I wonder if we should blank the content area or show some clear indication while the .onion is loading 15:18:12 good point mcs 15:18:17 are we planning to release this on some future Tor Browser, e.g 9.5 15:18:19 to figure out further UX stuff, and behaviors, and also ideas and concepts like what alec has written in the pad 15:18:20 * antonela takes notes 15:18:21 (normal browser loading indicator is kind of subtle) 15:18:33 since we're talking about experimenting... ;) 15:18:38 :) 15:18:48 we can have something also loading at the pill, will think about it 15:19:06 since the user focus is already there 15:19:15 not sure why but i feel like we talked about it before 15:19:30 :) I don't remember but maybe it was before my time 15:19:59 ok, anything else on this? 15:20:03 I assume we will release something in a Tor Browser alpha and then try to get feedback 15:20:18 mcs that is the plan, yes 15:20:22 ok, good 15:20:23 good :) 15:20:24 great 15:20:29 ++acat 15:20:44 so about the persistence of the setting 15:20:57 it's still not decided whether it will be global or per-site, right? 15:21:24 noope 15:21:31 i made a proposal to make global, but i see it working per site as well 15:21:50 *to make it 15:21:53 global seems more safe in terms of info leaks 15:21:59 per-site leaks info about previous visits 15:22:07 on the other hand, per site settings are kind of like browser history so we may want to have both options 15:22:12 what asn said :) 15:22:21 yes, i was also thinking about tracking potential 15:22:30 https://share.riseup.net/#46aPJezMDWU82l-j7yFwqw 15:22:30 so perhaps we should play it safe for the beginning 15:22:33 after all this is an experiment 15:22:37 although we should be careful this only happens on top-level loads and not iframes and so on, but still 15:22:39 * asn checks antonela 15:22:56 interesting antonela 15:23:02 not sure what "Websites already known" means 15:23:09 but this seems like a plausible settings 15:23:09 that is the per-site stuff 15:23:31 yes, lets say you opt-in for a site, that is a site you already know 15:23:43 but yes, we can think about it 15:24:28 ok, one more thing: are we considering having some visual feedback when a redirect to .onion has occurred? 15:24:50 where exactly? 15:24:58 the url gets updated with the onion icon 15:25:16 i think mcs suggestion of blanking in content goes in this direction (if i'm not wrong), but i was thinking of sth more explicit 15:25:26 and also we can have a loading animation at the pill as an option for mcs's point 15:25:45 yep, we can make it more explicit 15:25:52 what does "blanking in content" means? 15:26:05 something more obvious and clear would be better than just blanking 15:27:06 i was thinking something like firefox does with the new tracking protection ui, there's an separate (sometimes animated) icon in the urlbar, left to the lockpad 15:27:17 just a suggestion, there are many options i guess 15:27:42 yep, a gradient effect could work 15:29:03 ok, so i can try to implement the automatic redirects and persistence next (global, for now), and maybe try some visual feedback of the redirect? 15:29:23 ok, this could be a good point to throw in the discussion about #32256 15:29:31 acat: could you work on about:preferences first? 15:29:45 acat: i can work on the visual feedback when im back 15:29:57 * asn is slightly familiar with #32256 15:29:59 (sorry, carry on) 15:30:07 #32256 can wait a bit longer 15:30:24 antonela: sure! makes sense 15:30:33 acat: awesome, great work!! 15:32:14 ok 15:32:19 let's move on to #32256 then? 15:32:34 ack 15:33:04 alecmuffett: I don't know if you want to start or whether others have some other opinions or discussion points based on your notes? 15:34:04 I've added this ticket as an S27-can 15:34:24 not sure if GeKo or mcs or anyone else on the browser team have any views on this 15:34:30 I've posted my thoughts in the pad, and I've been sporadically batting these issues back and forth with GK in one of the trac tickets 15:34:37 so I'm interested to hear opinions 15:35:10 pili: my views are on the ticket :) 15:35:23 although we are still not done 15:35:30 I have not read all of the discussion in #32256 yet so I do not have an opinion right now (sorry!) 15:35:48 i think the important point here is 15:35:51 My goal is to increase adoption by simplifying/enabling use of standard features as-used in common big websites. 15:36:02 (and: standard webclients, too) 15:36:03 that we want to have a way to signal the server we support onions 15:36:15 without them needing some hacks to figure that out 15:36:38 like looking at relay list 15:36:39 s 15:37:08 right 15:37:11 For those who have not read the ticket, my solution to GeKo's need would be to add "... Tor/1" to the User Agent, or similar string 15:37:25 i've mainly read the first post by alec, but not the subsequent discussion 15:37:28 i found it reasonable 15:37:46 but i also felt it shakes The Foundations. but perhaps that's a good thing. 15:38:08 where by foundations, i mean "tor browser should not make it easy for websites to learn that it's tor browser" 15:38:16 but i definitely get alec's argument against The Foundations. 15:38:34 so yeah i'm kinda neutral here, and I could get persuaded that alec's way is the right way. 15:38:40 there are already some sites that automatically re-direct you to the onion site if they "somehow know" you have "onion capabilities" 15:39:03 we had a brief discussion about this some days ago on some channel ( I forget the site and which channel unfortunately...) 15:39:17 my argument: "we're already past the point where we can assume ignorance on the part of people who want to BLOCK tor clients, without adding commensurate ease for people to BE NICE TO tor clients." 15:40:13 based on the behaviour for that website I'm assuming it's not actually that hard to already be nice to onion-capable clients by offering them the .onion site if available 15:40:18 pili: Yes; that's in the ticket too. PrivacyInternational have one such. It;s a horrible hack, and if replicated would kill websites that want to scrape the consensus. 15:40:30 ah, yes, that's the one 15:40:34 I would know, because I once did much the same at Facebook. 15:40:41 :) 15:40:44 15:40:57 i feel like the main argument against #32256 is "How many more websites will block Tor if we change the UA?" 15:41:13 one thing i realized during the discussion is that we want to retain the option of users opting out 15:41:28 oh an option! 15:41:29 that is they might decide to not have this site loaded over onion 15:41:38 expecting all the world's onion-friendly websites to poll a directory of IP addresses of exit nodes (which: is incomplete and flaky) is suboptimal for adoption. 15:41:50 GeKo: maybe. 15:42:02 Have you tried opting-out of HTTPS recently? 15:42:20 well 15:42:35 we move forward with the onion-location work in #21952 15:42:52 which includes options for users 15:42:57 mostly (hoping) for opt-in s 15:43:05 it would be weird if #32256 would ignore that decision 15:43:32 GeKo: the "Onion-Location" idea is lovely, but I don't know any site that would adopt it 15:44:58 fwiw, i doubt we can take this decision in this meeting 15:45:01 so how should we proceed? 15:45:04 (someone had to say this) 15:45:04 so what I'm getting from this discussion is that if we were to consider sending a user agent to allow websites to identify tor browser we would have to allow users to consent to be re-directed to the onion site 15:45:08 asn: thanks :) 15:45:23 and yes, it doesn't seen like we will make a decision 15:45:37 asn: what decision? 15:45:48 do #32256 or not 15:46:00 you mean as part of s27? 15:46:14 in general i guess (?) 15:46:18 You might get *some* adoption of "Onion-Location" if it's easy to detect/offer Tor-capable clients, but frankly whomever is tasked with onionification of their site, wants to see their metrics for usage go *up* and will therefore issue a straightforward "Location" header 15:46:19 or in general? 15:46:19 or as part of s27 15:46:28 not sure.... it's the s27 meeting after all... 15:46:29 Because that will make their boss happy. 15:47:00 alecmuffett: yeah, and we produce a browser trying to make the user happy 15:47:05 I think it could be interesting to figure out a) if it makes sense to prototype this as part of S27 and how much effort that would be b) the reasons why we wouldn't want to do #32256 c) how to ensure users can opt-in 15:47:22 i feel #32256 is out of scope s27 15:47:43 altho is a good topic to discuss for the future of onions 15:47:47 GeKo: I understand that, and it's a primary tension between Tor-as-exit-nodes versus Tor-as-onion-networking 15:48:37 ok, I think we can wrap this up for now and continue on the ticket 15:48:40 ack 15:48:43 alecmuffett: i think we can get both groups happy fwiw 15:48:54 i also wanted to ask how mcs found our client auth branch wrt client auth 15:48:55 but we should be careful not throwing either under the bus 15:48:57 is it good enough for now mcs? 15:49:02 I want to have at least 10 minutes for the last point 15:49:07 ah sorry 15:49:08 there is a last point? 15:49:12 asn: it's fine, go ahead 15:49:14 which one is it? 15:49:17 about O2A5 and HTTPSE 15:49:19 oh yes 15:49:38 GeKo: That's cool; the question then becomes "does being redirected to a Tor-specific Onion Site generally make you Happy or Unhappy as a Tor user?" 15:49:39 although it's more about who will work on it from browser side, so maybe we can take that to the browser meeting later on today 15:49:50 Given that video works faster, I lean towards Happy. 15:50:04 asn: it seems to be good enough. we are not yet using all of the new capabilities, e.g., the control port commands for listing and removing keys but I assume they work :) 15:50:11 mcs: ack! 15:50:18 pili: ok on to the last point 15:50:32 asn: getting that merged into tor soon would be cool! 15:50:47 dgoulet: are we waiting for something there before merging? 15:50:50 or just testing from TB team? 15:51:27 for adding/removing client auth, waiting on nothing 15:51:42 asn: although it is in needs_revision, not sure why 15:51:51 mcs: ok we will look into it 15:51:55 hm 15:52:33 GeKo: do we have any idea about who can work on HTTPSE yet? or should we take that to the team meeting? 15:52:54 when would that work start? 15:53:17 last I double checked it was scheduled for this month (november) 15:53:28 but maybe we need to move to next month (december) 15:53:34 because we have right now 2 or 3 people working on s27 stuff 15:53:50 and adding that one would mean yet another one 15:54:18 i really like to get some info back from the eff folks as well if possible 15:54:21 yeah 15:54:27 ok, let's move to december then 15:54:30 i wonder whether we should ping them harder 15:54:48 that's what i would suggest, yes 15:55:03 yup, probably 15:55:04 maybe try other channels also 15:55:05 all right, any other last minute items for the last 5 minutes? 15:55:48 should we develop a plan b if eff folks don't reply? 15:56:11 let's also include bill on our bump email to eff 15:56:26 antonela: yes, I think we might have to 15:56:43 is not bill there? 15:56:53 not on the thread im looking at 15:56:57 To: alexis@eff.org, andres , Jeremy Gillula 15:57:20 yeah, we should add him in the second ping 15:57:23 is bill still involved with httpse though? I wasn't sure that's why I didn't include him 15:57:23 oki, i could add bill 15:57:28 i'm also not sure exactly what is to be discussed with EFF 15:57:46 check if they are going to maintain httpse, lists? 15:57:47 well, the maintenance 15:57:48 pili: Just an appeal: I understand that the goal of Tor is primarily (?) to protect the user; but the site administrators who are attempting to build user experiences over Onion are not the enemy of Tor users. 15:57:50 well, whether there is anyone from EFF we need to work with on this 15:57:57 and they miigh help with parts 15:58:04 yeah 15:58:07 *might 15:58:14 right 15:58:16 alecmuffett: got it :) 15:58:22 fwiw, we greatly restricted the scope of O2A5 in stockholm 15:58:28 to the point that i feel like the mods are not gonna be so big 15:58:51 yeah 15:59:04 i am not worried if the eff is not doing anything here 15:59:05 it's still worth talking to them 15:59:16 exactly 15:59:17 ok, so we start this work in december 15:59:22 ideally with their knowledge 15:59:27 yep 15:59:27 ok 15:59:30 who wants to write the bump email 15:59:30 ? 15:59:47 I can do it and I also don't mind if someone else wants to give it a try ;) 15:59:52 pili seems to be a good choice 16:00:05 ack 16:00:35 ok, will do that 16:00:58 ok great 16:01:02 let's leave things there then 16:01:03 ending the meeting... 16:01:04 awesome 16:01:05 #endmeeting