This content originally appeared on Brave’s Latest News on Brave Browser and was authored by Brave’s Latest News on Brave Browser
This is the eighteenth post in an ongoing, regular series describing new and upcoming privacy features in Brave. This post describes work done by Privacy PM and Engineer Shivan Sahib. This post was written by Shivan Sahib and Senior Director of Privacy Peter Snyder.
Summary
Brave is rolling out a new feature called De-AMP, which allows Brave users to bypass Google-hosted AMP pages, and instead visit the content’s publisher directly. AMP harms users' privacy, security and internet experience, and just as bad, AMP helps Google further monopolize and control the direction of the Web.
Brave will protect users from AMP in several ways. Where possible, De-AMP will rewrite links and URLs to prevent users from visiting AMP pages altogether. And in cases where that is not possible, Brave will watch as pages are being fetched and redirect users away from AMP pages before the page is even rendered, preventing AMP/Google code from being loaded and executed.
De-AMP is now available in our Nightly and Beta versions and will be enabled by default in the upcoming 1.38 Desktop and Android versions, and will be released on iOS soon after. If you are on Nightly or Beta and do not see the feature enabled, you may need to restart your browser for the changes to take effect.
What is AMP?
AMP, or Accelerated Mobile Pages, is a non-standard subset of HTML developed and pushed by Google. AMP pages are served from Google’s servers, though designed to look like they’re coming from the original publisher’s site.
For example, if you search for “new york times top stories” on Google Search, google.com will preload most/all of the stories in the background (thus downloading unnecessary data on your device) and when you click a Top Story, the article will be served from google.com while making you believe you are on nytimes.com.
Google claims the purpose of the AMP project is to improve website performance, through a combination of preloading, serving pages from Google’s (sometimes) faster servers, and removing some legacy browser features.
Why is AMP Harmful?
In practice, AMP is harmful to users and to the Web at large.
First, AMP is harmful to privacy. AMP gives Google an even broader view of which pages people view on the Web, and how people interact with them. AMP encourages developers to more tightly integrate with Google servers and systems, and penalizes publishers with decreased search rankings and placements if they don’t, further allowing Google to track and profile users.
Second, AMP is bad for security. By design, AMP confuses users about what site they’re interacting with. Users think they’re interacting with the publisher, when in actuality the user is still within Google’s control. User-respecting browsers defend the site as the security and privacy boundary on the web, and systems like AMP intentionally confuse this boundary.
Third, AMP furthers the monopolization of the Web. AMP encourages more of the Web to be served from Google’s servers, under Google’s control and arbitrary non-standards. It also allows Google to require pages to be built in ways that benefit Google’s advertising systems. AMP is one of many Google strategies to further monopolize the Web, and build a Web where users serve Google, instead of websites serving users. 1
Finally, AMP is bad for performance and usability. Though Google touts AMP as better for performance, internally Google knows that “AMP only improves the ‘median of performance’ and AMP pages can actually load slower than other publisher speed optimization techniques” (as revealed in Google’s disclosures to the DOJ, pg. 90). In many cases AMP is so bad for performance and usability that Web users literally pay money to avoid AMP.
How Does Brave Protect Users From AMP?
Brave protects users from AMP in three steps.
First, Brave will modify fetched pages that frequently link to AMP pages, so that links point to the publisher versions of pages instead of the AMP versions of those same pages. Examples of such pages include Google Search. When De-AMP is enabled in Brave, these pages will be able to interact with these pages as normal, just with the benefit of never being forced (or tricked) into visiting AMP pages.
Second, Brave has modified Blink to watch for when AMP pages are being loaded. When De-AMP is enabled, Brave will look for the AMP HTML markup in pages as they’re being loaded (and before they’re being rendered). If Brave sees an AMP page being loaded, the browser will stop loading the current page and instead load the “true” version of the page. This is done before the page is rendered, preventing Google’s AMP scripts and images from being fetched and executed, dramatically reducing the amount of information Google learns about your browsing.
Finally, Brave plans a third-step to protect users from AMP pages. Brave will extend our existing debouncing feature to detect when AMP URLs are about to be visited, and instead navigate users to the true version of the page. This work is under development and is planned for version 1.40.
Users who wish to continue visiting AMP versions of pages can continue to do so by going to brave://settings/shields and disabling De-AMP.
AMP 2.0 Will Be Even Worse
Google is currently developing a follow up to AMP, based around their Signed Exchange (SXG) and WebBundle proposals. This effort isn’t formally called AMP 2.0, but the goals are the same: allow more of the Web to be served from Google’s servers, and in ways that give users less control over how they interact with that content, and with less understanding of where that content is coming from.
Brave has previously shared its concerns with WebBundles, and why the proposal will kill the privacy, performance, and user-control benefits of many Web privacy tools. We’re encouraged that others in the privacy community share these concerns, and we continue to oppose this proposal in the W3C. We’ve also shared our alarm that SXG will harm user control and autonomy, especially when implemented alongside the rest of Google’s Privacy Sandbox proposal.
An ethical Web must be a user-first web, where users are in control of their browsing, and are aware of who they are communicating with. AMP (along with Google’s upcoming, actual name still to come, “AMP 2.0”) is incompatible with a user-first Web. De-AMP adds to the long list of Brave features that put users first on the Web.
-
In 2020 Google announced that Google would no longer require that sites use AMP to be placed in privileged locations on Google Search and Google News. Instead, Google announced that it would use an alternative “Core Web Vitals” (CWV) performance-scoring system to determine which sites qualify for privileged placement.
Some commentators have argued that this change shows Google is not using its monopoly power to control the direction of the Web. We disagree. Google still controls how CWV scores are determined, and what cutoffs are used for preferred placement. Further, and not coincidentally, using AMP seems to guarantee a sufficient CWV score.
Instead of being an attempt to foster an open Web, we believe that AMP and CWV together are a cynical effort to appear “open” to regulators, while in practice they enable Google to further control the shape and direction of the Web. ↩︎
This content originally appeared on Brave’s Latest News on Brave Browser and was authored by Brave’s Latest News on Brave Browser
Brave’s Latest News on Brave Browser | Sciencx (2022-04-19T00:00:00+00:00) De-AMP: Cutting Out Google and Enhancing Privacy. Retrieved from https://www.scien.cx/2022/04/19/de-amp-cutting-out-google-and-enhancing-privacy/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.