15:57:59 <meskio> #startmeeting tor anti-censorship meeting
15:57:59 <MeetBot> 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 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
15:58:04 <meskio> hello everyone!!!
15:58:12 <cohosh> hi
15:58:15 <meskio> here is our meeting pad: https://pad.riseup.net/p/tor-anti-censorship-keep
15:58:18 <meskio> feel free to add what you've been working on and put items on the agenda
15:58:19 <onyinyang[m]> hihi
15:58:40 <shelikhoo> hi~hi~
15:58:50 <ahf> o/
15:58:51 <meskio> I'll give it few minutes so people can fill up what they've been working on
15:59:11 <GeKo> hi
16:00:15 <ggus> hello o/
16:02:43 <meskio> if I understand correctly the first two discussion points are the same, as in what domain front we use in snowflake
16:02:53 <meskio> cohosh: do you want to introduce it?
16:03:26 <cohosh> sure, n8fr8 mentioned reports that foursquare.com is not working in iran and some ooni measurements back that up
16:04:03 <cohosh> 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 <cohosh> however, the other domain that we think will work, github.githubassets.com we just asked ooni about
16:05:05 <cohosh> and they said it was throttled by IP in Iran a year and a half ago
16:05:59 <meskio> 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 <cohosh> i guess throttling might not impact us that much since it's a pretty small channel we need anyway
16:06:22 <ggus> cohosh: meskio: the domain that you're investigating is only for the circumvention api or ?
16:06:43 <cohosh> ggus: we need fronts for both the api and for snowflake
16:06:45 <meskio> is both for circumvention settings/moat and snowflake
16:06:56 <cohosh> for example, orbot doesn't really use our api
16:06:59 <meskio> we've being using the same domain, maybe we should use two different ones
16:07:03 <cohosh> so they need something to work
16:07:21 <ggus> cohosh: i thought orbot 'smart connect' was using circumvention api
16:07:30 <cohosh> not for snowflake domains
16:07:38 <ggus> ahh, okay
16:07:48 <meskio> ggus: I think so, but I don't think is used by default, I'm confused by their UX
16:07:57 <cohosh> https://github.com/guardianproject/orbot/issues/983
16:08:13 <cohosh> *not for snowflake bridges
16:08:50 <cohosh> the tl;dr is that right now if the api returns a snowflake bridge they use their builtin snowflake bridge lines
16:09:57 <meskio> 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 <ggus> so, we need new domains in azure and/or fastly that works in china/iran/russia/+othe regions?
16:10:33 <meskio> ggus: fastly, yes
16:10:59 <cohosh> 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 <cohosh> in iran
16:11:33 <meskio> mmmm
16:12:13 <meskio> we could also check what others are using, like great fire, do they use fastly? if so what domain?
16:12:20 <ggus> cohosh: fwiw, cdn.sstatic was also blocked temporarily in Iran, so i wonder if foursquare was a temp issue too...
16:12:37 <cohosh> yeah that's possible
16:12:58 <cohosh> so maybe the idea of using githubassets and foursquare is good for now
16:13:08 <cohosh> (for snowflake, moat we need to just pick one)
16:13:25 <shelikhoo> 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 <shelikhoo> so that we don't need to worry too much about the quality of domain put into that list
16:14:02 <shelikhoo> so long as one of them work, it will work
16:14:03 <trinity-1686a> 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 <meskio> now that we'll have multiple domain names, would be nice to know how many people uses each from our broker...
16:14:33 <meskio> and from wich country, so we can see when something stops working
16:14:42 <shelikhoo> without usability issue like trying different fronting domain until one works
16:14:58 <cohosh> we did just talk to ooni about adding more of these potential front domains to their test lists
16:16:12 <cohosh> anyway, i think the short term question is what if anything to do about moat
16:16:35 <cohosh> since we have some pending snowflake features that shelikhoo mentioned
16:16:49 <cohosh> we can switch to githubassets for the next release
16:16:58 <cohosh> or stick with foursquare and hope the problem goes away
16:17:05 <cohosh> and meanwhile work on multi-front features
16:17:39 <meskio> if githubassets is just throttled and not blocked I think is a good idea to switch
16:17:48 <cohosh> okay, sounds good
16:18:03 <meskio> maybe we should look into it a bit
16:18:24 <cohosh> sure, that can happen after the meeting
16:18:33 <cohosh> we have some potential azure fronts to consider as well i think
16:19:02 <meskio> we can make the switch in TB alpha and ask some people in Iran to test
16:20:04 <cohosh> yeah that's a good idea
16:20:45 <meskio> 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 <ggus> or we can just give some bridge lines for people to test
16:21:02 <meskio> ggus: yep, we can also do that
16:21:12 <meskio> is that easier for the community team?
16:21:25 <meskio> I can produce a line for you
16:22:26 <ggus> meskio: we didn't have any report from iran... but in iran, people are mostly using Orbot and not tor browser
16:22:39 <meskio> ohh, true
16:23:07 <meskio> I'll make the line and pass it to you to test and see what we hear about
16:23:14 <ggus> sounds good!
16:23:16 <meskio> anything else on this topic?
16:23:31 <cohosh> 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 <cohosh> so they must have just switched to cloudflare fully
16:23:59 <dcf1> 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 <dcf1> ggus: unless you have other sources of information saying that Orbot is more used.
16:26:19 <meskio> 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 <meskio> lets move to the next topic
16:26:56 <meskio> future of PTs
16:27:08 <meskio> I've being talking with ahf on our ideas of HTTP based PT protocols
16:27:22 <ggus> 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 <ggus> https://www.appbrain.com/app/tor-browser/org.torproject.torbrowser
16:27:41 <shelikhoo> I personally don't think we should go with QUIC based transport
16:27:44 <dcf1> I think the discussion about MASQUE (re QUIC and TLS) in the issue is a little off the mark.
16:27:45 <meskio> and he was rising the question if we still need a network based PT protocol
16:27:52 <dcf1> Don't think "MASQUE" = "QUIC"
16:27:57 <ahf> o/
16:27:58 <dcf1> Think "MASQUE" = "HTTP"
16:28:08 <meskio> as in if we want just to use a plugin/library based system only
16:28:13 <dcf1> The "Q" in MASQUE originally stands for QUIC, yes, but that is somewhat an anachronism
16:28:36 <dcf1> MASQUE is just about specifying extensions and new ways to do proxying over HTTP
16:28:36 <shelikhoo> QUIC is designed to solve the issue of traffic over US/EU internet
16:28:37 <ahf> 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 <dcf1> In that sense you can consider good old HTTP CONNECT to fall under the same umbrella
16:29:02 <ahf> 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 <shelikhoo> and TCP based HTTP1.1 should work equally well without dealing with the complexity of QUIC
16:29:37 <ahf> 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 <dcf1> 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 <ahf> 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 <ahf> 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 <shelikhoo> 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 <ahf> 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 <ahf> 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 <shelikhoo> 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 <ahf> 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 <eta> https://gitlab.torproject.org/tpo/core/onionmasq/-/tree/main/crates/onionmasq-pt-wrapper?ref_type=heads this thing
16:32:26 <ahf> if we do things as plug-ins we can start releasing PT's together with the arti release process
16:32:27 <dcf1> ahf: the PT working group came to that conclusion years ago, I think.
16:32:40 <shelikhoo> I think we should go for simpler interface when it does what we wants to do
16:32:41 <ahf> and this build integration and such would become easier for folks wanting to embed our products
16:33:11 <ahf> 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 <shelikhoo> ahf: yes, we could have language depend PT interfaceS, however, it won't allow cross language calling
16:33:49 <ahf> 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 <meskio> I totally agree that we should integrate PTs in arti and make them as libraries that are compiled together with it
16:34:21 <ahf> 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 <shelikhoo> 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 <dcf1> 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 <meskio> 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 <ahf> shelikhoo: but that is also a solved issue today with what iptproxy have done with merging them all into one library :-)
16:35:51 <ahf> 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 <dcf1> 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 <ahf> (and static linking is important here - having DSO's is not enough)
16:36:36 <shelikhoo> 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 <dcf1> But there is certainly more demand out there for an API interface than what Tor does now.
16:36:38 <ahf> 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 <ahf> shelikhoo: but they solved that by wrapping all the go pt's in one "meta" pt
16:37:11 <shelikhoo> in iptlibrary's case, the pt is no longer pluggable, as custom logic is needed for each pt
16:37:18 <ahf> it's not like we see another PT arrive every week anymore :-)
16:37:46 <shelikhoo> ahf: yes, it would work by having a go pt aggregator
16:37:48 <ahf> 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 <ahf> shelikhoo: that exists today
16:38:03 <dcf1> 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 <shelikhoo> trinity-1686a: yes! I like that idea but maybe not everyone...
16:38:51 <cohosh> LEAP for one has tried to use our PTs without Tor
16:38:56 <ahf> dcf1: tor's goal's with arti is that more applications should be able to embed tor into their products
16:39:05 <ahf> and with that, they want our anti-censorship story too
16:39:30 <meskio> 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 <dcf1> 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 <ahf> 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 <ahf> dcf1: right
16:39:54 <dcf1> I myself would not be sad to see the IPC TOR_PT_MANAGED_TRANSPORT_VERSION etc. go away.
16:40:16 <ahf> oh boy, me too
16:40:24 <shelikhoo> dcf1: in the end, Tor, Shadowsocks all have different PT protocol, and different developer just target different standard
16:40:42 <dcf1> 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 <ahf> 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 <ahf> 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 <meskio> (LEAP does use the operator foundation libraries, not pt-spec)
16:42:00 <dcf1> 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 <ahf> right
16:42:42 <shelikhoo> I think it wouldn't be hard for us to target a in process language dependent PT spec
16:42:48 <dcf1> 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 <ahf> 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 <shelikhoo> and let the pt-library target different SOCKS or HTTP1.1 IPC spec
16:43:49 <shelikhoo> ahf: we could bring an interpretor for WASM
16:44:00 <shelikhoo> it will be slow, but it is iOS
16:44:10 <ahf> shelikhoo: i don't think we can do that and it would horribly slow
16:44:11 <shelikhoo> so it is apple's fault
16:44:18 <ahf> yeah, let's focus on products here ;p
16:44:24 <meskio> 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 <meskio> and forget about IPC for now
16:45:07 <shelikhoo> I think it is still a while before we get arti to support being a relay
16:45:30 <meskio> is also a while antil we can do any meaningful new IPC, as c-tor will not support it
16:45:48 <meskio> but we can start working on the client side
16:45:54 <ahf> 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 <ahf> arti should ideally be in TB at some point from next year
16:46:30 <dcf1> meskio: "forget about IPC for now" I think that is a productive direction to be headed in.
16:46:37 <ahf> ya <3
16:46:50 <shelikhoo> oh! nice! it is nice to see arti get adopted soon!
16:47:02 <shelikhoo> so it will get onion service support soon?!
16:47:16 <ahf> 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 <shelikhoo> yes, we should have an internal Go IPC PT spec
16:47:26 <meskio> shelikhoo: it got onion service support in the last release
16:47:42 <ahf> shelikhoo: yeah, connections to OS have been there for a while but OS services are arriving as we speak
16:47:46 <shelikhoo> meskio: oh! nice! I lost some tick in the past months...
16:47:48 <ahf> still not entirely tied up
16:47:54 <trinity-1686a> 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 <trinity-1686a> or find a non-jit runtime
16:48:26 <ahf> trinity-1686a: i see :o
16:48:32 <meskio> I hear some quorum on ditching the idea of a new IPC pt spec, are we all on that page?
16:48:35 <dcf1> trinity-1686a: the WASM idea is imo a promising one for actually achieving the "cross-project pluggability" goal.
16:48:40 <shelikhoo> 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 <dcf1> shelikhoo, that is basically the opposite of what meskio said :P
16:49:12 <ahf> shelikhoo: that is completely the opposite of what we just talked about i think
16:49:13 <meskio> I guess there is no quorum
16:49:22 <ahf> avoid thinking protocols, think library functions and interfaces is the goal
16:49:23 <shelikhoo> I am pretty interested in WASM pt as well! please let me know if there is any idea or progress!
16:49:51 <meskio> should we make a voice meeting to discuss this? it looks like it requires some more work
16:49:52 <trinity-1686a> and wasm could allow downloading new PTs as suggested by some api, without app update, which could be neat
16:49:57 <meskio> or we can keep discussing it next week
16:50:04 <meskio> there is 10min for the hour and two more topics
16:50:05 <shelikhoo> yes, but it would work for projects like iptlibrary now
16:50:39 <ahf> 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 <shelikhoo> and also solve the socks arg length issue now
16:50:48 <ahf> but it sounds like an interesting idea
16:51:18 <trinity-1686a> I don't know the story about memory usage in wasm. will add to my todolist
16:51:21 <shelikhoo> it wouldn't be too hard for C-Tor to support HTTP Connect PT Spec if anything goes wrong
16:51:21 <ahf> meskio: i think voice sounds good
16:51:23 <ahf> trinity-1686a: awesome!
16:51:39 <ahf> shelikhoo: we are not going to do more features in C tor unless there is a very, very, very good reason
16:51:51 <meskio> 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 <ahf> 👍
16:51:59 <shelikhoo> ahf: yes, it will be the worst case
16:52:22 <dcf1> 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 <shelikhoo> I will write my opinion as text in the issue as well
16:52:44 <meskio> there are two more topics in the agenda, can any of those be postponed for next week?
16:52:46 <trinity-1686a> dcf1: I hadn't. thx for the link
16:52:50 * meskio has to leave in tmin
16:52:51 <dcf1> 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 <meskio> s/tmin/5min/
16:53:14 <dcf1> trinity-1686a: https://github.com/unblockable/proteus
16:53:54 <dcf1> proteus has the first Rust implementation of PT 1.0 afaik.
16:53:55 <shelikhoo> dcf1: I am going to go ahead and remove proxy churn if you think it is the right time
16:54:20 <dcf1> shelikhoo: yes, I am okay with that any time.
16:54:37 <shelikhoo> as i later know the funding proposal for related feature is stuck
16:54:50 <dcf1> 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 <shelikhoo> okay then no discussion is necessary
16:55:07 <meskio> cool
16:55:10 <shelikhoo> let's remove it for now until we got a plan later
16:55:23 <meskio> last topic: (Network Health) 'Running' flag for counting bridges and network size
16:55:30 <meskio> GeKo: ???
16:55:36 <meskio> can it wait a week?
16:55:40 <ggus> yup
16:55:43 <meskio> or should we solve it now fast?
16:55:47 <dcf1> that gives us a finite concrete artifact that was can publish alongside the churn analysis in the paper
16:56:31 <ggus> meskio: gk is afk now, but it's fine to discuss next week
16:56:40 <meskio> great, then we are done
16:56:49 <ggus> we just wanted to bring to topic to the attention
16:56:49 <meskio> just on time for me leaving :)
16:57:04 <ggus> as it's affecting operators, indicators, metrics..
16:57:11 <meskio> ggus: sure, let's discuss it next week, anyway we've being talking in the issue
16:57:26 <meskio> I'll close the meeting now if there is nothing more
16:57:55 <meskio> #endmeeting