Open wkrp opened 4 years ago
xhdix
commented
4 years ago On mobile, by default, sites open with the https://google.com/amp/s/ without requesting *.ampproject.org. Blocking it has no effect on preventing unpleasant sites for governments!
wkrp
commented
4 years ago On mobile, by default, sites open with the
https://google.com/amp/s/without requesting*.ampproject.org.
But in the source code, www[]().google.com/amp (the "AMP viewer") contains an iframe that still loads the main content from cdn.ampproject.org.
$ curl https://www.google.com/amp/s/www.bbc.com/persian.amp -A 'Mozilla/5.0 (iPhone; CPU iPhone OS 11_0 like Mac OS X) AppleWebKit/604.1.38 (KHTML, like Gecko) Version/11.0 Mobile/15A372 Safari/604.1'
...
<iframe name="https://www.bbc.com/persian.amp" src="https://www-bbc-com.cdn.ampproject.org/v/s/www.bbc.com/persian.amp?..." ...></iframe>See the comments around https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/25985#note_2592342 for some more discussion.
wkrp
commented
4 years ago The block was short enough that it was not caught by any OONI measurements. Here are the measurements around that time: https://explorer.ooni.org/search?until=2020-07-31&domain=cdn.ampproject.org&probe_cc=IR&test_name=web_connectivity (archive)
The nearest measurements are at 2020-07-27 12:44:54 and 2020-07-30 10:53:09, and they are both normal. The block of cdn.ampproject.org must have begun and ended in between.
I do not find the incident reported in Google's transparency report for Iran (archive)
xhdix
commented
4 years ago I tested it manually at that particular time, and DNS, HTTP, and HTTPS were blocked. The commands were like:
dig cdn.ampproject.org @1.1.1.1 # returned 10.10.34.35
curl -4v --trace-time -m 31 --connect-to ::www.example.com: http://cdn.ampproject.org/ # returned <ifram src="http://10.10.34.35/">...
curl -4v --trace-time -m 31 --connect-to ::www.example.com: https://cdn.ampproject.org/ # timeout after Client helloHowever, on some ISPs ampproject.com and ampproject.org are still blocked:
https://explorer.ooni.org/search?since=2020-07-26&until=2020-08-06&domain=ampproject.org&probe_cc=IR&test_name=web_connectivity
https://explorer.ooni.org/search?since=2020-07-26&until=2020-08-06&domain=ampproject.com&probe_cc=IR&test_name=web_connectivity
From @xhdix I hear that the domains .ampproject.org and .ampproject.com were blocked in Iran for a few days. I don't know exactly when the block started, but it ended around 2020-07-28.
2020-07-27 23:35 https://twitter.com/NarimanGharib/status/1287894478150393858 (archive)
2020-07-28 17:43 https://twitter.com/EcommerceNsr/status/1288168230306091008 (archive)
2020-07-28 18:39 https://twitter.com/KhosroKalbasi/status/1288182268389928961 (archive)
cdn.ampproject.org is an AMP cache. It's a caching proxy for certain web pages optimized for mobile browsing. If you have ever browsed a page under amp.google.com, its contents were being served via cdn.ampproject.org. There are two other AMP caches I am aware of, amp.cloudflare.com and bing-amp.com.
To be honest, I don't understand why a censor would need to block an AMP cache. It's not exactly a covert proxy. The AMP cache URL format transparently encodes the domain name of the site being cached and reveals it in the TLS SNI. Instead of connecting to www[]().bbc.com, with an AMP cache you connect to www-bbc-com.cdn.ampproject.org, which would seem to be equally blockable. There's a demo of using an AMP cache for censorship circumvention at #5, but it relies on domain fronting to disguise the AMP cache URL format.
Prior to this incident in Iran, I was aware of two other cases of AMP cache blocking: in Saudi Arabia in January 2018 and in Egypt in February 2018.