Possible strategies
-
Doing reachability testing for the endpoints of the app (pros: low effort to implement, relatively easy to update when things change cons: not accurate when the blocking is not simply hostname/ip:port based)
-
Doing something where we collect a PCAP of how the traffic of a given app works and replay the traffic towards our control servers (pros: medium effort to implement, once implemented it can easily be extended to an arbitrary app cons: only accurate when blocking is protocol based)
-
Implementing the real protocol of the app and speaking it with the servers (pros: most accurate as it would tell us for sure when a given app is working or not working cons: high effort to implement, needs to be implemented indepedently for every app, requires reversing of the app, need to update the app every time it changes)
-
Setup a VPN on the probe end and route traffic from a real app in our censorship testbed (pros: medium effort to implement cons: can be complex to scale this approach to many measurement clients, requires setting up dedicated serverside infrastructure to run the measurements)
-
Have the user run the app, but route the traffic of the app via a VPN setup on the device and detect the blocking inside of the VPN. (pros: medium effort to implement, cons: requires user intervention, may not be possible on every platform)
Existing apps using approach 3.
Differentiator detector: http://dd.meddle.mobi/
Glasnost: http://broadband.mpi-sws.org/transparency/glasnost.php
Existing apps using approach 5.
Haystack: https://haystack.mobi/
** Key takeaways **
-
Standalone application to collect the data vs integrating inside of other pieces of software.
-
Application that detects blocking on mobile and tries different strategies to get around the blocking.
-
Could be a way to foster collaboration amongst CCT vendors.
-
Possibility of doing the same thing for Firefox.