15:57:32 <meskio> #startmeeting tor anti-censorship meeting
15:57:32 <MeetBot> Meeting started Thu Feb 29 15:57:32 2024 UTC.  The chair is meskio. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:57:32 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
15:57:36 <meskio> hello everybody!!!
15:57:39 <meskio> here is our meeting pad: https://pad.riseup.net/p/r.9574e996bb9c0266213d38b91b56c469
15:57:39 <shelikhoo> hi!
15:57:41 <meskio> ask me in private to give you the link of the pad to be able to edit it if you don't have it
15:57:43 <meskio> I'll wait few minutes for everybody to add you've been working on and put items on the agenda
15:58:14 <anarcat> interesting pad number, i wonder how that is generated ;)
15:58:53 <onyinyang> ah sorry, I thought I was facilitating this week and changed some things in the pad
15:59:33 <meskio> onyinyang: ahh, that makes sense
15:59:39 <meskio> I saw my name nad I thought was my turn
15:59:41 <meskio> sorry
15:59:45 <onyinyang> no problem
15:59:47 <meskio> I can put you for next week
15:59:51 <onyinyang> sounds good :)
16:00:12 <meskio> anarcat: this is what you get when you put a pad private
16:00:50 <anarcat> ooh, readonly, interesting!
16:00:56 <anarcat> nice, thanks!
16:01:19 <shelikhoo> Oh no...
16:01:38 <shelikhoo> It is probably me put meskio's name last week
16:01:50 <meskio> anarcat: yes, we get often trolls deleting the pad
16:02:56 <shelikhoo> and I am not really following an exact rule when it comes to nominating that
16:03:54 <meskio> I think you did right, onyinyang updated it and I jump after that :)
16:04:17 <meskio> anyway, let's start
16:04:30 <meskio> anything to note on the recent elections?
16:04:45 <meskio> I saw there has being blockades in nigeria and chad
16:05:28 <meskio> the first discussion point:
16:05:30 <meskio> Mysterious reported snowflake issue in China has maybe gone away as of 2024-02-26
16:05:38 <meskio> Mysterious reported snowflake issue in China has maybe gone away as of 2024-02-26
16:05:49 <dcf1> The user who originally reported it, snowflake had not worked for them for a month
16:06:10 <dcf1> They now say that it was started working again, but just barely, worse than meek they say
16:06:10 <meskio> https://github.com/net4people/bbs/issues/325#issuecomment-1963226429
16:06:30 <onyinyang> Nigeria is questionable. There are nationwide union protests going on, but it seems like outages might have been in only a few regions. It's hard to say if it was a shutdown or any number of other things.
16:06:36 <dcf1> Last time we discussed this, we discovered some correlation with 10% bootstrap bridge test restults from china, but we have not gotten to the bottom of it
16:07:21 <dcf1> I rebased my https://gitlab.torproject.org/dcf/snowflake/-/commits/handshake-padding branch and sent that, but it's unclear if it had an effect because it was after it had already started kind-of working again
16:07:55 <dcf1> I don't know what further to do. Just FYI. I do have another round of log files from a user if you want to examine them.
16:08:11 <shelikhoo> I think snowflake is working unreliably for sure, and last time it looks like either ip is in accessible, or dtls handshake couldn't finish
16:08:53 <shelikhoo> but since the remote end isn't directly controlled by us, it is unsure how it is actually block
16:09:05 <dcf1> The last round of logs for sure showed DTLS data channel transfer (got past the handshake), but the connections did not live very long
16:10:57 <meskio> more packet loss maybe
16:11:17 <shelikhoo> the thing we could do include use another broker to see if the connection is blocked by protocol
16:11:44 <shelikhoo> and send/replay udp packets with limited ttl to see where it got dropped
16:12:25 <shelikhoo> both of them requires some time investment
16:12:46 <dcf1> I have definitely gotten contradictory reports though, another tester in China reported to me they had no problems with Snowflake
16:13:10 <dcf1> So just fyi I guess, I don't know what more to do, other than as shelikhoo says, do some dedicated tests from a vantage point
16:14:45 <meskio> if we can't see the problem from a vantage point it might be hard to debug it by asking people to try things
16:15:54 <shelikhoo> https://gitlab.torproject.org/tpo/anti-censorship/connectivity-measurement/bridgestatus/-/blob/dc663e36d7dc81467a63f59c5d435b9f93e9e3ab/recentResult_cnnext#L89
16:15:58 <shelikhoo> Don't worry we can
16:16:25 <meskio> :)
16:16:25 <shelikhoo> it seems snowflake in our vantage point are not always able to bootstrap
16:16:43 <shelikhoo> some time ago, all attempts are failed
16:17:17 <shelikhoo> and in more recent tests, there are some connection via snowflake that were successful
16:19:12 <dcf1> Can you identify a threshold where there was a change? was it 2024-02-26?
16:20:02 <shelikhoo> It should be possible in theory, but it will need some time
16:20:13 <shelikhoo> so I don't have it now
16:20:30 <meskio> on a fast look 2024-02-23 was also failing
16:20:42 <dcf1> That's fair. We of course need to prioritize. 2 users on BBS reported something similar, but that's all I've heard.
16:21:24 <meskio> shelikhoo: what do you think? is it worhit investigate? do you have time for this? or let's keep with other things and look at this in the future if it keeps happening?
16:22:35 <shelikhoo> meskio: I wish to investigate it, and it will be an background task to work on
16:23:02 <shelikhoo> and other tasks with firm deadline will take precedence
16:23:09 <meskio> sounds good, can you open an issue for that? or we could reuse a previous issue, but maybe is too noisy?
16:24:15 <shelikhoo> Yes, I think I could just open a new ticket
16:24:25 <shelikhoo> the old ones are quite noisy already
16:24:39 <meskio> dcf1: that reminds me the unrliable networks work in snowflake was waiting for your review: https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/merge_requests/219
16:24:56 <meskio> this will not solve the bootstrap, but might improve the speed...
16:25:44 <dcf1> I know, I am sorry about not reviewing that yet.
16:26:11 <meskio> don't worry, I understan that things take time, I'm just checking you didn't forget :)
16:26:35 <shelikhoo> don't worry I have other on going tasks as well.., and was not blocked by the review
16:26:56 <meskio> should we move to the next topic?
16:27:25 <shelikhoo> eof from me on this topic
16:27:33 <dcf1> go ahead
16:27:46 <meskio> Unclear whether AWS will allow public disclosure of credentials
16:27:48 <meskio> https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40337
16:27:54 <meskio> cohosh: ??
16:28:34 <shelikhoo> I think correctly scoped token is supposed to be public
16:28:49 <cohosh> yes apparently aws has a way to scrape github repos for iam keys, which we have disclosed itnentionally
16:29:28 <cohosh> and they caught us doing that from mpu's bbs post: https://github.com/net4people/bbs/issues/335
16:29:41 <meskio> I recall reading that github has some service doing that
16:29:52 <cohosh> the problem is that unless we convince them that our use-case is valid, they'll suspend my aws root account
16:30:28 <cohosh> so far i've only managed to convince the front line support person that this disclosure was intentional
16:31:12 <cohosh> they keep saying it's against the terms of service to make it public
16:31:18 <shelikhoo> is there any technological means we could do to avoid being cancelled by aws?
16:31:32 <shelikhoo> let's say base64 encode it?
16:31:39 <cohosh> right now i'm waiting for someone else to take a look at the support case and decide if an exception can be made
16:32:14 <cohosh> shelikhoo: yeah that was my thought too, it might be worth trying
16:32:24 <meskio> :D
16:32:48 <cohosh> i think they also have some anomaly detection in place though, and will notice if many different IPs are using the same key
16:33:03 <cohosh> because that was part of the back-and-forth process
16:33:17 <cohosh> they told me how many different IPs had accessed it and asked if i was using a VPN
16:34:06 <cohosh> the funny thing is, they automatically apply a "quarantine" policy to leaked credentials, but the quarantine policy is less restrictive than the policy that was already applied to these
16:34:32 <dcf1> haha
16:34:47 <meskio> XD
16:34:51 <cohosh> anyway, hopefully this rendezvous method isn't immediately killed by a ToS
16:35:02 <meskio> I have some friends in AWS, I'll ask to see if I can get some inside on this
16:35:13 <shelikhoo> hshaha, I think it designed to "quarantine" unintentional leaks
16:35:44 <meskio> I might need some help to be able to form a coherent question, as I'm not sure I understand what we are doing there
16:36:09 <cohosh> meskio: okay cool :) it's worth trying
16:36:21 <cohosh> the main challenge so far is convincing people that i really did mean to do this
16:36:25 <shelikhoo> we live in a world even view source may break law, so using service in an unintended way is always going to be challenging
16:36:56 <onyinyang> cohosh, do you think aws' ToS would have a reason not to support this usecase and they just never considered it might be used like this?
16:37:36 <cohosh> onyinyang: it's possible they will dislike our usage for the same reason cloud providers dislike domain fronting
16:37:38 <meskio> bringing back dcf1 talk, I wonder if we end up playing an arm's race with the cloud providers
16:37:56 <onyinyang> yeah, that's what I'm wondering
16:38:07 <cohosh> but i don't think we're getting that pushback yet
16:38:23 <cohosh> so far it's just them worried that we're leaking root passwords or accidentally sharing credentials
16:38:38 <cohosh> and it's against their ToS to not properly secure your account
16:39:07 <cohosh> meskio: lol yes
16:39:30 <shelikhoo> they say credit check is to protect people from taking too much debt...
16:39:58 <shelikhoo> so it is more likely AWS just wish to protect themselves in reality
16:40:08 <onyinyang> but a decision to not allow this may not give us more information on the reasons that they actually don't want us to do this. It could be stated as a "just following orders" rather than, we're opposed to you doing this for x reasons.
16:40:30 <cohosh> sure, in the end they will do what is best and less risk for them
16:40:31 <shelikhoo> or "result from AI"
16:40:50 <onyinyang> ugh, yeah shelikhoo
16:41:29 <cohosh> we'll see what happens, i'm waiting for them to respond after explaining why we're using sqs this way
16:42:03 <cohosh> that's it from me on this for now
16:42:06 <meskio> yes, let's see what they respond
16:42:12 <meskio> anything else for today
16:42:35 <meskio> ?
16:42:42 <shelikhoo> eof from me
16:43:13 <meskio> I close the meeting then
16:43:16 <meskio> #endmeeting