Hacker News new | past | comments | ask | show | jobs | submit login

Most comments assume that this is for solving user confusion, or security, or building a better URL scheme, et al.

It's not, that is all smokescreen.

As ivs wrote[1] They are going to hide amp subdomain, so you don't know if you're looking at AMP or the actual destination. And then suddenly the whole world funnels through AMP.

And for that reason, it won't be reversed until people call them for what they are actually trying to do.

[1]: https://news.ycombinator.com/item?id=17928939




This should be the top comment. After this change, we are just one step away from using the browser's address bar only as a Google search box, and Google as the entire internet's gatekeeper. Google doesn't make money when you type the URL into your browser's address bar – it makes when you don't.


AMP pages are served through google.com, though? It's one of the big problems with them.


Not always. Sometimes Google results have taken me to websites like "amp.reddit.com" on mobile.


That makes sense. And not just AMP but they want to train users to NOT pay attention to domain/subdomains, leading to more room for other exploits.


Yeah... no. That's just baseless FUD.

They _are_ indeed planning to get rid of AMP cache URLs, but they'll be doing it through open W3C standards anyone can use, not through special-casing their own domains: https://amphtml.wordpress.com/2018/05/08/a-first-look-at-usi...


No, this Chrome update is about hiding the "amp." subdomain from the original URL. What Google wants to achieve, is to make it impossible for the average user to tell when the entire website is being served from Google Cache.


Google cache links aren't served from `amp.yoursite.com`, they're served from `cdn.ampproject.org`.

If you're visiting `amp.yoursite.com`, then the site _isn't_ being served from the Google cache.

Also "this Chrome update is about hiding the "amp." subdomain on the original site from the viewer" is patently false since this update _doesn't_ hide `amp.`; only `m.` and `www.`.


> Google cache links aren't served from `amp.yoursite.com`

That's not where things are going, according to your own source from the previous comment:

> Our approach uses one component of the emerging Web Packaging technologies—technologies that also support a range of other use cases. This component allows a publisher to sign an HTTP exchange (a request/response pair), which then allows a caching server to do the work of actually delivering that exchange to a browser. When the browser loads this “Signed Exchange”, it can show the original publisher’s web origin in the browser address bar because it can prove similar integrity and authenticity properties as a regular HTTPS connection.

So, the content will be served from Google Cache with the original publisher's URL in the address bar.

> this update _doesn't_ hide `amp.`; only `m.` and `www.`

It's Google, who decides what and when it wants to add to its browser's list of "trivial subdomains". Especially, when the websites with "amp." subdomains will become common.


Yes, once the Web Package Standard is finalized and implemented then AMP pages will indeed use the normal `amp.` URLs.

But at that point, what would be your concern with hiding `amp.`? That's no worse than hiding `m.`; it's just another subdomain which serves a different version of the same content. Heck, sites could serve their amp pages on `m.` domains if they wanted to; the actual subdomain they decide to use is irrelevant.


Seeing "amp." in the URL meant that it's not a "full version" of the site. Google wants to remove the separation for the end user, so that all publishers would serve their content through Google Cache. And that's a big concern to me, since it means, the entire web will be served from a single company's database.


> Seeing "amp." in the URL meant that it's not a "full version" of the site.

Yes, but once again that's no different from `m.`.

> And that's a big concern to me, since it means, the entire web will be served from a single company's database.

Are we talking about before or after the Web Package Standard is implemented here?

If before, then your concerns about the URL aren't applicable because `amp.` links aren't served from the Google cache (only `cdn.ampproject.org` links). If after, then the content isn't "served from a single company's database" anymore; it's served using a decentralized and open standard for cross-origin server push.


> If after, then the content isn't "served from a single company's database" anymore; it's served using a decentralized and open standard for cross-origin server push.

Does this mean that Google will no longer rank higher those, who implement AMP and serve through Google Cache, than those who don't?


Yes. https://amphtml.wordpress.com/2018/03/08/standardizing-lesso...

> Based on what we learned from AMP, we now feel ready to take the next step and work to support more instant-loading content not based on AMP technology in areas of Google Search designed for this, like the Top Stories carousel. This content will need to follow a set of future web standards and meet a set of objective performance and user experience criteria to be eligible.

Furthermore, once the Web Package Standard is finalized, the "Google Cache" won't exist anymore, at least not in the same way it does now.

The Web Package Standard allows any web page which supports origin signed responses to be served via cross-origin server push from any server that supports HTTP/2. So Google will probably still cache and push pages via their own infrastructure when you visit those pages from your Google search results, but the actual content being served will be fully controlled by the original publisher and behave exactly as if your browser received the page directly from the publisher's server.


> So Google will probably still cache and push pages via their own infrastructure when you visit those pages from your Google search results

And that's what I mean by saying, that the entire web will be served from a single company's database, which already controls the browser and the search. You will be able to browse the web without ever leaving Google servers, and Google will be able to track your every interaction on the web.


This doesn't increase Google's ability to track you at all. If you click a link on a Google search results page they already know you visited that site; them serving the initial page load via a cross-origin server push changes nothing.

It also doesn't give them any more control over the web, since the page contents are still strictly controlled by the original publisher (and that's cryptographically enforced).

So again, what's your actual concern?


Google now only knows the first page I visit from its search results. After this update, Google will be able to follow me across the entire web, because it will the one who serves it to me. How is that not a concern?

Are you seriously claiming that the largest ad company in the world is interested in decentralizing the web? Its blog article you linked to yourself says, that the goal of this entire initiative is to increase the usage of AMP by "displaying better AMP URLs".


> After this update, Google will be able to follow me across the entire web, because it will the one who serves it to me.

That's not how it works. Only the initial page is loaded over cross-origin server push. After you actually navigate to that page you're no longer on Google's site (which is why the URL bar is able to show the domain of the site you just navigated to instead of still showing google.com), so obviously they don't have any enhanced ability to monitor what you do after that point.

> Are you seriously claiming that the largest ad company in the world is interested in decentralizing the web?

The general web is already decentralized. This is about decentralizing AMP. And yes, decentralizing AMP is exactly what Google is doing here.

> the goal of this entire initiative is to increase the usage of AMP by "displaying better AMP URLs"

Yes, and they're accomplishing that by pursuing the development of open W3C standards which can be used by anyone. Just like how offline storage on the web started as a feature enabled by [a proprietary plugin developed by Google (Google Gears)][1] until Google pursued the development of open standards to replace it: https://www.w3.org/TR/service-workers-1/ (Check out who the editors are on that draft.)

Google's been following this pattern for over a decade now. They start with a proprietary initiative, then use the lessons learned from that effort to develop open web standards that improve the web for everyone. (I can give maybe a dozen more examples if you still don't believe me.) There's no reason to think AMP will be any different in this regard, especially since Google has already made their intentions on this matter clear.

[1]: https://support.google.com/code/answer/69197?hl=en


Another very real problem is not being able to share the real url rather than an amp link.

Is ampproject Google's website? On amp.google.com I can find the original url for sharing purposes, whereas on ampproject.org urls I can't.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: