#32740: Implement a feedback loop between BridgeDB and OONI -------------------------------------------------+------------------------- Reporter: phw | Owner: phw Type: project | Status: | assigned Priority: Medium | Milestone: Component: Circumvention/BridgeDB | Version: Severity: Normal | Resolution: Keywords: s30-o23a2, anti-censorship-roadmap- | Actual Points: 2020Q1 | Parent ID: #31280 | Points: 10 Reviewer: | Sponsor: | Sponsor30-must -------------------------------------------------+-------------------------
Comment (by phw): Here are preliminary design considerations: * We want a standalone service (let's call it wolpertinger) that lives on polyanthum, alongside BridgeDB. Wolpertinger exposes an API that OONI and others (e.g., ICLab) can query to fetch bridges to test. Upon receiving a request, wolpertinger uses BridgeDB's SQL database and yet-to-be-defined heuristics to find a bridge that's worth testing, and returns its bridge line. While we are specifically designing wolpertinger to work well with OONI, other censorship measurement platforms should be able to use it too. * Arturo mentioned that OONI probes may not talk to wolpertinger directly, but rather proxy their requests over OONI's infrastructure. In this case, we don't need to worry about making wolpertinger resistant to censorship, but we may still want to make it available over domain fronting so we are prepared for a future in which censorship measurement probes (which are unlikely to be able to talk to *.torproject.org) connect directly. * When requesting a bridge to test, a censorship measurement probe should tell us the country it's in. We may also want to know its autonomous system. What else do we want to know? * We must authenticate incoming requests, so we can be sure that they are from OONI, and not from an attacker who seeks to collect bridges. A simple authentication token would do the job. * Once OONI has test results for a given bridge, these results have to make it back to wolpertinger somehow, so it can write them to BridgeDB's SQL database. Both a push and pull model are conceivable here; OONI could make another request containing the test results, or wolpertinger fetches the results from OONI's API. * Asked about the number of requests wolpertinger would be seeing, Arturo said "Looking at the number of opened reports per day (which is ~20k), we can estimate that it’s probably not going to be more than 20k requests per day for some time. Or somewhere in the range of 10-15 requests per minute." * Considering all of the above, wolpertinger's API could take the following JSON request format as input: {{{ { "type": "TYPE", "country_code": "COUNTRY_CODE", "auth_token": "AUTH_TOKEN", } }}} `TYPE` identifies the censorship measurement probe, and could be "ooni" for OONI. `COUNTRY_CODE` identifies the country the probe is in and `AUTH_TOKEN` is an authentication token. Upon receiving this request, wolpertinger would then respond with: {{{ { "bridge_lines": ["BRIDGE_LINE_1", ..., "BRIDGE_LINE_N"] } }}} Any thoughts on the above? -- Ticket URL: <https://trac.torproject.org/projects/tor/ticket/32740#comment:4> Tor Bug Tracker & Wiki <https://trac.torproject.org/> The Tor Project: anonymity online
_______________________________________________ tor-bugs mailing list tor-bugs@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs