It's solely the search engine boost you get from AMP that bothers me. Because of the money involved many sites have no choice but to implement AMP and stay competitive. If it weren't for that, it would just be another technology and the fact that it only works in few circumstances would probably make many sites not bother with it. The UX downsides would probably see many sites actively avoid it.
The fact that it has seen such adoption is testament to Google's ability to influence with it's rankings alone.
Have you noticed ranking improvements? We've done AMP on some sites and not others and we saw no difference in ranking.
Sure, having a very quickly opened page is nice, but on the other hand, features are limited. That might or might not work well, depending on what kind of content you have, what engagement you're looking for.
Most people do not like to be forced to do things a certain way. Especially if they have a working site already and now have to remake it from the ground up just because some other actor decided it isn't good enough to get visitors.
Just you wait until you notice you can't go to town in your car any more. Only teslas are allowed into city.
That's a bad example for me personally since I think all cars should be banned (except maybe electric cars but I haven't done the necessary research to see the actual environmental impact). I haven't used my driver's license in years and always take the train (I've also stopped flying).
But anyway, that's off topic. I understand that it's a pain for developers but for users like me who are often on a bad connection it's a life saver.
On iOS it continues to be very broken, although the difference in scrolling "inertia" was resolved by Apple.
AMP introduces a very non-Appley top bar within the browser, adds new swipe semantics that can be confusing, breaks "tap status bar to scroll to top" behaviour, breaks reader mode (although this is inconsistent), and generally looks out of place. The best way to describe it is like a GTK or KDE app running in macOS. It's clearly not a "native" experience and doesn't really look or act like any other webpage in mobile Safari.
"Your website has been banned for illegal activity and all content has been deleted. The suspension is immediate and indefinite. Please consider using another Internet"
Also, their algorithms mistook live streaming of Notre Dame fires as 9/11 incident. How can live stream be a past incident?
You are confusing the term “live stream” to mean something actually happening at that moment in the real world. All a “live” stream actually is to Youtube or FB or any other streaming service is just incoming RTMP packets. Youtube matches incoming streams against their ContentID database just as they do for normal uploads. I would bet that the same thing would have happened if the same footage were uploaded normally after the fact. People will use unlisted streams to broadcast pirated content otherwise. I faced a similarly false claim once where me playing Super Mario World on a real life SNES was falsely matched to some major label song, and since it was my third strike (all false) my account got banned from being able to use Youtube Live entirely. In the end I’m kind of glad that happened because it led to me developing my own minimal self-hosted stream site for small friends-only streams, including things Youtube would give legit claims for. My tiny VPS wouldn’t stand up to thousands or probably even dozens of simultaneous viewers like Youtube or the other big names can, but that doesn’t matter at all for me.
"YouTube Live is an easy way to reach your audience in real time. Whether you're streaming a video game, hosting a live Q&A, or teaching a class, our tools will help you manage your stream and interact with viewers in real time."
Youtube live is supposed to be streaming of live events. My point is that their algorithms incorrectly decided a live stream was a past event. Even google/youtube acknowledged it was incorrect to tag a live event.
No it isn't. It's designed to make the user experience better on sites that frequently host Google ads (and also often contain a ton of bloat, 3rd party js, poorly constructed DOMs, awful CSS, etc).
The only way Google could proactively "solve" this problem was by creating a "standard", and then also offering to absorb end user traffic for sites that adopted the standard. FWIW, AMP is an open standard not solely owned or contributed to by Google.
Why is that the only way? Seems like they could easily have achieved the same result by significantly penalizing sites based on load time and number of external requests.
Because users want relevant search results much more than fast websites. Google already factors in a website's performance in their rankings, but weighing it too much over content relevance will make search results worse.
If they actually cared that much about making the results "relevant", they wouldn't mix a bunch of irrelevant suggestions into the results page, each marked with "missing: <query_term>" pointing out exactly how they ignored part of the user's request.
By that logic then, what's the point of AMP if Google is saying page load speeds aren't really that big of a factor? Why go through through the trouble of deriving a whole new subset of HTML?
A fast load time when a page is indexed does not guarantee a fast load time when it is served up to the actual viewer. Serving the page from cache is the only way to guarantee that the page will still be fast when the user wants to view it.
Because users want relevant search results much more than fast websites. Google already factors in a website's performance in their rankings, but weighing it too much over content relevance will make search results worse.
What's the difference between influencing positions and visibility based on AMP support vs overall page performance?
If visibility is influenced by AMP then Google benefits, users using Google services likely benefit, web developers suffer, users not using Google services to view the content continue to suffer (because companies will continue to maintain two versions of the website, a bloated version with 100 external tracking requests that will be shared on twitter/reddit/facebook/hn/etc, and an AMP version that will only appear on Googles services), and the internet as a whole suffer. Whereas if visibility is influenced by page speed+external requests then everyone would benefit.
- AMP is a transparent and unambiguous standard that leaves no uncertainty as to whether you are somehow "performant enough" to qualify for the simple but limited visibility boost (referring to the news carousel)
- AMP prevents important usability problems beyond performance, like page content jumping
- AMP can enable advanced/extreme performance optimizations by default that are somewhat rare in practice (eg. only loading images above the fold) or isn't really possible to do safely/properly without a spec like AMP (eg. preloading content before the user clicks the link without unpredictably disrupting the website's servers) or sometimes avoided due to cost (eg. fast global caching with Google's impressive CDN). Important for users in the developing world.
Addressing your other points:
- Users who don't use Google services don't suffer. AMP is not Google-exclusive, all the major search engines (like Bing, Yahoo, Yandex) are stakeholders in the AMP standard and are free to support AMP. AFAIK there is nothing in the AMP standard that favors Google over other search engines or any other platform that might support AMP.
- Not sure how web developers suffer more from AMP. I'd think web developers would suffer more from trying to wrangle their bloated website performance independently rather than use a standard toolkit that enforces best practices and enables difficult/expensive optimizations out of the box.
- It's not clear to me how the internet as a whole will suffer, but I suspect this is just general hyperbole and not a specific point.
7. Looking at the last few merged PRs nearly everyone involved is a Google employee. I realize this could be a coincidence but I'm not going to analyze the whole repo.
8. The TSC is 3/7 Google employees.
Regardless, until Google issues a legally binding release of the project to an independent organization it is owned by Google. The TSC and AC could be removed at Google's whim.
I partly agree with this. If you run a WordPress blog, then EasyEngine [1] and OpenLiteSpeed [2] can really boost your site performance.
The performance will be greatly affected if you run some cancerous theme with endless JavaScript calls. But both of the mentioned "engines" have changed the way I see blogging with WordPress.
Best of all, this is accessible to your average user as well. DigitalOcean can spin you up an OLS instance in a minute or so...
AMP pages loaded through Google search with hot cache load slower than some of the websites I've developed when loaded with cold cache.
It's absurdly slow, uses tons of unnecessary JS, and it is a privacy nightmare because now I can't just use server-side GDPR and ePrivacy guideline compliant analytics anymore, but either have to give up analytics entirely, or have to use privacy-obliterating Google Analytics.
And if a user ever loads the page with JS disabled (which all my sites are designed to support), AMP breaks and just shows nothing at all for over 8 seconds.
> AMP pages loaded through Google search with hot cache load slower than some of the websites I've developed when loaded with cold cache.
On a mobile device in India? Nonsense. Your page load time is dominated by latency, which the AMP user doesn't see because it is preloaded from near caches.
> uses tons of unnecessary JS,
Which of the JS is unnecessary? The JS to load images allows AMP not to preload images below the fold, which is absolutely necessary for speed and for being friendly to data plans.
> now I can't just use server-side GDPR and ePrivacy guideline compliant analytics anymore
Explain. You still get first party tracking that gets fired when the user clicks to your page and can get user consent via data-consent-notification-id.
> And if a user ever loads the page with JS disabled
In that case, it's the SERP's fault for showing the AMP page instead of the non-AMP page. In the normal JavaScript-enabled scenario, the SERP would be stupid to show your non-AMP page.
> On a mobile device in India? Nonsense. Your page load time is dominated by latency, which the AMP user doesn't see because it is preloaded from near caches.
My test device is a Huawei Ideos X3 on a 56kbit/s throttled 3G connection. The same effect also applies with a Pixel 1 on the same connection, or either of the devices on a modern 3.9G LTE connection. (Tested on O2 net in Germany, works reliably better than AMP even and especially while on a train — if you've ever tried using O2 on the intercity train between Hamburg and Münster you know that every third world country has better internet than, I've seen 8kbps with 13 seconds latency there)
> Which of the JS is unnecessary? The JS to load images allows AMP not to preload images below the fold, which is absolutely necessary for speed and for being friendly to data plans.
AMP uses megabytes of JS for that purpose, I do the same in under 1kiB (even including an intersection observer polyfill). And my CSS is much much smaller as well. Part of why I get a 100/100 in all pagespeed and lighthouse tests, including when simulating mobile connections, while AMP pages get only 60/100.
> Explain. You still get first party tracking that gets fired when the user clicks to your page and can get user consent via data-consent-notification-id.
I want JS-free analytics that do not require tracking or any consent (GDPR allows collecting some information without consent, same with the yet unreleased ePrivacy directive with which AMP is not compliant anyway).
What? Where are you pulling these numbers? Also, what do you mean by hot cache? I'm starting to suspect that you don't even understand that the AMP page (the JavaScript for sure, and often the entire HTML and above-the-fold images as well) is already on the user's device, while your page is not.
If the AMP version takes longer to load than the time between the search results loading and the user clicking on it, then the AMP version will still have a visible load time.
Obviously, this part is affected by the AMP js being in cache or not.
Still, often my own page can load faster than just this user-visible part of loading the AMP version.
AMP works best when the user visits almost only AMP pages (so the resources stay in cache), and the user has a high-latency high-bandwidth connection.
But that's almost nowhere in the world true, in reality most people have relatively low latency with low bandwidth.
Your claims disagree with the facts on the ground, where latency is the main factor affecting page load time. This is the driving force behind CDNs, HTTP2, QUIC, and pretty much every speed optimization that people have been working on in the past few years. https://www.afasterweb.com/2015/05/17/the-latency-effect/
Your claim that your page loads faster also reeks of wishful thinking. Pretty much every AMP page I have loaded from a SERP loads instantly, not just fast. For someone on a worse connection, the page will have started loading before the user clicks on the link from near caches versus have not started loading at all from a far server. In the rare case where the AMP JS is not in the browser cache, it will be after loading the first result.
As mentioned, I've done testing on actual devices on actual high-latency low-bandwith connections, hundreds of times. That's the "facts on the ground".
If you say pretty much every AMP page you've loaded has been instant, please post the specs of the devices and network you've been using for testing.
Additionally, if the latency between the device and the nearest server is over two seconds, the latency to a far server as well as the click latency don't even come into play anymore at all, instead the number of connections needed becomes much more important, and bandwidth also becomes a much larger factor.
Your claim that HTTP/2 would have worked towards better latency on lower connections is also false, on bad mobile connections HTTP/2 actually increases latency, which was a major reason for QUIC aka HTTP/3 in the first place.
> As mentioned, I've done testing on actual devices on actual high-latency low-bandwith connections, hundreds of times.
And as I've mentioned, you've been testing the wrong thing by not understanding the whole point of AMP (safe preloading).
> instead the number of connections needed becomes much more important
A page preloaded from an AMP cache needs at most one TCP connection, usually zero if it uses QUIC.
> and bandwidth also becomes a much larger factor.
Which also works in AMP's favor because the device doesn't need to load your custom JavaScript or potentially unoptimized images, just the tiny HTML and optimized images above the fold. The weight of this (and the associated gain) is tiny, which is why bandwidth is a relatively unimportant factor.
> On bad mobile connections HTTP/2 actually increases latency
You're mixing up dropped packets with high latency. That's neither here nor there because Google's and Cloudflare's AMP caches both use QUIC — my point was that latency is the key factor that all modern web speed technology has attacked, including AMP.
> AMP pages loaded through Google search with hot cache load slower than some of the websites I've developed when loaded with cold cache.
Basically this. AMP sets a hard upper bound for how fast your webpage can be. Have a purely static HTML+CSS blog but want to get the page rank boost from AMP? Just add reams of unnecessary Google Javascript to what should be a very simple site.
as long as google is using their grip on the web to drag crappy websites kicking and screaming into having acceptable load times, i'm okay with it.
yeah, there's a few sites out there that are faster than amp. but most of them are not, and before amp the trend was certainly not to make anything lighter or faster.
The experience on iOS remains profoundly buggy. The URL bar doesn't hide properly, scroll-to-top doesn't work, rotation is busted, text selection is wonky, reader mode is disabled. How I wish I could disable this monstrosity.
Nah I see AMP staying around long enough to capture a significant portion of web share that they mine data from. Essentially is just a way to insert themselves as "the internet"
What's wrong with it exactly... beside being weird. I'm not a fan of manipulating the URL the way they do with this change, but couldn't you just opt to not use AMP if you don't like it?
Ideally people would develop fast sites on their own, but apparently they need the help of Google.
The issue is that you can't, or you risk your site being basically blacklisted from google. Especially if your a news site.
Users have no control outside of not using google. If google were to provide a setting for the user to never see AMP, I would have less issue with this. But they don't
Instead, they basically force publishers to use this because if they don't the news carousel will not show their article.
It just gives Google more control over the web for minimal at best benefits
If you don't use AMP your search engine placement suffers. Often dramatically, as all the pages in Google's top-most carousel are all AMP pages.
And AMP is a pain in the ass. It's sold as being "just HTML" but it isn't, really. You can't even use an <img> tag, it has to be <amp-img>. So you have to generate two versions of every page. Achievable for large companies but if you don't have a lot of resources that's a big overhead. As is so often the case, it helps concentrate all web traffic to a smaller and smaller number of sites/publishers and shutting the rest out. That's not good.
This sounds terrible. Does it mean that browsers will begin lying to users and say that the users are visiting the website's server when they are really visiting a restricted version of the website that is hosted in Google's cache? I don't want my content restricted or hosted in Google's cache.
AMP doesn't load in a privacy sensitive way. It's on Google's servers and it takes many seconds to load if you have JavaScript disabled.
Also, the feature only works on Google Chrome and possibly Edge, which gives another point to the article below.
> I don't want my content restricted or hosted in Google's cache.
how is this different than using your own domain, but pointing it to a github.io page? Or using medium, but with your own domain (but still being served from medium's servers)?
Is it just google you're adverse to, or the entire idea of someone else hosting your content?
1) I want full control over my servers and to not be penalized in search engines for not hosting my sites on Google. Where are the server-side logs?
2) I want full control over how I publish my sites with real web standards. AMP is not a web standard, it's a Google format that they are strong-arming people into using.
3) Mozilla considers Signed HTTP Exchanges harmful. This technology is as bad as what Microsoft was doing with IE in the old days.
4) I don't publish on Github pages, but if I did, I would still have a choice over which servers I put the sites on.
5) There shouldn't be a single company (or few companies) that dictates how we publish online.
6) Shame on the people who are splitting the web with this fake-opensource technology. There's even a Google engineer over here referring to the Web like it's a Google product. https://news.ycombinator.com/item?id=19631136
As per point 6, I wouldn’t take what was said there as a statement from Google, or potentially even an employee of Google. They did it as a throwaway .. anybody wishing to kick the hornets nest could have posted that, employee or not.
It's not written like someone trying to kick a hornet's nest. It's written like someone who has been conditioned inside of a culture that has begun to view the Web as a Google product on some level.
That's a good point! Domain owners can host their websites wherever they like, and yes that includes Google's cloud.
If they go through a content network like Cloudflare, you can't even tell who's hosting the site by looking at the IP address.
It drives home the point that websites are abstractions that have no necessary relationship to any particular physical hardware. Network tools may or may not tell you a bit more about the source, depending on if there are any leaks in the abstraction.
There is a difference between the web publisher controlling that abstraction and a web publisher that has been strong armed into one abstraction or another.
However the last question is a fair point - nobody complains about CloudFlare's caching of your web page as you designed it.
The critique of AMP is that it receives privileged placement in search results, and that content authors are being pressured into adopting this de-facto Google-controlled spec, where they host your content and control its presentation. Anything that furthers AMP helps Google in this effort.
I didn't even know about "HTTP Exchanges", and I'm more interested than ~98% of the population about this kind of stuff.
Showing the name of the "signer" in the address bar, instead of the server where the content is actually hosted goes against decades of browser UI design.
> Showing the name of the "signer" in the address bar, instead of the server where the content is actually hosted goes against decades of browser UI design
Does it though? If you use Cloudflare or Akamai or Cloudfront or Netlify or etc. etc. then what shows up in the URL bar is not the server where the content is actually hosted. Well, it is the server where it is hosted, it's just one of the many domains hosted by that server.
That has never been different. Cloudflare & co are reverse proxies, for all intents and purposes from a user agent view, they are where the content is coming from. They are the ones pointed to in DNS, and they have valid SSL certs.
And how is this all that much different? In fact I would say it's more secure. DNS can be spoofed pretty easily. This is a cryptographically signed package. If anything, I'd have more faith in this changing my URL than a proxy via DNS.
Just because Google invented it doesn't make it bad.
But when there is a CDN there, "who I'm talking to" is really just an intermediary who pretends to be you, and may have in fact modified the content. With this, it is still an intermediary pretending to be you, but at least now the package is signed and can be verified.
The CDN is you, for all intents and purposes. It's your agent in the back and forth, as much as your hosting provider would be. A third-party cache isn't.
I don't mind that you can sign and verify content, that's fine and useful. I'm just not a fan of changing the address bar's meaning.
But what I'm saying is that the meaning that you ascribe to the address bar is incorrect -- it already only tells you who published the content, not who you are actually connected to.
What I'm saying is that this does not change the meaning of what's in the URL bar. It's the same as before. It tells you who published the content originally.
> it already only tells you who published the content
No, it tells you the origin of the document. If you are the creator, and you choose to put your content on server X it will tell you "I've got this from server X". Whether that server is a reverse proxy or a shared webhost or a dedicated server in a DC or a raspberry pi running on your desk doesn't matter - it's the designated original that you, the owner of example.org chose.
That's what it always meant, and it changes when you do a redirect, and it shows you the current URL even if there is a canonical header of http-equiv. I can put a reverse proxy on my host and proxy example.com to example.org - the address bar tells you that you're reading example.com, not example.org, as it should, because you're connected to me, not to example.org.
> In fact I would say it's more secure. DNS can be spoofed pretty easily. This is a cryptographically signed package
How is it more secure? If, as you say, DNS can be spoofed easily - I can easily get a certificate issued with the required extension and make a "cryptographically signed package".
> If, as you say, DNS can be spoofed easily - I can easily get a certificate issued with the required extension and make a "cryptographically signed package".
Spoofing DNS to clients is much easier than spoofing DNS to certificate authorities. Otherwise domain-validated HTTPS certs wouldn't mean much.
Do a trace route on any domain and you'll see that the server isn't the one that give you the answer, but some intermediary. Sure in that case when you did the request, the content is fresh and the server answered RIGHT NOW, but that cache still get the content from the server, it's just a bit older.
The browser displays the URL from the origin that digitally signed the unmodified content.
A browser already doesn't show you what server delivered the content. That would be your wifi AP, cell phone tower, or ISP node. The internet has already long established that we can trust content without trusting intermediaries.
There are two elements that are important: integrity and privacy. The content integrity is protected via a digital signature, the "signed" part of "signed http exchanges". The signature proves that the document hasn't been tampered with.
Regarding privacy: The intermediary (a search engine in this case) already has the content being delivered as a result of crawling it. It also knows the user clicked on a link to get that content, and knows the user's ip address. Even without AMP or Signed Exchanges, the privacy situation is the same. Once the page is loaded, all further interactions with the origin are normal https traffic, so later requests are not different in privacy either.
What this enables, for search results, is the ability to load the bytes of the content before the user clicks a search result. If the browser prefetched those bytes with the origin's awareness, then the user's privacy with respect to the search query would be violated, making prefetch problematic. With this setup, documents can be prefetched while preserving user privacy and after the user clicks all browser behavior continues as normal from that point forward.
Google can't tell if a link has been clicked if JavaScript is off and the `ping` attribute is removed, so AMP removes privacy there.
By forcing web publishers to host their content on a Google cache, they lose their server-side logging and the ability to determine how they set up they way they serve their own sites.
Also, why do you artificially slow page loads on AMP pages to 8 seconds when JavaScript is disabled? That is a privacy issue.
The linker (google in this case) could rewrite the link to use a redirector if they choose. If Javascript is off, AMP and thus Signed Exchanges are disabled on Google search results anyway.
You misunderstand the 8 second CSS animation in the AMP boilerplate. Here's the code (simplified):
<style>
body { animation:-amp-start 8s steps(1,end) 0s 1 normal both}
@keyframes -amp-start{from{visibility:hidden}to{visibility:visible}}
</style>
<noscript>
<style amp-boilerplate>
body{animation:none}
</style>
</noscript>
See the noscript section: if javascript is disabled, the CSS displays the body immediately. If Javascript is enabled, but for some reason the AMP javascript fails to load, after 8 seconds, the page is displayed anyway. The page is probably somewhat broken without the javascript loading, but the 8s is a fallback, not code to slow down non-javascript browsers.
There are legitimate (privacy/speed) reasons to not load AMP's JavaScript while still not turning of JavaScript entirely. Google does have the capability to know when you're on an AMP page, because the JS loads from ampproject.org, which is registered by Google.
An 8-second delay seems like an intentional "bug" to coerce users to turn on JavaScript (and advertising).
The javascript is heavily cached, so will not give a request on every page load.
That is not the intention. If javascript is disabled entirely, Google Search won't even load AMP pages. The scenario you describe of a user loading an AMP page directly without javascript enabled is somewhat rare.
Many people use tools to block third party JS from loading. AMP can't be called privacy-friendly while making it extremely difficult to use when tracking (AMP Analytics) is blocked. The 8-second delay happens to me every time I accidentally click an AMP URL in my browser.
I don't use Google Search, and I frequently get sent to Google's AMP cache via other link sources (e.g. HN).
I don't have javascript blocked, but I do have Google's tracking blocked via standard tracking protection (which is now a built-in feature in most non-Google browsers), which means <noscript> tags are not triggered, and I get the 8 second delay due to non-loading JS resources.
I don't think my setup is as rare as you make out.
AMP allows Google to see exactly how you interact with every page on the internet.
Just from the text of the pages you visit they can build a profile around you. What your interests are, how much of an article you're likely to finish, whether you're the type of person to highlight text as you read, etc.
Unless you live on an island with a poor satellite connection AMP is useless as anything more than a corporate user data collection tool.
If (or when) the share of that privacy-conscious users will rise, Google might motivate webmasters to compile GA scripts in the main JS script, and considering pretty much any website now a days just doesn't show content with no Javascript enabled, it would be much harder to avoid.
I browse mostly without javascript on and that's not true; easily more than half of websites work just fine without it, and that number goes far up if you accept some lack of features. Though there are some that indeed don't work at all.
Although your point is well taken that there could be ways to sneakily track users eventually despite the aforementioned measures, and potentially even without javascript being required (though I doubt that share of privacy-concious users will ever raise significantly - most people simply don't care).
We are talking about their AMP cache. If you don't use Google Service, except if you like to prepends their amp cache URL before your links, you'll never get there.
Their AMP cache happens only on their search service. They already know which links you click... having an AMP cache on top doesn't give them MORE information than they already get. The use of that cache also make sure the website doesn't get more information because it's preloaded.
AMP documents don't share user data with Google, which can be trivially seen by inspecting the network events that the page generates.
If the publisher chooses, they can send logging to Google Analytics, but this is not part of AMP.
The typical argument otherwise is that the AMP javascript is loaded from Google's cache, however these javascript resources allow for a very long cache lifetime (1yr if the page came from the Google Cache), so relatively few page loads will actually end up fetching them from the network for most users.
Edit: These resources are also on cookieless domains.
> The typical argument otherwise is that the AMP javascript is loaded from Google's cache, however these javascript resources allow for a very long cache lifetime (1yr if the page came from the Google Cache), so relatively few page loads will actually end up fetching them from the network for most users.
No, if Google can change the way web works from day one they can change anything they want. Don't forget Google is killing imap and dns already. Why not http to?
Also, Google explicitly states that it is collecting data in AMP Viewer [1]:
> The Google AMP Viewer is a hybrid environment where you can collect data about the user. Data collection by Google is governed by Google’s privacy policy.
I assume they collect information from HTTP request the browser sends when requesting an AMP page.
It is clear that the current developments on the web are worrysome and we need real privacy. We need to be able to find a website and visit it completely anonymous, unless we actively submit information to said website or a court order is issued.
A cell phone tower or ISP node is ideally just infrastructure, "plumbing". Google seems to be trying to advance their strategic position in that direction. Rather than just being one search engine among several, they are trying to become part of the infrastructure. This could prevent future privacy solutions (and even prevent competitions between search engines).
I think you're missing the point of the GP. It says that you don't know and you don't care which particular server returns your content - is it a self hosted machine, is it a cloud machine, is it a CDN? No way of knowing unless you inspect the deeper stack. What you see very visible is which BRAND (I. E. URL) returned your content.
So this Amp exhange technology changes nothing in this regard. It's like Google provides its own Free CDN, it is just not done in a traditional manner.
> It says that you don't know and you don't care which particular server returns your content
Which is plain wrong. I care.
When the URL-bar says I’m looking at company.com, I expect my browser to have used my OS’s DNS-resolver to look that name up, connect to the IP-given and nothing else.
I certainly don’t expect it to send traffic to certainly-not-the-nsa.com which are MITMing my traffic and tracking/monitoring it.
If I can’t trust my browsers URL-bar to exclusively and accurately reflect what is actually requested, it is effectively lying to me, the user, it’s owner.
And then suddenly all URLs are phishing URLs because Google made URLs no longer matter or mean anything.
My point is that even if you look at the URL bar currently and it says company.com, you don't know what you're connecting to. Probably you're connecting to CloudFlare/CloudFront/Akamai/Fastly/any other CDN which is set up with good-enough certs to impersonate the domain. Therefore you're not trusting a particular server, you're trusting a relationship that the domain owner built with her's service providers.
The proposed scheme is just another way to extend this kind of relationship that the publisher builds, a new mechanism if you will. There is nothing in there that requires more or less trust from your part than before.
You're complaining that need URLs to reflect what is requested - in fact, I argue that you want the URL to tell you what is being served. But this is not what's currently happening.
URLs are already lying to you.
I doubt that you WHOIS-lookup all DNS resolved-IPs to verify that the IP presenting a cert is assigned to the organisational entity that you want to connect to, and have a whitelist of those entities that you actually allow your browser to connect to. Because that's what currently required to make sure you don't go through CDNs and other intermediaries between you and the publisher.
Using a CDN currently means the company use trusted mechanisms like DNS to delegate certain traffic to other providers (like with Cloudflare). And it does so for everyone.
In which case the URL serves what was requested.
What AMP does is provide google.com content and lie to the user and says it comes from company.com.
Which isn’t true, and it only does so for users coming from google.com. Where I’m sure google will be happy for the additional tracking data.
This is NOT the url the user was lead to believe he requested. This is not what everyone else is served.
The real reason to make this spec is not to improve integrity o privacy or something else but to make users stay on Google's domain instead of going to other site. Google wants to build its little walled garden, and this spec is needed to make users think that the walls aren't there.
> With this setup, documents can be prefetched while preserving user privacy and after the user clicks all browser behavior continues as normal from that point forward.
But Google can already preload and show cached version of the page without this spec. The only difference would be that address bar shows "google.com" instead of publisher's domain. There is no need for this specification.
> AMP doesn't load in a privacy sensitive way. It's on Google's servers
Only if you load the page from a Google SERP, in which case, Google would already know if you visit the page. If it's loaded from a Bing SERP, it's served from a Bing server, and the same for Baidu and other AMP caches. This is far more privacy preserving than preloading a page from some third party web server that the user might never visit.
Signed HTTP exchanges may be harmful, but Google is beginning to get enough dominance so they implement it and browsers with a minor market share must follow or are left behind.
The behavior for browsers without support is to show the google.com/amp URL as before, along with a small html-based bar with additional information about the original domain and share intents.
Does that mean that the Google+ button is coming back? Seriously? Why not just serve the content and leave it at that? Is the tiny bit of extra data you get from a unique "share on Facebook" URL worth it?
I didn't know the Web Share API existed, but based on the RFC, it looks like yet another Google-driven "standard." I still don't see why it needs to be added to the page.
I've been using DDG for at least a year now. On some occasions I can't find what I need and end up checking Google, but in those cases, Google usually can't find what I need either.
Yeah, I think this feature and the signed exchanges standard both sound great. It allows CDN-like servers to host content without having to be trusted to not modify the content. That sounds like an improvement over the current CDN situation.
Also, sites that link to other sites can preload the linked site's content into the user's browser, without leaking the user's IP to the linked site, so if the user doesn't follow the link, nothing about the user is revealed to the linked site. That sounds like a performance and privacy improvement wrapped up into one. I'm finding the rest of this discussion thread extremely disappointing as it seems like most of the posts here are just "amp=bad and amp people like this so it's also bad".
Signed Exchanges could also remove some of the concerns around JavaScript crypto, because there is a (potentially offline) key that signs the web app you're running, so you're not vulnerable to hacks of the hosting environment itself.
What's really needed is a way for the browser to lock a given web app/package to a specific version (and hash), so that even if the signing key becomes compromised, the app can't auto-update to a newer version containing malicious code.
Combining this with something like Certificate/Binary Transparency would allow browsers to check that they are not being uniquely targeted with a specially altered version, and you could set a policy saying "Only auto-update to a newer version of this web app if its hash has been published in a log for more than a month (and/or endorsed by signatures from N out of M other organisations I trust)".
Semi-related, I think Web Packages and Signed Exchanges could have some usefulness outside of Google's caches. One of their spec examples was for verifiable web page archives.
Another idea it could be used for a wifi "drop box" (drop station?) when there's no internet connection around. That isn't uncommon at some popular spots up river into the woods in the US.
The idea is that as people enter the area, they can update the drop station automatically for things like news or public posts with whatever they've cached recently.
I'm pretty sure I read about this idea before the spec was drafted but I couldn't find or remember the site, something like vehicle-transported data.
Thanks. IIRC the site I saw was from a few years ago, before the spec was drafted. (I updated my post to be more clear). Pretty sure there was a few photographs on the page out in the flat grasslands.
In general, this sounds like an interesting use case.
One thing to note is that the specification currently limits the lifetime of a signed exchange to 7 days. It's possible that by exploring some of these use cases, especially offline, the spec could be improved with respect to some of these constraints.
Unfortunately, signed packages won't work for archival or any significant offline use. The signed exchanges are forced to be short lived (in days) to limit the damage that can be done when someone steals a TLS private key.
It's a very narrow spec designed just for AMP, basically.
Does nothing for publishers' needs for deeper control and analytics. Just a "feel good" gesture that results in additional complexity for everyone involved. Google is not the only company in the world that knows how to load a page efficiently.
The publisher's cookie-based analytics will operate on the origin in the URL bar in this case. The document (though not the delivery server) will have access to publisher origin cookies.
Conceptually, you can think of a signed exchange as a 301 redirect to a new URL which has already been cached by the browser (so there is no 2nd network event). The cache was populated by the contents of the signed exchange, assuming the signature validates.
With the peerweb.com platform I will be providing a free-for-non-commercial-use polyfill for Signed HTTP Exchanges which can be used for distributed p2p content offloading.
Peerweb helps sites automatically offload all resources (including streaming ugc video) to a decentralized p2p network.
The headline is an outright lie: these AMP pages are loaded from Google and not your domain.
The new feature is that Google's browser displays your domain, obscuring the fact that Google is doing the serving. The change is what is displayed, not the server.
When I had a website with embed videos from other sites, I had user contacting me because the other sites had some problems. They couldn't tell the difference between megavideo/youtube/dailymotion content and my site, so they came to me and blamed me.
So what this means is that not only Google bullies you into putting your traffic under their control, but now, any problem on their part will be blamed on you by the user.
> So what this means is that not only Google bullies you into putting your traffic under their control, but now, any problem on their part will be blamed on you by the user.
I hadn't even considered that. Add to this Google's notoriously absent customer support department and you have a recipe for a lot of frustration.
next month they'll also style it like your browser's native address bar for a better user experience and intoduce a w3c standard API for hiding the real address bar. /s?
They have been trying to make it so that users can't tell if they are on real webpages or AMP pages, and it looks like they finally implemented it. AMP is about Google, tracking, and ads, not page speed, even if they have convinced many of their engineers that it's about page speed.
So, when will Google roll out signed exchanges for plain HTML content? That's much more interesting, and if combined with e.g. a restriction such as a Lighthouse speed score of > 60, it'd be in all measurable ways better than AMP.
Faster than AMP, more open than AMP, and all the benefits of AMP.
Remember the talk about how the Chrome team was going to "rethink" the navbar, and what domain and site identity really mean? And people were a little worried about this?
Turns out people were right to be suspicious. This is hot garbage. You can no longer ask a user "What URL does your navbar say you're at?". It is no longer a source of truth. They will actively be lied to.
there was no need to be suspicious. google wasn't being sneaky about it, they have been actively talking about, promoting, and openly developing this feature for at least a year.
But what does it mean that you are on a particular URL?
For a long time already it's not being connecter to a particular physical server. Now it's the next step - to be completely decoupled from the server and just mean content instead.
This is meant to offload tracking from just Google Analytics and SERP clicks, which is used to track user behavior (but can be blocked) into services that cannot be blocked beyond Google domains.
If Google hosts the website and is masking the resulting url, they're able to have more visibility than Google analytics. They'll likely give this AMP some SEO boost temporarily and that will get web admins to adopt the technology.
It's just like reCaptcha, which is used to track users across the web (requires google.com + gstatic.com urls to load, which drops its own cookies or scans existing ones), blocking recaptcha will break core web functionality... and recaptcha v3 is even worse.
Web publishers don't necessarily want their content decoupled from their own servers, but they don't have a choice now if they depend on traffic from Google.
You are not decoupled from the server. Google still sees HTTP request you make in plaintext and collects your data according to their privacy policy. It just won't be obvious because of publisher's URL in the address bar.
This feels like it solves the biggest user complaint with AMP, which was the ugly URLs and having to click an extra time to get the "real URL" for sharing.
It also at least helps slightly address one of the complaints of publishers, which is that cookies and some analytics will work now.
But it still doesn't address the biggest complaints of publishers.
I'm guessing Google cares a lot more about the user experience than the publisher experience, since users make up most of the traffic and all of the ad consumption, so this is certainly good for them!
Who is going to be in charge of the signing process? Can I sign the content myself? Will Google eventually only sign content it deems appropriate? Can we trust Google to always do the right thing?
Good question. The signing is done by the publisher, using the same digital signature infrastructure that is used for TLS (https). So, the publisher alone has the signing key, and any browser can verify the signature by comparing to the public certificate, signed by a certificate authority.
339 comments
[ 4.7 ms ] story [ 202 ms ] threadThe fact that it has seen such adoption is testament to Google's ability to influence with it's rankings alone.
Sure, having a very quickly opened page is nice, but on the other hand, features are limited. That might or might not work well, depending on what kind of content you have, what engagement you're looking for.
Just you wait until you notice you can't go to town in your car any more. Only teslas are allowed into city.
But anyway, that's off topic. I understand that it's a pain for developers but for users like me who are often on a bad connection it's a life saver.
AMP introduces a very non-Appley top bar within the browser, adds new swipe semantics that can be confusing, breaks "tap status bar to scroll to top" behaviour, breaks reader mode (although this is inconsistent), and generally looks out of place. The best way to describe it is like a GTK or KDE app running in macOS. It's clearly not a "native" experience and doesn't really look or act like any other webpage in mobile Safari.
Type "amp sucks" into a search engine to find out more.
Also, their algorithms mistook live streaming of Notre Dame fires as 9/11 incident. How can live stream be a past incident?
https://abcnews.go.com/Business/youtube-mistakenly-flags-not...
"YouTube Live is an easy way to reach your audience in real time. Whether you're streaming a video game, hosting a live Q&A, or teaching a class, our tools will help you manage your stream and interact with viewers in real time."
Youtube live is supposed to be streaming of live events. My point is that their algorithms incorrectly decided a live stream was a past event. Even google/youtube acknowledged it was incorrect to tag a live event.
Amp is designed to tighten googles grip on the web, nothing more.
The only way Google could proactively "solve" this problem was by creating a "standard", and then also offering to absorb end user traffic for sites that adopted the standard. FWIW, AMP is an open standard not solely owned or contributed to by Google.
https://amp.dev/
I've yet to see a Google engineer, executive, or "fanboy" address this question adequately.
This thread will be no exception. Queue the crickets.
If visibility is influenced by AMP then Google benefits, users using Google services likely benefit, web developers suffer, users not using Google services to view the content continue to suffer (because companies will continue to maintain two versions of the website, a bloated version with 100 external tracking requests that will be shared on twitter/reddit/facebook/hn/etc, and an AMP version that will only appear on Googles services), and the internet as a whole suffer. Whereas if visibility is influenced by page speed+external requests then everyone would benefit.
- AMP is a transparent and unambiguous standard that leaves no uncertainty as to whether you are somehow "performant enough" to qualify for the simple but limited visibility boost (referring to the news carousel)
- AMP prevents important usability problems beyond performance, like page content jumping
- AMP can enable advanced/extreme performance optimizations by default that are somewhat rare in practice (eg. only loading images above the fold) or isn't really possible to do safely/properly without a spec like AMP (eg. preloading content before the user clicks the link without unpredictably disrupting the website's servers) or sometimes avoided due to cost (eg. fast global caching with Google's impressive CDN). Important for users in the developing world.
Addressing your other points:
- Users who don't use Google services don't suffer. AMP is not Google-exclusive, all the major search engines (like Bing, Yahoo, Yandex) are stakeholders in the AMP standard and are free to support AMP. AFAIK there is nothing in the AMP standard that favors Google over other search engines or any other platform that might support AMP.
- Not sure how web developers suffer more from AMP. I'd think web developers would suffer more from trying to wrangle their bloated website performance independently rather than use a standard toolkit that enforces best practices and enables difficult/expensive optimizations out of the box.
- It's not clear to me how the internet as a whole will suffer, but I suspect this is just general hyperbole and not a specific point.
> https://amp.dev/
amp.dev is owned and controlled by Google. ampproject.org is owned and controlled by Google. The core AMP team are Google employees.
How can you possibly say it's not owned by Google?
https://blog.amp.dev/2018/09/18/governance/
The TSC is independent and, at this point, the committee code commits are almost 4x the volume of Googler commits.
2. The privacy policy on amp.dev is Google's.
3. Both sites are hosted by Google.
4. The license in the amphtml repo says copyright Google.
5. The OWNERS.yaml file in the amphtml repo list 3 people, all of whom work for google.
6. Per the contributing code readme, contributing code requires signing this Google CLA: https://cla.developers.google.com/about/google-individual
7. Looking at the last few merged PRs nearly everyone involved is a Google employee. I realize this could be a coincidence but I'm not going to analyze the whole repo.
8. The TSC is 3/7 Google employees.
Regardless, until Google issues a legally binding release of the project to an independent organization it is owned by Google. The TSC and AC could be removed at Google's whim.
The performance will be greatly affected if you run some cancerous theme with endless JavaScript calls. But both of the mentioned "engines" have changed the way I see blogging with WordPress.
Best of all, this is accessible to your average user as well. DigitalOcean can spin you up an OLS instance in a minute or so...
[1]: https://easyengine.io/
[2]: https://openlitespeed.org/
It's absurdly slow, uses tons of unnecessary JS, and it is a privacy nightmare because now I can't just use server-side GDPR and ePrivacy guideline compliant analytics anymore, but either have to give up analytics entirely, or have to use privacy-obliterating Google Analytics.
And if a user ever loads the page with JS disabled (which all my sites are designed to support), AMP breaks and just shows nothing at all for over 8 seconds.
On a mobile device in India? Nonsense. Your page load time is dominated by latency, which the AMP user doesn't see because it is preloaded from near caches.
> uses tons of unnecessary JS,
Which of the JS is unnecessary? The JS to load images allows AMP not to preload images below the fold, which is absolutely necessary for speed and for being friendly to data plans.
> now I can't just use server-side GDPR and ePrivacy guideline compliant analytics anymore
Explain. You still get first party tracking that gets fired when the user clicks to your page and can get user consent via data-consent-notification-id.
> And if a user ever loads the page with JS disabled
In that case, it's the SERP's fault for showing the AMP page instead of the non-AMP page. In the normal JavaScript-enabled scenario, the SERP would be stupid to show your non-AMP page.
My test device is a Huawei Ideos X3 on a 56kbit/s throttled 3G connection. The same effect also applies with a Pixel 1 on the same connection, or either of the devices on a modern 3.9G LTE connection. (Tested on O2 net in Germany, works reliably better than AMP even and especially while on a train — if you've ever tried using O2 on the intercity train between Hamburg and Münster you know that every third world country has better internet than, I've seen 8kbps with 13 seconds latency there)
> Which of the JS is unnecessary? The JS to load images allows AMP not to preload images below the fold, which is absolutely necessary for speed and for being friendly to data plans.
AMP uses megabytes of JS for that purpose, I do the same in under 1kiB (even including an intersection observer polyfill). And my CSS is much much smaller as well. Part of why I get a 100/100 in all pagespeed and lighthouse tests, including when simulating mobile connections, while AMP pages get only 60/100.
> Explain. You still get first party tracking that gets fired when the user clicks to your page and can get user consent via data-consent-notification-id.
I want JS-free analytics that do not require tracking or any consent (GDPR allows collecting some information without consent, same with the yet unreleased ePrivacy directive with which AMP is not compliant anyway).
What? Where are you pulling these numbers? Also, what do you mean by hot cache? I'm starting to suspect that you don't even understand that the AMP page (the JavaScript for sure, and often the entire HTML and above-the-fold images as well) is already on the user's device, while your page is not.
Obviously, this part is affected by the AMP js being in cache or not.
Still, often my own page can load faster than just this user-visible part of loading the AMP version.
AMP works best when the user visits almost only AMP pages (so the resources stay in cache), and the user has a high-latency high-bandwidth connection.
But that's almost nowhere in the world true, in reality most people have relatively low latency with low bandwidth.
Your claim that your page loads faster also reeks of wishful thinking. Pretty much every AMP page I have loaded from a SERP loads instantly, not just fast. For someone on a worse connection, the page will have started loading before the user clicks on the link from near caches versus have not started loading at all from a far server. In the rare case where the AMP JS is not in the browser cache, it will be after loading the first result.
If you say pretty much every AMP page you've loaded has been instant, please post the specs of the devices and network you've been using for testing.
Additionally, if the latency between the device and the nearest server is over two seconds, the latency to a far server as well as the click latency don't even come into play anymore at all, instead the number of connections needed becomes much more important, and bandwidth also becomes a much larger factor.
Your claim that HTTP/2 would have worked towards better latency on lower connections is also false, on bad mobile connections HTTP/2 actually increases latency, which was a major reason for QUIC aka HTTP/3 in the first place.
And as I've mentioned, you've been testing the wrong thing by not understanding the whole point of AMP (safe preloading).
> instead the number of connections needed becomes much more important
A page preloaded from an AMP cache needs at most one TCP connection, usually zero if it uses QUIC.
> and bandwidth also becomes a much larger factor.
Which also works in AMP's favor because the device doesn't need to load your custom JavaScript or potentially unoptimized images, just the tiny HTML and optimized images above the fold. The weight of this (and the associated gain) is tiny, which is why bandwidth is a relatively unimportant factor.
> On bad mobile connections HTTP/2 actually increases latency
You're mixing up dropped packets with high latency. That's neither here nor there because Google's and Cloudflare's AMP caches both use QUIC — my point was that latency is the key factor that all modern web speed technology has attacked, including AMP.
Basically this. AMP sets a hard upper bound for how fast your webpage can be. Have a purely static HTML+CSS blog but want to get the page rank boost from AMP? Just add reams of unnecessary Google Javascript to what should be a very simple site.
yeah, there's a few sites out there that are faster than amp. but most of them are not, and before amp the trend was certainly not to make anything lighter or faster.
I'm frankly shocked that people can't see this land grab for what it is.
[Working on AMP at Google]
Ideally people would develop fast sites on their own, but apparently they need the help of Google.
Users have no control outside of not using google. If google were to provide a setting for the user to never see AMP, I would have less issue with this. But they don't
Instead, they basically force publishers to use this because if they don't the news carousel will not show their article. It just gives Google more control over the web for minimal at best benefits
And AMP is a pain in the ass. It's sold as being "just HTML" but it isn't, really. You can't even use an <img> tag, it has to be <amp-img>. So you have to generate two versions of every page. Achievable for large companies but if you don't have a lot of resources that's a big overhead. As is so often the case, it helps concentrate all web traffic to a smaller and smaller number of sites/publishers and shutting the rest out. That's not good.
If there are some benefits to it why shouldn't those benefits be standardized? Is Google preventing the standardization of AMP?
This is false. as a user I cannot easily opt out of using AMP
AMP doesn't load in a privacy sensitive way. It's on Google's servers and it takes many seconds to load if you have JavaScript disabled.
Also, the feature only works on Google Chrome and possibly Edge, which gives another point to the article below.
https://www.zdnet.com/article/former-mozilla-exec-google-has...
AMP is a fundamentally bad idea that needs to disappear.
Edit: Mozilla has marked Signed HTTP Exchanges as harmful.
https://mozilla.github.io/standards-positions/
how is this different than using your own domain, but pointing it to a github.io page? Or using medium, but with your own domain (but still being served from medium's servers)?
Is it just google you're adverse to, or the entire idea of someone else hosting your content?
2) I want full control over how I publish my sites with real web standards. AMP is not a web standard, it's a Google format that they are strong-arming people into using.
3) Mozilla considers Signed HTTP Exchanges harmful. This technology is as bad as what Microsoft was doing with IE in the old days.
4) I don't publish on Github pages, but if I did, I would still have a choice over which servers I put the sites on.
5) There shouldn't be a single company (or few companies) that dictates how we publish online.
6) Shame on the people who are splitting the web with this fake-opensource technology. There's even a Google engineer over here referring to the Web like it's a Google product. https://news.ycombinator.com/item?id=19631136
My point is, you cannot just blindly trust anonymous comments to be who they say they are, it’s an easy way to get yourself in trouble.
If they go through a content network like Cloudflare, you can't even tell who's hosting the site by looking at the IP address.
It drives home the point that websites are abstractions that have no necessary relationship to any particular physical hardware. Network tools may or may not tell you a bit more about the source, depending on if there are any leaks in the abstraction.
However the last question is a fair point - nobody complains about CloudFlare's caching of your web page as you designed it.
The critique of AMP is that it receives privileged placement in search results, and that content authors are being pressured into adopting this de-facto Google-controlled spec, where they host your content and control its presentation. Anything that furthers AMP helps Google in this effort.
Showing the name of the "signer" in the address bar, instead of the server where the content is actually hosted goes against decades of browser UI design.
Good on Mozilla for marking it as harmful.
Does it though? If you use Cloudflare or Akamai or Cloudfront or Netlify or etc. etc. then what shows up in the URL bar is not the server where the content is actually hosted. Well, it is the server where it is hosted, it's just one of the many domains hosted by that server.
Just because Google invented it doesn't make it bad.
It changes the meaning of the address bar from "this is who I'm talking to" to "this is who (at some point in time) signed this content".
I don't mind that you can sign and verify content, that's fine and useful. I'm just not a fan of changing the address bar's meaning.
What I'm saying is that this does not change the meaning of what's in the URL bar. It's the same as before. It tells you who published the content originally.
No, it tells you the origin of the document. If you are the creator, and you choose to put your content on server X it will tell you "I've got this from server X". Whether that server is a reverse proxy or a shared webhost or a dedicated server in a DC or a raspberry pi running on your desk doesn't matter - it's the designated original that you, the owner of example.org chose.
That's what it always meant, and it changes when you do a redirect, and it shows you the current URL even if there is a canonical header of http-equiv. I can put a reverse proxy on my host and proxy example.com to example.org - the address bar tells you that you're reading example.com, not example.org, as it should, because you're connected to me, not to example.org.
How is it more secure? If, as you say, DNS can be spoofed easily - I can easily get a certificate issued with the required extension and make a "cryptographically signed package".
Spoofing DNS to clients is much easier than spoofing DNS to certificate authorities. Otherwise domain-validated HTTPS certs wouldn't mean much.
Do a trace route on any domain and you'll see that the server isn't the one that give you the answer, but some intermediary. Sure in that case when you did the request, the content is fresh and the server answered RIGHT NOW, but that cache still get the content from the server, it's just a bit older.
A browser already doesn't show you what server delivered the content. That would be your wifi AP, cell phone tower, or ISP node. The internet has already long established that we can trust content without trusting intermediaries.
There are two elements that are important: integrity and privacy. The content integrity is protected via a digital signature, the "signed" part of "signed http exchanges". The signature proves that the document hasn't been tampered with.
Regarding privacy: The intermediary (a search engine in this case) already has the content being delivered as a result of crawling it. It also knows the user clicked on a link to get that content, and knows the user's ip address. Even without AMP or Signed Exchanges, the privacy situation is the same. Once the page is loaded, all further interactions with the origin are normal https traffic, so later requests are not different in privacy either.
What this enables, for search results, is the ability to load the bytes of the content before the user clicks a search result. If the browser prefetched those bytes with the origin's awareness, then the user's privacy with respect to the search query would be violated, making prefetch problematic. With this setup, documents can be prefetched while preserving user privacy and after the user clicks all browser behavior continues as normal from that point forward.
By forcing web publishers to host their content on a Google cache, they lose their server-side logging and the ability to determine how they set up they way they serve their own sites.
Also, why do you artificially slow page loads on AMP pages to 8 seconds when JavaScript is disabled? That is a privacy issue.
You misunderstand the 8 second CSS animation in the AMP boilerplate. Here's the code (simplified):
See the noscript section: if javascript is disabled, the CSS displays the body immediately. If Javascript is enabled, but for some reason the AMP javascript fails to load, after 8 seconds, the page is displayed anyway. The page is probably somewhat broken without the javascript loading, but the 8s is a fallback, not code to slow down non-javascript browsers.An 8-second delay seems like an intentional "bug" to coerce users to turn on JavaScript (and advertising).
That is not the intention. If javascript is disabled entirely, Google Search won't even load AMP pages. The scenario you describe of a user loading an AMP page directly without javascript enabled is somewhat rare.
I don't have javascript blocked, but I do have Google's tracking blocked via standard tracking protection (which is now a built-in feature in most non-Google browsers), which means <noscript> tags are not triggered, and I get the 8 second delay due to non-loading JS resources.
I don't think my setup is as rare as you make out.
Just from the text of the pages you visit they can build a profile around you. What your interests are, how much of an article you're likely to finish, whether you're the type of person to highlight text as you read, etc.
Unless you live on an island with a poor satellite connection AMP is useless as anything more than a corporate user data collection tool.
Although your point is well taken that there could be ways to sneakily track users eventually despite the aforementioned measures, and potentially even without javascript being required (though I doubt that share of privacy-concious users will ever raise significantly - most people simply don't care).
Their AMP cache happens only on their search service. They already know which links you click... having an AMP cache on top doesn't give them MORE information than they already get. The use of that cache also make sure the website doesn't get more information because it's preloaded.
If the publisher chooses, they can send logging to Google Analytics, but this is not part of AMP.
The typical argument otherwise is that the AMP javascript is loaded from Google's cache, however these javascript resources allow for a very long cache lifetime (1yr if the page came from the Google Cache), so relatively few page loads will actually end up fetching them from the network for most users.
Edit: These resources are also on cookieless domains.
Christ this is thin as a privacy argument.
They might not now, but could ‘t Google start creating unique URLs on each page, allowing them to track you that way?
Is there anything preventing Google from changing this later?
> The Google AMP Viewer is a hybrid environment where you can collect data about the user. Data collection by Google is governed by Google’s privacy policy.
I assume they collect information from HTTP request the browser sends when requesting an AMP page.
[1] https://developers.google.com/search/docs/guides/about-amp#a...
A cell phone tower or ISP node is ideally just infrastructure, "plumbing". Google seems to be trying to advance their strategic position in that direction. Rather than just being one search engine among several, they are trying to become part of the infrastructure. This could prevent future privacy solutions (and even prevent competitions between search engines).
No. Incorrect. Completely backwards. Factually wrong. You just failed your networking-exam.
Those things you mentioned would be transparent networking nodes forwarding your TCP-packets and they have nothing to do with any layers above that.
The fact that you don’t even know this completely invalidates any other point you may have.
So this Amp exhange technology changes nothing in this regard. It's like Google provides its own Free CDN, it is just not done in a traditional manner.
Which is plain wrong. I care.
When the URL-bar says I’m looking at company.com, I expect my browser to have used my OS’s DNS-resolver to look that name up, connect to the IP-given and nothing else.
I certainly don’t expect it to send traffic to certainly-not-the-nsa.com which are MITMing my traffic and tracking/monitoring it.
If I can’t trust my browsers URL-bar to exclusively and accurately reflect what is actually requested, it is effectively lying to me, the user, it’s owner.
And then suddenly all URLs are phishing URLs because Google made URLs no longer matter or mean anything.
Completely unacceptable.
The proposed scheme is just another way to extend this kind of relationship that the publisher builds, a new mechanism if you will. There is nothing in there that requires more or less trust from your part than before.
You're complaining that need URLs to reflect what is requested - in fact, I argue that you want the URL to tell you what is being served. But this is not what's currently happening.
URLs are already lying to you.
I doubt that you WHOIS-lookup all DNS resolved-IPs to verify that the IP presenting a cert is assigned to the organisational entity that you want to connect to, and have a whitelist of those entities that you actually allow your browser to connect to. Because that's what currently required to make sure you don't go through CDNs and other intermediaries between you and the publisher.
In which case the URL serves what was requested.
What AMP does is provide google.com content and lie to the user and says it comes from company.com.
Which isn’t true, and it only does so for users coming from google.com. Where I’m sure google will be happy for the additional tracking data.
This is NOT the url the user was lead to believe he requested. This is not what everyone else is served.
This is malware.
> With this setup, documents can be prefetched while preserving user privacy and after the user clicks all browser behavior continues as normal from that point forward.
But Google can already preload and show cached version of the page without this spec. The only difference would be that address bar shows "google.com" instead of publisher's domain. There is no need for this specification.
Only if you load the page from a Google SERP, in which case, Google would already know if you visit the page. If it's loaded from a Bing SERP, it's served from a Bing server, and the same for Baidu and other AMP caches. This is far more privacy preserving than preloading a page from some third party web server that the user might never visit.
Yeah, I didn't think so.
Does that mean that the Google+ button is coming back? Seriously? Why not just serve the content and leave it at that? Is the tiny bit of extra data you get from a unique "share on Facebook" URL worth it?
> The Navigator.share() method invokes the native sharing mechanism of the device as part of the Web Share API.
One could imagine replacing the serving layer with something like BitTorrent or IPFS.
Also, sites that link to other sites can preload the linked site's content into the user's browser, without leaking the user's IP to the linked site, so if the user doesn't follow the link, nothing about the user is revealed to the linked site. That sounds like a performance and privacy improvement wrapped up into one. I'm finding the rest of this discussion thread extremely disappointing as it seems like most of the posts here are just "amp=bad and amp people like this so it's also bad".
What's really needed is a way for the browser to lock a given web app/package to a specific version (and hash), so that even if the signing key becomes compromised, the app can't auto-update to a newer version containing malicious code.
Combining this with something like Certificate/Binary Transparency would allow browsers to check that they are not being uniquely targeted with a specially altered version, and you could set a policy saying "Only auto-update to a newer version of this web app if its hash has been published in a log for more than a month (and/or endorsed by signatures from N out of M other organisations I trust)".
Another idea it could be used for a wifi "drop box" (drop station?) when there's no internet connection around. That isn't uncommon at some popular spots up river into the woods in the US.
The idea is that as people enter the area, they can update the drop station automatically for things like news or public posts with whatever they've cached recently.
I'm pretty sure I read about this idea before the spec was drafted but I couldn't find or remember the site, something like vehicle-transported data.
One thing to note is that the specification currently limits the lifetime of a signed exchange to 7 days. It's possible that by exploring some of these use cases, especially offline, the spec could be improved with respect to some of these constraints.
It's a very narrow spec designed just for AMP, basically.
Conceptually, you can think of a signed exchange as a 301 redirect to a new URL which has already been cached by the browser (so there is no 2nd network event). The cache was populated by the contents of the signed exchange, assuming the signature validates.
Peerweb helps sites automatically offload all resources (including streaming ugc video) to a decentralized p2p network.
ETA: ~1yr
The new feature is that Google's browser displays your domain, obscuring the fact that Google is doing the serving. The change is what is displayed, not the server.
What Google actually means here is "We make AMP pages _appear_ to come from your own domain".
That's something entirely different.
This whole thing is just more doublespeak.
When I had a website with embed videos from other sites, I had user contacting me because the other sites had some problems. They couldn't tell the difference between megavideo/youtube/dailymotion content and my site, so they came to me and blamed me.
So what this means is that not only Google bullies you into putting your traffic under their control, but now, any problem on their part will be blamed on you by the user.
I hadn't even considered that. Add to this Google's notoriously absent customer support department and you have a recipe for a lot of frustration.
So Google’s browser now directly lie to the user about what’s being loaded?
I bet the SSL mark is still there though?
How can anyone trust this Googlan horse?
This is why you don’t make a browser and control major web-assets at the same time. These lines should not be muddied.
Faster than AMP, more open than AMP, and all the benefits of AMP.
Turns out people were right to be suspicious. This is hot garbage. You can no longer ask a user "What URL does your navbar say you're at?". It is no longer a source of truth. They will actively be lied to.
For a long time already it's not being connecter to a particular physical server. Now it's the next step - to be completely decoupled from the server and just mean content instead.
If Google hosts the website and is masking the resulting url, they're able to have more visibility than Google analytics. They'll likely give this AMP some SEO boost temporarily and that will get web admins to adopt the technology.
It's just like reCaptcha, which is used to track users across the web (requires google.com + gstatic.com urls to load, which drops its own cookies or scans existing ones), blocking recaptcha will break core web functionality... and recaptcha v3 is even worse.
It also at least helps slightly address one of the complaints of publishers, which is that cookies and some analytics will work now.
But it still doesn't address the biggest complaints of publishers.
I'm guessing Google cares a lot more about the user experience than the publisher experience, since users make up most of the traffic and all of the ad consumption, so this is certainly good for them!
I'm not entirely a fan of this, though it could have uses in other places;
Debian for example, could use this to enable HTTPS-like security without requiring mirrors to upgrade their security to the late 2000's.
Split Alphabet already.
Don’t use Google search.
That’s all. That’s really all there is to it. You should give it a try!
One example: https://news.ycombinator.com/item?id=19679136 , luckily someone also provided the non-amp equivalent...