Circumvent Internet censorship without external apps or services

[gnarea]

Executive summary

Internet apps are responsible for the transport of the data they produce and consume, so circumventing Internet censorship requires a system-wide tool on the user's device (e.g., Tor, VPNs) or a custom technology built into an app (and/or the servers it talks to).

By contrast, Awala apps delegate the transport of their data to the local Android/desktop gateway, whose sole job is to connect the local apps to the outside world using the best network available. So it makes sense for it to also be responsible for circumventing censorship when using the Internet, so that Awala users, couriers and service providers will never have to worry about Internet censorship.

Tackling this issue soon is very important for three reasons:

• Populations susceptible to Internet blackouts are permanently subject to (severe) Internet censorship anyway. Having to have separate apps to circumvent both forms of censorship will be a hassle and only tech-savvy people will end up doing it.
• If Awala is only useful to people when the Internet is and may be unavailable, they're unlikely to use it or its apps the rest of the time. Which means they'll end up trying to install them once they've lost access to the Internet, which isn't ideal (Support the onboarding of users during an Internet blackout #1).
• As a service provider serving people susceptible to Internet blackouts, it'd be hard to justify the effort of integrating Awala if people won't be using it most of the time when they do have access to the Internet.

This is a meta issue for all the changes we'd have to make to the Awala protocol suite and/or Relaycorp's implementations.

Background

Internet censorship is implemented differently by country, and even by ISPs within the same country. This requires us to employ a variety of technologies and techniques -- some of which may have to be limited to certain countries/regions if they incur a performance penalty, for example.

Fortunately, today we can leverage the amazing work by the Internet Freedom community, who's been documenting censorship techniques and designing/developing circumvention tools. We'll achieve the goal of this issue by building on the their work and contributing back when possible.

Techniques and technologies

We already have plans to support the following technologies, not just to circumvent censorship, but also to improve privacy and scalability:

• ESNI, which is currently recommended by Awala and may be required eventually.
• DNS-over-HTTPS, or DNS-over-TLS when the DNS for the resolver (e.g., cloudflare-dns.com) can't be resolved.
• IPFS.

To circumvent censorship when necessary, we may use the following technologies/techniques in certain cases -- starting with the ones that seem more robust, easier to implement and less likely to cause performance/UX issues:

1. PoObjectStore would probably be the most user-friendly and scalable of all the options on this list. However, it depends on access to the APIs of Amazon S3, Google Cloud Storage and Azure Blob Storage -- which some censors might not mind blocking.
2. PoProxy.
3. Geneva as an L4 reverse proxy for public gateways.
4. Geneva on desktop (doesn't work on Android and some strategies require elevated privileges that Android won't ever allow without rooting).
5. PoEmail.
6. As the very last resort, manually exporting/importing cargo and sharing it via email, WhatsApp or any service that isn't blocked. We may want to use steganography in case cargo is shared over non-E2E-encrypted services, such as email.

It might be good to consider Pluggable Transports as a stopgap solution, but whilst think they're great for regular Internet traffic (i.e, RPCs), I think integrating them in a Delay-Tolerant Network like Awala will involve some pretty serious shoehorning -- and I believe the techniques above offer equal or better UX/performance anyway.

We should also consider how to onboard users when they can't download the desktop/Android gateways (see also #1). For example: People who haven't yet installed the desktop/Android gateway should be able to send an email to something like download+windows@awala.network to get an automatic reply with an installer (instead of the full app, as that'd take up more than 10 MiB). The installer itself should be able to bypass Internet censorship too.

Challenges

I've identified the following (surmountable) challenges:

• Ease of deployment. Some server-side changes are easy (e.g., ESNI) but most others will be hard and therefore unlikely to be widely adopted by public gateway and centralised service providers. I'd only count on Relaycorp-run public gateways supporting them all.
• Performance. Whilst all gateways and courier apps may be capable to support the technologies/techniques above, they should only be used when strictly necessary.
• UX. Where a circumvention approach requires upfront or ongoing user interaction, that interaction must be minimised as much as possible. They should also be hidden behind some advanced settings when we don't have a reason to believe the user actually needs them.

Drawbacks

Compared to VPNs

I can't think of any disadvantage to circumventing Internet censorship via Awala compared to using VPNs, nor can I think of a single reason why placing a VPN in front of a gateway or courier app would be useful.

Putting censorship circumvention aside:

• From a privacy perspective, the user may be concerned about sharing their IP address with public endpoints or public gateways. However, they could configure their local gateway to route all its Internet traffic through the public gateway it's paired to. And if the user still doesn't trust its own public gateway with its IP address, then they should probably switch to a public gateway run by someone they trust, use Tor or operate their own VPN.
• From a performance perspective, Awala can't be any worse than a VPN -- if anything, it should be faster when delivering parcels if the public endpoint can be reached directly.

Compared to Tor

I believe Awala would be at least as effective as Tor at circumventing censorship and it'd be more performant, but Tor would still provide better privacy because the user's IP address is never revealed to the target server. Consequently, many whistleblowers, activists and journalists may still prefer Tor -- Until a reputable third party agrees to operate an Awala-Internet Gateway with a strict no-logs policy (which Relaycorp is extremely unlikely to do).

Limitations

The above can only work if the global Internet is at least partially reachable to end users or intermediaries. It's also less likely to work if the censor employs an allowlist approach where only selected IP addresses can be reached, unless the allowed services can be exploited (e.g., email).