Blog article about simulating Internet shutdowns

content/news/2023-simulating-internet-shutdowns.md

+---
+aliases:
+- /news/2023-simulating-internet-shutdowns.html
+date: 2023-01-30T11:00:00+00:00
+title: "Researching Android's behavior during Internet shutdowns"
+---
+
+### Background
+
+The Briar team is currently doing some research into the long-term
+evolution of the project that is funded by [eQualitie](https://equalit.ie/).
+We have two main branches of research: the social mesh and the public mesh.
+For the social mesh part, we're looking at questions around routing
+messages within a social graph of established and trusted contacts.
+The public mesh part is concerned with routing messages via untrusted
+devices. The overarching goal is to find suitable mechanisms and concepts
+for extending messaging capabilities especially in the event of a disaster
+where Internet access is temporarily unavailable or in the case of an
+Internet shutdown.
+
+### Simulated Internet shutdowns
+
+One aspect of the public mesh research is looking into how Android devices
+behave in case of an Internet shutdown.
+While it is clear that during a full or partial Internet shutdown, many
+websites and services cannot be reached from any device, it is not
+so clear which functionality remains intact.
+The Android operating system has mechanisms in place that detect whether
+a device has a working Internet connection and we wanted to find
+out whether this assessment is preventing installed apps from communicating
+with servers that are technically still reachable.
+
+To get insight into this, we decided to simulate Internet shutdowns on a
+wireless network using different techniques and observe how Android devices
+react while connected to that Wi-Fi.
+
+The experiments have shown that it is relatively simple to simulate a
+partial Internet shutdown where Android thinks the Internet connection is
+not working, however it does not seem to prevent any non-blocked Internet
+traffic. The system and the browser UI give strong indication to the user
+that the connected Wi-Fi doesn't provide Internet access, but the browser
+and other apps just keep working nonetheless.
+
+#### Experiment setup
+
+The basic setup for our experiments is a Linux-based Wi-Fi router that has
+been configured in different ways to simulate an Internet shutdown.
+A phone with Android 11 has been used for testing.
+The idea is to block just enough to make Android think the Internet
+connection is broken and then see how much is still working.
+We already knew that a special domain name is used for checking Internet
+connectivity: `connectivitycheck.gstatic.com`.
+This is often used in restricted open Wi-Fi networks to force the user to
+first open a so-called captive portal where they need to accept some terms
+and conditions before gaining Internet access.
+We manipulated the DNS server to behave in different ways for that special
+domain name and created four distinct situations:
+
+1. Install a fake captive portal reachable at `connectivitycheck.gstatic.com`.
+2. No captive portal, instead configure the DNS server to behave irregularly
+   for `connectivitycheck.gstatic.com` and some more of Google's domains:
+	* a) return unused IP addresses,
+	* b) return DNS error responses,
+	* c) do not return DNS responses at all.
+
+A combination of *dnsmasq*, *nginx* and *iptables* has been used to set up
+these situations.
+
+#### 1. Fake captive portal
+
+If you've used an Android phone on a public Wi-Fi on a conference venue or
+in a hotel, you're probably familiar with the basic situation created
+by setup 1).
+Right after establishing a connection to the Wi-Fi, Android shows a
+notification telling you that you're required to sign in to the network
+in order to use it.
+The wireless connections settings screen shows a similar message.
+In addition, the Wi-Fi symbol in the status area has a small "X" in the
+corner as a hint that the network does not provide Internet access.
+Tapping the notification opens a browser screen that usually displays
+the captive portal prompting you to enter a token or simply accept some
+terms and conditions.
+
+We didn't simulate a full-blown captive portal, just returned an unexpected
+HTTP response code for the relevant endpoint
+`connectivitycheck.gstatic.com/generate_204`.
+Usually, a router would block other network traffic until the user has
+completed the required confirmation steps in the captive portal.
+In our case, all network traffic was still possible as far as the
+router was concerned.
+We used the Chrome browser to check network access to other websites.
+Even though the browser shows a black bar at the top saying
+"No Internet connection", we were able to browse random sites just fine.
+
+#### 2. Manipulating DNS responses for some of Google's domains
+
+Setup 2) is different from the first one in that Android is incapable to
+check `connectivitycheck.gstatic.com/generate_204` and receive any HTTP
+response.
+For case a), *dnsmasq* was configured to return a local IP address for that
+domain name that was known not to be in use at the time.
+For case b), it was configured to return an NXDOMAIN response instead.
+For case c), *iptables* was configured to silently drop the relevant
+requests.
+
+In all three cases, Android didn't think the Wi-Fi connection was broken.
+Inspecting DNS traffic on the network, we were able to observe that other
+domains were queried without any user interaction:
+`google.com` and `www.google.com`.
+Extending the scenarios to block these domains in addition to the
+connectivity check, Android's assessment of the Wi-Fi connection degrades
+to "not working". The small "X" on the status bar icon appears, the
+Wi-Fi settings screen shows "No Internet" for on the current connection
+and Chrome has the additional black bar at the top.
+There's no prompt to sign in to the network though, but this makes sense as
+the system is not able to reach the captive portal.
+
+As in the first case, we used Chrome to check random websites and except
+for Google, which was really blocked, we had no problems browsing the web.
+
+#### Summary
+
+Whatever we configure to make the Android device think the Internet
+connection does not work, does not affect the ability to connect to other
+IP addresses that can be reached and neither does it stop the device from
+resolving DNS queries to non-blocked domains.
+Even though various parts of the UI indicate that the system considers the
+Wi-Fi connection offline, the system does not seem to block any traffic as a
+result of this assessment.
+For our project, this is good news: it means that even when the public
+Internet is rigidly blocked, it should not harm the ability to communicate
+with other devices on local networks or national subsets of the Internet.
+While other mechanisms could still influence the ability to form mesh
+networks, the Android operating system itself doesn't seem to get in our
+way.
+
+### About Briar
+
+Briar is a messaging app designed for activists, journalists,
+and anyone else who needs a safe, easy and robust way to communicate.
+Unlike traditional messaging tools such as email, Twitter or Telegram,
+Briar doesn't rely on a central server -
+messages are synchronized directly between the users' devices.
+If the internet's down,
+Briar can sync via Bluetooth or Wi-Fi, keeping the information flowing in a crisis.
+If the internet's up, Briar can sync via the Tor network, protecting users
+and their relationships from surveillance.
+
+{{% funding %}}
+
+{{< contact  >}}
+
+Twitter: [@BriarApp](https://twitter.com/BriarApp)
+
+Mastodon: [@Briar](https://fosstodon.org/@briar)