Telling censorship from outages: probing Russia's internet from both sides of the border

When Internet services stop working in Russia, there are two possible explanations: either the service is completely down for everyone or it is accessible everywhere except within Russia. Current outage trackers that rely solely on user complaints cannot distinguish between these scenarios, as both situations appear identical – a spike in users reporting the service is not functioning.

To address this issue, I developed shutdown.fyi, an open-source tracker for 38 services, eight carriers, and 85 regions. The core concept behind this tracker is straightforward: it checks the same web address from both inside Russia and abroad, step by step, and compares the results at each stage of the process. By taking measurements from two distinct vantage points, we can determine whether a service is blocked or simply experiencing an outage.

Every 5 minutes, for every service, we probe up to two hostnames – the actual websites, not CDN hosts. We perform a TLS handshake to an image CDN to check if the domain resolves, open a TCP connection to port 443, complete the TLS handshake with the correct SNI, and finally, retrieve an HTTP response. By comparing these results from the Russian server and a server in Helsinki, we can ascertain the cause of the issue.

If all steps pass from Russia but fail from abroad, we know the service is restricted, and we can identify at which stage the failure occurs. If the HTTP status code is 403 or 451, the service itself refuses Russian users. Recently, an example of this type of scenario was demonstrated with YouTube's Russian domain. At the time of checking, the DNS resolution in Russia took 20 milliseconds, the TCP connection was successful, but the TLS handshake timed out, while the HTTP request from abroad was successful with a 200 status code.

This pattern, known as "blocked-tls," indicates that the issue lies with the server name in the TLS ClientHello. Other popular services such as Telegram, WhatsApp, and Instagram have experienced similar issues, with their access being restricted at a later step in the process (blocked-tcp). To improve the accuracy of the information provided, the tracker now displays two independent axes for each service – access and reachability.

Access is determined by active probes, while reachability applies only to carriers and regions. This distinction is crucial, as a service that has been restricted for an extended period may no longer be considered an anomaly, whereas a service that is not currently reachable is clearly broken. Additionally, the tracker incorporates incident responses to determine whether the current situation is worse than usual for a particular hour.

This is based on user complaints, OONI measurements, IODA traffic data, and BGP visibility. The baseline is calculated as the median of the same hour over previous days, with a floor set at half the weekly median to avoid false positives from occasional spikes in complaints. The tracker also addresses the issue of bugs that may lead to inaccurate reporting.

By aggregating data from eight public outage detectors, we ensure that levels are not simply counts, but rather aggregated measurements that account for differences in reporting formats. For example, some detectors publish hourly series, while others only report the number of complaints in the last 24 hours. To address this discrepancy, we apply a rolling 24-hour level, dividing the daily level by 24 to obtain a more accurate representation of the current situation.

Furthermore, the tracker distinguishes between levels and counts, recalculating totals and charts accordingly. Additionally, our Russian probe occasionally flagged a major Russian bank as restricted due to TLS timeouts from Russia and successful connections from Helsinki. However, this was a false positive, as the bank's anti-bot protection drops connections from specific hosting IP ranges, and our probe is located in a datacenter.

To rectify this, our tracker now displays "no conclusion" for domestic services on the government's whitelist when only our Russian vantage fails. Finally, the tracker has implemented a new criterion for closed incidents. Previously, incidents were closed based on the first "ok" snapshot, which often led to frequent reopenings as subsequent spikes occurred.

To mitigate this issue, incidents are now only closed after 15 minutes of consistently normal readings, and any shorter outages are hidden from the feed. By providing a more accurate and nuanced analysis of internet access in Russia, shutdown.fyi aims to offer a clearer understanding of whether a service is experiencing censorship or an outage, ultimately helping users better navigate the digital landscape in the country.