16:00:02 <shelikhoo> #startmeeting tor anti-censorship meeting
16:00:02 <shelikhoo> here is our meeting pad: https://pad.riseup.net/p/r.9574e996bb9c0266213d38b91b56c469
16:00:02 <shelikhoo> editable link available on request
16:00:02 <MeetBot> 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 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
16:00:07 <shelikhoo> hi~hi~
16:00:22 <WofWca[m]> 👋
16:02:10 <shelikhoo> dcf1: just a ping on https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40349#note_3081332
16:02:10 <shelikhoo> 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 <cohosh> hi
16:02:38 <shelikhoo> I am happy with whatever choice you make either switch to certbot or let it be as is
16:03:11 <dcf1> shelikhoo: thanks, it is on my list
16:03:19 <shelikhoo> 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 <shelikhoo> yes, thanks!
16:03:56 <dcf1> 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 <dcf1> 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 <dcf1> we have to try to make things nice for our future selves
16:06:05 <shelikhoo> yes... I was thinking it will not run into dependency issues with a bash script
16:06:30 <shelikhoo> instead of the python version that drag in so many things with different version requirements
16:06:45 <shelikhoo> and you are also right that most of these dependencies are managed by debian
16:07:13 <shelikhoo> so it is hard to say which route will take more energy to maintain from my side
16:07:20 <dcf1> 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 <dcf1> 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 <dcf1> I think I do see your point of view though. I will leave a comment on the issue.
16:10:05 <shelikhoo> 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 <shelikhoo> yes, I fully understand your point that debian can manage the update so that we don't have to
16:10:59 <shelikhoo> 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 <shelikhoo> 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 <shelikhoo> yes
16:12:08 <shelikhoo> 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 <shelikhoo> but maybe that's just me
16:12:40 <shelikhoo> let me see if there is any new topic
16:13:27 <dcf1> 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 <dcf1> we are better off is we saty with old, boring technologies as much as possible, avoid anything cutting-edge
16:14:23 <shelikhoo> 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 <cohosh> 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 <shelikhoo> I think we could discuss it here if everyone agrees
16:15:00 <shelikhoo> I didn't see any other new topic
16:16:55 <cohosh> we're missing a few people and my internet connection is spotty
16:17:34 <cohosh> WofWca[m]: if i understand correctly, these changes are part of an effort to use snowflake in a non-Tor context?
16:17:50 <WofWca[m]> That's right
16:18:09 <WofWca[m]> E.g. see this https://github.com/WofWca/snowflake-generalized
16:18:20 <WofWca[m]> And I also opened a few issues a while back
16:18:37 <WofWca[m]> E.g. this
16:18:37 <WofWca[m]> https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40248
16:19:45 <WofWca[m]> One of the main implications is to let proxies connect to arbitrary addresses
16:20:31 <WofWca[m]> Relay addresses I mean
16:20:43 <shelikhoo> 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 <WofWca[m]> Based on what the client wants
16:21:01 <cohosh> WofWca[m]: yeah, that's the what I read from your MRs too
16:21:31 <shelikhoo> Yes. personally I think there are actually 2 set of issues here
16:21:33 <dcf1> WofWca[m]: is there a lower-level driving goal? Let proxies connect to arbitrary relay addresses -- for what purpose?
16:22:07 <WofWca[m]> So that anyone can set up a server and benefit from a Snowflake network
16:22:18 <dcf1> 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 <WofWca[m]> I.e. set up a server that can be accessed through Snowflake if it's blocked
16:22:47 <cohosh> 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 <dcf1> 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 <WofWca[m]> dcf1: Both, I'd say. Ideally I'd want to change the current Snowflake network
16:23:48 <shelikhoo> 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 <WofWca[m]> But I'm fine with a hard-fork initially
16:24:50 <WofWca[m]> cohosh: Yes, I know. But having separate proxy pools for each website / service that needs censorship-resistance is not great IMO
16:25:01 <dcf1> 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 <WofWca[m]> dcf1: Yes, that's the idea.
16:25:41 <WofWca[m]> About plans: i'd start with setting up my own VPN
16:26:35 <cohosh> 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 <WofWca[m]> Yes, that's why a lot of my MRs have to do with hardening
16:28:12 <shelikhoo> 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 <WofWca[m]> Thanks!
16:29:28 <cohosh> i wish you luck on this project
16:29:54 <shelikhoo> although many proxy operators may sign up as being a Tor proxy, rather than a generic proxy
16:30:10 <WofWca[m]> cohosh: Thank you!
16:30:14 <cohosh> 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 <cohosh> so this might be where the two projects diverge
16:30:46 <WofWca[m]> shelikhoo: We could provide them with a setting to choose
16:31:06 <shelikhoo> In https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40156
16:31:09 <cohosh> but i appreciate your attention to improving safety with hardening fixes
16:31:26 <shelikhoo> I purposed a system that allow proxy operators to choose which subpool they are contributing to
16:31:27 <WofWca[m]> cohosh: Even if it's off by default?
16:31:27 <dcf1> 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 <WofWca[m]> shelikhoo: Thanks! I forgot about this issue
16:32:22 <shelikhoo> 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 <WofWca[m]> dcf1: cohosh https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/merge_requests/379
16:32:37 <shelikhoo> and bring a lot of maintenance works as well
16:32:44 <dcf1> 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 <shelikhoo> as it makes project more complex
16:33:10 <WofWca[m]> IN this issue I proposed an ideo of how to implement this such that it's off by default
16:34:07 <dcf1> 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 <WofWca[m]> I see. So, hardening is fine, new features related to this are not?
16:35:36 <WofWca[m]> "softening" XD
16:36:05 <WofWca[m]> Genuine question btw, just want to make sure I got it right
16:36:48 <shelikhoo> 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 <dcf1> 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 <cohosh> WofWca[m]: yes i think that's where we're at, at least for now
16:38:52 <WofWca[m]> Got it. Ok, I'll go do my thing then!
16:39:11 <WofWca[m]> I'll close the MRs
16:39:15 <dcf1> 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 <WofWca[m]> And thank you all for the comments!
16:39:26 <cohosh> 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 <shelikhoo> 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 <WofWca[m]> cohosh: I totally understand.
16:40:13 <dcf1> 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 <dcf1> 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 <WofWca[m]> shelikhoo: Sounds great, I'll check it out!
16:41:02 <shelikhoo> 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 <shelikhoo> since if there is people using that protocol, then there will be someone working on keep it working
16:42:00 <shelikhoo> WofWca[m]:https://github.com/v2fly/v2ray-core
16:42:16 <dcf1> 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 <WofWca[m]> dcf1: I see. Well, I'll keep you all updated by other means anyways XD
16:43:18 <WofWca[m]> Meaning the forum at least
16:43:28 <dcf1> 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 <WofWca[m]> I'm not in direct contact, but yes, I saw a bit of what they're doing.
16:44:40 <dcf1> 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 <shelikhoo> I will also check out Lantern Browsers Unbounded with their latest updates...
16:44:52 <dcf1> A future synthesis of the ideas could be cool.
16:45:05 <cohosh> yeah i am really excited to see where this project goes
16:45:22 <WofWca[m]> I guess I'll need to take a closer look
16:45:41 <dcf1> 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 <shelikhoo> WofWca[m]: If you are interested in implement a webrtc based transport or tunnel service in V2Ray, just let me know
16:46:29 <shelikhoo> we can discuss how it will work
16:46:33 <dcf1> 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 <WofWca[m]> dcf1:  Great!
16:46:58 <WofWca[m]> shelikhoo: Yes, this sounds interesting but I don't get the entire idea yet.
16:47:15 <shelikhoo> yes, we can chat about that if you are interested in it
16:47:24 <dcf1> 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 <shelikhoo> my idea about this was having a option to choose which set of service one is willing to contribute to
16:47:59 <WofWca[m]> dcf1: Woulnd't it be a matter of a toggle in settings?
16:48:03 <shelikhoo> with a list UI
16:48:09 <WofWca[m]> Yeah
16:48:16 <shelikhoo> Tor's one would be selected by default
16:48:41 <shelikhoo> but one are encouraged to have a look at list, and tick the check box of projects they like
16:49:00 <shelikhoo> and then the choice will be respected on broker side
16:49:11 <shelikhoo> only match request to selected project
16:49:11 <dcf1> Yeah that's kind of what I mentally pictured too, a list or checkboxes.
16:49:33 <dcf1> And the broker doing matching based on project preferences similarly to how it now takes NAT type into account.
16:49:35 <shelikhoo> although it would take a lot of effort to get to that part...
16:49:53 <WofWca[m]> dcf1: I mean, without having to make users uninstall the "old" extension
16:50:08 <shelikhoo> with a lots development and maintain all the additional codes
16:50:31 <WofWca[m]> shelikhoo: yeah, that's for sure
16:51:49 <dcf1> 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 <dcf1> That is something I would push hard against, even if it were opt-in with a toggle.
16:52:44 <cohosh> another reason for a new extension would be to decouple it from the tor project account, for branding and update purposes
16:53:35 <dcf1> 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 <WofWca[m]> 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 <WofWca[m]> But I guess we're bikeshedding at this point
16:54:27 <dcf1> One might say that, but I myself would not :)
16:55:06 <dcf1> WofWca[m] and shelikhoo, thank you, by the way, for keeping eyes on the future and keeping the spirit of innovation
16:55:08 <WofWca[m]> dcf1: Yeah, that would be awesome
16:55:26 <cohosh> :)
16:55:35 <shelikhoo> yes, WofWca[m] feel free to chat with me if you wants some suggestions about alternatives
16:55:53 <shelikhoo> and thanks dcf1!
16:56:00 <WofWca[m]> shelikhoo: Thanks a lot, I'll check it out!
16:56:13 <shelikhoo> anything else we would like to discuss in this meeting?
16:56:56 <WofWca[m]> One more thing from me
16:56:57 <WofWca[m]> https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/merge_requests/397
16:57:24 <shelikhoo> I think dcf1 have replied and I can merge it now
16:57:26 <WofWca[m]> 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 <shelikhoo> yes, I will do that!
16:57:56 <WofWca[m]> Alright then!
16:58:03 <cohosh> yeah, thanks so much for that fix, i'll give an update on prometheus metrics after it's deployed
16:58:25 <shelikhoo> I will merge it now, and deploy it maybe next Monday.
16:58:29 <dcf1> 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 <dcf1> So you may have to pick those up from me if you don't want to wait.
16:58:53 <shelikhoo> yes
16:58:56 <WofWca[m]> cohosh: Thanks, looking forward!
16:59:23 <shelikhoo> #endmeeting