3 ms·

> Do you really want third party sites knowing what you searched for...? My user agent /is/ me. If I want to prefetch results, I unerstand it means people know

by dcow 9y ago

> Do you really want third party sites knowing what you searched for...? My user agent /is/ me. If I want to prefetch results, I unerstand it means people know I'm looking at those results. I don't think it's really the privacy issue they are trying to make it out to be. And the counter consideration is that you are implicitly saying you trust Google with that info more than the actual service providers so it's not "do you want people" it's "who do you want" knowing. Easy solution: off by default and inform users of the implication when turned on. As a user I don't actually want the internet prefetched for me mostly because it's a stupid idea catering to a subset of people who are so impatient it's baffling. If your site performs poorly on mobile let users complain to the creators so they can make better sites. Does Google really get the schtick when a mobile site has a poor UX? No. So why are they even investing effort into this?... > ISPs can't cache the content of HTTPS pages. Indeed. That's the point of HTTPS. As a user I don't expect that contract undermined even by a claimed benevolent Google just trying to altruistically get you content better with signed bundles that masquerade around as the original service. A few points, too. Often the static CDN content is served HTTP because it's not sensitive or it employes other means of restricting access such as GUID/signed urls etc., all of which can be cached. But even if that's a bad idea (I think people are moving away from that model, and http2) that just shifts the responsibility to the ISP and CDN providers to make sure that they have good fast connections between their networks. That's something that is in both their business models and it works just fine today. ISPs want to provide the best user experience on their network compared to others and CDNs sell their highly available global network to customers so a better CDN closer to more users means happier customers.

Ajedi32 9y ago
> 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.

by dcow 9y ago

Ajedi32 9y ago

> 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.