15:58:06 #startmeeting tor anti-censorship meeting 15:58:06 Meeting started Thu Aug 3 15:58:06 2023 UTC. The chair is onyinyang[m]. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:58:06 Useful Commands: #action #agreed #help #info #idea #link #topic. 15:58:49 hello everyone! 15:58:51 here is our meeting pad: https://pad.riseup.net/p/tor-anti-censorship-keep 15:58:55 hello 15:59:16 hello o/ 16:03:16 ok let's start 16:03:36 Does anyone want to address any points from the discussion from last week? 16:04:08 shell is not around today, I guess he didn't have the time to reproduce it before going AFK 16:04:08 if not, let's move on to the discussion items for this week 16:04:29 neither I heard back from guardian project, I'll bring this topic in our next in voice meeting 16:04:35 EOF 16:04:55 Ok, so let's continue these discussions at a later time and move on to this week. 16:05:08 The first item is on the ptspec status version support 16:05:44 ptspec status version support... (full message at ) 16:05:55 since a year (or more??) we've being working on a change on the ptspec to report the PT version 16:06:07 so we know what version and implementation is using each bridge 16:06:22 c-tor is planning to include support for that in the next release 0.4.8 16:06:36 https://gitlab.torproject.org/tpo/core/tor/-/merge_requests/731 16:06:50 I have implemented it in goptlib: 16:07:23 https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/goptlib/-/merge_requests/1 16:07:56 AFAIK the change is backward compatible both ways, so it should be fine to implement it in our PTs even if they are run with a version of tor that doesn't support 16:08:13 I iwll review that MR. Core team just wanted a quick implementation to test their side against though, goptlib is not blocking them? 16:08:43 no, is not blocking them, I did some basic testing and saw the version and implemenation appearing in the bridge descriptor 16:09:13 I don't think we need to hurry on this, but will be nice to move it so we get it working at some point :) 16:09:14 I'm looking at https://gitlab.torproject.org/tpo/core/tor/-/merge_requests/731, one thing I am wondering is what happens if there are two different server pts configured 16:09:39 if there is something to disambiguoate their transport-version and transport-implementation 16:09:54 yes, I wrote about that, AFAIK the likes will come together one after the other, so is possible to guess wich goes with which, but not so nice 16:10:01 I'll leave some comments on tpo/core/tor!731 16:10:07 thanks 16:10:19 meskio: aha, I see your comment 16:10:22 we could change the proposal to don't support spaces on the implemenation or version to fix that 16:10:31 I don't see a clear need for them 16:10:34 imo prohibiting spaces is worse 16:11:06 I don't have a strong opinion here 16:11:12 I wish tor would stop invienting data formats that are so cumbersome to parse and process 16:11:53 +1 16:12:03 but we live in a legacy world... 16:13:16 Anymore on this topic or should we move on to the next one? 16:13:32 not from me 16:14:03 ok, let's move on to the next discussion item. 16:14:14 Webtunnel soft release and next phase: https://gitlab.torproject.org/tpo/community/team/-/issues/94 16:14:47 ggus ?? 16:14:48 so, we are at the end of july and almost all the items for phase #1 are done 16:14:57 nice :) 16:15:31 the feedback that we collected so far from operators is about: improving the docs for compiling from the source 16:15:48 and some ppl asked apache instructions and not just nginx 16:16:01 we can work on this during phase #2 16:16:29 from users: 1. some ppl in china reported that didn't work. in russia it worked without prblem 16:16:32 problem 16:16:37 we still need to test in iran 16:16:54 (in tm didn't work, but probably because of the ip blockage rule) 16:17:21 any question about this first phase? if not, we can move to discuss the next steps 16:17:45 I wonder why it didn't work in china, but we can move along and investigate that in the future 16:18:15 meskio: here are the logs - https://gitlab.torproject.org/tpo/community/support/-/issues/40119#note_2923287 16:19:15 thanks, I'll try to dump some of that into webtunnel issues 16:19:17 and this comment in net4ppl: https://github.com/net4people/bbs/issues/263#issuecomment-1621447664 16:19:36 ops, this one: https://github.com/net4people/bbs/issues/263#issuecomment-1613856517 16:20:18 +1 16:20:34 for phase 2, i'm planning to work on moving the readme instructions to the community portal next week 16:20:49 sounds good 16:20:57 let me know if you need any help to improve or review them 16:21:12 shell will be AFK most of next week, but I can help there if needed 16:21:37 ok! 16:21:58 i'll include a new section here: https://community.torproject.org/relay/setup/ 16:22:28 should we rename 'bridge' to 'obfs4 bridge' or something? 16:22:31 and probably rename "bridge" to "obfs4 bridge" 16:22:32 yes 16:22:34 hehe 16:22:39 :D 16:23:43 Anything more on this topic? 16:23:43 and TB 13 will be release in septmber, are we going to include webtunnel in stable? 16:23:53 there was an issue from jacobo to pay attention when fixing the doc: 16:24:00 https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/webtunnel/-/issues/20 16:24:29 yes, i saw that 16:24:41 nvjacobo: * 16:24:51 I think is a good idea to include webtunnel and conjure in the next TB 16:25:02 +1 16:25:05 we should poke the applications team about that 16:25:15 I mean include support, no UX to enable them 16:25:28 (besides pasting a bridgeline) 16:26:07 for conjure the idea is still not to have it as a default bridge, right? 16:26:20 right 16:26:25 +1 16:27:56 the plan looks good 16:28:05 this is all for me on this topic 16:28:37 ok cool, let's move on to the final point? 16:28:49 HTTP connect pts 16:29:02 I added that point 16:29:22 meskio: we should discuss next week in s96 or here when we will do the public call as we'll both be busy/traveling to ccc 16:29:40 ggus: let's do it in the s96 meeting 16:29:58 ok! 16:30:13 on HTTP connect PTs, nickm was proposing in the past that socks5 is not a great protocol to do PTs and it will be better to use HTTP connect 16:30:40 HTTP connect has things like headers, were we can pass arguments fixing our bridge line length and maybe be able to do many other things 16:31:17 in the in person meeting we did discuss this a bit, and saw it as a nice change 16:31:38 we might want to move that forward to happen sometime in arti 16:31:41 Maybe not just HTTP CONNECT but also MASQUE more generally? Hopefully could open the door to datagram-based protocols (MASQUE has projects for UDP proxying, for example) 16:32:17 I don't know anything about MASQUE, but that sounds good 16:32:21 * ggus needs to leave. o/ 16:32:36 thanks for coming ggus ! 16:32:44 bye ggus 16:33:05 dcf1: I wanted to hear your opinion on this, but it sounds like you like the idea 16:33:21 I am a little bit familiar with MASQUE but not enough to have anything useful to say for now 16:33:29 SOCKS is annoying too, there are like no good standard *server* implementations of SOCKS in commonly used packages, which is necessary for implementing client PTs, and is why goptlib includes a SOCKS server. 16:33:49 meskio: do you havea ticket for this? 16:34:07 Much better HTTP server support in common programming language libraries. 16:34:13 gaba: no, that will be the next step, is being mentioned in a ticket about the bridge line size 16:35:32 Even Proteus (new PT presented at FOCI 2023) had to implement its own SOCKS server: https://github.com/unblockable/proteus/tree/99751539b78782d4477411786e4df03b68213e5d/src/net/proto/socks 16:35:46 :( 16:35:52 (Proteus implemented in Rust, not using goptlib.) 16:36:17 we might see more rust PTs in the future, having something that is easier for more languages will be nice 16:37:47 being realistic, this change will take time and I don't expect c-tor ever to support it, but we could work on getting a spec and include it in arti 16:38:23 I'll create an issue to discuss that and poke the arti people to see if they are interested in helping (or leading) writting the spec 16:39:56 anything else on this topic? 16:40:40 not from my side, I just wanted to start the conversation 16:41:53 ok, that brings us to the end of the discussion points. Is there anything else anyone else wanted to bring up? 16:42:59 not from me 16:43:21 ok then, let's end the meeting! 16:43:24 #endmeeting