Opened 3 months ago
Last modified 2 months ago
#31701 assigned defect
Reachability tests for new obfs4 bridges
| Reported by: | cohosh | Owned by: | cohosh |
|---|---|---|---|
| Priority: | Medium | Milestone: | |
| Component: | Circumvention/Obfs4 | Version: | |
| Severity: | Normal | Keywords: | reachability, measurement |
| Cc: | phw | Actual Points: | |
| Parent ID: | Points: | ||
| Reviewer: | Sponsor: |
Description
As a follow up to #29279, we can now set up some new reachability tests on a subset of the bridges we've gotten through our bridge campaign \o/
We probably don't want to test all of the new bridges in case these tests cause a bunch of bridges to get blocked when they otherwise wouldn't.
As mentioned in #29279:comment:9, we should sample bridges from our various distribution mechanisms (email, private, and HTTPS), and also from any finer grained partitions we have (email provider, subnet, etc.).
Child Tickets
Attachments (1)
Change History (3)
comment:1 Changed 3 months ago by
Changed 2 months ago by
| Attachment: | obfs4-reachability-2019-10-03.pdf added |
|---|
comment:2 Changed 2 months ago by
| Owner: | set to cohosh |
|---|---|
| Status: | new → assigned |
Oof, okay looks like many of our bridgeDB bridges are already unreachable in China.
I have the most data for moat bridges due to accidentally leaving some blank lines in bridge_lines.txt for the first two days. So we can see some more interesting behaviour for those. However, it looks like some moat bridges were blocked even before we started the tests.
Sounds good to me. I will extract a few and send them your way. I'm particularly interested in learning if our moat bucket is being scraped too.