15:57:38 <meskio> #startmeeting tor anti-censorship meeting
15:57:38 <MeetBot> Meeting started Thu Oct 26 15:57:38 2023 UTC.  The chair is meskio. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:57:38 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
15:57:44 <shelikhoo> hi!hi!
15:57:44 <meskio> hello everybody!!!
15:57:48 <meskio> here is our meeting pad: https://pad.riseup.net/p/tor-anti-censorship-keep
15:57:50 <meskio> feel free to add what you've been working on and put items on the agenda
15:57:58 <cohosh> hi
15:58:13 <onyinyang[m]> hihi
16:00:17 <meskio> I think people has finished with their updates, we can probably start
16:00:28 <meskio> the first point in the agenda is the fastly domain front
16:01:13 <meskio> it looks like fastly is going to close domain front february 2024
16:01:20 <meskio> we use fastly both for snowflake and moat
16:01:38 <cohosh> if my understanding is correct, it will continue working for a while after february
16:01:52 <cohosh> for all of the fronts listed in the customer report
16:01:57 <shelikhoo> when was the time azure going to shut down domain fronting?
16:02:02 <cohosh> until the certificates expire
16:02:12 <meskio> shelikhoo: November, so next month
16:02:33 <shelikhoo> okay, so we are on borrowed time to actually deal with this situation...
16:02:36 <meskio> cohosh: can we renew the certificate to enlarge the time?
16:02:48 <cohosh> it's dependent on the front certificates i think
16:02:57 <cohosh> the report has the number of days until those certs expire
16:03:16 <meskio> I see
16:03:33 <cohosh> but, i think we shouldn't rely on that
16:03:45 <meskio> AFAIK the only "big" cloud provider left with domain front support is akamai, but I haven't tested if that is true
16:04:39 <meskio> it looks like we need to find alternatives fast, either implement ampcache for moat and/or see if akamai or others can be a real option
16:04:44 <shelikhoo> I think one need to speak a human to setup an account at akamai?
16:05:24 <meskio> no idea, never used it
16:05:49 <shelikhoo> there is also cdn77 and netlify that we potentially could use
16:06:13 <cohosh> another potentially quick rendezvous method is to use tapdance as it's currently deployed
16:06:29 <cohosh> i'm not sure what the load situation is for just that part of the deployment
16:06:57 <cohosh> but i believe all tapdance would need is a client integration and then we just point it to snowflake-broker.torproject.net
16:07:25 <meskio> if we could survive with some domain front alternative for a bit, we had plans to work on a 'signaling channels' library next year, but we don't have a specific timeline for it...
16:07:31 <cohosh> moat will be trickier
16:07:56 <cohosh> there is also amp cache, but i don't know where it works and where it doesn't
16:08:49 <shelikhoo> I think once we have a signaling channel library with automatic fallback system
16:08:58 <shelikhoo> we can just add more methods into it
16:09:06 <meskio> to me it would make sense to experiment with akamai, cdn77 and netlify, see how blocked is in the places we have vantage points and if they are a real alternative
16:09:09 <shelikhoo> without worrying too much about which will actually work
16:09:23 <gaba> cohosh: this is work you can do in the new project starting on nov 1st, right?
16:09:28 <gaba> thhe research on what else to use
16:09:32 <meskio> and look into making a proper signaling channels library soon, so we don't reimplement it on every place
16:09:43 <cohosh> gaba: yeah this fits into that
16:10:05 <shelikhoo> nice!
16:10:11 <meskio> cool
16:10:27 <shelikhoo> I personally think we should try cdn77 first
16:10:43 * meskio didn't even know about cdn77
16:11:43 <meskio> cohosh: do you have time to look into this next month?
16:11:50 <cohosh> yes
16:11:51 <shelikhoo> for netlify I believe one will need to create a function to handle request
16:11:58 <shelikhoo> this will be some work to do
16:12:11 <shelikhoo> while for cdn77, it should be more or less an dropin replacement
16:12:48 <shelikhoo> https://www.akamai.com/products/global-traffic-management#free-trial
16:12:59 <shelikhoo> akamai seems require talking to human
16:13:41 <meskio> I guess that human don't need to know we'll do domain fronting...
16:14:50 <meskio> anyway, I guess we need to wait for cohosh to come back with more information
16:14:51 <shelikhoo> yes... it seems we can try cdn77 without talking with a human for 14 days
16:15:04 <shelikhoo> but there is only one way to know for sure
16:15:05 <shelikhoo> yes
16:15:12 <cohosh> i still think it makes sense to at least try some other alternatives to domain fronting
16:15:32 <cohosh> even if it's just stress testing amp cache a bit by making one of the default bridges use it
16:15:47 <meskio> that will be nice, but we should look into it to don't reinvent the wheel again and again
16:16:05 <shelikhoo> yes, the thing is that moat don't support amp cache yet
16:16:06 <shelikhoo> I think
16:16:20 <cohosh> that's right, it doesn't
16:16:42 <meskio> but yes, knowing if ampcache does work well is a worth it research
16:16:57 <shelikhoo> yes, that's true
16:16:57 <meskio> I think is a good idea to switch one of the default bridges
16:17:48 <meskio> but as they get that big difference on traffic not sure if the change will not be mixed in the rest of the confusion we have on why is this happening
16:18:03 <meskio> would be nice to have some stadistics from the broker on how many clients come from ampcache
16:18:12 <shelikhoo> yes, there is no reason we couldn't do both: give amp more research and find next fronting cdn
16:18:14 <meskio> do that already exist? is it possible to do?
16:18:50 <shelikhoo> I believe it should be possible, but I don't know if it exists
16:19:37 <shelikhoo> I don't think it exist, but we should be able to add that
16:20:04 <cohosh> yeah we don't currently do that but it shouldn't be difficult to add
16:21:14 <meskio> should we enable ampcache in snowflake-01, so if it fails more people uses snowflake-02?
16:21:54 <cohosh> i guess we also don't know how many Tor Browser vs Orbot users we have so the change might not actually affect that many people, heh
16:22:36 <shelikhoo> I think it is at least will give us chance to see how well it works, for example where it works
16:22:46 <cohosh> i think it's a reasonable thing to try and it might tell us more about that as well
16:22:49 <meskio> yes, it might not affect many, but if we have metrics of how many ampcache connections come from each country we might get some idea if it works in some areas
16:23:08 <shelikhoo> I think ampcache don't forward origin ip?
16:23:20 <shelikhoo> I think ampcache don't forward client ip?
16:24:05 <dcf1> shelikhoo: rendezvous method does not interact with forwarding of client IP
16:24:19 <dcf1> the proxy doesn't even know what rendezvous method was used, it sends client_ip= in every case
16:25:02 <cohosh> shelikhoo: do you mean for broker metrics?
16:25:06 <shelikhoo> I means broker don't receive the client ip from amp proxy, so we don't know if amp proxy work in one region or not
16:25:16 <cohosh> the broker only looks at the ip of proxies at the moment, not of clients
16:25:32 <dcf1> shelikhoo: I see, thanks
16:25:56 <meskio> ohh, so we might only get global metrics of the rendezvous method and not per country
16:26:05 <shelikhoo> yes, I understand the client ip is not collected by broker
16:26:43 <shelikhoo> yes, so we should request community team to forward us the user feedback if any
16:27:36 <shelikhoo> or alternatively, we could peak at the client's offer
16:27:40 <shelikhoo> to get client ip address
16:27:47 <shelikhoo> which is in the content of the traffic
16:28:07 <shelikhoo> that sent over amp
16:28:15 <cohosh> hmm it would be useful to have that
16:28:22 <cohosh> for this purpose
16:29:35 <meskio> nice, that looks like a plan, to work on both looking at other CDNs and testing ampcache
16:29:44 <meskio> anything more on this topic?
16:29:50 <shelikhoo> EOF
16:29:55 <cohosh> not from me
16:30:16 <meskio> there is no more in the agenda, but I have a short one seeing that we have time
16:30:28 <meskio> I was reviewing this merge request: https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/merge_requests/187
16:30:48 <meskio> that proposes to hand out unrestricted proxies to unrestricted clients if there no restricted proxies available
16:31:01 <meskio> it looks like it helps the user to test thins in their testing setup
16:31:21 <cohosh> sorry, i forgot to follow up on that
16:31:45 <meskio> I was inclined to merge it, but wondering if in that rare case that I don't expect to happen we'll "waste" unrestricted proxies instead of making the client to wait for a restricted one to be available
16:32:22 <meskio> cohosh: I can also shetle it with you
16:32:47 * arma2 catches up on backlog: re akamai, we have a board member who is high up in the chain at akamai, and knows about other groups like psiphon using them for domain fronting
16:32:52 <cohosh> yeah after seeing WofWca's response I think we should suppport this feature
16:33:01 <cohosh> since we can't forsee every deployment scenario
16:33:15 <cohosh> and like you said it's unlikely to have an impact on our deployment
16:33:16 <shelikhoo> I think this is unlikely to happen in our production... so it is okay to have it
16:33:30 <meskio> sounds good, I'll merge it then, thanks
16:33:36 <cohosh> arma2: ok, that's promising :)
16:33:41 <shelikhoo> arma2: nice!
16:33:43 <meskio> nice
16:34:37 <meskio> cool, we have few interesting links this week:
16:34:51 <meskio> there is a callout for webtunnel testers in the forum: https://forum.torproject.org/t/call-for-testers-webtunnel-a-new-way-to-bypass-censorship-with-tor-browser/9855
16:35:13 <arma2> (when the time comes to need an akamai contact, let me know and i will introduce you to him)
16:35:29 <arma2> (we hung out with him in kyoto so now he knows we are human beings)
16:36:16 <meskio> and a blog post about a code audit we got for sponsor 30 (rdsys, bridgedb and conjure are there): https://blog.torproject.org/security-audit-report-tor-browser-ooni/
16:36:34 <meskio> and a paper "On the Performance Evaluation of Tor Pluggable Transports": https://dl.acm.org/doi/10.1145/3618257.3624817
16:36:44 <meskio> maybe something to add to our reading group queue at some point
16:37:13 <meskio> anything else for todays meeting?
16:38:03 <meskio> great, then I guess we can end it here
16:38:03 <shelikhoo> EOF from me
16:38:05 <meskio> #endmeeting