3 ms·

> If I want to prefetch results, I unerstand it means people know I'm looking at those results. Why do that though when you can have your cake and eat it? Goog

> If I want to prefetch results, I unerstand it means people know I'm looking at those results. Why do that though when you can have your cake and eat it? Google's proposed solution allows you to prefetch results _and_ not allow the third-party to know you're looking at those results. > the counter consideration is that your implicitly saying you trust Google with that info more than the actual service providers If I'm using Google search, then yes, obviously I'm fine with Google knowing what I searched for. If I wasn't okay with that, I most certainly would not be using Google search. In contrast, I'm less likely to be okay with a random site in the search results page that I haven't clicked on knowing that I saw a link to their site in a search results page. Note that if I were using DuckDuckGo instead and DuckDuckGo supported AMP, then my browser would prefetch from DuckDuckGo's AMP cache, not Google's. No additional information is being shared with any party who doesn't already possess that information. (DuckDuckGo already knows what I searched for. Me loading an AMP page from them related to that query reveals no additional information.) > Indeed. That's the point of HTTPS. As a user I don't expect that contract undermined even by a claimed benevolent Google Could you explain how Google's proposed solution here undermines HTTPS? Note that the OP talks about using the upcoming [Web Package standard][1] to distribute AMP pages. This standard would allow the integrity guarantees of HTTPS to be preserved even when the page in question is being served by Google's AMP cache rather than the original server. [1]: https://github.com/WICG/webpackage https://github.com/WICG/webpackage

dcow 9y ago
I guess this becomes an interesting discussion about who owns my browsing experience. I believe I (along with what I cede to my browser vendor) own my browsing experience. This means once the content has hit my browser it's no longer Google's domain. It rubs me weird that Google wants to stick their fingers in and control the way my browser handles results served from their service. That's really up to me (and my browser). re: web packaging, if a new standard is being developed that will set user expectations around content delivered by a third party then fine. But to boot I'm really confused why the content requested is not the result of loading the certified URL in my address bar (which TLS has conditioned us to be privy to). And so users will become accustomed to the implications of using a service that leverages the standard and there shouldn't be any long term confusion, I guess. But let's not ignore what it is: AMP is evolving into a CDN owned by Google only focused on serving Google search results which is only even feasible because it exploits Google's scale to further lock down its search monopoly and prevent information from leaking out that might even arguably benefit users. DuckDuckGo wouldn't get the same benefit from adopting AMP because they don't have loads of internet infrastructure to play with.
- Ajedi32 9y ago
  Unless you're using Google Chrome, Google does not and can not control "the way [your] browser handles results served from their service". That's completely up to your browser to decide (and by extension, you, by means of which browser you decide to use). If you're using Firefox, for example, this change to the URL bar will only happen if Mozilla decides to implement the web package standard, after evaluating it and deciding its reasonable to display the URL of the original page for pages loaded using that standard. > DuckDuckGo wouldn't get the same benefit from adopting AMP because they don't have loads of internet infrastructure to play with. That may be true in the sense that DuckDuckGo can't deploy a global CDN as easily, since Google has more resources than them, but you could make the same case against almost any new web technology. For example, you could argue DuckDuckGo wouldn't make as effective use of HTTP/2 as Google, since Google can afford to rewrite their applications to take full advantage of HTTP/2 server push much more quickly than DDG can. That's not a very good argument against HTTP/2 though IMO.
  - Ajedi32 9y ago
    I will add though that despite what it may sound like, I'm still not entirely sold on AMP myself. My main issue with it is that it the spec still contains [this line][1]: > AMP HTML documents MUST > [...] > * contain a <script async src="https://cdn.ampproject.org/v0.js"></script> https://cdn.ampproject.org/v0.js"></script> tag inside their head tag The actual specification requiring JavaScript to be loaded into your page from any one particular server is unacceptable IMO. Hopefully this is fixed in future updates to the spec. My other problem with it is much more minor; I just don't like the idea of serving a "special" version of my site just for mobile. I'm very much a fan of responsive design, and I'd prefer to just serve one version of my site that looks and works great no matter what device or internet connection you're viewing it with. [1]: https://www.ampproject.org/docs/reference/spec#scrpt https://www.ampproject.org/docs/reference/spec#scrpt

dcow 9y ago

I guess this becomes an interesting discussion about who owns my browsing experience. I believe I (along with what I cede to my browser vendor) own my browsing experience. This means once the content has hit my browser it's no longer Google's domain. It rubs me weird that Google wants to stick their fingers in and control the way my browser handles results served from their service. That's really up to me (and my browser). re: web packaging, if a new standard is being developed that will set user expectations around content delivered by a third party then fine. But to boot I'm really confused why the content requested is not the result of loading the certified URL in my address bar (which TLS has conditioned us to be privy to). And so users will become accustomed to the implications of using a service that leverages the standard and there shouldn't be any long term confusion, I guess. But let's not ignore what it is: AMP is evolving into a CDN owned by Google only focused on serving Google search results which is only even feasible because it exploits Google's scale to further lock down its search monopoly and prevent information from leaking out that might even arguably benefit users. DuckDuckGo wouldn't get the same benefit from adopting AMP because they don't have loads of internet infrastructure to play with.

Ajedi32 9y ago
Unless you're using Google Chrome, Google does not and can not control "the way [your] browser handles results served from their service". That's completely up to your browser to decide (and by extension, you, by means of which browser you decide to use). If you're using Firefox, for example, this change to the URL bar will only happen if Mozilla decides to implement the web package standard, after evaluating it and deciding its reasonable to display the URL of the original page for pages loaded using that standard. > DuckDuckGo wouldn't get the same benefit from adopting AMP because they don't have loads of internet infrastructure to play with. That may be true in the sense that DuckDuckGo can't deploy a global CDN as easily, since Google has more resources than them, but you could make the same case against almost any new web technology. For example, you could argue DuckDuckGo wouldn't make as effective use of HTTP/2 as Google, since Google can afford to rewrite their applications to take full advantage of HTTP/2 server push much more quickly than DDG can. That's not a very good argument against HTTP/2 though IMO.
- Ajedi32 9y ago
  I will add though that despite what it may sound like, I'm still not entirely sold on AMP myself. My main issue with it is that it the spec still contains [this line][1]: > AMP HTML documents MUST > [...] > * contain a <script async src="https://cdn.ampproject.org/v0.js"></script> https://cdn.ampproject.org/v0.js"></script> tag inside their head tag The actual specification requiring JavaScript to be loaded into your page from any one particular server is unacceptable IMO. Hopefully this is fixed in future updates to the spec. My other problem with it is much more minor; I just don't like the idea of serving a "special" version of my site just for mobile. I'm very much a fan of responsive design, and I'd prefer to just serve one version of my site that looks and works great no matter what device or internet connection you're viewing it with. [1]: https://www.ampproject.org/docs/reference/spec#scrpt https://www.ampproject.org/docs/reference/spec#scrpt