15:58:07 <onyinyang[m]> #startmeeting tor anti-censorship meeting
15:58:07 <MeetBot> Meeting started Thu May 18 15:58:07 2023 UTC.  The chair is onyinyang[m]. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:58:07 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
15:58:16 <onyinyang[m]> here is our meeting pad: https://pad.riseup.net/p/tor-anti-censorship-keep
15:58:26 <onyinyang[m]> feel free to add what you've been working on and put items on the agenda
15:58:29 <meskio> hello
15:58:39 <onyinyang[m]> hello! :)
16:00:04 <shelikhoo> o/
16:00:06 <shelikhoo> hi~
16:00:19 <itchyonion> hello
16:04:44 <onyinyang[m]> ok, let's start the meeting
16:05:12 <onyinyang[m]> there are no announcements so the first discussion item is:     Reported blocking of Snowflake in China since 2023-05-12
16:05:12 <onyinyang[m]> https://gitlab.torproject.org/tpo/anti-censorship/censorship-analysis/-/issues/40038
16:05:35 <dcf1> I'll let you read the issue for details, but briefly,
16:06:13 <dcf1> there was reported blocking of the cdn.sstatic.net front domain in China for about 3 days last week.
16:06:34 <dcf1> Two different users commented on the nature of the block, which is interesting and something I don't think we have seen before.
16:07:06 <dcf1> Namely, you only got blocked if you accessed cdn.sstatic.net 2 or more times within about 60 seconds.
16:07:19 <dcf1> One user reported a threshold of 2 for blocking; the other reported a threshold of 3.
16:07:36 <dcf1> Follow the links to https://github.com/net4people/bbs/issues/249 and https://forum.torproject.net/t/snowflake-bridge-does-not-work-in-china-since-days-ago/7635 for more discussion.
16:08:20 <dcf1> It seems like it's stopped for now, but could possibly reoccur at any moment.
16:08:37 <dcf1> I made a list of short- and long-term mitigations at https://gitlab.torproject.org/tpo/anti-censorship/censorship-analysis/-/issues/40038#note_2902981
16:09:24 <shelikhoo> Yesterday, I was discussing with meskio about writing a script to test domain for domain fronting in an automated way, which can be used to find additional domain for domain fronting
16:09:56 <shelikhoo> which can be useful in dealing with censorship in iran and in this case china
16:09:57 <dcf1> We were vaguely worried, when we added a second bridge, that the double rendezvous would be a distinguising feature (tpo/core/tor#40578), and now it may actually have been
16:10:46 <meskio> we could use different domains for each bridge
16:11:01 <meskio> but could be also a recognizable pattern
16:11:17 <cohosh_away> if it's 60 seconds, it might not just be the two bridges triggering it, but also if clients are turned away and have to re-poll the broker
16:11:22 <shelikhoo> or at least be able to switch domains when one of them get blocked
16:11:29 <dcf1> Ideally this is something that would get fixed in tor, but things of this nature are being closed in favor of arti, so IMO we should not count on it ever happening.
16:12:02 <meskio> yes, not sure if we can get it into tor any time soon, but I'll check with network team about it
16:12:08 <dcf1> shelikhoo: apparently, for one of the users at least, the specific domain did not matter. It was 2 requests within 60 seconds with the same SNI to a Fastly IP address.
16:12:18 <arma2> what would the-fix-in-tor look like?
16:12:28 <dcf1> So switching to a different domain would not help, if it was still doing double rendezvous with that other domain.
16:13:04 <shelikhoo> dcf1: yes, if we use different (set)? of fronting domains it would help
16:13:13 <meskio> arma2: AFAIK it will be your merge request to use a single bridge
16:13:21 <shelikhoo> use different fronting domain for different bridges
16:13:27 <dcf1> arma2: in this case, it would look something like tor having a feature to choose just one of the available bridge lines at a time
16:13:36 <arma2> meskio: ah ha. my merge request uses only two bridges. so it will help when we add more than two snowflake servers, but not with only two.
16:13:48 <arma2> meskio: we could set numentryguards 1 for snowflake users i guess, but i think we want two
16:13:55 <dcf1> or, alternatively, support in Tor Browser to dynamically rewrite the torrc file so there's only 1 bridge line. (I think Orbot does something like this already, so it may be easier for them.)
16:14:42 <dcf1> It occurred to me that we could also hack around this in snowflake-client: since we know tor is going to make multiple effectively redundant SOCKS requests,
16:14:59 <arma2> do we know if it is a dns resolve of the front domain, or a tcp connect to it?
16:15:00 <dcf1> we wait at startup and buffer them for 2s, then choose one and only one at random
16:15:09 <arma2> s/it/the blocking trigger/
16:15:12 <dcf1> arma2: it's a TLS SNI, I think
16:15:22 <arma2> fun. ok
16:15:41 <arma2> so the theory is that real browsers will make one tls connection and keep using it. so we are weird to make two in parallel.
16:16:19 <shelikhoo> https://www.speedguide.net/faq/tweak-the-maximum-concurrent-connections-in-firefox-231
16:16:19 <cohosh_away> yeah, i would expect that two simultaneous connections to fastly to be common but maybe browsers are really that good at always reusing the same tls connection
16:16:26 <dcf1> Observing DNS queries *has* been proposed in a research paper, though: https://www.mdpi.com/2076-3417/13/1/622#sec4dot1-applsci-13-00622
16:16:50 <shelikhoo> I think for browsers, it is not uncommon to have more than one connection
16:17:14 <dcf1> cohosh_away: I think the opposite, browsers will open up to their limit of parallel TCP connections. Maybe it's different with HTTP/2, still though I agress that 2 connections is probably not uncommon.
16:17:20 <dcf1> This is maybe why it's turned off now.
16:17:47 <arma2> so if 2 connections is not uncommon, are they causing collateral damage? and maybe that's why they stopped?
16:17:51 <shelikhoo> https://kb.mozillazine.org/Network.http.max-connections-per-server
16:18:06 <dcf1> I tried settings MaxConnsPerHost=1 in snowflake-client, and interestingly it still does a double rendezvous, but to 2 *different* IP addresses rather than the same IP address twice.
16:19:00 <arma2> shelikhoo: i would expect those browser params to be for http but not https
16:19:15 <cohosh_away> is this the first inter-connection block pattern we've seen?
16:19:22 <cohosh_away> (that we know of)
16:19:37 <dcf1> cohosh_away: hm, yes, maybe
16:19:42 <arma2> it is the first i have heard of
16:20:25 <cohosh_away> and perhaps the first stateful block pattern?
16:20:51 <cohosh_away> i guess we don't know how the potential obfs4 blocking was working
16:21:09 <dcf1> If it happens again, one quick mitigation I recommend trying is setting just 1 bridge in Connection Assist for cn.
16:21:19 <meskio> yes, that can be easily done
16:21:46 <meskio> we could modify rdsys to provide a different one each time so not everybody goes to the same bridge...
16:22:07 <shelikhoo> or we can just provide the second bridge
16:22:18 <meskio> yes, that will work for now as it has less load :)
16:22:19 <shelikhoo> which have less user than the primary one
16:22:24 <shelikhoo> yes
16:22:31 <dcf1> yes, if you pick one, pick snowflake-02, which is only at about 50% capacity vs. snowflake-01 at 100%
16:23:34 <onyinyang[m]> thanks for bringing this up dcf1 :) should we move on to the next topic now or is there more to discuss?
16:23:41 <meskio> for next time doing the change it takes me few mintes, I just missed the issue on my long pile of tickets, feel free to poke me directly for it
16:24:04 <dcf1> onyinyang[m]: that's all
16:24:23 <onyinyang[m]> ok. The next topic is:     Update on Analysis of speed deficiency of Snowflake in China, 2023 Q1 https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40251#note_2883879
16:24:58 <shelikhoo> There is currently an ongoing discussion about this on gitlab, please have a look
16:25:01 <arma2> (thought on previous topic: i wonder if we want to ask ooni to do a triple-connect test for us or something)
16:25:16 <shelikhoo> we will discuss it in more detail next week
16:25:22 <shelikhoo> let's skip to the next topic
16:25:42 <dcf1> appreciate you writing and posting the design proposal shelikhoo
16:25:54 <onyinyang[m]> sure shelikhoo
16:26:04 <onyinyang[m]> the last discussion topic is:     Research about designing an armored bridge line sharing URL format
16:26:04 <onyinyang[m]> https://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/126
16:26:12 <shelikhoo> yes, I was writing an reply for your comment dcf1...
16:26:49 <meskio> arma2: I think we should try to keep ooni's snowflake test as close as we can to what TB is doing
16:26:50 <shelikhoo> There is a pending design for a new armored bridge line format ready for discussion
16:27:37 <shelikhoo> let's discuss it mostly in anti-censorship team's meeting until it is more polished, and purpose it to other teams
16:28:14 <arma2> meskio: right, not the snowflake test, but a separate thing. like their current https connectivity test but another one.
16:28:37 <shelikhoo> there is a lots of optional transform step we can decide to include or not
16:29:10 <shelikhoo> and we can decide it now, which kind of transform step should not proceed to the next round of discussion
16:29:12 * arma2 runs off to airplane
16:29:48 <shelikhoo> bye arma2~
16:30:01 <shelikhoo> over
16:30:28 <onyinyang[m]> shelikhoo: ok, that seems reasonable. Does anyone have opinions about what should not proceed to the next round of discussion?
16:30:47 <onyinyang[m]> safe trip (I assume) arma2
16:30:49 <meskio> shelikhoo: thank you for the proposal, and to bring a lot of cool ideas on things to do
16:31:17 <shelikhoo> no problem, meskio ~ ^~^
16:31:50 <shelikhoo> I will also actually do some of them soon...
16:31:51 <meskio> I have some doubts about AONT step, I didn't even know about that construct, how common are those? I mean, will implementors find easily implementations to use in any language?
16:32:26 <shelikhoo> One can implement it with common crypto libraries, but as far as I can tell it is not common
16:32:41 <meskio> I think we should aim for something easy to implement, that is traight forward
16:33:02 <meskio> that is what makes me think that AONT might not be worth it, but are cool propierties...
16:33:53 <shelikhoo> do we wants some other methods to make sure encoded bridge line have more than one representation?
16:34:37 <meskio> my first hunch is that this is not so important, but I'm not sure
16:35:11 <shelikhoo> let's say we can encrypt it AES-SIV
16:36:36 <shelikhoo> in many apps censorship is implemented with simple string match
16:36:58 <meskio> they could string match our method or domain name...
16:36:59 <shelikhoo> if one bridge lone happen to have a particular keyword in it
16:37:05 <shelikhoo> https://twitter.com/felixonmars/status/1658115169355014147
16:37:12 <shelikhoo> oh, yes
16:37:32 <shelikhoo> okay then it is no necessary
16:37:44 <shelikhoo> we already have something to be recognized
16:37:58 <shelikhoo> let's don't have AONT step
16:38:03 <shelikhoo> what about other steps
16:38:27 <shelikhoo> do we wants forward error correction? it would make things more complex
16:38:29 <meskio> I think compresion makes sense and obviously checksum
16:38:36 <meskio> not sure aobut forward error correction
16:38:50 <meskio> exactly it will make it more complex
16:39:02 <meskio> and being able to detect that is not a valid bridge might be enough
16:39:40 <itchyonion> agree, unless it's easy to implement forward error correction
16:39:43 <itchyonion> "more than one representation" this is for the text portion of the armoured bridge?
16:40:52 <itchyonion> I thought we are not trying to prevent the bridge line from being censored or detected by authority, so the keyword search mitigation wouldn't be of concern for this design?
16:41:24 <shelikhoo> yes, the advantage of forward error correction is that when the bridge line is corrupted, the user can still get the bridge. otherwise they might repeat the step to get the bridge(which could still be corrupted if there is an issue with tooling)
16:41:46 <shelikhoo> itchyonion: yes, I was reminded of the bridge line have a keyword in it already
16:41:54 <shelikhoo> so AONT is ditched
16:42:23 <meskio> if we decide to do forward error correction it would be nice if is optional to implement, in a sense of: "you can ignore the X last bytes and still decode the bridge correclty"
16:43:56 <shelikhoo> meskio: it will be possible to do that with systemic coding(like reed solomon), and we are doing that
16:43:59 <itchyonion> is it practical to do both? Forward error correction for TB and an easy one for the other Tor clients that uses the bridge line?
16:44:46 <shelikhoo> however, the client will still need to parse the bridgeline into chunks and read meta data
16:45:07 <shelikhoo> of each chunk to recover the original message
16:45:27 <shelikhoo> and there is already reed solomon libraries
16:45:36 <onyinyang[m]> shelikhoo: would it be ok to continue this discussion in #tor-anticensorship:matrix.org so we can get through the interesting links and reading group discussion seeing as there are less than 15 minutes or should we prioritize this discussion and shift the other two items?
16:46:00 <shelikhoo> yes, let keep discuss this in the ticket
16:46:07 <meskio> +1
16:46:10 <onyinyang[m]> ok.
16:46:10 <dcf1> The last discussion point on bridge churn I just entered does not need discussion, I just wanted to enter some links to references into the record
16:46:39 <onyinyang[m]> oh thanks dcf1 ! I will take a look at those :)
16:47:06 <onyinyang[m]> In the Interesting Links we have:     Unofficial(?) Snowflake extension for Safari in Apple App Store?
16:47:06 <onyinyang[m]> https://apps.apple.com/us/app/torproject-snowflake/id1597501940
16:47:06 <onyinyang[m]> Previously noted at https://lists.torproject.org/pipermail/anti-censorship-team/2022-February/000222.html
16:47:32 <itchyonion> no new updates AFAIK
16:47:39 <onyinyang[m]> I think we have gotten in touch with the developer and have asked them to join the meeting at some point--so we hope to hear from them at some point :)
16:47:53 <itchyonion> yes
16:48:07 <onyinyang[m]> Ok, finally the reading group discussion on Lox.
16:48:24 <onyinyang[m]> "Lox: Protecting the Social Graph in Bridge Distribution" on 2023 May 18
16:48:24 <onyinyang[m]> https://cypherpunks.ca/~iang/pubs/lox-popets23.pdf
16:48:47 <dcf1> I read it :) Thanks onyinyang[m], it's really good.
16:49:10 <meskio> yes, is pretty good
16:49:21 <onyinyang[m]> Thanks dcf1 and meskio
16:49:51 <onyinyang[m]> As a very very brief summary, the paper outlines Lox, a new privacy-preserving, reputation-based bridge distribution system. Lox uses anonymous credentials to preserve a user's reputation while maintaining their anonymity throughout their interactions with the Lox bridge distributor.
16:50:21 <dcf1> I like you putting costs/benefits to the censor on a quantifiable basis in Section 2.4.1, "forces the censor to make a tradeoff between gaining trust and keeping bridges unblocked"
16:50:57 <dcf1> Lox takes the idea of user levels from Salmon, and uses a kind of cryptographic credential from Hyphae
16:51:24 <dcf1> And it also makes explicit the idea of "inheritance" (Section 2.4.2 that was implicit in Salmon
16:51:36 <onyinyang[m]> Yes!
16:52:07 <dcf1> Let me check my intuition: users are supposed to get bridges in the official way via the bridge distributor
16:52:24 <dcf1> but there is nothing technically to stop them sharing that bridge information out-of-band with others they know
16:52:45 <dcf1> the thing that prevents them from doing so is the risk to their own reputation, if the bridge gets discovered and blocked?
16:53:42 <onyinyang[m]> that is correct.
16:54:22 <onyinyang[m]> And additionally the opportunity to migrate to new bridges once bridges are blocked is meant as an incentive to use Lox
16:54:45 <dcf1> there's some aspects that are assumed to exist and to be plugged into the Lox system, which is what you're doing now with integration
16:55:06 <dcf1> like for example you need a signal when a bridge has been blocked, and to realize that somehow
16:55:40 <dcf1> my impression of the model in the paper is that bridge operators are trusted(?) to report their level of use, and when it goes to zero that indicates a block?
16:55:43 <onyinyang[m]> yes. There are many missing pieces that make the full system tricky in practice, blocking being a major sticking point.
16:55:44 <cohosh_away> that luckily exists with rdsys
16:55:54 <cohosh_away> https://gitlab.torproject.org/cohosh/rdsys-backend-api
16:56:15 <dcf1> I realize there are many many ways that could be done, but my question is more general:
16:56:30 <cohosh_away> or rather telling whether bridges are gone does
16:56:33 <cohosh_away> not blocked
16:56:54 <dcf1> is there anything like "hoarding" bridges, creating an account and keeping it idle to get good bridges, then perhaps resell them?
16:57:23 <dcf1> I am thinking about how markets exist around aged e.g. reddit and twitter account, since age is a marker of non-maliciousness
16:57:35 <onyinyang[m]> hmmmm that's an interesting question
16:57:51 <onyinyang[m]> I suppose that could happen
16:58:02 <dcf1> Maybe it's not actually a concern, i.e., if people are selling their bridge addresses, who cares, as long as they are doing so responsibly and not getting them blocked?
16:58:18 <shelikhoo> (I have already discussed anti-replay window and new-bridge-should-be-considered-most-valuable concern in in-person meet up)
16:58:45 <meskio> but AFAIK an old lox account only gives you more invites, that will inherite what you do
16:58:45 <shelikhoo> I think for censor, they can also keep unlimited amount of account and wait for them to mature
16:58:52 <meskio> so for a censor is not so great
16:59:06 <shelikhoo> until 3 bridges are assigned to it
16:59:45 <onyinyang[m]> oh I guess the meeting time is actually over
16:59:47 <dcf1> yes, but in that case there is the tradeoff involved, the censor has to keep the bridge unblocked in order to mature the account
16:59:56 <onyinyang[m]> I can end the meeting and we can keep discussing here?
17:00:04 <dcf1> I'm just thinking of actors with motivations other than censorship. It's a little off the wall, I admit.
17:00:07 <onyinyang[m]> or in #tor-anticensorship:matrix.org
17:00:34 <cohosh_away> onyinyang[m]: i think it's ok to keep the meeting going
17:00:45 <shelikhoo> reselling the account is actually the same as reselling the bridge line
17:00:49 <onyinyang[m]> ok :) let's keep going for a few more minutes and reassess
17:01:09 <shelikhoo> since once the account is matured, it does not give you any additional bridges
17:01:20 <shelikhoo> until one of them is blocked
17:01:56 <dcf1> I just had a couple more questions.
17:02:00 <cohosh_away> " you need a signal when a bridge has been blocked, and to realize that somehow" -> just to follow up on this, i think it's one of the hardest parts
17:02:09 <cohosh_away> we had some discussion during the meeting about it
17:02:22 <cohosh_away> and the idea we landed on was to do a limited trial focused on one region
17:02:38 <dcf1> What happens if there is a catastrophic loss of the database of spent IDs? (Section 4.2.1) Does that mean rebooting the system with new well-know distributor keys?
17:02:41 <cohosh_away> and deploy a bridge tester there to get some kind of ground truth
17:03:09 <dcf1> cohosh_away: I see, thanks. In different deployment models it might be different
17:03:32 <cohosh_away> what do you mean by different deployment models?
17:03:36 <dcf1> like I'm thinking this could be really useful for VPNs, who besides having a lot more ndoes than Tor does bridges, also own+trust their own nodes
17:03:39 <onyinyang[m]> dcf1: I think its an interesting point. It could be abused, even in a really off the wall scenario, by censors to sell "good" connections to select people for exorbitant amounts as a "VPN" or something. . .
17:03:49 <dcf1> so bridge self-reporting of blockage would be sufficient for them.
17:04:07 <cohosh_away> ah yeah, i was curious about self-reporting
17:04:21 <cohosh_away> and whether it's possible to mailiciously report blockages
17:05:23 <dcf1> Second, I know it's early stages, but Lox could be really big if the rquired legwork is done to get it to the attention of VPNs or other possibly interested parties
17:05:52 <dcf1> I'm thinking of refraction networking and how that team put in a ton of effort building relationships with ISPs, etc., and it has paid off
17:06:07 <dcf1> in the form of Conjure integration in Psiphon
17:06:24 <dcf1> what I'm saying is, don't be afraid to dream big, if that kind of thing interests you
17:06:24 <onyinyang[m]> dcf1: in the case of catastrophic loss of spent IDs, by well-known do you mean rotated and publicly committed to?
17:07:14 <dcf1> onyinyang[m]: Um, I'm not sure. I'm talking about the "Φ is revealed so the LA can add it to its database of speng IDs"
17:07:43 <dcf1> That database needs to persist forever, otherwise some kind of replay is possible, I presume? Sorry I don't have all the details paged in just now.
17:08:03 <shelikhoo> i have discussed the idea about anti-replay window for the spent id
17:08:29 <shelikhoo> so any token don't valid forever, and have to be refreshed in a given time period
17:08:49 <shelikhoo> so we don't keep a log of all consumed spend id
17:08:51 <dcf1> If someone does a DROP TABLE on it, does that mean rebooting the system? Or is some less drastic recovery possible?
17:09:05 <dcf1> I guess shelikhoo has proposed an alternative.
17:09:13 <onyinyang[m]> dcf1: yes, the database has to persist forever is the right idea, but we can also rotate the keys at some point so that doesn't need to happen
17:09:20 <cohosh_away> shelikhoo: yeah i really like your idea there
17:09:45 <shelikhoo> my version don't prevent drop the table incident, just don't need to data we need to keep forever
17:10:03 <onyinyang[m]> dcf1: also thanks for the vote of confidence re: dreaming big :)
17:10:12 <shelikhoo> my version don't prevent drop the table incident, just don't need to keep data forever
17:11:00 <dcf1> My last note may not make sense, I was wondering if there's a way to bind Lox credentials with bridge access, like
17:11:27 <shelikhoo> this is also why a lot of proxy proxy protocol need correct system time, this is used to avoid the need to keep used nonce forever for anti-replay
17:11:38 <dcf1> probe-resistant proxies incorporate some kind of shared secret (e.g. shadowsocks, obfs4) so that the IP address and port are not sufficient information to use the proxy,
17:11:51 <shelikhoo> shadowsocks don't have this, and basically replay is unpreventable
17:12:15 <dcf1> is there a way that the proxy itself, separately from the LA, could somehow use the credeitnals to ensure that access was granted through an official channel?
17:12:23 <onyinyang[m]> hmmmmmmm
17:12:32 <onyinyang[m]> another interesting question
17:12:35 <cohosh_away> dcf1: ooo cool
17:12:44 <dcf1> shelikhoo: shadowsocks does have a little bit, in the form of the password. it's not cryptographically very sound, but that's what the password is supposed to try to be doing.
17:12:58 <shelikhoo> and that token can also be copied
17:13:18 <onyinyang[m]> thinking about it for just the time since you posed the question, that would be very cool dcf1
17:13:35 <shelikhoo> dcf1: I was replying to the issue about spent id, not auth
17:13:37 <dcf1> hmm okay, I'm glad it was a meaningful question :)
17:13:48 <dcf1> shelikhoo: ok
17:14:11 <shelikhoo> i think it is not possible to restrict an client from sharing the bridge access, unless
17:14:26 <shelikhoo> we include the client ip address in the credential
17:14:43 <shelikhoo> so as soon as the client change ip address, a new credential is needed
17:14:59 <dcf1> shelikhoo: well, maybe it's possible that there is no way to share access to a single bridge you know, without also effectively sharing access to your entire account, and putting all the bridges you know at risk.
17:15:31 <dcf1> Or something like that, I am not fluent enough with this crypto.
17:15:46 <cohosh_away> hmm, what threat specifically would this prevent?
17:15:58 <shelikhoo> yes, anyway this would need to change the proxy to include an authentication system
17:16:02 <cohosh_away> because someone could still just publish ip addresses to be blocked
17:16:17 <cohosh_away> and you don't need a secret to block an ip, just to confirm it's a tor bridge
17:16:40 <cohosh_away> which maybe makes the case for it because you don't want collateral damage with fake bridge addresses
17:17:05 <dcf1> Yes I admit my thoughts on this are not too clear
17:17:34 <cohosh_away> i guess it could enforce assumptions on who has access to the bridge
17:17:39 <shelikhoo> for tor's use case it is not necessary to authenticate client to a specific user to prevent sharing
17:18:08 <shelikhoo> since there is no billing
17:18:22 <cohosh_away> i'd be more interested in it for this use-case:
17:18:46 <onyinyang[m]> My thoughts were more in the direction of some password or credential authenticated PT to go along with the bridge. This would probably have to be a brand new PT though so it's not a small problem afaict.
17:19:05 <onyinyang[m]> I'm not sure if this is the direction in which you were thinking dcf1
17:19:10 <shelikhoo> it can be added to webtunnel
17:19:18 <cohosh_away> the bridge collects metrics on its own use so that we could use those usage metrics to determine a) whether that bridge is in use by lox users or if it's idle, and b) whether it has been blocked (judged by a single user dropping out suddenly)
17:19:22 <dcf1> that's what I mean, I know existing bridge protocols do not work that way, I'm just wondering if there are any advantages to bridges that are Lox-aware and integrated
17:19:35 <shelikhoo> but I doubt this would be necessary
17:20:06 <shelikhoo> since blocking only require the network address part
17:20:20 <dcf1> Like, here's a strawman idea
17:20:20 <cohosh_away> like we have existing usage metrics, but these bridges probably arent' getting enough usage for them to be reliable determinators of blocking events
17:20:51 <dcf1> suppose the bridge auth uses one-time tokens, there are millions of valid tokens but each one can only be used once
17:21:16 <dcf1> the LA knows the valid token for each bridge, but to get one you have to talk to the LA and prove your credential
17:21:38 <dcf1> the bridge would enforce the one-timeness of the access tokens
17:22:13 <dcf1> in a situation such as this, it would be impossible to just email the bridge access information to someone else, without giving them all your crendentials needed to access the LA
17:23:03 <dcf1> there may be more efficient ways to do this that don't require a round-trip to the LA for every access to the bridge, but making the bridge protocol aware of Lox credentials or some kind of derived information
17:24:11 <dcf1> But let's not get off track, the questions I'm asking may not be well-formed
17:25:09 <onyinyang[m]> We considered changes to the bridge operators as being an additional way to improve the current situation, something similar-ish to what you're describing but with the bridge operators providing tokens to users to prove that they are actually using the bridges (it was also not very well formed)
17:25:36 <shelikhoo> is there anything specific objective wish be achieved with this?
17:25:56 <shelikhoo> is there any specific objective wish be achieved with this?
17:25:59 <dcf1> no, shelikhoo
17:26:00 <onyinyang[m]> we didn't go this route because we didn't want to have to require bridge operators to update/run an entirely new bridge in order to have some kind of working system
17:26:24 <shelikhoo> I understand this is very attractive for commercial VPN providers
17:26:35 <onyinyang[m]> but it doesn't mean that the system couldn't be improved with something like this.
17:26:42 <shelikhoo> as this prevent trivial sharing
17:27:08 <cohosh_away> onyinyang[m]: yeah that's the use-case i find interesting (some interaction with credentials to determine bridge usage and/or blocking events)
17:27:15 <shelikhoo> although in reality I doubt the user will be afraid to just share the lox account
17:27:26 <onyinyang[m]> We wanted to see if we could tie reputation to actual bridge use, which would be more likely to correspond with a genuine user than a censor, we thought.
17:27:27 <shelikhoo> since it is something you can just get another
17:27:51 <cohosh_away> it sounds like that's something that could be achieved in a similar way to dcf1's idea
17:27:54 <shelikhoo> oh, yes... determine if the user is actually using the bridge
17:28:42 <onyinyang[m]> cohosh_away: yes, I think so
17:28:57 <shelikhoo> then it could be an optional hint send to the bridge, which the bridge may submit to LA to indicate the bridge is being used
17:29:00 <cohosh_away> i gotta head out~ thanks onyinyang[m] for the awesome paper, and i'm excited for this integration with tor :D
17:29:09 <onyinyang[m]> ok well, we are now 30 minutes over meeting time 😅
17:29:44 <shelikhoo> although by design, the bridge might not be able to associate this back to the lox account
17:29:53 <onyinyang[m]> so we should probably end the meeting, but happy to discuss this in more detail anytime! Feel free to send me a message about it if you're interested in discussing further :)
17:29:59 <shelikhoo> see you cohosh_away...
17:30:59 <shelikhoo> yes, I think we can discuss this in an issue or another channel
17:31:03 <onyinyang[m]> shelikhoo: right, and I'm not sure we'd want the association to the Lox account tbh. _A_ Lox account is one thing, but _The_ Lox account definitely has anonymity problems :)
17:31:11 <onyinyang[m]> Anyway, let's end it here
17:31:19 <onyinyang[m]> #endmeeting tor anti-censorship meeting