Uganda's Social Media Tax through the lens of network measurements

Cover image

Image by @neemascribbles.

Probed ISPs: MTN (AS20294), Africell (AS36991), Airtel (AS37075), Smile Telecom (AS37122), Africa Online Uganda (AS29039), DATANET (AS29032), Sombha Solutions (AS328015), Roke (AS37063), Airtel (AS36977), Uganda Telecom (AS21491)

OONI tests: Web Connectivity, HTTP Invalid Request Line, HTTP Header Field Manipulation, WhatsApp, Facebook Messenger, Telegram, Vanilla Tor

Testing/analysis period: 1st July 2018 to 24th October 2018

Censorship methods: HTTP blocking (resetting connections) and TCP/IP blocking

Key Findings


This study is part of an ongoing effort to examine internet censorship in Uganda and in more than 200 other countries around the world.

The Open Observatory of Network Interference (OONI) and DefendDefenders (The East and Horn of Africa Human Rights Defenders Project) collaborated on a joint research study to examine internet censorship in Uganda through the collection and analysis of network measurements. The aim of this study is to document internet censorship in Uganda through the analysis of empirical data. 

The following sections provide information about Uganda’s new social media tax. We also document our methodology and present the findings from our analysis.

Social Media Tax

Since 1st July 2018, people in Uganda are required to pay taxes to the Ugandan government in order to access several online social media platforms. Unless this levy is paid, access to these specific platforms is blocked. The tax is commonly referred to as the Social Media Tax or the OTT (Over The Top) Tax.

According to MTN, the taxed online platforms include:

To access platforms like Facebook, WhatsApp and Twitter, users of Ugandan ISPs are now required to pay a tax of UGX 200 (USD 0.05) per day. This was introduced through a new set of taxes in the Excise Duty Act (Amended) on OTT services and mobile money transactions. For mobile money, a 0.5% levy applies to withdrawals, and 1% is levied on transfers.

Most ISPs in Uganda have blocked access to social media platforms, requiring upfront payment of the tax, while smaller ISPs have simply increased the cost of data. This is not the first time that social media has been blocked in Uganda. In early 2016, ISPs were instructed to block access to social media in the run-up to the general elections and during President Museveni’s subsequent inauguration ceremony. Authorities ordered the blocking of social media for “security purposes”, but the move reportedly harmed the political opposition.

Now Ugandan civil society organizations are concerned that the new OTT tax is being introduced to silence alternative or dissenting opinions on matters of public interestin Uganda. In December 2016, an opposition politician, Swaibu Nsamba Gwogyolonga, was arrested over his (offensive to President Museveni) Facebook post. These concerns were exacerbated when President Yoweri Museveni reportedly claimed that the new tax is meant to “deal with the consequences of online gossip” (lugambo) on social media platforms.

Civil society groups have also expressed concern that these taxes will negatively affect internet access and affordability, as well as financial inclusion for low income and marginalized groups such as women, youth and rural communities. The Alliance for Affordable Internet (A4AI) estimates that the new taxes will represent a 30% increase in the cost to connect to the internet for Uganda’s poorest populations.

In his statement, President Museveni argued that the social media tax is meant to reduce capital flight and improve the country’s tax to GDP ratio. The 14th June national budget speech for the fiscal year 2018/19 indicated projections of up to UGX 486 billion (approximately USD 129 million) of estimated revenue annually by 2022/23.

Restricting access to the internet, however, can have an economic impact. According to CIPESA’s framework for calculating the economic impact of internet disruptions in sub-Saharan Africa, Uganda’s five-day social media shutdown in 2016 set the economy back an estimated USD 2.2 million. The ICT sector has previously contributed up to 3.4% to Uganda’s GDP per annum, while recent studies have shown that a 10% increase in mobile broadband penetration can increase economic growth by nearly 3%. Increasing the cost to access the internet, therefore, has the potential to impact the country’s economic growth.

In response to the OTT tax, protests erupted in Uganda. Five users and a technology company reportedly filed a lawsuit with the Constitutional Court, suing the Uganda Communications Commission, Uganda Revenue Authority and the country’s Attorney General. In an attempt to prevent untaxed access to social media, circumvention tools are being blocked as well. According to MTN:

“The operators will block access to VPNs that the authorities declare to be used for OTT services, unless the consumer has paid their OTT tax.”

Internet taxes are not unique to Uganda. Zambia plans to tax calls made over social media apps, while Tanzania has rolled out a “blogger tax”. According to DefendDefenders, Tanzania’s Electronic and Postal Communications (Online Content) Regulations 2018 prohibit online content in broad terms and impose registration or licensing requirements which enable the government to arbitrarily regulate and ban online content produced by bloggers, citizen journalists, forum administrators, social media users, as well as websites, television and radio stations. Benin previously had plans to tax social media use, but it was repealed following public backlash.


To measure internet censorship in Uganda, OONI’s network measurement software (called OONI Probe) was run across multiple local vantage points. OONI Probe is free and open source software designed to measure various forms of network interference.

The main OONI Probe tests run as part of this study include:

Given that the Ugandan government recently rolled out a new social media tax - resulting in the blocking of social media platforms - running OONI’s Web Connectivity test was core to the objective of collecting network measurement data that shows which websites are blocked, how they are blocked, and which ISPs implement the blocks.

OONI’s Web Connectivity test is designed to measure whether websites are blocked by means of DNS tampering, TCP/IP blocking, or by an HTTP transparent proxy. This test is automatically performed both over the vantage point of the user and from a non-censored control vantage point. If the results from both vantage points match, the tested website is most likely accessible. If the results however differ, the measurement is flagged as anomalous. OONI’s current methodology is blockpage-driven, primarily confirming censorship events when ISPs serve blockpages. In cases where ISPs do not serve blockpages, the relevant network measurements are analyzed over time, examining whether the specific types of failures persist and what caused these failures (i.e. ruling out false positives).

The testing was mostly limited to the URLs included in the Citizen Lab’s global and Ugandan test lists. These lists consist of a variety of different types of URLs that fall under 30 categories and that are tested for censorship by network measurement projects like OONI. Throughout the course of this research, test lists were updated to ensure that social media sites affected by the tax were tested.

To monitor the accessibility of popular instant messaging platforms, OONI’s WhatsApp, Facebook Messenger and Telegram tests were run locally. These tests are designed to measure the reachability of the WhatsApp, Facebook Messenger, and Telegram apps and web interfaces through DNS lookups and by attempting to establish TCP and TLS connections to their servers.

Since censorship circumvention tools were reportedly blocked to prevent untaxed access to social media, the accessibility of circumvention tools was measured as well. Many circumvention tool sites were already included in the Citizen Lab’s global test list and additional ones were added, all of which were measured via OONI’s Web Connectivity test. OONI’s Vanilla Tor test was also run, which is designed to measure the blocking of the Tor network. To better understand how circumvention tools are blocked, a series of custom tests and experiments were run as well.

Once network measurement data was collected from all of these tests, OONI data was subsequently processed and analyzed based on a standardized set of heuristics for detecting internet censorship and traffic manipulation. All OONI Probe network measurements collected from Uganda between 1st July 2018 to 24th October 2018 were analyzed as part of this study.


Ugandan ISPs don’t appear to serve block pages. Confirming censorship events can therefore be quite challenging, particularly in light of false positives that (almost) inevitably emerge (due to transient network failures, for example). The findings have therefore been limited to network anomalies that are consistent and persistent in the same ASNs over time.

While a directive has been issued for the OTT tax, the blocking of certain adult websites is legally required of all ISPs in Uganda. Banned adult websites (listed on the UCC letter) were therefore tested to detect the censorship techniques adopted by different ISPs and to compare them with measurements testing the blocking of social media and circumvention tool sites.

Blocking of social media

Since 2014 - and particularly since the OTT tax was rolled out in July 2018 - the accessibility of social media sites has been measured across multiple ASNs in Uganda through the use of OONI Probe.

As part of this study, the analysis has been narrowed to:

Measurements collected from MTN (AS20294) and Africell (AS36991) met the above criteria, which is why findings from these two networks are primarily presented. Measurements were also collected from a number of other ASNs, as well as from networks where the OTT tax was paid. The latter served as a baseline, allowing the comparison of measurements based on whether or not the OTT tax was paid. This was particularly useful for ruling out false positives and presenting the findings with more confidence.

Before we dive into the findings, it’s important to first highlight that MTN subscribers are required to use an HTTP proxy to access the internet. On mobile devices, they generally do not have to do anything to setup the HTTP proxy, as it’s shipped as part of the APN settings. This means that MTN mobile users may have a different internet experience in comparison to what is captured by OONI Probe on the network level. The HTTP proxy used for MTN testing has the address:

The following table shows results collected between 1st July 2018 to 24th October 2018 (without having paid the OTT tax) from MTN, Africell and Airtel. The findings under the “MTN without proxy” column were gathered (using OONI Probe) on the MTN network with the proxy settings disabled, while the results under the “MTN with proxy” column were collected using curl with the --proxy flag.

URLsMTN without proxy (AS20294)MTN with proxy (AS20294)Africell (AS36991)Airtel (AS37075)
https://badoo.comHTTP failureCONNECT failHTTP failureHTTP failure
https://go-text.meHTTP failureOKAccessibleHTTP failure failureOKHTTP failureHTTP failure
https://hitwe.comAccessibleCONNECT: 503 errorAccessibleAccessible
https://line.meAccessibleOKHTTP failureAccessible
https://secure.hi5.comHTTP failureOKHTTP failureHTTP failure
https://tinder.comHTTP failureOKHTTP failureHTTP failure
https://twitter.comTCP/IP connect timeoutCONNECT failHTTP failureHTTP failure
https://web.telegram.orgAccessibleOKHTTP failureHTTP failure
https://web.wechat.comHTTP failureCONNECT failHTTP failureHTTP failure
https://web.whatsapp.comTCP/IP connect timeoutOKHTTP failureHTTP failure
https://www.facebook.comTCP/IP connect timeoutOKHTTP failureHTTP failure
https://www.instagram.comTCP/IP connect timeoutCONNECT failHTTP failureHTTP failure failureSSL failN/AHTTP failure
https://www.linkedin.comHTTP failureOKHTTP failureHTTP failure
https://www.meetme.comAccessibleOKHTTP failureAccessible failureCONNECT failHTTP failureHTTP failure
https://www.snapchat.comTCP/IP connect timeoutOKHTTP failureHTTP failure
https://www.textra.meTCP/IP connect timeoutCONNECT: 502 errorTCP/IP connect timeoutTCP/IP connect timeout
https://www.truecaller.comHTTP failureCONNECT failHTTP failureHTTP failure
https://www.tumblr.comHTTP failureCONNECT failHTTP failureHTTP failure
https://www.viber.comHTTP failureCONNECT failHTTP failureHTTP failure failureOKN/AHTTP failure timeoutAccessible
http://www.grindr.comHTTP timeoutN/AN/A

What is evident is that not all social media sites are blocked across ISPs. Africell, for example, blocks access to and, while MTN and Airtel don’t. In many cases, the accessibility of social media sites on MTN varies depending on whether or not the user has configured the carrier provided proxy or not.

In relation to the tests run using the MTN proxy:

OK via proxy


SSL fail

Bad Gateway

Proxy Service Unavailable”

“CONNECT fail” connections were likely aborted by MTN’s blocking equipment, rather than by the MTN HTTP proxy itself. If the proxy fails to establish a connection, then the proxy delivers errors, rather than resetting connections.

### traceroute to the port of the proxy shipped as the APN setting for MTN
$ mtr --report-wide --show-ips --aslookup --tcp --port=8080
Start: Fri Oct 19 16:24:17 2018
HOST: raspberrypi            Loss%   Snt   Last   Avg  Best  Wrst StDev
  1. AS???     0.0%    10    2.1   2.9   1.6   4.9   1.1
  2. AS???   0.0%    10    7.0   6.7   3.7   8.8   1.3
  3. AS???    0.0%    10   39.4  37.8  27.7  52.6   7.0
  4. AS???    ???            100.0    10    0.0   0.0   0.0   0.0   0.0
  5. AS???    0.0%    10  404.0 221.0 149.3 404.0  66.8

MTN, Africell and Airtel primarily appear to block access to social media sites by means of HTTP blocking. Most measurements collected from these three ISPs present the same HTTP failures and “connection reset” errors, which means that they reset connections to block access to those sites. A few of those measurements are annotated by OONI Probe as DNS failures due to geoDNS-based load balancing, but they are actually HTTP failures too. The fact that HTTP failures and “connection reset” errors consistently occur in most anomalous measurements (expanding beyond the above social media sites) leads to the conclusion that Ugandan ISPs primarily block access by resetting connections.

In some cases though, MTN appears to block access to sites by means of TCP/IP blocking. Most measurements collected from MTN testing,,, and consistently presented TCP connect timeout errors. In an attempt to examine whether MTN in fact blocks these sites by means of TCP/IP (or if these anomalies are caused by poor network performance), further tests were run from two Raspberry Pis connected to MTN.

When testing, we observed the same pattern with TCP connect timeout errors. TCP traceroutes to port 443 terminated at the third hop, while TCP traceroutes to port 22 or another host in same /25 subnet went further. We also observed the same patterns and the same TCP connect timeout errors when testing, and RIPE Atlas measurements show the same errors for, and from local vantage points.

### traceroute to HTTPS port of IP for
$ mtr --report-wide --show-ips --aslookup --tcp --port=443
Start: Fri Oct 19 10:16:01 2018
HOST: raspberrypi            Loss%   Snt   Last   Avg  Best  Wrst StDev
  1. AS???     0.0%    10    3.0   3.4   2.0   4.8   0.7
  2. AS???   0.0%    10    7.7   6.2   3.4   7.7   1.2
  3. AS???    ???            100.0    10    0.0   0.0   0.0   0.0   0.0

### traceroute to nearby IP in same /24 using same TCP port
$ mtr --report-wide --show-ips --aslookup --tcp --port=443
Start: Fri Oct 19 10:16:25 2018
HOST: raspberrypi                                      Loss%   Snt   Last   Avg  Best  Wrst StDev
  1. AS???                               0.0%    10    2.3   3.7   0.9  11.4   2.9
  2. AS???                             0.0%    10    3.3   6.9   3.3   8.8   1.5
  3. AS???                              0.0%    10   36.1  33.5  27.4  38.1   3.2
  4. AS???                              0.0%    10   36.8  33.2  24.7  46.5   7.6
  5. AS20294 (      0.0%    10   25.0  33.2  25.0  44.4   6.1
  6. AS20294 (   0.0%    10   25.5  34.8  25.0  46.2   7.5
  7. AS20294 (   0.0%    10   26.3  32.4  22.7  49.1   8.2
  8. AS16637                             0.0%    10  227.2 236.7 226.5 253.4   8.2
  9. AS16637                            0.0%    10  239.3 246.4 229.1 280.4  18.6
 10. AS16637                            0.0%    10  239.3 240.7 229.1 287.1  16.9
 11. AS16637                            0.0%    10  238.9 235.5 225.5 251.8   7.2
 12. AS???    ???                                      100.0    10    0.0   0.0   0.0   0.0   0.0

### traceroute to same IP using TCP port 22/ssh
$ mtr --report-wide --show-ips --aslookup --tcp --port=22
Start: Fri Oct 19 10:17:24 2018
HOST: raspberrypi                                      Loss%   Snt   Last   Avg  Best  Wrst StDev
  1. AS???                               0.0%    10    3.7   3.3   2.3   4.1   0.3
  2. AS???                             0.0%    10    8.7   6.4   1.9   8.7   2.2
  3. AS???                              0.0%    10   41.2  33.8  21.1  52.4   9.0
  4. AS???                              0.0%    10   33.9  32.3  26.0  42.8   4.7
  5. AS20294 (      0.0%    10   90.5  39.2  23.3  90.5  18.9
  6. AS20294 (   0.0%    10   78.9  39.5  24.5  78.9  15.1
  7. AS20294 (   0.0%    10   71.6  38.3  25.1  71.6  14.1
  8. AS16637                             0.0%    10  228.0 241.9 228.0 273.8  15.3
  9. AS16637                            0.0%    10  236.5 250.9 226.5 331.9  34.2
 10. AS16637                            0.0%    10  236.0 253.5 230.7 373.9  43.0
 11. AS16637                            0.0%    10  229.5 234.3 223.0 266.4  12.5
 12. AS???    ???                                      100.0    10    0.0   0.0   0.0   0.0   0.0

### traceroute to same IP using TCP port 25/SMTP
$ mtr --report-wide --show-ips --aslookup --tcp --port=25
Start: Fri Oct 19 10:23:42 2018
HOST: raspberrypi            Loss%   Snt   Last   Avg  Best  Wrst StDev
  1. AS???     0.0%    10    3.4   3.1   1.3   4.8   1.1
  2. AS???   0.0%    10    8.0   6.9   5.4   8.5   1.1
  3. AS???    0.0%    10   44.1  35.7  23.2  44.1   6.1
  4. AS???    ???            100.0    10    0.0   0.0   0.0   0.0   0.0

### traceroute to HTTPS port of IP for
$  mtr --report-wide --show-ips --aslookup --tcp --port=443
Start: Fri Oct 19 10:19:51 2018
HOST: raspberrypi            Loss%   Snt   Last   Avg  Best  Wrst StDev
  1. AS???     0.0%    10    3.6   2.8   1.1   4.8   1.1
  2. AS???   0.0%    10    5.1   6.0   2.6   8.6   1.6
  3. AS???    ???            100.0    10    0.0   0.0   0.0   0.0   0.0

In testing the reachability of, without the MTN proxy, we noticed that this site appeared to be blocked by IP rather than by hostname. Since is hosted on the Google Cloud, the blocking of the IPs associated to may have resulted in the blocking of many other unrelated sites. According to the Rapid7 Forward-DNS dataset, around 300,000 domains use the endpoint.

To examine whether these sites were indeed blocked on the MTN network without the proxy, we tested a sample of high profile sites using that network endpoint as an entry point for their website. We also tested a random sample of hosted sites. OONI measurements presented TCP anomalies for all those sites, suggesting that they may have been affected by the blocking of MTN may, therefore, have blocked access to by means of TCP/IP, unintentionally causing collateral damage and possibly affecting thousands of other sites.

Most MTN users, though, probably won’t experience any of this collateral damage, since the MTN proxy appears to circumvent IP level blocking by issuing CONNECT requests by hostname, instead of IP. This would explain why MTN users, with the proxy enabled and without having paid the OTT tax, can access sites that are blocked by IP (such as However, they cannot access social media sites that are blocked by means of HTTP (such as This also explains why they can access many of the other potentially affected domains hosted on the same cloud load balancer as One of these sites is, which presents TCP anomalies in OONI testing (likely as a result of collateral damage), but which is accessible from a mobile browser connected to MTN (using its HTTP proxy).

Overall, the TCP anomalies for,,, and highlight inconsistencies in the configuration of the MTN HTTP proxy. This could potentially be explained as an attempt by MTN to block applications, without distinguishing the website traffic from the application traffic. Perhaps their blocking equipment was misconfigured, or perhaps it was configured with cached IP addresses.

Finally, OONI measurements show that is inaccessible on the TCP/IP level, but this appears to be due to server-side issues. The site also presents reachability issues from global vantage points, as illustrated by RIPE Atlas measurements (15% of vantage points can’t do a TLS handshake). TCP traceroutes towards from a vantage point in MTN differ significantly from TCP traceroutes towards other websites that are inaccessible on the TCP level (such as, while attempts to connect to the website via MTN’s auto-provisioned proxy are not blocked (unlike or, but produce a proxy-level error. All of this suggests that is inaccessible due to server-side issues, which is further implied by the 503 error that appears when attempting to access the site via MTN’s proxy.

$ mtr --report-wide --show-ips --aslookup --tcp --port=443
Start: Fri Oct 19 10:45:59 2018
HOST: raspberrypi                                                   Loss%   Snt   Last   Avg  Best  Wrst StDev
  1. AS???                                            0.0%    10    1.9   2.8   1.0   6.1   1.6
  2. AS???                                          0.0%    10    4.9   5.8   2.7   8.0   1.3
  3. AS???                                           0.0%    10   37.2  32.1  18.2  43.4   6.7
  4. AS???                                           0.0%    10   44.7  39.4  26.5  47.9   6.2
  5. AS20294 (                   0.0%    10   28.8  34.8  25.6  44.8   5.4
  6. AS20294 (                0.0%    10   25.2  34.0  21.8  57.8   9.8
  7. AS20294 (                0.0%    10   33.7  36.5  24.4  46.7   7.2
  8. AS16637                                          0.0%    10  229.4 239.0 225.3 275.9  15.0
  9. AS???    ???                                                   100.0    10    0.0   0.0   0.0   0.0   0.0
 10. AS???    ???                                                   100.0    10    0.0   0.0   0.0   0.0   0.0
 11. AS3356 (      0.0%    10  229.2 234.8 227.7 244.6   5.2
 12. AS3356 (      0.0%    10  233.1 235.8 229.7 240.1   3.2
 13. AS2914 (    0.0%    10  233.2 236.9 233.2 246.1   4.0
 14. AS2914 (    0.0%    10  229.3 233.2 221.2 244.0   6.9
 15. AS2914 (     0.0%    10  307.6 305.0 293.9 312.9   6.4
 16. AS2914 (    10.0%    10  369.2 1067. 369.2 3517. 1377.5
 17. AS2914 (     0.0%    10  365.7 681.6 363.2 3467. 978.8
 18. AS2914 (    0.0%    10  378.2 380.1 370.6 391.8   7.5
 19. AS2914 (   0.0%    10  382.4 383.1 370.9 400.6   7.8
 20. AS2914 (     0.0%    10  382.8 387.6 376.9 400.7   8.8
 21. AS???    ???                                                   100.0    10    0.0   0.0   0.0   0.0   0.0


OONI’s WhatsApp test is designed to measure the reachability of WhatsApp’s app and web interface by attempting to perform an HTTP GET request, TCP connection and DNS lookup to WhatsApp’s endpoints, registration service and website ( Depending on the success or failure of these methods, we can evaluate whether (and to what extent) WhatsApp’s app and/or web interface are blocked.

The following table summarizes our findings on the testing of WhatsApp across ISPs from 1st July 2018 to 19th October 2018.

MTN (AS20294)BlockedBlockedBlocked
Africell (AS36991)OKBlockedBlocked
Smile Communications (AS37122)OKOKOK
Airtel (AS37075)OKBlockedBlocked
Uganda Telecom (AS21491)OKOKOK

MTN appears to block access to both WhatsApp’s app and web versions, as TCP connections to the app’s endpoints, registration service and failed. This is also corroborated by Web Connectivity measurements collected from MTN, showing the TCP/IP blocking of Both WhatsApp and Web Connectivity measurements collected from MTN show the same timeout errors, strongly suggesting that MTN blocks WhatsApp entirely by means of TCP/IP blocking.

Africell also appears to block access to both WhatsApp’s app and web version, but their blocking techniques are different. They reset connections (HTTP blocking) to WhatsApp’s registration service and website, while refraining to block WhatsApp’s endpoints. The same techniques are also observed in Web Connectivity measurements testing in Africell. Similarly, Airtel blocks WhatsApp’s app and web version by resetting connections to the app’s registration service and website.  

Smile Communications and Uganda Telecom, on the other hand, do not block WhatsApp. All measurements suggest that both the app and its web version are accessible in these two networks. In July 2018, Smile Communications announced that they would pay the OTT tax on behalf of their customers for at least three months.

Facebook Messenger

OONI’s Facebook Messenger test is designed to measure the reachability of Facebook Messenger by attempting to perform TCP connections and DNS lookups to Facebook’s endpoints. If TCP connections fail or DNS lookups do not resolve to IP addresses allocated to Facebook, then access to the app is likely blocked.

The following table summarizes findings on the testing of Facebook Messenger across ISPs from 1st July 2018 to 19th October 2018.

ASNsTCP connectionsDNS lookups
MTN (AS20294)BlockedOK
Africell (AS36991)OKOK
Smile Communications (AS37122)OKOK
Airtel (AS37075)OKOK
Uganda Telecom (AS21491)OKOK

Only MTN appears to block access to Facebook Messenger. Most measurements collected from MTN show that TCP connections to Facebook’s endpoints failed. Recent measurements suggest that Facebook Messenger is accessible on (at least) Africell, Smile Communications, Airtel and Uganda Telecom.


OONI’s Telegram test is designed to measure the reachability of Telegram’s app and web version by attempting to perform an HTTP POST request and establish a TCP connection to Telegram’s access points, as well as an HTTP GET request to If these methods fail, Telegram’s app and/or web version are likely blocked.

The following table summarizes findings on the testing of Telegram across ISPs from 1st July 2018 to 19th October 2018.

ASNsTCP connectionsHTTP
Africell (AS36991)OKBlockedBlocked
Smile Communications (AS37122)OKOKOK
Airtel (AS37075)OKOKBlocked
Uganda Telecom (AS21491)OKOKBlocked

Interestingly, MTN does not appear to block Telegram, even though they block access to WhatsApp and Facebook Messenger. This is also suggested by Web Connectivity measurements, showing the accessibility of on MTN. Africell, on the other hand, appears to block access to both Telegram’s app and web version by resetting connections. The same censorship techniques are also observed in Web Connectivity measurements for on that network.

Unsurprisingly (given that Smile committed to paying the OTT tax for their customers), Telegram is accessible on Smile Communications. The Telegram app appears to work on Airtel, but they reset connections to, potentially censoring access to the website. Similar measurements are observed from Uganda Telecom. It’s worth noting, however, that very few Telegram measurements have been collected from Smile Communications, Airtel and Uganda Telecom during the testing period, limiting confidence in confirming findings from these three networks.

Blocking of circumvention tools

Some censorship circumvention tools have been blocked to prevent untaxed access to social media.

Through the use of OONI’s Web Connectivity test, multiple circumvention tool sites included in the Citizen Lab’s global test list were measured. The analysis was subsequently narrowed to the sites presenting consistent anomalies in these two networks. These measurements were compared with those collected from Uganda Telecom, since most of them show that circumvention tools are accessible.

The following table summarizes findings on the testing of circumvention tool sites.

URLsMTN (AS20294)Africell (AS36991)Uganda Telecom (AS21491)Airtel (AS37075)
https://www.torproject.orgHTTP failureAccessibleAccessibleHTTP failure
https://www.tunnelbear.comHTTP failureHTTP failureAccessibleHTTP failure
https://www.betternet.coHTTP failureHTTP timeoutAccessibleHTTP failure
https://www.getoutline.orgTCP connect errorAccessibleAccessibleAccessible

MTN appears to block, and by means of HTTP blocking, resetting connections to these sites. Most measurements collected from MTN suggest that it may, instead, block access to by means of TCP/IP blocking. Africell appears to adopt similar techniques (HTTP blocking), but they don’t block access to and It’s worth noting that all of these circumvention tool sites are accessible on Uganda Telecom.

Even though MTN blocks access to, the Tor network appears to be accessible from MTN and various other local vantage points. Most measurements collected from Airtel and iWayAfrica, for example, also show that OONI’s Vanilla Tor test is able to successfully bootstrap connections to the Tor network.

The accessibility of the Tor network from Uganda is also suggested by Tor Metrics which show a huge spike in Tor usage on 1st July 2018, following the rollout of the OTT tax.

Tor Metrics for Uganda

Tor usage gradually declined - possibly as a result of being blocked in some networks (limiting the ability to download Tor Browser) - but the fact that there have been subsequent spikes in usage suggests that it has been accessible (at least from some local ASNs).

VPN blocking

To better understand VPN blocking, a series of experiments were run from an MTN vantage point in Uganda. The goal was to understand if protocol-specific blocking was used or not, if VPN-in-a-box solutions like Streisand, Algo and Outline work or not.

As part of our testing methodology, we deployed a VPN-in-a-box server, connected to it from an MTN vantage point and downloaded a 10-megabyte file from the RFC1918 IP of a VPN server. We found that OpenConnect, OpenVPN/TCP, OpenVPN/UDP, Wireguard work. IPsec and shadowsocks-based Outline also face no problems according to our sources.

However, OpenVPN deployed with Streisand uses the tls-crypt feature, which has been available since OpenVPN 2.4. tls-crypt is used to both authenticate and encrypt most metadata available on the wire with a pre-shared key. If the tls-crypt feature is disabled completely or replaced with authentication-only tls-auth, then attempts to block OpenVPN are clearly observed.

MTN (AS20294) NAT does not preserve the source port, but preserves the IP ID field, which can be used to correlate packets sent from the Raspberry Pi and arriving to the Streisand server. The following Wireshark screenshots show that UDP traffic is blocked as soon as the man-in-the-middle (MITM) sees the initial OpenVPN/UDP handshake packet from the server:

OpenVPN/UDP, client side

The client part of the connection above does not get any reply from the server. The server below does not see any retries coming from the client (IP ID 6184, 6372, 6842, 7058) using the same 5-tuple (combination of the client’s and server’s IP address, used port and protocol).

OpenVPN/UDP, server side

While OpenVPN/UDP packets are just dropped, a slightly different pattern is observed for OpenVPN/TCP connections: the connections are reset actively in both directions, RTT difference and echoed IP ID of client-side RST packet suggests that it’s injected:

OpenVPN/UDP, client side

The initial P_CONTROL_HARD_RESET_CLIENT_V2 packet from the client is likely dropped by the middlebox (unlike UDP case), so the server does not receive it at all. The RST packet the server gets has the “usual” TTL and IP ID fields:

OpenVPN/UDP, server side

Besides tls-crypt, there are options to circumvent MTN OpenVPN blocking that are useful when it’s hard to upgrade the clients or the server to OpenVPN 2.4. First, brdgrd can be used to enforce P_CONTROL_HARD_RESET_CLIENT_V2 packet fragmentation from the server-side. It successfully circumvents the block (note Win=3 in the SYN-ACK packet coming from the server):

OpenVPN/TCP + brdgrd, client side

The downside of the brdgrd method is that low TCP flow-control window is a network anomaly and this fingerprint may be used to block traffic as well.

Enforcing client-side TCP segmentation is also possible with a patched OpenVPN client or tooling like GoodbyeDPI which circumvents the filter (note Len=2 in the first data packet from the client).

OpenVPN/TCP + segmentation, client side

Blocking of adult websites

On 6th July 2018, following the rollout of the OTT tax, the Uganda Communications Commission (UCC) instructed all telecom operators and ISPs in Uganda to block a list of adult websites. According to Uganda’s Pornography Control Committee, these sites stream pornographic content in breach of section 13 of the Anti-Pornography Act (2014).

UCC letter banning adult sites

Adult websites listed on the UCC letter were tested with OONI Probe (as well as several other, internationally popular adult sites included in the Citizen Lab’s global test list).

The findings reveal that adult websites are blocked in the same way social media and circumvention tool sites are blocked. The same HTTP failures and “connection reset” errors are present in most measurements testing adult websites, similarly to the measurements testing social media and circumvention tool sites. In some cases, Ugandan ISPs may also block adult sites by means of TCP/IP blocking (which was also observed in the testing of social media and circumvention tool sites). The consistency in terms of the types of anomalies identified in measurements across ASNs strongly suggests that most Ugandan ISPs are resetting connections to block access to banned (and OTT taxed) sites.

The analysis, containing all measurements showing the blocking of banned adult sites across ASNs (from 1st July 2018 to 19th October 2018), is available via this CSV file. Even corporate networks on which probes were run - which were formerly completely unfiltered - now block access to the sites banned by Uganda’s Pornography Control Committee. It’s worth noting that Uganda Telecom did not block access to the same adult sites, despite being the state-owned telecom.


Leading up to the 2016 general elections and during President Museveni’s inauguration, access to social media was blocked in Uganda. At the time, OONI reported that Smile Telecom and Orange carried out IP blocking and that Orange only blocked the HTTP version of and, while Smile blocked both the HTTP and HTTPS versions of,, and

Circumstances have now changed considerably. In light of the new OTT tax, most Ugandan ISPs appear to block a number of taxed social media sites, while Smile doesn’t. Instead, they (Smile) have paid the OTT tax for their customers(for at least three months). Quite similarly, Uganda Telecom doesn’t appear to block social media either. Orange, on the other hand (which has been acquired by Africell), has blocked a number of social media sites, requiring upfront payment of the OTT tax prior to access.

Social media censorship varies across ASNs, as not all ISPs appear to block the same sites. They are consistent in terms of their censorship techniques, since most ISPs block sites by means of HTTP, resetting connections to taxed sites. The same censorship techniques are also observed in relation to the blocking of adult websites, which are legally banned under section 13 of the Anti-pornography Act (2014).

MTN seems to have blocked access to,,, and by means of TCP/IP blocking, possibly as a result of blocking the applications without distinguishing application traffic from website traffic. The blocking of Snapchat, however, may have resulted in collateral damage, possibly affecting thousands of other sites hosted on the same CDN. But even if this is the case, most MTN users probably won’t experience this collateral damage, since MTN’s proxy circumvents IP-level blocking.

Following the rollout of the OTT tax, various circumvention tools sites were blocked to prevent untaxed access to social media. Some circumvention tool sites were found to be blocked but, similarly to social media sites, their blocking varied across ASNs. In some cases, MTN appears to block access to OpenVPN. It’s worth noting that the Tor network is accessible on MTN, even though MTN seems to block access to

Further testing is required to better understand the breadth and depth of internet censorship in Uganda, particularly in light of the new OTT tax. Since this study was carried out through the use of free and open source software, open methodologies and open data, it can be reproduced and expanded upon.


We thank all the volunteers in Uganda who have run OONI Probe, making this research possible.