16:00:02 #startmeeting tor anti-censorship meeting 16:00:02 here is our meeting pad: https://pad.riseup.net/p/r.9574e996bb9c0266213d38b91b56c469 16:00:02 editable link available on request 16:00:02 Meeting started Thu Sep 26 16:00:02 2024 UTC. The chair is shelikhoo. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:00:02 Useful Commands: #action #agreed #help #info #idea #link #topic. 16:00:07 hi~hi~ 16:00:22 👋 16:02:10 dcf1: just a ping on https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40349#note_3081332 16:02:10 I was trying to get the development part of this task finished, and left only the deployment part before taking new personalities next Wednesdays related to new sponsored project 16:02:11 hi 16:02:38 I am happy with whatever choice you make either switch to certbot or let it be as is 16:03:11 shelikhoo: thanks, it is on my list 16:03:19 I was trying to get the development part of this task finished, and left only the deployment part before taking new responsibilities next Wednesdays related to new sponsored project 16:03:22 yes, thanks! 16:03:56 a general rule of thumb is that we should optimize for low maintenance. anything that is slightly cute or unusual can end up costing us much more in the future 16:04:39 we've done pretty good in the snowflake project with deploying things that don't need constant fiddling to keep running, but you see how the team is currently eaten up with routine maintenance and for that reason is having trouble making progress on new development 16:04:59 we have to try to make things nice for our future selves 16:06:05 yes... I was thinking it will not run into dependency issues with a bash script 16:06:30 instead of the python version that drag in so many things with different version requirements 16:06:45 and you are also right that most of these dependencies are managed by debian 16:07:13 so it is hard to say which route will take more energy to maintain from my side 16:07:20 but to me that's almost the worst case -- now it's effectively another software project that we have to manage, maintain, and document; and when someone has to fix something that goes wrong in the future, it's something they have to learn and look up in our own documentation to understand the custom way we have done it 16:08:16 whereas if it's `apt upgrade`, there's very low probability of that going wrong, less problematic than "ask shelikhoo how this works, it's something custom" 16:08:32 I think I do see your point of view though. I will leave a comment on the issue. 16:10:05 yes, the choice is yours to make... I was not trusting debian... I kind of prefer to do things myself as I know I will be able to do things in the exact why I wish it to be... but we all have limited amount of energy and there is need a compromise... 16:10:39 yes, I fully understand your point that debian can manage the update so that we don't have to 16:10:59 yes, the choice is yours to make... I was not trusting debian... I kind of prefer to do things myself as I know I will be able to do things in the exact way I wish it to be... but we all have limited amount of energy and there is need a compromise... 16:11:10 yes, the choice is yours to make... I was not trusting debian... I kind of prefer to do things myself as I know I will be able to do things in the exact why I wish it to be... but we all have limited amount of energy and there is need for a compromise... 16:11:11 yes 16:12:08 to be fair the debian packaged version of V2Ray is constantly failed to catch up with upstream updates, and I have to push them to patch CVEs.... 16:12:30 but maybe that's just me 16:12:40 let me see if there is any new topic 16:13:27 well, that's another thing about designing for low maintenance, is not to rely on any software that requires us always to have the latest version 16:13:56 we are better off is we saty with old, boring technologies as much as possible, avoid anything cutting-edge 16:14:23 I wasn't able to find the last meeting note in the mailing list archive, so please move your new topic below the Sep 26 new marker if any 16:14:31 i'm wondering if we should discuss some of the open snowflake MRs by wofwca here? or is that discussion best left for gitlab? 16:14:51 I think we could discuss it here if everyone agrees 16:15:00 I didn't see any other new topic 16:16:55 we're missing a few people and my internet connection is spotty 16:17:34 WofWca[m]: if i understand correctly, these changes are part of an effort to use snowflake in a non-Tor context? 16:17:50 That's right 16:18:09 E.g. see this https://github.com/WofWca/snowflake-generalized 16:18:20 And I also opened a few issues a while back 16:18:37 E.g. this 16:18:37 https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40248 16:19:45 One of the main implications is to let proxies connect to arbitrary addresses 16:20:31 Relay addresses I mean 16:20:43 dcf1: yes, that's correct. I think I spent a lot energy to deliver next-morning security fix by working over night and spent weekends writing new features so I do wish people to using it, instead of waiting for years for it to land... but on the other side of screen, it would be best if things keeps working without new energy input is also a very valid wish to have... 16:20:48 Based on what the client wants 16:21:01 WofWca[m]: yeah, that's the what I read from your MRs too 16:21:31 Yes. personally I think there are actually 2 set of issues here 16:21:33 WofWca[m]: is there a lower-level driving goal? Let proxies connect to arbitrary relay addresses -- for what purpose? 16:22:07 So that anyone can set up a server and benefit from a Snowflake network 16:22:18 Is this a snowflake-related side project you are working on? Or do you just think this is the way it should work? 16:22:43 I.e. set up a server that can be accessed through Snowflake if it's blocked 16:22:47 it's worth noting that this isn't required for using snowflake in a non-tor setting as well, that setting could use a similar curation of snowflake server destinations 16:23:14 Is your larger vision that the existing pool of snowflake proxies should be usable by other projects, for example even one-hop proxies and VPNs? What plans have you considered in that direction? 16:23:44 dcf1: Both, I'd say. Ideally I'd want to change the current Snowflake network 16:23:48 first is that whether we should support this in our code base, and whether we deploy a policy allowing these on Tor's existing proxy pool 16:23:52 But I'm fine with a hard-fork initially 16:24:50 cohosh: Yes, I know. But having separate proxy pools for each website / service that needs censorship-resistance is not great IMO 16:25:01 Thanks. That helps. I had the feeling that in talking about the various MRs, we were really talking around some more fundamental design. 16:25:11 dcf1: Yes, that's the idea. 16:25:41 About plans: i'd start with setting up my own VPN 16:26:35 one of the reasons for restricting which server destinations proxies connect to is a safety guarantee for proxy operators, which is something to keep in mind if you go down this route 16:27:05 Yes, that's why a lot of my MRs have to do with hardening 16:28:12 I think I personally like the idea with more webrtc based proxies, and I personally also have a personal project that create a udp tunnel based on pion/webrtc 16:29:04 Thanks! 16:29:28 i wish you luck on this project 16:29:54 although many proxy operators may sign up as being a Tor proxy, rather than a generic proxy 16:30:10 cohosh: Thank you! 16:30:14 i don't think we should merge all of these changes into our code bases,particularly allowing clients to determine arbitrary (or port-restricted) destinations 16:30:42 so this might be where the two projects diverge 16:30:46 shelikhoo: We could provide them with a setting to choose 16:31:06 In https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40156 16:31:09 but i appreciate your attention to improving safety with hardening fixes 16:31:26 I purposed a system that allow proxy operators to choose which subpool they are contributing to 16:31:27 cohosh: Even if it's off by default? 16:31:27 I, too, am sympathetic to the generalized snowflake idea, but I would not be comfortable merging changes into our code to connect to controllable destinations. 16:32:14 shelikhoo: Thanks! I forgot about this issue 16:32:22 although one of the issue here is that such development would require a lot of energy that is more than what your merge request have purposed 16:32:36 dcf1: cohosh https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/merge_requests/379 16:32:37 and bring a lot of maintenance works as well 16:32:44 WofWca[m]: it's not only the extra security and trust risk engendered, it's more code complexity, more maintenance, the removal of assumptions based on which code has already been deployed 16:32:46 as it makes project more complex 16:33:10 IN this issue I proposed an ideo of how to implement this such that it's off by default 16:34:07 there is the opportunity cost: it seems to be going towards a goal that is not in the main mission of the team, and time spent on this is time not doing other tasks. New design constraints can get in the way of doing the business that is actually part of the team's responsibility. 16:34:49 I see. So, hardening is fine, new features related to this are not? 16:35:36 "softening" XD 16:36:05 Genuine question btw, just want to make sure I got it right 16:36:48 WofWca[m]: I think it is more about a lot of additional maintenance and development costs associate with achieving what you are purposing in a way that works for every party involved 16:37:34 WofWca[m]: yes, that is pretty much my view I think, though even some of the "hardening" changes I think are questionably useful. 16:38:06 WofWca[m]: yes i think that's where we're at, at least for now 16:38:52 Got it. Ok, I'll go do my thing then! 16:39:11 I'll close the MRs 16:39:15 I thin I left a comment on tpo/anti-censorship/pluggable-transports/snowflake#40248 also, with some perspective from a software engineering point of view. It's risky to develop new features in a vacuum, in anticipation of future needs, without actually gathering requirements from the ones who are interested. 16:39:19 And thank you all for the comments! 16:39:26 WofWca[m]: thanks for being so involved, i don't want you to feel discouraged from contributing by us not merging all of the MRs, it's really great to have you contributing to these projects :) 16:39:34 if you really wish to make a webrtc based proxy, and are fine with a entirely self-hosted proxy solution(no shared proxy pool like snowflake), I could offer you support in implementing such feature in V2Ray, and prioritize its pull request processing 16:39:59 cohosh: I totally understand. 16:40:13 If we say "here are the new features we've prepared for you, come use them!" we will inevitably have overlooked things that are important to those imagined users. 16:40:50 I know this case is not quite like that, because you yourself *have* been considering a certain use case (which I appreciate), and have been proposing changes according to those requirements. 16:40:54 shelikhoo: Sounds great, I'll check it out! 16:41:02 there is a lots of users of V2Ray that would love such a feature, with a fully modular and community based maintenance model, so there is no need to worry about additional maintenance cost 16:41:20 since if there is people using that protocol, then there will be someone working on keep it working 16:42:00 WofWca[m]:https://github.com/v2fly/v2ray-core 16:42:16 It's just my own software engineering perspective, but I think good design needs to start from a clear understanding of requirements, and in this case what that might look like is a fork that does what you want. 16:43:08 dcf1: I see. Well, I'll keep you all updated by other means anyways XD 16:43:18 Meaning the forum at least 16:43:28 And I wonder if you have been in contact with Lantern Browsers Unbounded? Because I think that generalization to multiple projects was actually a clear part of their vision from the start. 16:44:09 I'm not in direct contact, but yes, I saw a bit of what they're doing. 16:44:40 Lantern's is already a one-hop proxy as I understand it, also they have made some different design decisions that I think are pretty cool. 16:44:45 I will also check out Lantern Browsers Unbounded with their latest updates... 16:44:52 A future synthesis of the ideas could be cool. 16:45:05 yeah i am really excited to see where this project goes 16:45:22 I guess I'll need to take a closer look 16:45:41 I would not have a problem with moving the Snowflake deployment to some kind of multi-project community proxy pool, if it were successful. You are right that it at least feels wasteful for every project to do all the social work of building up a proxy pool. 16:46:16 WofWca[m]: If you are interested in implement a webrtc based transport or tunnel service in V2Ray, just let me know 16:46:29 we can discuss how it will work 16:46:33 My feeling on possible repurposing of the existing Tor-Snowflake proxy pool, is that the only way to do it would be to release a new extension, with a new extension ID, and then do outreach to encourage people to uninstall the old and install the new. 16:46:40 dcf1: Great! 16:46:58 shelikhoo: Yes, this sounds interesting but I don't get the entire idea yet. 16:47:15 yes, we can chat about that if you are interested in it 16:47:24 I don't think there's any other way to get around the consent issue, no matter what we put in the release notes, existing proxy operators would be surprised if they started supporting something other than what they signed on for. 16:47:56 my idea about this was having a option to choose which set of service one is willing to contribute to 16:47:59 dcf1: Woulnd't it be a matter of a toggle in settings? 16:48:03 with a list UI 16:48:09 Yeah 16:48:16 Tor's one would be selected by default 16:48:41 but one are encouraged to have a look at list, and tick the check box of projects they like 16:49:00 and then the choice will be respected on broker side 16:49:11 only match request to selected project 16:49:11 Yeah that's kind of what I mentally pictured too, a list or checkboxes. 16:49:33 And the broker doing matching based on project preferences similarly to how it now takes NAT type into account. 16:49:35 although it would take a lot of effort to get to that part... 16:49:53 dcf1: I mean, without having to make users uninstall the "old" extension 16:50:08 with a lots development and maintain all the additional codes 16:50:31 shelikhoo: yeah, that's for sure 16:51:49 This is just my point of view. Thousands of people installed the web browser extension because they wanted to support Tor. To me, I would feel I had committed an ethical violation if that changed. Asking someone to take the positive action of installing a new extension would be enough, but I would not try to repurpose the existing pool. 16:52:14 That is something I would push hard against, even if it were opt-in with a toggle. 16:52:44 another reason for a new extension would be to decouple it from the tor project account, for branding and update purposes 16:53:35 I am not opposed to a multi-project proxy idea at all (and in fact it is probably the best future outcome if such a thing "wins" and becomes the common standard), I just want to know that proxy operators are fully aware of what they are signing up for. 16:54:04 dcf1: I see. But I mean, you could say that a toggle is not that much different from a link to the new extension. 16:54:18 But I guess we're bikeshedding at this point 16:54:27 One might say that, but I myself would not :) 16:55:06 WofWca[m] and shelikhoo, thank you, by the way, for keeping eyes on the future and keeping the spirit of innovation 16:55:08 dcf1: Yeah, that would be awesome 16:55:26 :) 16:55:35 yes, WofWca[m] feel free to chat with me if you wants some suggestions about alternatives 16:55:53 and thanks dcf1! 16:56:00 shelikhoo: Thanks a lot, I'll check it out! 16:56:13 anything else we would like to discuss in this meeting? 16:56:56 One more thing from me 16:56:57 https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/merge_requests/397 16:57:24 I think dcf1 have replied and I can merge it now 16:57:26 I think it's better to merge and deploy this sooner, as this is likely to be responsible for low "unrestricted" NAT counts 16:57:42 yes, I will do that! 16:57:56 Alright then! 16:58:03 yeah, thanks so much for that fix, i'll give an update on prometheus metrics after it's deployed 16:58:25 I will merge it now, and deploy it maybe next Monday. 16:58:29 One other note from me, I am going to be busy with other things the next 2+ weeks, and I might have to drop some of the things I am in the process of reviewing on the floor. 16:58:46 So you may have to pick those up from me if you don't want to wait. 16:58:53 yes 16:58:56 cohosh: Thanks, looking forward! 16:59:23 #endmeeting