16:00:37 <onyinyang> #startmeeting tor anti-censorship meeting
16:00:37 <MeetBot> Meeting started Thu Nov  7 16:00:37 2024 UTC.  The chair is onyinyang. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:37 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
16:00:37 <onyinyang> hello everyone!
16:00:37 <onyinyang> here is our meeting pad: [https://pad.riseup.net/p/r.9574e996bb9c0266213d38b91b56c469](https://pad.riseup.net/p/r.9574e996bb9c0266213d38b91b56c469)
16:00:48 <nipaton> hello!
16:00:48 <shelikhoo> hi~hi~
16:01:44 <nipaton> I don't have permission to access the pad ☹️
16:01:53 <cohosh> hi
16:02:14 <nipaton> o now I have
16:03:01 <meskio> hello
16:03:08 <meskio> I almost forgot about the meeting
16:04:27 <onyinyang> me too because of the time change
16:05:21 <onyinyang> ok let's start
16:05:39 <onyinyang> The first (only?) announcement is: The rest of our Fastly front domains have stopped working over the last few months, and have been replaced
16:06:41 <onyinyang> I moved this but did not add it and am not sure who did 😅
16:06:57 <cohosh> i don't think there's much to discuss
16:07:04 <cohosh> it might explain some problems connecting
16:07:19 <onyinyang> ok, that makes sense
16:07:53 <shelikhoo> yes... I will see if i can make vantage point update it automatically
16:08:06 <shelikhoo> yes... I will see if i can make vantage point update from it automatically
16:09:12 <onyinyang> Ok, there was a new announcement added about obfs4 blocked in mobile networks in russia
16:09:27 <meskio> ohh, wait
16:09:32 <meskio> I wanted to add it to discussion
16:09:34 <meskio> sorry, let me move it
16:09:50 <meskio> sorry, just rushing around
16:09:51 <onyinyang> well, there are no other announcements, so that can be the first discussion point
16:11:17 <ggus> hello o/
16:11:31 <onyinyang> o/
16:11:59 <cohosh> the point about it being protocol blocking is interesting
16:12:04 <dcf1> I posted about obfs4 mobile blocking in a thread in NTC, but didn't get any replies https://ntc.party/t/11010/15
16:12:14 <cohosh> i want to point out something we found in 2020 in belarus on that
16:12:32 <cohosh> we had some TCP tests that showed that connections to obfs4 bridges were working
16:13:16 <cohosh> so  we although at first thought it was DPI
16:14:02 <cohosh> but we found later by looking at packet captures that the TCP SYN-ACK packets were blocked, not TCP SYN packets
16:14:32 <cohosh> which presented itself as an application layer error but it was still endpoint TCP blocking
16:14:43 <meskio> there has being a discussion in net4people and ntc.party about blocking of fully encrypted protocols on mobile networks in russia, so it will match that
16:14:52 <meskio> shadowshocks and vmess seems to be affected too
16:15:00 <cohosh> or sorry, it was the TCP ACK packets being blocked i think
16:15:20 <meskio> and those bridges do work in other connections in russia
16:15:30 <cohosh> ok good to know
16:15:52 <ggus> but why downgrading the connection from 4G to 3G would bypass this block?
16:16:11 <meskio> so it might be that russia is blocking traffic over its entropy, and the weird things will be that they've being doing for months
16:16:24 <shelikhoo> a lot of censor hesitate to block client to server traffic as it would allow people to send traffic to that ip address to DDoS the firewall itself
16:16:26 <meskio> while china didn't keep the block for long when they try
16:16:56 <meskio> ggus: I guess they have a different firewall on each network and 4G and 3G are different networks in practice
16:17:16 <ggus> hmm i see
16:17:18 <meskio> they might be experimenting with the measure just with 4G and see if they can apply it elsewhere
16:18:00 <shelikhoo> it is possible that 4g and 3g has different routing route
16:18:18 <meskio> as we don't have direct access to any 4G connection in russia I guess the best we can do for now is wait to see if someone answers to dcf1 message
16:19:15 <cohosh> where's the discussion on fully encrypted protocols being blocked in Russia?
16:19:17 <ggus> nina can translate a short call and add it to ntc party
16:19:44 <cohosh> i just want to link it in the issue
16:19:47 <meskio> cohosh: https://github.com/net4people/bbs/issues/363
16:20:03 <meskio> https://ntc.party/t/%D0%BD%D0%B5%D1%80%D0%B0%D0%B1%D0%BE%D1%82%D0%BE%D1%81%D0%BF%D0%BE%D1%81%D0%BE%D0%B1%D0%BD%D0%BE%D1%81%D1%82%D1%8C-%D1%88%D0%B8%D1%84%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%BD%D1%8B%D1%85-%D0%BF%D1%80%D0%BE%D1%82%D0%BE%D0%BA%D0%BE%D0%BB%D0%BE%D0%B2-shadowsocksvmess-25042024/7776
16:20:14 <meskio> (fun with encodings)
16:20:17 <cohosh> thanks!
16:20:22 <ggus> https://dpidetector.org/en/
16:20:27 <ggus> ^cool resource
16:20:49 <dcf1> I learned you can delete the percentencoded slug and it still works https://ntc.party/t/7776
16:21:09 <meskio> ohh, nice
16:21:15 <onyinyang> nice tip
16:22:17 <shelikhoo> X~X unsure why discourse developers insisted on putting title in the url even it does not work for many languages...
16:22:21 <meskio> BTW, talking about russia
16:22:31 <shelikhoo> maybe because google like it...
16:22:34 <meskio> cloudflare's ECH seems to be blocked already there
16:22:53 <meskio> I requested ooni to add the couldflare ECH domain to their tests...
16:23:23 <meskio> shelikhoo: because they only speack languages that use ascii
16:23:24 <dcf1> arturo posted OONI results for cloudflare-ech.com https://github.com/net4people/bbs/issues/393#issuecomment-2462121200
16:23:30 <dcf1> https://explorer.ooni.org/chart/mat?probe_cc=RU&since=2024-10-08&until=2024-11-08&time_grain=day&axis_x=measurement_start_day&test_name=web_connectivity&domain=cloudflare-ech.com
16:23:57 <shelikhoo> shelikhoo: oh yes... that's true..
16:24:06 <dcf1> there is no blocking detected by OONI, because the blocking signature is SNI=cloudflare-ech.com *and* ECH extension is present https://github.com/net4people/bbs/issues/393#issuecomment-2462130383
16:24:11 <shelikhoo> meskio: oh yes... that's true..
16:24:23 <dcf1> I'm in the process of summarizing these comments on BBS and moving them to a dedicated issue
16:25:07 <meskio> they are fast, but a pity that an specific test is needed
16:25:09 <shelikhoo> I think ECH didn't work because it didn't actually make it is still an extension
16:25:32 <shelikhoo> I think ECH didn't work because it didn't actually make core, it is still an extension
16:25:53 <meskio> shelikhoo: no, blocking ECH means they have to block all websites that use the same ECH domain
16:25:59 <meskio> so they have to block most cloudflare
16:26:06 <meskio> if I understand it correctly
16:26:08 <dcf1> I wouldn't assume ECH is necessarily failed just from this, we have seen before Roskomnadzor make a show of blocking something and then back off
16:26:36 <dcf1> Yeah it would be virtually all cloudflare sites, as I understand it, people on the cloudflare free plan have ECH enabled automatically
16:26:39 <meskio> yes, I kind of expect them to back off when they discover the size of their block, but we'll see
16:27:40 <dcf1> There is an official acknowledgement from some bureau of the Russian government (cmu.gov.ru, never heard of it before): https://cmu.gov.ru/ru/news/2024/11/07/%D1%80%D0%B5%D0%BA%D0%BE%D0%BC%D0%B5%D0%BD%D0%B4%D1%83%D0%B5%D0%BC-%D0%BE%D1%82%D0%BA%D0%B0%D0%B7%D0%B0%D1%82%D1%8C%D1%81%D1%8F-%D0%BE%D1%82-cdn-%D1%81%D0%B5%D1%80%D0%B2%D0%B8%D1%81%D0%B0-cloudflare/
16:27:52 <shelikhoo> let's see... I think they could make some compromise on rtt for better censorship resistance
16:28:58 <shelikhoo> but big tech obviously wants less rt
16:29:00 <dcf1> There may be a Firefox bug, in that it apparently eventually retries without ECH, in violation of the spec. https://github.com/net4people/bbs/issues/393#issuecomment-2462162744 "Firefox retries without ECH after about a minute"
16:29:01 <shelikhoo> rtt
16:29:41 <dcf1> also ooni has an open issue, not yet replied, for an ECH nettest https://github.com/ooni/probe/issues/1453
16:29:41 <meskio> ohh, if retrying becomes common it will be really bad
16:30:12 <dcf1> I did a quick search on bugzilla.mozilla.org and didn't find anything about this Russia incident yet, neither on https://mailarchive.ietf.org/arch/browse/tls/
16:30:17 <meskio> I heard them mentioning they were working on it, I see the issue mentions a PoC
16:31:04 <meskio> maybe something to report to mozilla
16:32:39 <onyinyang> so we skipped a discussion point and jumped right into the interesting links (though this is probably the right place for the ECH discussion anyway)
16:32:52 <onyinyang> if there's nothing else to add on this, let's backtrack a bit to the push notifications point
16:33:00 <meskio> ahh, that was in the interesting links, ups
16:33:01 <dcf1> I'm planning to skim through the 300 o_0 comments on https://ntc.party/t/12732 to see if there's more info there.
16:33:24 <meskio> dcf1: let us know what you find, I only look at very few of them
16:33:30 <cohosh> wow that's a lot of comments, thanks for doing that :)
16:33:38 <onyinyang> heh it's ok meskio, we can adjust and be flexible :) hehe
16:33:43 <dcf1> trouble is they seem to be written in some foreign language
16:33:46 <ggus> 300 posts in 2 days
16:33:52 <onyinyang> o_o
16:33:54 <ggus> -.-
16:33:55 <shelikhoo> thanks...
16:34:22 <shelikhoo> don't worry... I think at least the content can be copy and pasted to translator
16:34:40 <cohosh> okay for push notifications i want to talk about whether this is something we feel good about pursuing, whether the advantages are worth the risks
16:34:55 <cohosh> i started playing around with what a distributor for circumvention settings could look like with push notifications, to be a backup for the settings part of moat if the domain fronted channel fails:
16:34:59 <cohosh> gitlab.torproject.org/cohosh/push-notification-distributor
16:35:08 <cohosh> this channel has been a single point of failure for us so it makes sense to try and make this process more robust
16:35:33 <cohosh> but it has a different privacy impact than domain fronting
16:35:53 <cohosh> like domain fronting, it's important for the messages to be authenticated and probably encrypted
16:36:03 <cohosh> the main privacy drawback compared to domain fronting is the long-lived background connection to the push notification provider that would allow tracking a user across IP addresses
16:37:03 <meskio> if we could clreate that long lived connection only if domain fronting fails the problem will be solved
16:37:28 <cohosh> my understanding is we don't have control over that
16:37:41 <meskio> can't we use the creation of this connection to pass a request? as a RPC using the push notifications only for one notification?
16:37:43 <cohosh> for android at least, it's the google services installation that handles that connection
16:37:53 <cohosh> and it's shared across all apps that use push notifications
16:38:01 <meskio> yes, but there is some kind of client registration process, isn't it?
16:38:12 <meskio> you don't need to do that if domain fronting works
16:39:00 <shelikhoo> cohosh: is there a code for the receiving end of the connection?
16:39:21 <cohosh> shelikhoo: there is an onMessage callback you can set
16:39:39 <shelikhoo> so it is assisted by the OS?
16:39:51 <cohosh> it's assisted by google services
16:40:00 <shelikhoo> I think this push notification would always exist, we use it or not
16:40:14 <cohosh> which is part of the android distribution i guess
16:40:16 <shelikhoo> since other service would be using gcm already
16:40:24 <cohosh> yes that's my understand too
16:40:29 <cohosh> *understanding
16:40:48 <shelikhoo> although I really wants to see the client side code to understand how it actually works...
16:41:02 <shelikhoo> the code the implement the onMessage callback
16:41:04 <cohosh> so integrating this with orbot won't give more information to Google necessarily, but it will add the additional information that a user has Orbot installed
16:41:51 <cohosh> meskio: on your point, i don't understand what you're suggesting, we don't have the ability at the application level to control when or how the user makes a connection to the push notification provider
16:42:30 <meskio> I thought the process was:
16:42:40 <meskio> 1. application registers to receive notifications for that user
16:42:43 <ggus> cohosh: i wonder if this distributor would work in cases where apple/google has removed the app from their stores (like in china and russia)
16:42:45 <cohosh> shelikhoo: here's a partial integration on the client side https://github.com/guardianproject/orbot/compare/master...cohosh:orbot:push-notification
16:42:48 <meskio> 2. application waits for notifications to arrive
16:43:01 <ggus> but looks a great idea!
16:43:23 <meskio> are you saying that there is no registration step?
16:43:29 <cohosh> there is a registration step
16:43:47 <meskio> cool, so we can choose to register or not depending if domain fronting is working
16:43:47 <cohosh> the user would register (using domain fronting or something similar) with our push notification distributor
16:44:02 <cohosh> well, how do we register if domain fronting isn't working?
16:44:07 <meskio> ohh, wait the registration is offband
16:44:09 <cohosh> the registration happens out of band
16:44:10 <cohosh> yep
16:44:10 <meskio> ohh, I see
16:44:12 <shelikhoo> Yes, thanks! Okay I now understood that it is basically based on shared push connection
16:44:32 <meskio> then yes, you do need to register before domaing fronting stops working
16:44:58 <cohosh> ggus: that's a good point, google claims not to maintain a mapping of tokens to services but that doesn't mean they couldn't
16:45:20 <cohosh> *tokens to apps that is
16:45:42 <shelikhoo> I think they could just ban the account of the developer I guess…
16:46:01 <cohosh> yeah true, that's probably how it would look
16:47:01 <cohosh> the privacy concerns are little difficult to reason about, because the orbot users who would use this already have this background connection
16:47:17 <cohosh> and there's the point that google claims it doesn't have a mapping of tokens to apps
16:47:54 <cohosh> but i'm worried about this mapping existing, being used to narrow down a list of tor users, and then the fine-grained location information being requested by law enforecement who are looking for patterns that match online behaviour
16:48:31 <shelikhoo> yes... although I have to say I believe google already collect the app users installed
16:48:32 <cohosh> this could be helped by opting into it and informed consent before registering
16:48:56 <shelikhoo> and apple collect what app user have 'bought(including free apps)'
16:49:16 <cohosh> the good thing is that this use of push notifications has no link to client behaviour
16:49:20 <shelikhoo> so push notification does not make it easier for them to give info to states
16:49:26 <meskio> cohosh: the inform consent I think is important, as most Tor users will not need this service and we should not set it up for everybody for sure
16:49:29 <cohosh> because the messages only happen when there are circumvention settings updates
16:49:42 <cohosh> not triggered by the client
16:50:32 <meskio> I think is a good idea to explore, but we might need to include apps and UX teams on this conversation
16:51:19 <cohosh> yeah, in the case of orbot that would be guardian project
16:52:33 <cohosh> anyway, thanks for the discussion
16:52:43 <meskio> thank you for playing around with it
16:52:48 <onyinyang> cohosh, I also think it sounds like a good idea to explore and informed consent would help, but would also be tricky to communicate effectively since we're not totally clear on how risky it is for users
16:52:50 <shelikhoo> is there any plan for some work about web push
16:52:52 <cohosh> it's good to figure out what the risks are and if we're okay with running the distributor
16:53:01 <onyinyang> but transparency is good at leat
16:53:09 <onyinyang> *least
16:53:10 <cohosh> shelikhoo: i don't have plans right now but the apps team brought it up when we were talking on irc about it
16:53:26 <shelikhoo> cohosh: yes...
16:53:49 <shelikhoo> I think web push is another thing we could do
16:54:09 <shelikhoo> that is harder for push providers to ban website than app
16:54:34 <shelikhoo> as apps requires developers to sign up with push providers, while web don't
16:54:39 <shelikhoo> eof
16:54:51 <onyinyang> anything else to discuss today?
16:55:01 <meskio> but web push will require that the website we use for pushing notifications is not blocked, isn't it?
16:55:08 <meskio> as in, we can't do that in torproject.org
16:55:25 <shelikhoo> no, even localhost would work..
16:55:50 <shelikhoo> the registration part can be done out of band
16:56:23 <meskio> who sends the push notification to the client (or holds the long lived client connection) for web push?
16:56:42 <shelikhoo> the browser will have its own push connection on desktop
16:56:52 <shelikhoo> and mobile browser will use os's push
16:56:57 <meskio> as in mozilla or google chrome will provide that as a service?
16:57:12 <shelikhoo> yes, they have push connection on desktop
16:57:18 <meskio> ohhh, I didn't know about that, cool
16:57:34 <shelikhoo> yes, it is included in browser
16:57:51 <shelikhoo> and it would be nice to just write once and use on every browser
16:58:34 <meskio> nice
16:58:37 <meskio> that is all for me
16:58:40 <shelikhoo> eof
16:58:46 <cohosh> thanks! same from me
16:59:56 <onyinyang> ok thanks everyone!
16:59:59 <onyinyang> #endmeeting