7 ms·

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 w

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 https://news.ycombinator.com/item?id=17928939

fouc 8y ago
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.
untog 8y ago
AMP pages are served through google.com, though? It's one of the big problems with them.
- Seirdy 8y ago
  Not always. Sometimes Google results have taken me to websites like "amp.reddit.com" on mobile.
krn 8y ago
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.
Ajedi32 8y ago
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-using-web-packaging-to-improve-amp-urls/ https://amphtml.wordpress.com/2018/05/08/a-first-look-at-usi...
- krn 8y ago
  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.
  - Ajedi32 8y ago
    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.`.
    - krn 8y ago
      > 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.
      - Ajedi32 8y ago
        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.

fouc 8y ago

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.

untog 8y ago

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

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

krn 8y ago

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.

Ajedi32 8y ago

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-using-web-packaging-to-improve-amp-urls/ https://amphtml.wordpress.com/2018/05/08/a-first-look-at-usi...

krn 8y ago
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.
- Ajedi32 8y ago
  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.`.
  - krn 8y ago
    > 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.
    - Ajedi32 8y ago
      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.