15:57:59 #startmeeting tor anti-censorship meeting 15:57:59 Meeting started Thu Oct 5 15:57:59 2023 UTC. The chair is meskio. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:57:59 Useful Commands: #action #agreed #help #info #idea #link #topic. 15:58:04 hello everyone!!! 15:58:12 hi 15:58:15 here is our meeting pad: https://pad.riseup.net/p/tor-anti-censorship-keep 15:58:18 feel free to add what you've been working on and put items on the agenda 15:58:19 hihi 15:58:40 hi~hi~ 15:58:50 o/ 15:58:51 I'll give it few minutes so people can fill up what they've been working on 15:59:11 hi 16:00:15 hello o/ 16:02:43 if I understand correctly the first two discussion points are the same, as in what domain front we use in snowflake 16:02:53 cohosh: do you want to introduce it? 16:03:26 sure, n8fr8 mentioned reports that foursquare.com is not working in iran and some ooni measurements back that up 16:04:03 it's probably a good idea to switch to something else or at least have some variety in the domains we choose 16:04:51 however, the other domain that we think will work, github.githubassets.com we just asked ooni about 16:05:05 and they said it was throttled by IP in Iran a year and a half ago 16:05:59 now that snowflake will have suppor for multiple domains it might be good idea to keep those two anyway, but we need to find a better one for moat and legacy-snowflake 16:06:05 i guess throttling might not impact us that much since it's a pretty small channel we need anyway 16:06:22 cohosh: meskio: the domain that you're investigating is only for the circumvention api or ? 16:06:43 ggus: we need fronts for both the api and for snowflake 16:06:45 is both for circumvention settings/moat and snowflake 16:06:56 for example, orbot doesn't really use our api 16:06:59 we've being using the same domain, maybe we should use two different ones 16:07:03 so they need something to work 16:07:21 cohosh: i thought orbot 'smart connect' was using circumvention api 16:07:30 not for snowflake domains 16:07:38 ahh, okay 16:07:48 ggus: I think so, but I don't think is used by default, I'm confused by their UX 16:07:57 https://github.com/guardianproject/orbot/issues/983 16:08:13 *not for snowflake bridges 16:08:50 the tl;dr is that right now if the api returns a snowflake bridge they use their builtin snowflake bridge lines 16:09:57 seeing that our main snowflake use is in iran, maybe we can test our full list from our vantage point, and trim down the ones that work 16:10:19 so, we need new domains in azure and/or fastly that works in china/iran/russia/+othe regions? 16:10:33 ggus: fastly, yes 16:10:59 i don't think foursquare.com is blocked in all ASes: https://explorer.ooni.org/chart/mat?test_name=web_connectivity&axis_x=measurement_start_day&since=2023-09-04&until=2023-10-04&time_grain=day&probe_cc=IR&axis_y=probe_asn&domain=foursquare.com 16:11:05 in iran 16:11:33 mmmm 16:12:13 we could also check what others are using, like great fire, do they use fastly? if so what domain? 16:12:20 cohosh: fwiw, cdn.sstatic was also blocked temporarily in Iran, so i wonder if foursquare was a temp issue too... 16:12:37 yeah that's possible 16:12:58 so maybe the idea of using githubassets and foursquare is good for now 16:13:08 (for snowflake, moat we need to just pick one) 16:13:25 At least for snowflake we are think about remembering last working fronting domain, which will enable us to ship a bunch of fronting domains 16:13:49 so that we don't need to worry too much about the quality of domain put into that list 16:14:02 so long as one of them work, it will work 16:14:03 pypi.org (python packet manager) is probably works in most place, though they don't seem to like the idea of domain fronting https://github.com/pypi/warehouse/issues/10399 16:14:20 now that we'll have multiple domain names, would be nice to know how many people uses each from our broker... 16:14:33 and from wich country, so we can see when something stops working 16:14:42 without usability issue like trying different fronting domain until one works 16:14:58 we did just talk to ooni about adding more of these potential front domains to their test lists 16:16:12 anyway, i think the short term question is what if anything to do about moat 16:16:35 since we have some pending snowflake features that shelikhoo mentioned 16:16:49 we can switch to githubassets for the next release 16:16:58 or stick with foursquare and hope the problem goes away 16:17:05 and meanwhile work on multi-front features 16:17:39 if githubassets is just throttled and not blocked I think is a good idea to switch 16:17:48 okay, sounds good 16:18:03 maybe we should look into it a bit 16:18:24 sure, that can happen after the meeting 16:18:33 we have some potential azure fronts to consider as well i think 16:19:02 we can make the switch in TB alpha and ask some people in Iran to test 16:20:04 yeah that's a good idea 16:20:45 I see we have decided to move to githubassets and check how it goes, who wants to do the changes in TB? 16:20:48 or we can just give some bridge lines for people to test 16:21:02 ggus: yep, we can also do that 16:21:12 is that easier for the community team? 16:21:25 I can produce a line for you 16:22:26 meskio: we didn't have any report from iran... but in iran, people are mostly using Orbot and not tor browser 16:22:39 ohh, true 16:23:07 I'll make the line and pass it to you to test and see what we hear about 16:23:14 sounds good! 16:23:16 anything else on this topic? 16:23:31 oh that last thing is, it looks like cdn.sstatic.net no longer resolves to fastly domains for any of the recent ooni tests 16:23:40 so they must have just switched to cloudflare fully 16:23:59 The supposition that people in Iran mostly use Orbot is derived from the unequal usage of snowflake-01 and snowflake-02 bridges. But the recent strange dynamics of the two bridges have me questioning whether that was a valid inference to draw in the first place. 16:24:11 ggus: unless you have other sources of information saying that Orbot is more used. 16:26:19 I've being hearing from people mentioning they use orbot in Iran and not TB, but I don't have any stadistics on it 16:26:49 lets move to the next topic 16:26:56 future of PTs 16:27:08 I've being talking with ahf on our ideas of HTTP based PT protocols 16:27:22 dcf1: idk how reliable is this source, but scroll down to Top Rankings: https://www.appbrain.com/app/orbot-tor-for-android/org.torproject.android 16:27:26 https://www.appbrain.com/app/tor-browser/org.torproject.torbrowser 16:27:41 I personally don't think we should go with QUIC based transport 16:27:44 I think the discussion about MASQUE (re QUIC and TLS) in the issue is a little off the mark. 16:27:45 and he was rising the question if we still need a network based PT protocol 16:27:52 Don't think "MASQUE" = "QUIC" 16:27:57 o/ 16:27:58 Think "MASQUE" = "HTTP" 16:28:08 as in if we want just to use a plugin/library based system only 16:28:13 The "Q" in MASQUE originally stands for QUIC, yes, but that is somewhat an anachronism 16:28:36 MASQUE is just about specifying extensions and new ways to do proxying over HTTP 16:28:36 QUIC is designed to solve the issue of traffic over US/EU internet 16:28:37 yeah, i think there is a lot of things that have changed since we did anything towards the PT "ecosystem" itself. i think under sponsor 8 we changed some things and that was an extremely wasteful project in terms of how much we got out of compared to the amount of time we spend on it 16:28:50 In that sense you can consider good old HTTP CONNECT to fall under the same umbrella 16:29:02 because a significant amount of time was spend trying to ask external folks about their new spec systems for PT 2.x and whatever - so in my mind spending time on that isn't particularly useful 16:29:20 and TCP based HTTP1.1 should work equally well without dealing with the complexity of QUIC 16:29:37 today in tor, we have a big change since we did sponsor 8 in 2018 which is that we now have a lot of nice mobile folks wanting to integrate tor into their apps and they do it both because they want the anonymity features, but also they want the anti-censorship features 16:29:47 I think nickm is right: "HTTP CONNECT and MASQUE are not 100% orthogonal". The point is that if, in the future, you want to specify something like datagram proxying for PTs, and you're already using HTTP CONNECT for PTs, you don't have to invent something new: CONNECT-UDP and CONNECT-IP are already there from MASQUE. 16:30:01 right now when someone wants to add "tor features" to their apps, they need to first integrate tor, which is a big task, then after they need to integrate the PT ecosystem 16:30:21 this is also reflected in how "we" do releases: we all deliver our products to the TB team (inside tor) for them to put all our components together and release it 16:30:41 So I think it does not justify the cost of introducing a huge library for us to implement a PT spec, that is mostly just localhost traffic 16:30:58 this have lead to folks like GP, providing some really nice engineering work into building systems such as iptproxy, which solves a ton of issues that are platform specific (such as iOS not doing processes at all and only allows us to do threads) 16:31:32 and eta recently did something similar to iptproxy for onionmasq (our experimental vpn implementation that will be the first tor app to deliver udp from client and from exit to the users) 16:31:36 dcf1: yes, it is considered HTTP3, yet, it is still something we couldn't just write by hand ourselves 16:31:44 * eta was mentioned :o 16:32:02 this leads me to think: wouldn't it be smarter to think of next generations of PT's as an API/ABI/rust trait/golang interface/whatever 16:32:17 https://gitlab.torproject.org/tpo/core/onionmasq/-/tree/main/crates/onionmasq-pt-wrapper?ref_type=heads this thing 16:32:26 if we do things as plug-ins we can start releasing PT's together with the arti release process 16:32:27 ahf: the PT working group came to that conclusion years ago, I think. 16:32:40 I think we should go for simpler interface when it does what we wants to do 16:32:41 and this build integration and such would become easier for folks wanting to embed our products 16:33:11 since they would need to integrate arti and pick the anti-censorship plug-ins they want, initialize them with potentially interactive components (if something needs to prompt the user for something? an url? whatever here) 16:33:45 ahf: yes, we could have language depend PT interfaceS, however, it won't allow cross language calling 16:33:49 dcf1: did they do anything about it? last time i looked there was an ABI defined from operator foundation that looked extremely like it was designed by someone who had no users that wanted to use it 16:34:15 I totally agree that we should integrate PTs in arti and make them as libraries that are compiled together with it 16:34:21 shelikhoo: cross language calls isn't the biggest issue if we have plug-ins since we can provide an executor binary for people who wants socks4/socks5/masque/http connect/whatever 16:34:43 and language like Go have a runtime that isn't nice when you load 2 C exported Go library in the same process 16:34:46 I think the picture is that the "IPC" interface that Tor uses is DOA for any use case but Tor: it's basically just a bespoke custom internal protocol, because it turns out not to work for most other people's use cases, as you have said 16:35:16 I guess my question is if it makes sense to also have a PT protocol to have PTs as different processes or that is a waste of time 16:35:19 shelikhoo: but that is also a solved issue today with what iptproxy have done with merging them all into one library :-) 16:35:51 i am trying very hard not to say "let's do it all in rust" because i know a lot of components that are useful for PT's are not in rust today, but of course in the end for arti, these things would be linked statically through a rust interface 16:36:03 So the intention behind the "API" interface was to answer the needs of non-Tor developers. How successful it is at that, I don't know. I don't know whether any other groups use it or not. Even as we use it in Snowflake to facilitate use by iPtProxy, it's not quite as specified, I believe. 16:36:06 (and static linking is important here - having DSO's is not enough) 16:36:36 ahf: yes, but the final use case is iOS, in which case one does need load more than one PT and in different language, and there are more than go PT 16:36:37 But there is certainly more demand out there for an API interface than what Tor does now. 16:36:38 dcf1: that is the big question i don't know the answer to: does anybody other than tor use these things so how important is the stability of the interfaces here? 16:36:51 * trinity-1686a mumble something about defining a wasm ABI 16:37:06 shelikhoo: but they solved that by wrapping all the go pt's in one "meta" pt 16:37:11 in iptlibrary's case, the pt is no longer pluggable, as custom logic is needed for each pt 16:37:18 it's not like we see another PT arrive every week anymore :-) 16:37:46 ahf: yes, it would work by having a go pt aggregator 16:37:48 right, i think the pluggable component of it is an illusion in that each one of them may have initialization settings that potentially even needs user interaction (in addition to static configuration) 16:37:55 shelikhoo: that exists today 16:38:03 Well, that's the question: are pluggable transports meant to be pluggable across different projects (which was the original vision, I believe, but which pt-spec failed to achieve), or are they meant only to be pluggable within the Tor ecosystem (which is de facto the situation now) 16:38:30 trinity-1686a: yes! I like that idea but maybe not everyone... 16:38:51 LEAP for one has tried to use our PTs without Tor 16:38:56 dcf1: tor's goal's with arti is that more applications should be able to embed tor into their products 16:39:05 and with that, they want our anti-censorship story too 16:39:30 I don't think we need here to solve how a pluging/library interface will look like, and it looks like something like that will exist whatever we wanted or not (iptproxy for example) 16:39:31 I think both of those possibilities ar reasonable goals, btw. PT 1.0 already doesn't work as a cross-project interface, so nothing is lost by giving that up imo. 16:39:34 today embedding tor is a nightmare - only GP have been succesful with that, and it's a pain for them to do 16:39:46 dcf1: right 16:39:54 I myself would not be sad to see the IPC TOR_PT_MANAGED_TRANSPORT_VERSION etc. go away. 16:40:16 oh boy, me too 16:40:24 dcf1: in the end, Tor, Shadowsocks all have different PT protocol, and different developer just target different standard 16:40:42 And as meskio says, it would obviate the need to specify something like an HTTP proxy for things like the args length issue. 16:41:00 but, one thing i like about the plug-in idea is that we potentially can continue to provide socks5/masque/whatever interface to people who needs that (like cohosh just mentioned, LEAP), but also i remember some of the old PT examples included how one could wrap your ssh port for client/server in obfs4 16:41:14 that could still be possible with plug-ins if we just have some executor that provides the client/server side of the plug-ins 16:41:34 (LEAP does use the operator foundation libraries, not pt-spec) 16:42:00 Yes, that's basically what one of operator foundation's prducts does (shapeshifter?). It links with a PT using the API and wraps it in the IPC interface. 16:42:15 right 16:42:42 I think it wouldn't be hard for us to target a in process language dependent PT spec 16:42:48 https://github.com/OperatorFoundation/shapeshifter-dispatcher "Shapeshifter Dispatcher converts Pluggable Transports that implement the Go API from the Pluggable Transports 2.1 specification into proxies usable by applications." 16:43:08 trinity-1686a: isn't ios and wasm a bad idea - we cannot bundle a JIT there and would have to potentially have a network extension link against webkit? 16:43:13 and let the pt-library target different SOCKS or HTTP1.1 IPC spec 16:43:49 ahf: we could bring an interpretor for WASM 16:44:00 it will be slow, but it is iOS 16:44:10 shelikhoo: i don't think we can do that and it would horribly slow 16:44:11 so it is apple's fault 16:44:18 yeah, let's focus on products here ;p 16:44:24 we've being discussing in the past that we wanted to do a new version of the ptspec, and the question here is if we really need that or should we directly focus on making a rust API/ABI and link our PTs to it 16:44:40 and forget about IPC for now 16:45:07 I think it is still a while before we get arti to support being a relay 16:45:30 is also a while antil we can do any meaningful new IPC, as c-tor will not support it 16:45:48 but we can start working on the client side 16:45:54 shelikhoo: we have a grant for it, the client side does PT's today and the interface is fairly nice. with the executor model, backwards compatibility on the server side should be fairly easy to provide for C tor usage today (even without modifying C tor) 16:46:11 arti should ideally be in TB at some point from next year 16:46:30 meskio: "forget about IPC for now" I think that is a productive direction to be headed in. 16:46:37 ya <3 16:46:50 oh! nice! it is nice to see arti get adopted soon! 16:47:02 so it will get onion service support soon?! 16:47:16 forget about IPC, think about the developer experience for arti integrators, and ignore external spec bureaucracy would be my 3 items that i hope people think of from this 16:47:22 yes, we should have an internal Go IPC PT spec 16:47:26 shelikhoo: it got onion service support in the last release 16:47:42 shelikhoo: yeah, connections to OS have been there for a while but OS services are arriving as we speak 16:47:46 meskio: oh! nice! I lost some tick in the past months... 16:47:48 still not entirely tied up 16:47:54 ahf: I think there are ways to "compile" wasm bins to C, so we could do a strange thing where we compile rust/go/whatever to wasm, and then for iOS only compile to C then to native code 16:48:22 or find a non-jit runtime 16:48:26 trinity-1686a: i see :o 16:48:32 I hear some quorum on ditching the idea of a new IPC pt spec, are we all on that page? 16:48:35 trinity-1686a: the WASM idea is imo a promising one for actually achieving the "cross-project pluggability" goal. 16:48:40 yes, we should have an internal Go IPC PT spec, then let the library and arti exchange traffic in HTTP Connect PT 16:49:02 shelikhoo, that is basically the opposite of what meskio said :P 16:49:12 shelikhoo: that is completely the opposite of what we just talked about i think 16:49:13 I guess there is no quorum 16:49:22 avoid thinking protocols, think library functions and interfaces is the goal 16:49:23 I am pretty interested in WASM pt as well! please let me know if there is any idea or progress! 16:49:51 should we make a voice meeting to discuss this? it looks like it requires some more work 16:49:52 and wasm could allow downloading new PTs as suggested by some api, without app update, which could be neat 16:49:57 or we can keep discussing it next week 16:50:04 there is 10min for the hour and two more topics 16:50:05 yes, but it would work for projects like iptlibrary now 16:50:39 trinity-1686a: one concern i'd have with wasm is the run-time cost and its abstraction cost, particularly in the iOS setting where memory usage is a concern (and this one i think we can totally blame on apple) 16:50:41 and also solve the socks arg length issue now 16:50:48 but it sounds like an interesting idea 16:51:18 I don't know the story about memory usage in wasm. will add to my todolist 16:51:21 it wouldn't be too hard for C-Tor to support HTTP Connect PT Spec if anything goes wrong 16:51:21 meskio: i think voice sounds good 16:51:23 trinity-1686a: awesome! 16:51:39 shelikhoo: we are not going to do more features in C tor unless there is a very, very, very good reason 16:51:51 I'll try to coordinate a voice meeting, I'll be mostly AFK next week, but let's target in two weeks 16:51:57 👍 16:51:59 ahf: yes, it will be the worst case 16:52:22 trinity-1686a: I wonder if you have seen the Proteus paper from FOCI 2023. It has the same vision of "protocol downloadable as if it were configuration". https://www.petsymposium.org/foci/2023/foci-2023-0013.php 16:52:23 I will write my opinion as text in the issue as well 16:52:44 there are two more topics in the agenda, can any of those be postponed for next week? 16:52:46 dcf1: I hadn't. thx for the link 16:52:50 * meskio has to leave in tmin 16:52:51 They use a custom sandboxed runtime and a new programming language. There was one slide in the presentation like "Why not WASM/Lua/etc.?", but I don't remember what it said. 16:52:57 s/tmin/5min/ 16:53:14 trinity-1686a: https://github.com/unblockable/proteus 16:53:54 proteus has the first Rust implementation of PT 1.0 afaik. 16:53:55 dcf1: I am going to go ahead and remove proxy churn if you think it is the right time 16:54:20 shelikhoo: yes, I am okay with that any time. 16:54:37 as i later know the funding proposal for related feature is stuck 16:54:50 If a plan emerges for long-term use or continuous records, I am okay with it coming back, I just think there should always be a plan. 16:54:51 okay then no discussion is necessary 16:55:07 cool 16:55:10 let's remove it for now until we got a plan later 16:55:23 last topic: (Network Health) 'Running' flag for counting bridges and network size 16:55:30 GeKo: ??? 16:55:36 can it wait a week? 16:55:40 yup 16:55:43 or should we solve it now fast? 16:55:47 that gives us a finite concrete artifact that was can publish alongside the churn analysis in the paper 16:56:31 meskio: gk is afk now, but it's fine to discuss next week 16:56:40 great, then we are done 16:56:49 we just wanted to bring to topic to the attention 16:56:49 just on time for me leaving :) 16:57:04 as it's affecting operators, indicators, metrics.. 16:57:11 ggus: sure, let's discuss it next week, anyway we've being talking in the issue 16:57:26 I'll close the meeting now if there is nothing more 16:57:55 #endmeeting