4 ms·

Can someone explain what this is about? > As we detailed in a deep-dive blog post last year, privacy reasons make it basically impossible to load the page fro

by spc476 9y ago

Can someone explain what this is about? > As we detailed in a deep-dive blog post last year, privacy reasons make it basically impossible to load the page from the publisher’s server. Publishers shouldn’t know what people are interested in until they actively go to their pages. Instead, AMP pages are loaded from the Google AMP Cache but with that behavior the URLs changed to include the google.com/amp/ URL prefix. To me, this reads as "for our privacy, we don't tell the publisher what page has loaded" but that may be an uncharitable interpretation. I read the referenced blog post and it didn't clear up anything about the "privacy" issues.

niftich 9y ago
The post makes the case that they don't want the publisher to know that AMP thinks the user would want to visit, and that's more of a matter of the user's privacy, since that implementation would have the user's user-agent as the origin. Instead, the concern is sidestepped by the extra indirection: the user's user-agent will load the prefetches from the AMP cache. How much of this is moot given that many browsers, including Chrome, offer speculative fetching as a feature, is debatable.
- pgeorgi 9y ago
  > How much of this is moot given that many browsers, including Chrome, offer speculative fetching as a feature, is debatable. There's a difference between explicit prefetching (given by html tags, ie there's intent), speculative prefetching on the same origin (you already talk to them) and speculative prefetching across the entire net (you talk to somebody new out of the blue). Preloading search results for faster display without a local Google-side cache means that more parties know that you (IP, User Agent, cookies) are potentially interested in certain pages due to a Google search (referer header). With the AMP cache as currently implemented (and with the TAG bundles in a future version), Google gets to know that you just got the URLs A, B and C proposed by Google. Which is no additional information for anybody, at Google or elsewhere. If this new scheme allows rolling back some of the less fortunate effects of AMP (the visibility of the AMP cache URL, the in-page URL bar emulation as a workaround to that), all the better.

by spc476 9y ago

niftich 9y ago

The post makes the case that they don't want the publisher to know that AMP thinks the user would want to visit, and that's more of a matter of the user's privacy, since that implementation would have the user's user-agent as the origin. Instead, the concern is sidestepped by the extra indirection: the user's user-agent will load the prefetches from the AMP cache. How much of this is moot given that many browsers, including Chrome, offer speculative fetching as a feature, is debatable.

pgeorgi 9y ago
> How much of this is moot given that many browsers, including Chrome, offer speculative fetching as a feature, is debatable. There's a difference between explicit prefetching (given by html tags, ie there's intent), speculative prefetching on the same origin (you already talk to them) and speculative prefetching across the entire net (you talk to somebody new out of the blue). Preloading search results for faster display without a local Google-side cache means that more parties know that you (IP, User Agent, cookies) are potentially interested in certain pages due to a Google search (referer header). With the AMP cache as currently implemented (and with the TAG bundles in a future version), Google gets to know that you just got the URLs A, B and C proposed by Google. Which is no additional information for anybody, at Google or elsewhere. If this new scheme allows rolling back some of the less fortunate effects of AMP (the visibility of the AMP cache URL, the in-page URL bar emulation as a workaround to that), all the better.