5 ms·

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 co

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.

krn 8y ago
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.
- Ajedi32 8y ago
  > 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.
  - krn 8y ago
    > 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?
    - Ajedi32 8y ago
      Yes. https://amphtml.wordpress.com/2018/03/08/standardizing-lessons-learned-from-amp/ 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.
      - krn 8y ago
        > 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.
        Ajedi32 8y ago
        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?
        8y ago

krn 8y ago

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.

Ajedi32 8y ago
> 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.
- krn 8y ago
  > 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?
  - Ajedi32 8y ago
    Yes. https://amphtml.wordpress.com/2018/03/08/standardizing-lessons-learned-from-amp/ 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.
    - krn 8y ago
      > 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.
      - Ajedi32 8y ago
        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?
        8y ago