9 ms·

This is such a strange reaction from HN. The AMP cache URLs have been a top 3 complaint about AMP here. "I can't copy-paste URLs, it's hard for users to underst

by jsnell 8y ago

This is such a strange reaction from HN. The AMP cache URLs have been a top 3 complaint about AMP here. "I can't copy-paste URLs, it's hard for users to understand which site they are on, it looks like the content is provided by Google rather than the real provider", etc. 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.

andy_ppp 8y ago
Fair enough but there is now zero need to load them from the AMP cache at all - this security model could allow News Carousel to load them from the originating site and still have access to the pre-rendering instant load magic/lies that AMP provides. 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?
- jsnell 8y ago
  If you're loading the content from the originating site, surely there's no benefit at all to signing. If you're loading the content directly from the site, the browser just needs TLS to verify the integrity of the content. 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.
  - andy_ppp 8y ago
    > If you're loading the content from the originating site, surely there's no benefit at all to signing. If you're loading the content directly from the site, the browser just needs TLS to verify the integrity of the content. 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.
  - AlexandrB 8y ago
    > And you're also back to the situation where you can't preload the content in a controlled manner or privacy-preserving manner... 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.
    - gregable 8y ago
      Good question. 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/amppackageexample.com/ 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.
RobertRoberts 8y ago
I simply don't trust Google to not change the rules later. 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/AAAAAAAADYE/T6a46VohjS4u5UmYgW3h5yNyqMc4YjbTQCLcBGAs/s1600/url_bar2.gif https://3.bp.blogspot.com/-Xqfy7IhiTzc/XLY7goySWzI/AAAAAAAAD...
- deleted 8y ago
  [deleted]
- eudora 8y ago
  Sneaky because now you don't know what server a web page is coming from? Because yes that's true, although cryptography it's maybe half true.
  - hedora 8y ago
    Sneaky because (especially for news articles), the most common web-based attack is google (or fb, etc) slurping up my information. 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?)
    - codedokode 8y ago
      On their page about AMP Viewer Google admits that they are collecting user's data when they view AMP pages [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. With replaced URL it will be more difficult to spot. [1] https://developers.google.com/search/docs/guides/about-amp https://developers.google.com/search/docs/guides/about-amp
mtberatwork 8y ago
Well, I wouldn't call this a solution just yet. If you read through the documentation, you'll find that this won't work on shared hosts and requires a TLS certificate "that supports the CanSignHttpEchanges flag. As of April 2019, only DigiCert provides this extension." [1] Plus, as if the lift of transforming HTML into AMP HTML wasn't already big enough for your average web site owner, implementing signed exchanges will be over the head of 99% of the folks building web pages on the Web. 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-and-measure/signed-exchange https://amp.dev/documentation/guides-and-tutorials/optimize-...
- jefftk 8y ago
  > as if the lift of transforming HTML into AMP HTML wasn't already big enough for your average web site owner, implementing signed exchanges will be over the head of 99% of the folks building web pages on the Web 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)
  - tcd 8y ago
    Well, it's disappointing DigiCert didn't tell Google to fuck off. I hope this never comes to something like Let's Encrypt, so the vast majority of developers can never use this. Sometimes, Google needs a gentle nudge from users saying "we don't like this" and hope they reconsider (I doubt it).
    - hedora 8y ago
      Honestly, if comcast and friends started blocking this crap by default (with an opt in for people that want to be spied on by google) I’d take back at least half the mean things I’ve said about Pai.
cannedslime 8y ago
My biggest quarrel with this is that its just another way for google to take control over the internet. Does any other search provider than google use AMP? Does any browser other than googles own support this? How busy are you? You can't wait 0.5 seconds for an HTTP request? And you think its worth feeding google with more precise data about your movements online than they already have? And as a business integrating AMP, loose control over your own content and platform? Why?
- delroth 8y ago
  https://blogs.bing.com/Webmaster-Blog/September-2018/Introducing-Bing-AMP-viewer-and-Bing-AMP-cache https://blogs.bing.com/Webmaster-Blog/September-2018/Introdu... Disclaimer: I work at Google, nothing related to AMP or search.
  - andrekandre 8y ago
    my counter argument to this would be: we don’t need more corporate control of the internet and standards, we need less... bing throwing their weight in isn’t any better imo
  - ajmurmann 8y ago
    Bing is the best thing that ever happened to Google. It's the fig leave that protects you from antitrust.
- IanCal 8y ago
  > You can't wait 0.5 seconds for an HTTP request? 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.
  - cannedslime 8y ago
    Yes but you don't need AMP to have a fast loading website or even one that applies the same principles as AMP when it comes to having inline CSS, loading scripts async etc. The biggest problem in all of this is usually ads and analytics anyways.
jxdxbx 8y ago
the preloading and caching seems like a marginal speed boost. the main win from AMP is just the stripped-down format, which does not require the cache.
e12e 8y ago
First, everyone go out of their way to break REST[1] caching by eliminating proxies from SSL (for some good, some bad - reasons). 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 https://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm
gnomewascool 8y ago
I think that most people are worried about Google using a controversial[0], draft web "standard" (Signed HTTP Exchanges), that introduces a major change in how the web works, in mass production, without trying to first resolve the problems raised with the proposal. [0] For instance, Mozilla considers the current specification to be harmful[1]. [1] https://mozilla.github.io/standards-positions/ https://mozilla.github.io/standards-positions/
- eudora 8y ago
  It also puts a _lot_ of work on the publisher to implement these changes. Again. (Unless you're using CloudFlare)
  - gregable 8y ago
    Currently, it's difficult to implement however unlike rewriting a page in AMP, signing the page is a purely mechanical operation. All that's required is to improve the tooling, it is theoretically possible to be a one-click change for any website out there. Initially adding gzip support to a web server was difficult and out the reach of many webmasters, now it's basically universal.
- tytso 8y ago
  There was an attempt to address Mozilla's concerns[1], but Mozilla never responded, unfortunately. If the Mozilla community chooses not to respond, that might cause people to consider whether or not their position should be given much weight. [1] https://github.com/mozilla/standards-positions/issues/29#issuecomment-459547918 https://github.com/mozilla/standards-positions/issues/29#iss...
  - RubenSandwich 8y ago
    What do you mean they never responded? They say they are working on a response[0]. Taking time to respond and informing the other party that it will take a while is not "never responded". [0] https://github.com/mozilla/standards-positions/issues/29#issuecomment-459605378 https://github.com/mozilla/standards-positions/issues/29#iss...
loudtieblahblah 8y ago
Because literally the entire private reason for AMP is a power grab. 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
- tantalor 8y ago
  Power grab from whom? Bing serves AMP too. https://blogs.bing.com/Webmaster-Blog/September-2018/Introducing-Bing-AMP-viewer-and-Bing-AMP-cache https://blogs.bing.com/Webmaster-Blog/September-2018/Introdu...
  - rum3 8y ago
    They also push a browser based on Chromium. I wonder how many intentional incompatibility issues there will be with other web browsers that are not developed by G$$gle.
- deleted 8y ago
  [deleted]
dbbk 8y ago
As bad as the URLs were, at least you could edit them to get back to the non-AMP version if you were technically literate enough. Now there'll be no distinction, you could get sent to an AMP link from Google which is a lesser experience than the 'real' site and have no way of getting out.
- jefftk 8y ago
  > have no way of getting out 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.
- jedieaston 8y ago
  Can't you just click the link at the top right that will send you to the real page as it does today?
  - teddyh 8y ago
    What reason does Google now have for keeping the link there?
  - dbbk 8y ago
    I believe they said that bar would be going away once they rolled out 'real URLs'.
snarfy 8y ago
Most people agree that URL spoofing is bad. I'm not sure why google should get a pass.
matt4077 8y ago
It works best if you try understanding everything from the perspective of someone tail’ing Apache logs and fiddling with their kernel parameters.
wayneftw 8y ago
Different groups of people are commenting at different times. 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.
48309248302 8y ago
It only works in Chrome. The Web has now been split in two, and you now have to use Google Chrome to be on the faster version. Google is shamefully abusing its power in several places here.
- gruturo 8y ago
  If by not using Chrome you don't end up on an AMP page, I consider that a feature.
  - 48309248302 8y ago
    Google is unethically abusing their power against non-Chromium browsers like Firefox. Speed matters in the eyes of users, even if we individually block AMP. See the link below for a general pattern. https://www.zdnet.com/article/former-mozilla-exec-google-has-sabotaged-firefox-for-years/ https://www.zdnet.com/article/former-mozilla-exec-google-has...
    - nebulaserfer 8y ago
      Google just gives users what they want. I've checked the link you provided and the website is total wreck in terms of user experience (subscription popup, large obtrusive ad banners and so on). 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.
api 8y ago
I think everyone sees clearly that AMP is a power grab but fishes for proximate reasons to reject it instead of just sticking to that. I don't care how AMP works. It's a power grab. Done.
jononor 8y ago
People here have been complaining that AMP is a power-grab from the very start. So I do not see this as a strange reaction.
codedokode 8y ago
This is actually the opposite: users are deceived because they think they connect to publisher's site but in fact they are still inside Google's walled garden. Their data are collected according to Google's privacy policy but it is difficult to spot looking at the address bar. 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'?
nialv7 8y ago
"Oh, you don't like the AMP url? OK, how about, we solve this problem, BY MAKING YOUR BROWSER LIE TO YOU. How does that sound?" - Google, probably. 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.

by jsnell 8y ago

andy_ppp 8y ago

Fair enough but there is now zero need to load them from the AMP cache at all - this security model could allow News Carousel to load them from the originating site and still have access to the pre-rendering instant load magic/lies that AMP provides. 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?

jsnell 8y ago
If you're loading the content from the originating site, surely there's no benefit at all to signing. If you're loading the content directly from the site, the browser just needs TLS to verify the integrity of the content. 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.
- andy_ppp 8y ago
  > If you're loading the content from the originating site, surely there's no benefit at all to signing. If you're loading the content directly from the site, the browser just needs TLS to verify the integrity of the content. 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.
- AlexandrB 8y ago
  > And you're also back to the situation where you can't preload the content in a controlled manner or privacy-preserving manner... 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.
  - gregable 8y ago
    Good question. 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/amppackageexample.com/ 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.

RobertRoberts 8y ago

I simply don't trust Google to not change the rules later. 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/AAAAAAAADYE/T6a46VohjS4u5UmYgW3h5yNyqMc4YjbTQCLcBGAs/s1600/url_bar2.gif https://3.bp.blogspot.com/-Xqfy7IhiTzc/XLY7goySWzI/AAAAAAAAD...

deleted 8y ago
[deleted]
eudora 8y ago
Sneaky because now you don't know what server a web page is coming from? Because yes that's true, although cryptography it's maybe half true.
- hedora 8y ago
  Sneaky because (especially for news articles), the most common web-based attack is google (or fb, etc) slurping up my information. 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?)
  - codedokode 8y ago
    On their page about AMP Viewer Google admits that they are collecting user's data when they view AMP pages [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. With replaced URL it will be more difficult to spot. [1] https://developers.google.com/search/docs/guides/about-amp https://developers.google.com/search/docs/guides/about-amp

mtberatwork 8y ago

Well, I wouldn't call this a solution just yet. If you read through the documentation, you'll find that this won't work on shared hosts and requires a TLS certificate "that supports the CanSignHttpEchanges flag. As of April 2019, only DigiCert provides this extension." [1] Plus, as if the lift of transforming HTML into AMP HTML wasn't already big enough for your average web site owner, implementing signed exchanges will be over the head of 99% of the folks building web pages on the Web. 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-and-measure/signed-exchange https://amp.dev/documentation/guides-and-tutorials/optimize-...

jefftk 8y ago
> as if the lift of transforming HTML into AMP HTML wasn't already big enough for your average web site owner, implementing signed exchanges will be over the head of 99% of the folks building web pages on the Web 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)
- tcd 8y ago
  Well, it's disappointing DigiCert didn't tell Google to fuck off. I hope this never comes to something like Let's Encrypt, so the vast majority of developers can never use this. Sometimes, Google needs a gentle nudge from users saying "we don't like this" and hope they reconsider (I doubt it).
  - hedora 8y ago
    Honestly, if comcast and friends started blocking this crap by default (with an opt in for people that want to be spied on by google) I’d take back at least half the mean things I’ve said about Pai.

cannedslime 8y ago

My biggest quarrel with this is that its just another way for google to take control over the internet. Does any other search provider than google use AMP? Does any browser other than googles own support this? How busy are you? You can't wait 0.5 seconds for an HTTP request? And you think its worth feeding google with more precise data about your movements online than they already have? And as a business integrating AMP, loose control over your own content and platform? Why?

delroth 8y ago
https://blogs.bing.com/Webmaster-Blog/September-2018/Introducing-Bing-AMP-viewer-and-Bing-AMP-cache https://blogs.bing.com/Webmaster-Blog/September-2018/Introdu... Disclaimer: I work at Google, nothing related to AMP or search.
- andrekandre 8y ago
  my counter argument to this would be: we don’t need more corporate control of the internet and standards, we need less... bing throwing their weight in isn’t any better imo
- ajmurmann 8y ago
  Bing is the best thing that ever happened to Google. It's the fig leave that protects you from antitrust.
IanCal 8y ago
> You can't wait 0.5 seconds for an HTTP request? 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.
- cannedslime 8y ago
  Yes but you don't need AMP to have a fast loading website or even one that applies the same principles as AMP when it comes to having inline CSS, loading scripts async etc. The biggest problem in all of this is usually ads and analytics anyways.

jxdxbx 8y ago

the preloading and caching seems like a marginal speed boost. the main win from AMP is just the stripped-down format, which does not require the cache.

e12e 8y ago

First, everyone go out of their way to break REST[1] caching by eliminating proxies from SSL (for some good, some bad - reasons). 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 https://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm

gnomewascool 8y ago

I think that most people are worried about Google using a controversial[0], draft web "standard" (Signed HTTP Exchanges), that introduces a major change in how the web works, in mass production, without trying to first resolve the problems raised with the proposal. [0] For instance, Mozilla considers the current specification to be harmful[1]. [1] https://mozilla.github.io/standards-positions/ https://mozilla.github.io/standards-positions/

eudora 8y ago
It also puts a _lot_ of work on the publisher to implement these changes. Again. (Unless you're using CloudFlare)
- gregable 8y ago
  Currently, it's difficult to implement however unlike rewriting a page in AMP, signing the page is a purely mechanical operation. All that's required is to improve the tooling, it is theoretically possible to be a one-click change for any website out there. Initially adding gzip support to a web server was difficult and out the reach of many webmasters, now it's basically universal.
tytso 8y ago
There was an attempt to address Mozilla's concerns[1], but Mozilla never responded, unfortunately. If the Mozilla community chooses not to respond, that might cause people to consider whether or not their position should be given much weight. [1] https://github.com/mozilla/standards-positions/issues/29#issuecomment-459547918 https://github.com/mozilla/standards-positions/issues/29#iss...
- RubenSandwich 8y ago
  What do you mean they never responded? They say they are working on a response[0]. Taking time to respond and informing the other party that it will take a while is not "never responded". [0] https://github.com/mozilla/standards-positions/issues/29#issuecomment-459605378 https://github.com/mozilla/standards-positions/issues/29#iss...

loudtieblahblah 8y ago

Because literally the entire private reason for AMP is a power grab. 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

tantalor 8y ago
Power grab from whom? Bing serves AMP too. https://blogs.bing.com/Webmaster-Blog/September-2018/Introducing-Bing-AMP-viewer-and-Bing-AMP-cache https://blogs.bing.com/Webmaster-Blog/September-2018/Introdu...
- rum3 8y ago
  They also push a browser based on Chromium. I wonder how many intentional incompatibility issues there will be with other web browsers that are not developed by G$$gle.
deleted 8y ago
[deleted]

dbbk 8y ago

As bad as the URLs were, at least you could edit them to get back to the non-AMP version if you were technically literate enough. Now there'll be no distinction, you could get sent to an AMP link from Google which is a lesser experience than the 'real' site and have no way of getting out.

jefftk 8y ago
> have no way of getting out 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.
jedieaston 8y ago
Can't you just click the link at the top right that will send you to the real page as it does today?
- teddyh 8y ago
  What reason does Google now have for keeping the link there?
- dbbk 8y ago
  I believe they said that bar would be going away once they rolled out 'real URLs'.

snarfy 8y ago

Most people agree that URL spoofing is bad. I'm not sure why google should get a pass.

matt4077 8y ago

It works best if you try understanding everything from the perspective of someone tail’ing Apache logs and fiddling with their kernel parameters.

wayneftw 8y ago

Different groups of people are commenting at different times. 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.

48309248302 8y ago

It only works in Chrome. The Web has now been split in two, and you now have to use Google Chrome to be on the faster version. Google is shamefully abusing its power in several places here.

gruturo 8y ago
If by not using Chrome you don't end up on an AMP page, I consider that a feature.
- 48309248302 8y ago
  Google is unethically abusing their power against non-Chromium browsers like Firefox. Speed matters in the eyes of users, even if we individually block AMP. See the link below for a general pattern. https://www.zdnet.com/article/former-mozilla-exec-google-has-sabotaged-firefox-for-years/ https://www.zdnet.com/article/former-mozilla-exec-google-has...
  - nebulaserfer 8y ago
    Google just gives users what they want. I've checked the link you provided and the website is total wreck in terms of user experience (subscription popup, large obtrusive ad banners and so on). 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.

api 8y ago

I think everyone sees clearly that AMP is a power grab but fishes for proximate reasons to reject it instead of just sticking to that. I don't care how AMP works. It's a power grab. Done.

jononor 8y ago

People here have been complaining that AMP is a power-grab from the very start. So I do not see this as a strange reaction.

codedokode 8y ago

This is actually the opposite: users are deceived because they think they connect to publisher's site but in fact they are still inside Google's walled garden. Their data are collected according to Google's privacy policy but it is difficult to spot looking at the address bar. 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'?

nialv7 8y ago

"Oh, you don't like the AMP url? OK, how about, we solve this problem, BY MAKING YOUR BROWSER LIE TO YOU. How does that sound?" - Google, probably. 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.