15:59:23 <phw> #startmeeting anti-censorship team meeting
15:59:23 <MeetBot> Meeting started Thu Jun 11 15:59:23 2020 UTC.  The chair is phw. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:59:23 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
15:59:34 <phw> here's our meeting pad: https://pad.riseup.net/p/tor-anti-censorship-keep
15:59:46 <cohosh> hi
15:59:47 <agix> hi
15:59:51 <antonela> hi
15:59:52 <hanneloresx> hi everyone
16:00:00 <AlwaysLivid> o/
16:00:07 <DuckSoft> o/
16:00:17 <gaba> o/
16:00:23 <studentmain> hi
16:00:24 <Shelikhoo> Hi
16:00:32 <phw> today's announcement is that the trac -> gitlab migration is happening tomorrow, on friday
16:00:53 <phw> ahf sent an email to tor-project@ with everything we need to know about it
16:00:54 <phw> https://lists.torproject.org/pipermail/tor-project/2020-June/002866.html
16:02:06 <juggy> hi
16:02:27 <phw> that's it for today's agenda :) anything else on anyone's mind?
16:02:53 <cohosh> there's the ooni internet measurement village talks
16:03:08 <cohosh> if anyone wants to join they are public
16:03:08 <tomcat> cohosh: yeah
16:03:15 <cohosh> https://ooni.org/post/2020-internet-measurement-village/#schedule
16:03:50 <agix> nice
16:04:09 <juggy> Hi, I'm thinking of helping our for some small tasks similar to hanneloresx , are there any for me to take care of? (I studied BridgeDB and Twisted a bit in preparation for google SoC, so I could help for some small things there too)
16:04:45 <cohosh> juggy: awesome :)
16:05:33 <AlwaysLivid> i'm currently working on a distributor for gettor and i'm close to bringing up an "initial" version of the bot public in a few minutes.
16:05:51 <AlwaysLivid> do any of you have accounts on telegram right now?
16:05:54 <cohosh> juggy: by similar, do you mean translation tasks or are you looking for coding tasks?
16:06:06 <juggy> Coding tasks :)
16:06:19 <juggy> Originally I wanted to help beef out the docs with some sort of technical overview of BridgeDB for laymen, but there are talks of re-architecting it? So not sure if that would be the best use of my time
16:07:22 <cohosh> ah yeah this is a bit tricky since we are trying to decide how to move forward
16:07:51 <cohosh> (also nice work AlwaysLivid on the telegram distributor :D)
16:08:15 <phw> juggy: if you're interested in continuing to work on bridgedb, then i can compile a small list of tickets that can get you started
16:08:19 <cohosh> juggy: i think bridgedb (the current version) will still exist for a while even if we decide to work on a replacement
16:08:49 <AlwaysLivid> Bringing the bot live in a second.
16:08:56 <juggy> phw: Thanks, that'll be great!
16:09:02 <juggy> cohosh: Ah
16:09:40 <AlwaysLivid> It works!
16:09:41 <phw> juggy: i think the technical overview would still be useful. someone recently pointed out the sorry state of our current docs: https://blog.torproject.org/comment/288198#comment-288198
16:10:26 <phw> a good place to put extra documentation would be bridgedb's info page at https://bridges.torproject.org/info
16:10:43 <phw> but focus on whatever you find interesting. if that's programming instead of documenting, then that's totally fine
16:11:14 <cohosh> AlwaysLivid: :D can you update #22011 with info on how to try it out?
16:11:22 <juggy> Hmm, I guess I could do programming tasks, and along the way gain enough knowledge to beef out the docs
16:11:38 <AlwaysLivid> cohosh, right now, I'm not hosting it on a server or anything, so I doubt that it'll be reliable in any way whatsoever.
16:11:40 <phw> juggy: sounds like a good plan! these things go hand in hand anyway
16:13:37 <cohosh> AlwaysLivid: that's okay. whatever updates/code you have would be great to see on that ticket
16:14:02 <phw> hanneloresx: hi! how's your "reading up on things" going? anything that we can help with?
16:14:47 <AlwaysLivid> Good. I just pushed a latest commit. I had a few interesting ideas regarding gettor and I think I've kept up cohosh up to date about them, not sure if this is interesting enough to the channel.
16:15:00 <dcf1> small point of order: I have someone trying to join for the reading group using https://webchat.oftc.net/?channels=tor-meeting , but it says "Cannot join channel (Need to be identified and verified to join this channel)"
16:15:51 <hanneloresx> phw, thanks for asking!  i tried read up on everything on our pad and team page and all the links haha, so at least i know where all the info live now
16:16:05 <phw> dcf1: that may be a (temporary?) anti-spam thing. arma2: ^
16:16:36 <hanneloresx> i took a look at our blog, seems straightforward enough, if you can send the June one to me in draft I can aim to translate with 2-day turnaround
16:17:18 <hanneloresx> agree that we could use more documentation for lay people though :) so happy to help on that front, too
16:17:39 <hanneloresx> maybe even tutorials or the like
16:17:45 <phw> hanneloresx: very nice, thanks! i've been working on a blog post that summarises the state of tor in china, ie, what it takes to get it to run. that would be a perfect post to translate too
16:18:24 <hanneloresx> perfect! please feel free send to me when you've got a draft. I'll email you so you have my contact
16:18:33 <phw> (we should also have a plan for where to publish it. blog.torproject.org won't be very helpful because it's blocked in china)
16:18:36 <phw> will do, thanks!
16:18:42 <agix> dcf1: it could be that the nick needs to be registered first to be able to join
16:18:42 <cohosh> AlwaysLivid: a good first place for gettor design ideas will be in tickets. we have this gitlab migration over the weekend so that might make it a bit chaotic until we've ironed out the gitlab workflow
16:19:05 <AlwaysLivid> understood
16:19:09 <cohosh> dcf1: i asked internally to lift the requirement, but am not sure how quickly that will be addressed
16:19:25 <AlwaysLivid> i think one of gitlab's biggest advantages is their integrated ci/cd
16:19:35 <AlwaysLivid> i think that's available in free tiers as well iirc
16:19:56 <AlwaysLivid> would be interesting to think how one could take advantage of that, considering that there are mechanisms put in place already
16:20:00 <AlwaysLivid> (afaik)
16:20:14 <cohosh> dcf1: here's the beginner resource on how to register https://trac.torproject.org/projects/tor/wiki/org/onboarding/IRC#Advancedbeginners
16:21:58 <antonela> hi, can i quick update on some ux stuff for s30?
16:22:09 <phw> antonela: yes, i was about to ask. please do!
16:22:24 <antonela> thanks for your review on #31282! i'll bring this to the browser meeting next week so we can get some reviews from the browser folks before moving forward. Given that this team capacity has been intact and the browser one has been reduced, i want to make sure we agree on what is doable for the next stable release
16:22:45 <antonela> about #32811 besides the notes from the interviews, duncan did an amazing job linking ooni reports from the targeted countries to backup the information we are actually rendering in the profiles
16:22:52 <antonela> it is a work in progress and he will probably join this meeting next week to share the progress and open it for feedback.
16:23:00 <antonela> this one #31283 needs review and i wonder if you have any thoughts on it or if we can move forward with that framework/scope
16:23:07 <antonela> and
16:23:13 <antonela> also this week, as part of S58 i discussed with sysrqb how we can have a better workflow with tba bundles to improve the way we are calling for testing
16:23:20 <antonela> I want to have this workflow in a good place for when we are going to call for testing for snowflake in tba
16:23:31 <antonela> which we discussed to run after the tb release, probably this month
16:24:01 <phw> (i commented on #31283 yesterday)
16:25:34 <antonela> okey, is the other one #31282 \
16:25:43 <phw> tba = tor browser alpha or tor browser for android?
16:25:51 <antonela> tor browser for android
16:25:53 <phw> okay, i'll take a look at #31282!
16:26:20 <antonela> awesome, thank you
16:27:03 <phw> what meeting log should i read to catch up on your workflow discussion?
16:27:30 <antonela> this one http://meetbot.debian.net/tor-meeting/2020/tor-meeting.2020-06-09-16.02.log.html
16:29:02 <cohosh> antonela: nice, thanks for reaching out about the workflow
16:29:58 <antonela> is good, i hope we can make it works
16:30:49 <phw> ok, so my todo list is 1) read the workflow log and 2) review #31282. is there anything else antonela?
16:31:22 <antonela> if you want to read our progress in personas, there is a wip .csv file on what we are thinking are the profiles emerged from the interviews
16:31:38 <antonela> as i said, duncan will probably join us here next week to share a first version for review
16:31:44 <phw> where can we find the .csv?
16:32:03 <antonela> https://trac.torproject.org/projects/tor/attachment/ticket/32811/new-persona-notes.csv
16:32:10 <phw> thanks
16:33:02 <antonela> np
16:35:00 <phw> ok, anything else before we move on to assigning reviews?
16:36:13 <antonela> im groot
16:36:14 <antonela> thank you
16:36:38 <phw> moving on to reviews. i have #33835 and cohosh has #34129
16:36:48 <phw> i think that's it. agix, do you mind taking another look at #33835?
16:37:17 <agix> already did :) finished with the review about an hour ago
16:37:19 <phw> (it's just a small revision + unit tests)
16:37:28 <phw> oh, nice!
16:37:34 <dcf1> I will look at #34129
16:38:10 <cohosh> thanks
16:39:01 <phw> we're done with our anti-censorship agenda for today. next up is our meeting group about v2ray. is there anything else to discuss before we start the reading group? don't be shy!
16:40:22 <phw> *crickets* means we should start with our reading group
16:40:29 <dcf1> I can lead the discussion on V2Ray
16:40:32 <phw> dcf1: did your guest manage to join?
16:40:33 <phw> thanks
16:40:39 <Shelikhoo> Hi, I am xiaokangwang aka Shelikhoo. I am currently one of the developers maintaining the V2Ray project.
16:40:43 <dcf1> Yes I think we are connected now.
16:40:49 <phw> Shelikhoo: very cool, welcome!
16:40:57 <dcf1> We are honored to have Shelikhoo with us, who knows more about V2Ray than I do.
16:41:09 <dcf1> Let me paste a short summary and a few links to get started.
16:41:16 <dcf1> V2Ray (or V2Fly) is a platform for deploying proxy protocols. It is possible to configure it for circumvention purposes.
16:41:25 <dcf1> There's a basic summary here: https://github.com/net4people/bbs/issues/36
16:41:37 <dcf1> V2Ray has an interesting layered architecture, divided into "proxy" and "transport" layers.
16:41:45 <dcf1> You can compose any proxy (SOCKS, Shadowsocks, VMess...) with any transport (TCP, QUIC, WebSocket...). Some transports have their own additional obfuscation op
16:41:48 <dcf1> tions.
16:42:03 <dcf1> VMess was the first proxy protocol supported by V2Ray. It is an authenticated look-like-nothing protocol similar to ScrambleSuit, obfs4, or Shadowsocks.
16:42:18 <dcf1> There are currently changes being made to VMess in response to recently discovered replay / active probing vulnerabilities:
16:42:29 <dcf1> https://lists.torproject.org/pipermail/anti-censorship-team/2020-June/000104.html https://pad.riseup.net/p/64MatYTvPX5_xvPCF-uz
16:42:45 <dcf1> (end summary)
16:43:24 <dcf1> So one thing you may notice is that both the name V2Ray and V2Fly are used. My understanding is that this is due to a github/domain ownership problem, and that future work is going ahead under the v2fly organization.
16:44:34 <Shelikhoo> Yes, that's right. The original developer of V2Ray disappeared with a lot of management rights with her.
16:44:45 <dcf1> There's a large and active development and research community around it. Discussion threads with hundreds of comments, etc. It can be hard to follow without being a Chinese speaker, but there is a lot happening, e.g. at https://github.com/v2ray/discussion/issues/704
16:45:27 <dcf1> I get the impression that v2ray is starting to fill the space occiped by Shadowsocks, as detection attacks against Shadowsocks get more sophisticated.
16:45:48 <dcf1> But really it's not a 1:1 comparison, as v2ray can use Shadowsocks directly, as one of its supported proxy protocols.
16:46:38 <dcf1> I had only heard about v2ray before; I tried setting it up for the first time this week.
16:48:02 <phw> while reading the faq at <https://guide.v2fly.org/en_US/#frequent-questions-q-a>, i noticed the following feature: "Dynamic port: dynamically change the communication port to combat the speed limit of long-term large traffic port"
16:48:04 <cohosh> i didn't get through as much of the beginners guide as i wanted, but i'm curious about what this PAC is? is it some kind of proxy distribution system?
16:48:06 <dcf1> So our usual questions are: what can we learn from this? What short-term or long-term actions can we take? What future work is advisable?
16:48:17 <studentmain> v2ray already fill the space occupied by Shadowsocks
16:48:50 <dcf1> I didn't use any PAC when I set it up. My understanding is that a PAC file (proxy auto-config) is a configuration file for browsers that control what proxy to use for what sites.
16:48:59 <cohosh> ahh okay
16:49:15 <DuckSoft> PAC is used for traffic diversion. It's generally a JavaScript script telling browsers if a target is applicable for a proxy outbound or not
16:49:17 <cohosh> so similar to mass browser, because they are one-hop proxies
16:49:23 <dcf1> studentmain: I am curious about this. I have heard that there is a large market for SS resellers in China, who install SS on a VPS in Japan or wherever, and then charge for access to it.
16:49:47 <dcf1> studentmain: Do you know if those resellers are switching to v2ray? Or is it something people normally set up for themselves?
16:49:50 <DuckSoft> Sure. We call proxy service resellers "Airport" (机场) in Chinese.
16:50:19 <chartor> ducksoft - then what do mac users call airport?
16:50:22 <chartor> english?
16:50:29 <dcf1> DuckSoft: aha, so that's what that term means, thanks :) I saw it used at https://github.com/v2ray/v2ray-core/releases/tag/v4.24.2
16:50:54 <studentmain> yes, many reseller are using v2ray and trojan
16:51:28 <Shelikhoo> Dynamic port is used to bypass some kind network restriction that ban ports that have large amount of unrecognized  traffic(like VMess).
16:51:32 <studentmain> only a few of them are using original shadowsocks
16:51:48 <dcf1> trojan is https://github.com/trojan-gfw/trojan btw, TLS-based system.
16:52:00 <DuckSoft> it's a steorotype that "airports" using ss are low in tech, and v2ray & trojan ones are more superior, afaik
16:52:26 <phw> Shelikhoo: that's interesting. can i learn more about this somewhere?
16:53:45 <Shelikhoo> "Airport"'s name maybe come form the icon of SS which is a paper plane
16:53:56 <Shelikhoo> "Airport"'s name maybe come from the icon of SS which is a paper plane
16:54:35 <DuckSoft> You can look into the specs of vmess protocol: https://www.v2fly.org/developer/protocols/vmess.html
16:54:39 <dcf1> Is the dynamic port thing a "balancer" as described at https://v2ray.com/en/configuration/routing.html ?
16:56:48 <DuckSoft> dcf1: i don't think so. dynamic port is a command defined in vmess protocol. given by the server, the client may use the dynamic port provided by the server in the following T minutes. It's in the specs.
16:56:54 <dcf1> And now VMess is experimenting with a new cryptographic construction using AEAD, possibly to replace the AES-CFB that is used currently (whose malleability contributed to the recent replay vulnerabilities)
16:57:17 <DuckSoft> and if you can read Chinese, here it is: https://www.v2fly.org/developer/protocols/vmess.html#%E5%8A%A8%E6%80%81%E7%AB%AF%E5%8F%A3%E6%8C%87%E4%BB%A4
16:57:31 <dcf1> I haven't looked at the new AEAD docs yet.
16:58:48 <dcf1> I want to talk a bit about V2Ray's layered design, which is very interesting to me.
16:58:49 <Shelikhoo> No, I it not an "balancer". Sever will push the necessary setting with VMess protocol, and client don't need to configure it manually
16:59:12 <dcf1> The v2ray program itself is very flexible and configurable. The "client side" and "server side" are the same program, just configured differently.
17:00:06 <dcf1> It's based on a general notion of "inbounds" and "outbounds". On the client, you may have a "socks" inbound and a "vmess" outbound. On the server, you may have a "vmess" inbound and a "freedom" outbound ("freedom" means no further proxying).
17:00:23 <studentmain> v2ray is a platform, all protocols are designed to be pluggable
17:00:35 <dcf1> Each inbound and outbound is made up of a layered "proxy" and "transport"
17:01:09 <dcf1> It's no arbitrarily composable, though, afaik you can only do `proxy | transport`, not `proxy | transport | transport`.
17:01:17 <dcf1> So no TLS-in-TLS or things like that.
17:01:38 <dcf1> In the past, the Tor Project had a mostly failed experiment for composition of transports: https://trac.torproject.org/projects/tor/wiki/doc/PluggableTransports#Combiningpluggabletransports
17:02:14 <dcf1> The proxy/transport divide makes a lot of sense, basically saying you can replace a TCP connection with any other sort of reliable stream abstraction.
17:02:58 <dcf1> There are still some weird features of how the layering in V2Ray works, though. For example, different layers can be responsible for the traffic obfuscation.
17:03:02 <cohosh> hmm cool
17:03:32 <dcf1> Like in `vmess | tcp`, you are relying on vmess to be undetectable.
17:03:43 <dcf1> (the proxy)
17:03:44 <Shelikhoo> (proxy |)+  transport is allowed to bounce traffic between different servers, but only the last hop can use non-tcp transport
17:04:06 <dcf1> But in `socks | quic-with-wechat-obfsucation`, you are relying on the transport for obfuscation.
17:04:28 <dcf1> Shelikhoo: like a chain of proxies? I see, that makes sense. I did not realize it could work that way.
17:05:14 <cohosh> this is interesting and related to some discussions we've had about using conjure and/or snowflake with a variety of obfuscation methods
17:05:35 <dcf1> Anyway, what I'm saying is that I know that composition of these interfaces is non-trivial and has a lot of unexpected difficulties, and v2ray's approach seems pretty good.
17:05:53 <cohosh> cool XD
17:06:20 <dcf1> I am so glad we are able to bring together some different development communities.
17:06:24 <Shelikhoo> Yes, it is designed in that way so you can chain your proxies. Mostly used to bypass ISP rate limit and use public proxy safely
17:06:45 <tomcat> QoS
17:07:03 <dcf1> Shelikhoo, and others with experience: do you know if any of the discovered flaws in V2Ray protocols were being exploited by the GFW before being fixed?
17:08:06 <DuckSoft> for mKCP, mostly yes, since mKCP cannot even survive within one day when deployed across the Great Firewall
17:08:08 <dcf1> https://gfw.report/blog/gfw_shadowsocks shows that GFW *is* doing active probing against Shadowsocks, maybe it is already happening against V2Ray protocols too.
17:09:01 <Shelikhoo> I don't have time to run the experiment this time, but we used to receive replay traffic long before this
17:09:08 <studentmain> Yes, we detected active probing on vmess protocol server, but we're not sure what's the payload
17:09:58 <dcf1> DuckSoft: ah, that's every interesting. mKCP is UDP too, not TCP, which is interesting because most active probing so far has been TCP. I noticed mKCP mentioned at https://github.com/v2ray/v2ray-core/issues/2542
17:09:58 <Shelikhoo> If they are still probing, maybe we can tcpdump that
17:10:11 <studentmain> I mean, it's possible they're sending payload for shadowsocks to determine it's a shadowsocks server
17:10:42 <Shelikhoo> The issue with mKCP is that it used to be encrypted before I patched it
17:10:43 <dcf1> studentmain: agreed, it may be that GFW cannot distinguish SS from VMess, for example, until it does some more detailed active tests.
17:11:04 <studentmain> We can get historical data from research for SS
17:11:04 <phw> studentmain: does the gfw block your vmess protocol server? or is it just probing?
17:11:10 <Shelikhoo> The issue with mKCP is that it used to be UNencrypted before I patched it
17:11:51 <studentmain> personally I use shadowsocks with AEAD protocol
17:12:12 <dcf1> It is even possible that some of the probes seen by gfw.report and https://censorbib.nymity.ch/#Ensafi2015b were intended for v2ray, who knows.
17:12:46 <studentmain> we can investigate it, as we have samples
17:14:01 <dcf1> studentmain: I think that would be very interesting.
17:14:27 <dcf1> GFW active probing was already surprisingly sophisticated in 2015 and has only gotten more capable since then.
17:15:34 <dcf1> I think that covers most of the topics I have in my notes.
17:15:38 <Shelikhoo> Any replay against V2Ray must happen within 60 seconds, since V2Ray will take time into consideration, with at least 16 bytes of head unchanged.
17:15:53 <dcf1> V2Ray devs, is there any specific help you are looking for from outside, or what would you want others to know?
17:16:23 <dcf1> I am planning to take a look at the AEAD proposal for VMess and see if I notice any flaws.
17:17:51 <Shelikhoo> Any additional audit is appreciated, since I am not the original developer of this project, there could have a lot of weakness that I can't discover by myself
17:18:26 <studentmain> FYI, v2ray (and shadowsocks) are designing next generation protocol
17:18:36 <cohosh> i'm curious about how users add new proxies they discover to the client-side software
17:18:38 <DuckSoft> Personally I will appreciate if we can bridge across different censorship circumvention systems using a shared protocol, such as SIP003 in Shadowsocks and PT in Tor
17:19:08 <cohosh> perhaps we can share some usability work there with proxy distribution
17:19:47 <phw> as i understand it, users must set up their own v2ray instance, right? the devs don't provide users with ready-to-use instances?
17:20:09 <cohosh> that's my understanding too
17:20:21 <dcf1> phw: or users buy access from an "airport" that sets it up for them.
17:20:22 <DuckSoft> Correct. Either you deploy it yourself, either you get the service from a 3rdparty provider.
17:20:24 <cohosh> but we've had our own usability issues with people adding private bridges
17:20:29 <studentmain> Yes, they need set up by themselves
17:20:48 <dcf1> I'm looking for the trac ticket about obfs4 improvements
17:21:06 <Shelikhoo> No, V2Ray team just wrote the software, users have to setup it  or buy one themselves
17:21:08 <phw> #30716
17:21:09 <dcf1> I was reminded of it because studentmain mentioned a next-gen protocol
17:21:13 <dcf1> thanks phw
17:21:43 <Shelikhoo> If we publish one proxy, it could be quickly blocked by IP
17:22:03 <DuckSoft> "Airport"s are using a simple mechanism called "subscription". After a user purchased the service, the provider gives user a link with token, which, when requested, returing all the nodes available for the user in encoded plaintext format
17:22:25 <dcf1> Yes, it's interesting to me, the SS/V2Ray reseller system is markedly different from the BridgeDB system.
17:22:40 <cohosh> DuckSoft: thanks
17:22:49 <dcf1> If you don't know, BridgeDB is the Tor Project's system for distributing secret proxy addresses. https://bridges.torproject.org/
17:23:23 <dcf1> You can request a bridge address through HTTPS, email, or a few other ways. There is no monetary charge, but the system tries to rate-limit requests to prevent enumeration of all addresses.
17:23:38 <cohosh> (and doesn't do a great job at it right now)
17:23:47 <dcf1> It is more successful against some censors than others; for example the GFW is good at getting addresses from BridgeDB.
17:23:56 <studentmain> Resellers are commercial system
17:24:27 <dcf1> The reseller model has some nice advantages, it's naturally more distributed, bridges cost something to acquire (you pay for a subscrition).
17:24:29 <cohosh> so is the idea that the GFW just can't track them all down/it's too expensive for them to subscribe to all of them?
17:24:45 <dcf1> Also provide an incentive to run proxies.
17:24:58 <phw> i wonder if these resellers struggle with having their websites blocked by the gfw
17:25:36 <studentmain> They just can't track all of them.
17:25:47 <DuckSoft> Yes and no. Airports nodes are being blocked from time to time, and the operators may use different techniques to circumvent that thing.
17:26:21 <studentmain> Old server 'died', they switch to a new server
17:26:24 <Shelikhoo> If they change the address fast enough, it can't be blocked.
17:27:41 <dcf1> I wonder if the commercial model could be merged with a system like Salmon (we discussed last time, https://github.com/net4people/bbs/issues/33)
17:27:47 <studentmain> Same for reseller itself, old reseller 'died', there will be a new reseller then, it's profitable.
17:27:48 <DuckSoft> They can use a server in the wall as a "relay". Since proxy programs preserve no data in the disk, they simply can't get busted.
17:27:50 <Shelikhoo> And some darker theorists believe these resellers provide user info to government so that they can run indefinitely
17:28:07 <cohosh> this ability to spin up new servers seems really crucial. our set of bridges ends up being very static
17:28:49 <rg1> > If they change the address fast enough, it can't be blocked.
17:28:57 <dcf1> Yeah my impression is that part of the day-to-day operation of Psiphon, Lantern, etc. is just burning through addresses and rotating them constantly.
17:29:20 <rg1> Do you mean the reseller will change the domain name and IP addresses of their websites from time to time?
17:29:31 <DuckSoft> That's a good word, "dynamic". "Airport" mode is in a dynamic loop. Emerged, grown, famous, busted, broken, reborn...
17:30:27 <DuckSoft> rg1: yes. they will change the panel domain from time to time, if the panel using to provide "subscription" itself was blocked.
17:31:01 <dcf1> Do people buy airport subscription on Wechat? Is it save to do wall-jumping business on Wechat?
17:31:05 <dcf1> *safe
17:31:11 <tomcat> :D
17:31:26 <cohosh> if not a commercial model, some planning on how to devote resources to keeping the IP addresses of proxies/bridges dynamic would be a huge improvement
17:31:55 <Shelikhoo> I believe if we wants to follow that model, server should be set up on VPS that can change IP easily
17:32:49 <Shelikhoo> yes, resellers get paid on wechat and alipay
17:33:16 <dcf1> Shelikhoo: interesting.
17:33:20 <dcf1> We are getting close to 1 hour of discussion, so we should finish soon.
17:33:22 <Shelikhoo> They have special payment gateway to wash their money
17:33:37 <dcf1> I will summarize the main points of the discussion at https://github.com/net4people/bbs/issues/36
17:33:47 <cohosh> thanks dcf1
17:34:16 <dcf1> This has been a very stimulating discussion. I'm glad that so many experts could take part. We are really benefiting from your knowledge.
17:34:42 <Shelikhoo> Thanks you, we have a lot to learn from you too
17:34:54 <phw> yes, thank you very much for your time and for answering our questions
17:35:55 <cohosh> i hope we can talk again in the future :D
17:35:59 <cohosh> this is awesome work
17:36:14 <Shelikhoo> If there is any more questions, I can answer them on email
17:36:18 <DuckSoft> yes, looking forward to that too
17:36:18 <tomcat> 1:37 am (China Standard Time)
17:36:33 <tomcat> Good night
17:36:43 <DuckSoft> o/
17:36:51 <phw> have a good night!
17:36:54 <studentmain> We're working on same goal, we need more contact.
17:37:55 <phw> #endmeeting