[0] For instance, Mozilla considers the current specification to be harmful[1].
(Unless you're using CloudFlare)
[1] https://github.com/mozilla/standards-positions/issues/29#iss...
[0] https://github.com/mozilla/standards-positions/issues/29#iss...
What will stop Google from down-grading 2nd class URLs (ie, not hosted with google) to page 2 results?
It's effectively the same thing as having no AMP at all, yet they cleverly got everyone on board with this tactic.
Edit: I just skimmed through this... this looks _WORSE_ than having Google show their domain. This is some of the sneakiest most deceitful garbage I could have ever imagined.
Just no way. Need convincing? Look at the animated gif half way down:
https://3.bp.blogspot.com/-Xqfy7IhiTzc/XLY7goySWzI/AAAAAAAAD...
Because yes that's true, although cryptography it's maybe half true.
Now, they want to remove the remaining user interface element that says they’re spying on me!
Also, this makes it even harder to ad block their junk at the network layer (is foo.com down, or is this more amp bs?)
> 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.
With replaced URL it will be more difficult to spot.
[1] https://developers.google.com/search/docs/guides/about-amp
Not the public reason, but absolutely the private reason.
If Google, Apple, Amazon, Microsoft, or whatever publicly traded company makes a move its for money and power and preferably power, since that yields even more money.
AMP on web and email is the perfection of embrace, extend and extinguish
https://blogs.bing.com/Webmaster-Blog/September-2018/Introdu...
IMO, while the URL problem was a big issue, the bigger issue is that AMP's restrictions and limitations gives your users a neutered user experience in the final end. As others have pointed out, if it wasn't for Google's implicit requirement to implement AMP (e.g. to get into their carousel and other locations), AMP would have been DOA.
[1] https://amp.dev/documentation/guides-and-tutorials/optimize-...
Converting web pages into AMP isn't something you can automate, but supporting signed exchanges is. You need certificate authorities to support the flag and web servers support the protocol, but if this catches on then the only thing you'll need from the site owner is the decision on whether to allow it.
(Disclosure: I work for Google)
Sometimes, Google needs a gentle nudge from users saying "we don't like this" and hope they reconsider (I doubt it).
Let's Encrypt's response:
I think it’s likely too early in
this draft’s development for Let’s
Encrypt to prioritize implementation.
It looks like it has a ways to go
within the IETF before it would be
an internet standard.
* I like that when AMP is used for ads then the ads are fully declarative. Advertisers getting to run custom javascript, even in a cross-domain iframe, isn't great.
* I like that AMP allows sites (currently primarily search engines) to trigger preloading in a way that doesn't leak information to the site that is being preloaded.
* I like the way things like "sorry AMP only allows us to use 50k of CSS" can give developers leverage to push back against bad site designs.
* I like that it centralizes some measurements: instead of every ad provider using their own custom polling system to determine if the ad is on screen they can all subscribe to events triggered by a single well written system. This doesn't affect the amount of tracking (there's lots either way) but it makes it hurt the user experience less.
On the other hand, I don't like that:
* AMP uses a ton of JS, and if all you want is a simple website it's going to slow things down in the non-preloaded case. For example, taking a random post on my site (https://www.jefftk.com/p/trycontra-implementation and https://www.jefftk.com/p/trycontra-implementation.amp) I see a median speed index of 1.611s on non-AMP but 2.051s on AMP: https://www.webpagetest.org/result/190417_XB_22673cb98ce390a... https://www.webpagetest.org/result/190417_PS_1a60378762d87fb...
* A lot of people that don't want to implement AMP are doing it because then they get more search traffic. I understand how there isn't currently a non-AMP way of doing preloading in a way that doesn't leak information to the site (see above) but I think Web Packaging should be extended to support this in the general case and allow publishers to use AMP only if they want to.
* The interaction between AMP and content blockers isn't great. If you have a content blocker set to allow some JS but not all (for example, no third party JS) then it's not going to run the AMP JS or the contents of the <noscript> block, and AMP pages will render with 8s of white screen before the CSS times out. This is a pain, but I'm not sure what the right way to fix it would be. (I wish content blockers were smart enough to figure out which <noscript> tags to run, but that's probably asking too much.)
If you wanted to expand on how AMP seems like an attempt at a walled garden I would be interested in reading it; I haven't previously read any explanations that made sense.
If they don't/won't, no matter what your justification for why is (you believe it will provide speed, security, whatever), that's one of the walls.
Sure, you can not use it, but does that limit your ability to be found on the internet? If yes, then there's that wall again.
They're in the extend stage of Microsoft's favourite strategy.
Google clearly doesn't treat AMP and non-AMP pages the same way: only AMP pages are eligible for the carousel in Google search, and there's a little icon.
Once there's a way for non-AMP pages be safely preloaded I would be very surprised if Google search didn't start doing that, though. (Speaking only for myself, not the company.)
[1] https://developers.google.com/search/docs/guides/images/amp0...
It feels a little dodgy to me this standard and a bit embrace extend but I'll see how it plays out and reserve judgement until we see this happening in the wild and how well it works. Personally I'd like to be informed in the browser chrome that it was being served via this mechanism rather than me visiting the original site.
Can you maybe see that people feel the browser is now lying to them about where the content is coming from?
And you're also back to the situation where you can't preload the content in a controlled manner or privacy-preserving manner, nor have the page-speed guarantees since the version being served to the user is not the version that Google crawled.
It's kind of the opposite. The cache is where the actual benefits come from. That's not the part you want to get rid of. The AMP spec was just a vehicle for making the caching possible in a secure manner.
This model would theoretically allow the validation, caching and prefetching to be done for all (signed, so opt-in by the publisher) HTML pages. Which is another one of the historical top complaints about AMP: why can't light, fast-loading, mobile-friendly HTML get the same treatment in search results.
> Can you maybe see that people feel the browser is now lying to them about where the content is coming from?
I can see that they are feeling like that, I just don't understand how they arrived there.
How is this different from a e.g. company X's website being behind Cloudflare? The browser didn't contact the actual server that company X hosted the content on. Instead the browser contacted a server run by Cloudflare that could prove cryptographically (via TLS) that it was authorized to serve content on behalf of the actual site.
A few people have pointed out the privacy-preserving aspect of AMP. I'm not sure I get how that's the case. Is this referring to the fact that the page is not being pre-loaded from the content owner's own webserver? The main privacy violators on the internet are Google and Facebook. How is loading something from Google cache protecting my privacy?
Worse still, if someone posts an amp link on Twitter or a chat client Google now gets to know when I access a specific website even though they are an unrelated third party[1].
Edit: [1] In practice this was probably already the case since Google Analytics is so popular. But still.
If you make a search query, but have not clicked on any results, you have a privacy expectation that the web servers of the search results you have not clicked on will not know you performed this query, your ip address, cookie, etc. For example, if you search for [headache] and then close the window, mayoclinic.com knowing that you made this query would probably be a surprising result.
With naive preloading, you would preload a search result from that origin. Your browser would make an HTTP request to the site and that site (sending an ip address, the URL you are preloading, and any cookies you may have set on that origin). So, this approach would violate your expectation of privacy.
Instead, if the page is delivered from Google's own cache, the HTTP request goes to Google instead of the publisher. Google already knows that you have made this query, and are going to preload it (the search results page instructed your browser to do so in the first place). The request will not have any cookies in it except for Google's origin cookies, which Google already knows as well. Therefore this type of preload does not reveal anything new about you to any party, even Google.
AMP has been doing this for a long time in order to preload results before you click them. However, until Signed Exchanges the only way to do this was that on click the page would need to be from a Google owned cache URL (google.com/amp/...). With Signed Exchanges, that can be fixed. The network events are essentially the same.
Note that once the page has been clicked on, the expectation of privacy from the publisher is no longer there. The page itself can then load resources directly from the publishers origin, etc.
To your last point, if someone posts a link on twitter to an AMP page on a publisher domain, and then you click it, your browser will make a network request to the publisher's origin. Google will not be involved in this transaction in any way. If someone explicitly posts a link to an Google AMP Cache Signed Exchange, then yes this will trigger a request to Google but this will be far less likely going forward as these URLs will never be shown in a browser. For example, try loading https://amppackageexample-com.cdn.ampproject.org/wp/s/amppac... using Chrome 73 or later. This is a signed exchange from one domain being delivered from another. You'll never see that URL in the URL bar for more than a moment, so it's unlikely to ever be shared, like I'm doing now.
At its root, I think my objections to AMP boil down to a few things:
On a technical level:
1. It's buggy and weird on iOS.
2. I'm not convinced I care about a few seconds of loading time enough to justify the added complexity of making this kind of prefetching possible. Additionally, this seems like a stop-gap that will be rendered unnecessary by increasingly wide pipes for data.
On a philosophical level:
3. It gives Google way too much power over content.
4. I want the option to turn it off completely because of points [1] and [3], and because I fundamentally want to feel in control of my internet experience.
Edit: The point about SXG making AMP URLs less likely to get copy/pasted to other mediums is a key benefit I hadn't considered and will likely make avoiding AMP outside of Google search easier.
I totally want that time saved if possible.
It looks like you were trying to make some deeper philosophical point, but you'll have to be clearer because your statement makes no sense.
Google has to know what you're searching for to compute and show the results. So there are few additional privacy implications from the preload.
And your last case is exactly what will no longer happen. People will now copy-paste the original URL rather than the cache URL. Click on the link, and you're taken to the original site.
The browser security model stops them from doing this, but presumably in this new world they could allow this to work and not host the content in the carousel themselves.
I think the argument about content suddenly becoming "slow" and no longer AMP validated if it's not served from the AMP cache is a poor one.
Finally I'm willing to postpone judgement but I did just explain why people feel that Google is embracing and extending the web if you can't understand why people are worried about this that's not something I can help you with ;-)
Cloudflare does not have the same scope, power, monopoly or scale that Google have - I can change CDN provider if they start doing weird stuff, no problem, but I can never really get away from Google.
Disclaimer: I work at Google, nothing related to AMP or search.
I don't have links to hand but everything I've seen shows real dropoffs in users as you increase the time. Once you're looking at low numbers of seconds you're looking at significant numbers of users simply abandoning the site. Half a second extra is not insignificant, and the user experience changes a lot between things that feel instant and things that have a noticeable wait.
Also, Google controlling AMP means that Google decides what analytic systems and ad networks are allowed on the AMP page. With Google having its own ads and analytics business, doesn't this tempt them to make life little easier for its own products and little more difficult for competitors'?
I believe if you refresh the page it triggers a request to the original site, which will probably then choose to give you the non-AMP version of the site.
https://www.zdnet.com/article/former-mozilla-exec-google-has...
I have push notification disabled but it wouldn't be surprise for me if they asking to subscribe for push notifications on the first page view.
Current era of content websites is a disaster except few cases like medium and maybe reddit with a discount.
AMP is an only solution for general users who just want to google a cooking recipe or latest news in their town.
And now we're trying to shoehorn it back in?
It used to be that a local caching squid proxy was a great way to make load times of various "front pages of the Internet" bearable on a shared low bandwidth uplink (local/national news sites etc typically being served from the cache/lan).
New ssl/tls kinda-sorta breaks that (there's no middle ground - either install intercepting cert that catches everything, or abandon caching on everything. Either cache CNN. com and medical records, email(webmail) and Facebook messages - or neither).
AMP might be a bridge too far - but some kind of (semi) public "signed, not encrypted" would still be a good fit for hypertext applications/documents - because of the caching benefits.
[1] As excellently outlined and contrasted by Fielding in his thesis: https://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm
If you look back, Google has made multiple attempts at "improving" the url. It starts to become clear what they are trying to do now.
I don't care how AMP works. It's a power grab. Done.
Also, Mozilla members rally around a ton of stuff here on HN. That's why you see so many posts about Rust despite the fact that it's not really that popular. That's also why the top comments on stories about MS Edge switching to Chrome where lamenting the fact that they didn't choose Firefox, despite the fact that hardly anybody uses Firefox.
Now there's a solution that preserves the preloading and validation benefits of AMP caches but maintains the original URLs, in a way that's cryptographically sound, in the process of being standardized, and controlled by the publisher. This gets launched much faster than one would have expected. And suddenly everyone pretends that the AMP cache URLs were never a problem and this is some kind of a power-grab.