16:00:37 #startmeeting tor anti-censorship meeting 16:00:37 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 Useful Commands: #action #agreed #help #info #idea #link #topic. 16:00:37 hello everyone! 16:00:37 here is our meeting pad: [https://pad.riseup.net/p/r.9574e996bb9c0266213d38b91b56c469](https://pad.riseup.net/p/r.9574e996bb9c0266213d38b91b56c469) 16:00:48 hello! 16:00:48 hi~hi~ 16:01:44 I don't have permission to access the pad ☹️ 16:01:53 hi 16:02:14 o now I have 16:03:01 hello 16:03:08 I almost forgot about the meeting 16:04:27 me too because of the time change 16:05:21 ok let's start 16:05:39 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 I moved this but did not add it and am not sure who did 😅 16:06:57 i don't think there's much to discuss 16:07:04 it might explain some problems connecting 16:07:19 ok, that makes sense 16:07:53 yes... I will see if i can make vantage point update it automatically 16:08:06 yes... I will see if i can make vantage point update from it automatically 16:09:12 Ok, there was a new announcement added about obfs4 blocked in mobile networks in russia 16:09:27 ohh, wait 16:09:32 I wanted to add it to discussion 16:09:34 sorry, let me move it 16:09:50 sorry, just rushing around 16:09:51 well, there are no other announcements, so that can be the first discussion point 16:11:17 hello o/ 16:11:31 o/ 16:11:59 the point about it being protocol blocking is interesting 16:12:04 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 i want to point out something we found in 2020 in belarus on that 16:12:32 we had some TCP tests that showed that connections to obfs4 bridges were working 16:13:16 so we although at first thought it was DPI 16:14:02 but we found later by looking at packet captures that the TCP SYN-ACK packets were blocked, not TCP SYN packets 16:14:32 which presented itself as an application layer error but it was still endpoint TCP blocking 16:14:43 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 shadowshocks and vmess seems to be affected too 16:15:00 or sorry, it was the TCP ACK packets being blocked i think 16:15:20 and those bridges do work in other connections in russia 16:15:30 ok good to know 16:15:52 but why downgrading the connection from 4G to 3G would bypass this block? 16:16:11 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 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 while china didn't keep the block for long when they try 16:16:56 ggus: I guess they have a different firewall on each network and 4G and 3G are different networks in practice 16:17:16 hmm i see 16:17:18 they might be experimenting with the measure just with 4G and see if they can apply it elsewhere 16:18:00 it is possible that 4g and 3g has different routing route 16:18:18 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 where's the discussion on fully encrypted protocols being blocked in Russia? 16:19:17 nina can translate a short call and add it to ntc party 16:19:44 i just want to link it in the issue 16:19:47 cohosh: https://github.com/net4people/bbs/issues/363 16:20:03 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 (fun with encodings) 16:20:17 thanks! 16:20:22 https://dpidetector.org/en/ 16:20:27 ^cool resource 16:20:49 I learned you can delete the percentencoded slug and it still works https://ntc.party/t/7776 16:21:09 ohh, nice 16:21:15 nice tip 16:22:17 X~X unsure why discourse developers insisted on putting title in the url even it does not work for many languages... 16:22:21 BTW, talking about russia 16:22:31 maybe because google like it... 16:22:34 cloudflare's ECH seems to be blocked already there 16:22:53 I requested ooni to add the couldflare ECH domain to their tests... 16:23:23 shelikhoo: because they only speack languages that use ascii 16:23:24 arturo posted OONI results for cloudflare-ech.com https://github.com/net4people/bbs/issues/393#issuecomment-2462121200 16:23:30 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: oh yes... that's true.. 16:24:06 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 meskio: oh yes... that's true.. 16:24:23 I'm in the process of summarizing these comments on BBS and moving them to a dedicated issue 16:25:07 they are fast, but a pity that an specific test is needed 16:25:09 I think ECH didn't work because it didn't actually make it is still an extension 16:25:32 I think ECH didn't work because it didn't actually make core, it is still an extension 16:25:53 shelikhoo: no, blocking ECH means they have to block all websites that use the same ECH domain 16:25:59 so they have to block most cloudflare 16:26:06 if I understand it correctly 16:26:08 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 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 yes, I kind of expect them to back off when they discover the size of their block, but we'll see 16:27:40 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 let's see... I think they could make some compromise on rtt for better censorship resistance 16:28:58 but big tech obviously wants less rt 16:29:00 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 rtt 16:29:41 also ooni has an open issue, not yet replied, for an ECH nettest https://github.com/ooni/probe/issues/1453 16:29:41 ohh, if retrying becomes common it will be really bad 16:30:12 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 I heard them mentioning they were working on it, I see the issue mentions a PoC 16:31:04 maybe something to report to mozilla 16:32:39 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 if there's nothing else to add on this, let's backtrack a bit to the push notifications point 16:33:00 ahh, that was in the interesting links, ups 16:33:01 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 dcf1: let us know what you find, I only look at very few of them 16:33:30 wow that's a lot of comments, thanks for doing that :) 16:33:38 heh it's ok meskio, we can adjust and be flexible :) hehe 16:33:43 trouble is they seem to be written in some foreign language 16:33:46 300 posts in 2 days 16:33:52 o_o 16:33:54 -.- 16:33:55 thanks... 16:34:22 don't worry... I think at least the content can be copy and pasted to translator 16:34:40 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 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 gitlab.torproject.org/cohosh/push-notification-distributor 16:35:08 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 but it has a different privacy impact than domain fronting 16:35:53 like domain fronting, it's important for the messages to be authenticated and probably encrypted 16:36:03 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 if we could clreate that long lived connection only if domain fronting fails the problem will be solved 16:37:28 my understanding is we don't have control over that 16:37:41 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 for android at least, it's the google services installation that handles that connection 16:37:53 and it's shared across all apps that use push notifications 16:38:01 yes, but there is some kind of client registration process, isn't it? 16:38:12 you don't need to do that if domain fronting works 16:39:00 cohosh: is there a code for the receiving end of the connection? 16:39:21 shelikhoo: there is an onMessage callback you can set 16:39:39 so it is assisted by the OS? 16:39:51 it's assisted by google services 16:40:00 I think this push notification would always exist, we use it or not 16:40:14 which is part of the android distribution i guess 16:40:16 since other service would be using gcm already 16:40:24 yes that's my understand too 16:40:29 *understanding 16:40:48 although I really wants to see the client side code to understand how it actually works... 16:41:02 the code the implement the onMessage callback 16:41:04 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 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 I thought the process was: 16:42:40 1. application registers to receive notifications for that user 16:42:43 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 shelikhoo: here's a partial integration on the client side https://github.com/guardianproject/orbot/compare/master...cohosh:orbot:push-notification 16:42:48 2. application waits for notifications to arrive 16:43:01 but looks a great idea! 16:43:23 are you saying that there is no registration step? 16:43:29 there is a registration step 16:43:47 cool, so we can choose to register or not depending if domain fronting is working 16:43:47 the user would register (using domain fronting or something similar) with our push notification distributor 16:44:02 well, how do we register if domain fronting isn't working? 16:44:07 ohh, wait the registration is offband 16:44:09 the registration happens out of band 16:44:10 yep 16:44:10 ohh, I see 16:44:12 Yes, thanks! Okay I now understood that it is basically based on shared push connection 16:44:32 then yes, you do need to register before domaing fronting stops working 16:44:58 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 *tokens to apps that is 16:45:42 I think they could just ban the account of the developer I guess… 16:46:01 yeah true, that's probably how it would look 16:47:01 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 and there's the point that google claims it doesn't have a mapping of tokens to apps 16:47:54 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 yes... although I have to say I believe google already collect the app users installed 16:48:32 this could be helped by opting into it and informed consent before registering 16:48:56 and apple collect what app user have 'bought(including free apps)' 16:49:16 the good thing is that this use of push notifications has no link to client behaviour 16:49:20 so push notification does not make it easier for them to give info to states 16:49:26 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 because the messages only happen when there are circumvention settings updates 16:49:42 not triggered by the client 16:50:32 I think is a good idea to explore, but we might need to include apps and UX teams on this conversation 16:51:19 yeah, in the case of orbot that would be guardian project 16:52:33 anyway, thanks for the discussion 16:52:43 thank you for playing around with it 16:52:48 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 is there any plan for some work about web push 16:52:52 it's good to figure out what the risks are and if we're okay with running the distributor 16:53:01 but transparency is good at leat 16:53:09 *least 16:53:10 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 cohosh: yes... 16:53:49 I think web push is another thing we could do 16:54:09 that is harder for push providers to ban website than app 16:54:34 as apps requires developers to sign up with push providers, while web don't 16:54:39 eof 16:54:51 anything else to discuss today? 16:55:01 but web push will require that the website we use for pushing notifications is not blocked, isn't it? 16:55:08 as in, we can't do that in torproject.org 16:55:25 no, even localhost would work.. 16:55:50 the registration part can be done out of band 16:56:23 who sends the push notification to the client (or holds the long lived client connection) for web push? 16:56:42 the browser will have its own push connection on desktop 16:56:52 and mobile browser will use os's push 16:56:57 as in mozilla or google chrome will provide that as a service? 16:57:12 yes, they have push connection on desktop 16:57:18 ohhh, I didn't know about that, cool 16:57:34 yes, it is included in browser 16:57:51 and it would be nice to just write once and use on every browser 16:58:34 nice 16:58:37 that is all for me 16:58:40 eof 16:58:46 thanks! same from me 16:59:56 ok thanks everyone! 16:59:59 #endmeeting