3 ms·

Of your 5 bullet points, what's the difference between #2 and #5? You say people believing #2 are misinformed, but that #5 raises a true anticompetitive concern

Of your 5 bullet points, what's the difference between #2 and #5? You say people believing #2 are misinformed, but that #5 raises a true anticompetitive concern, but they're the same thing, no? As for it being for the Google Search team to address, rather than the AMP team, I'd be inclined to disagree. AMP Cache is a part of the AMP spec., the Google Search team are just implementing it as described. What they're doing is just what the AMP Cache is designed to do, nothing more. Also, while you describe #3 as nihilist,I fear it's the most true among the wider, non-HN implementers of AMP on sites.

ninkendo 8y ago
You can definitely care about #5 without caring about #2: Morphing my search results into a captive newsreader gives me a demonstrably terrible experience browsing to sites on my phone. The swipe-back gesture is broken, scrolling doesn't move the safari borders away like it's supposed to, there's a big AMP border I can't get rid of, swiping just moves between results instead of going back (or did they "fix" this?), the URL bar shows google.com instead of the site, making it harder to share, etc etc. I don't care that they're "stealing traffic", I care that my mobile experience is demonstrably worsened.
- lucideer 8y ago
  That's true, but I was more addressing that #2 and #5 are two different outputs of the same technical mechanism—therefore saying that #2 is misinformed while #5 is valid is a contradiction.
niftich 8y ago
The difference between "stealing traffic" and the "Google Search Mobile is a captive newsreader" is nuanced. It's surprising and upsetting to people when they find out that in Google Search Mobile, their attempt to navigate to an AMP-lightning-marked search result doesn't result in a navigation to the target site, while an attempt to navigate to a non-AMP search result does go to the target site, as one would damn well expect. It's upsetting, because the designers of Google Search Mobile have gone through great lengths to hide the fact that the navigation didn't occur, and have adopted UI elements that intentionally try to mimic familiar navigation cues from browsers, rather than playing up the fact that they're viewing proxied content in a wrapping frame. On the other hand, the 'stealing traffic' critique is memetic from a catchy title by a much-revised blog post, and seems to genuinely be upset that bytes that would ordinarily be transferred between the end user and the article's originating host stop short of of the distant origin [1], and get served from a Google-owned CDN instead. It's a technically unsound mishmash of complaints, most probably deriving from the aforementioned behavior of the Google Search Mobile page, but imbued with the subtext that Google is exploiting publishers by providing a CDN. That's absurd. Maybe Google's exploiting publishers with its captive newsreader, but not by providing a CDN. [1] https://www.alexkras.com/google-may-be-stealing-your-mobile-traffic/ https://www.alexkras.com/google-may-be-stealing-your-mobile-...
- MrStonedOne 8y ago
  Stealing traffic also means stealing information about how many hits a page has if such is recorded via the webserver logs. Honestly third party websites serving a proxy/cdn/transparent cache of a website is something that should require affirmative consent from either side of the party. Something Google is not getting, and as such stealing traffic is an acceptable critique. It also reduces the security of the website by allowing users to get used to it being hosted from a google search page. SEO an imposter website that shows the same fake ui border and phish logins, the user wouldn't notice as it looks absolutely normal. (Something I might make a grey hat attempt at just because it's likely the only way to get google to stop doing it.)
  - niftich 8y ago
    The publisher of the AMP content can configure hooks into their analytics solution [1]. These events can fire during any AMP pageview. Given this, I'm not convinced they'll mourn the lack of httpd logs. The typical practice for CDNs is that only the publisher consents; the CDN assumes responsibility for routing and serving the content (and has the private key for the origin's cert, to masquerade as them), and the requester doesn't get a choice. This isn't whataboutism, just an observation that CDNs are always the choice of the content originator, and never the content requester, who possesses few tools to convincingly tell the two apart. [1] https://www.ampproject.org/docs/analytics/analytics_amp https://www.ampproject.org/docs/analytics/analytics_amp
    - lucideer 8y ago
      I think the main point here from an analytics perspective is that, even if you don't choose to use Google Analytics or opt for any other service from Google, if you implement the (allegedly non-Google) AMP specification, Google gets to analyse your users while they browse your content, even after they've clicked away from the Google results page and are—for all intents and purposes—browsing a non-Google property. This is in contravention of both user and publisher expectations, and is non-optional for both parties.
- alangibson 8y ago

ninkendo 8y ago

You can definitely care about #5 without caring about #2: Morphing my search results into a captive newsreader gives me a demonstrably terrible experience browsing to sites on my phone. The swipe-back gesture is broken, scrolling doesn't move the safari borders away like it's supposed to, there's a big AMP border I can't get rid of, swiping just moves between results instead of going back (or did they "fix" this?), the URL bar shows google.com instead of the site, making it harder to share, etc etc. I don't care that they're "stealing traffic", I care that my mobile experience is demonstrably worsened.

lucideer 8y ago
That's true, but I was more addressing that #2 and #5 are two different outputs of the same technical mechanism—therefore saying that #2 is misinformed while #5 is valid is a contradiction.

niftich 8y ago

The difference between "stealing traffic" and the "Google Search Mobile is a captive newsreader" is nuanced. It's surprising and upsetting to people when they find out that in Google Search Mobile, their attempt to navigate to an AMP-lightning-marked search result doesn't result in a navigation to the target site, while an attempt to navigate to a non-AMP search result does go to the target site, as one would damn well expect. It's upsetting, because the designers of Google Search Mobile have gone through great lengths to hide the fact that the navigation didn't occur, and have adopted UI elements that intentionally try to mimic familiar navigation cues from browsers, rather than playing up the fact that they're viewing proxied content in a wrapping frame. On the other hand, the 'stealing traffic' critique is memetic from a catchy title by a much-revised blog post, and seems to genuinely be upset that bytes that would ordinarily be transferred between the end user and the article's originating host stop short of of the distant origin [1], and get served from a Google-owned CDN instead. It's a technically unsound mishmash of complaints, most probably deriving from the aforementioned behavior of the Google Search Mobile page, but imbued with the subtext that Google is exploiting publishers by providing a CDN. That's absurd. Maybe Google's exploiting publishers with its captive newsreader, but not by providing a CDN. [1] https://www.alexkras.com/google-may-be-stealing-your-mobile-traffic/ https://www.alexkras.com/google-may-be-stealing-your-mobile-...

MrStonedOne 8y ago
Stealing traffic also means stealing information about how many hits a page has if such is recorded via the webserver logs. Honestly third party websites serving a proxy/cdn/transparent cache of a website is something that should require affirmative consent from either side of the party. Something Google is not getting, and as such stealing traffic is an acceptable critique. It also reduces the security of the website by allowing users to get used to it being hosted from a google search page. SEO an imposter website that shows the same fake ui border and phish logins, the user wouldn't notice as it looks absolutely normal. (Something I might make a grey hat attempt at just because it's likely the only way to get google to stop doing it.)
- niftich 8y ago
  The publisher of the AMP content can configure hooks into their analytics solution [1]. These events can fire during any AMP pageview. Given this, I'm not convinced they'll mourn the lack of httpd logs. The typical practice for CDNs is that only the publisher consents; the CDN assumes responsibility for routing and serving the content (and has the private key for the origin's cert, to masquerade as them), and the requester doesn't get a choice. This isn't whataboutism, just an observation that CDNs are always the choice of the content originator, and never the content requester, who possesses few tools to convincingly tell the two apart. [1] https://www.ampproject.org/docs/analytics/analytics_amp https://www.ampproject.org/docs/analytics/analytics_amp
  - lucideer 8y ago
    I think the main point here from an analytics perspective is that, even if you don't choose to use Google Analytics or opt for any other service from Google, if you implement the (allegedly non-Google) AMP specification, Google gets to analyse your users while they browse your content, even after they've clicked away from the Google results page and are—for all intents and purposes—browsing a non-Google property. This is in contravention of both user and publisher expectations, and is non-optional for both parties.
alangibson 8y ago