2 ms·

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 priva

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.