Google's AMP system is a threat to user's privacy and the concept of the Open Web.
Amputator attempts to aid in this problem by serving the canonical (base) URL of AMP links that are posted.
The AMP format is itself not much of a problem. In fact, we should applaud search engines that give ranking preference to fast-loading pages like AMP, but four aspects of its implementation are flawed: Google mobile Search’s Top Stories carousel has a premium position above of all other results, which is only accessible for AMP pages. These pages have to use a technology that was build and maintained mostly by Google (of the top 10 contributors to the AMP project on GitHub, 9 are Google employees), are then served by Google from their infrastructure and placed within a Google controlled user experience. And since this carousel generates a lot of clicks and revenue, publishers are left no choice but to embrace AMP. This has the effect of further reinforcing Google’s dominance of the Web. Fortunately, Google has announced that it's working on opening up the Top Stories carousel to non-AMP pages in 2021. The biggest performance boost doesn’t come from the AMP framework, but from preloading the page. It begs the question: Should preloading really be exclusive to AMP? They could introduce a way for publishers to allow or disallow preloading and if Google sees fit, they could preload those pages too, alongside AMP. When a user navigates from Google to a piece of content Google has recommended (or when a user clicks on a shared cached AMP link), they are, unwittingly, remaining within Google’s ecosystem and the publisher’s domain is obscured by the google.com/amp prefix. To work around this Google introduced Signed HTTP Exchanges ([Draft], , ), a web-standard that allows the browser to display the original site's URL, instead of the actual one (the one with the google.com/prefix). This would solve the original issue, but while doing so it introduced new ones (e.g. it obfuscates the fact that they're delivering the AMP page you're visiting). Interestingly enough, Google's Chrome already has support for this technology, but parties not involved with AMP are not so enthusiastic: Mozilla has deemed it a harmful web standard , and Apple has taken a similar stance. Google’s entire business model is about collecting as much personal data as possible, AMP is just another tool to do so. As described in Google’s Support article:
“When you use the Google AMP Viewer, Google and the publisher that made the AMP page may each collect data about you.”
To be clear, the above flaws are only with AMP pages cached by Google (or another party like Bing or Cloudflare) but there are also plenty of pages simply utilizing the AMP framework, recognized by URLs such as bbc.com/news/amp/. However, these are also problematic, mainly because there's only a small performance improvement when AMP pages aren't cached and AMP pages tend to be less feature-rich and less diverse than their originals. And in some edge cases, it breaks stuff. One could argue that the more popular the AMP framework becomes, the more AMP threatens the open web. That said, it should be clear that the biggest problem lies with the cached AMP pages.