4 ms·

First of all this is not a Google-only project. There are many partners. See e.g. https://blog.twitter.com/2015/introducing-accelerated-mobile-pages-0 https://b

First of all this is not a Google-only project. There are many partners. See e.g. https://blog.twitter.com/2015/introducing-accelerated-mobile-pages-0 https://blog.twitter.com/2015/introducing-accelerated-mobile... <amp-pixel> supports all kinds of tracking. You just give it a URL. Ironically it does not work with Google Analytics but we'll fix that eventually. Most others should work. <amp-ad> currently supports these ad networks https://github.com/ampproject/amphtml/blob/master/builtins/amp-ad.md https://github.com/ampproject/amphtml/blob/master/builtins/a... We are super happy to add more. We want to support all networks. You suggest elsewhere there is revenue sharing involved, but that is not true. amp-ad just loads an ad. This is controlled by the publishers and and their agreement with the advertiser. Google only plays a role if it happens to be the ad network (or the advertiser) involved.

felipeerias 11y ago
Taking into account that Google "happens to be" the largest ad company around, it is hard to not see this as a defensive move to protect themselves at a time when the disproportionately negative impact of ad-tech has put their business at the mercy of adblockers and native apps.
- solofounder1 11y ago
  In general, I think that there is an important conversation to be had about how this newly proposed cacheing tier would effect the overall cat and mouse game between tracking networks and ad blockers on mobile phones. Since the web community is being asked to choose to adopt a new technology, I don't think there's anything wrong with trying to reason about what would be technically possible to achieve in terms of tracking tech with this architecture. Here one rough estimate: If ads are all served locally (from a single domain) then it becomes technically feasible to utilize a short-lived rotating mutation URI generation scheme. Under such a tracking system each ad unit URI would be instantiated "just in time" to redirect a certain amount of load after which it would expire away. This JIT transient URI generator could be aware of the domain's application routing table so that it can dynamically spin out each new tracking/ad unit URI in a camouflaged form. In other words each URI could appear to be only a mutated variation of organic cached content. In computer security parlance this would establish a "covert channel" on top of HTTP via a timing attack vector (extremely short-lived URLs). https://en.wikipedia.org/wiki/Covert_channel https://en.wikipedia.org/wiki/Covert_channel https://en.wikipedia.org/wiki/Timing_attack https://en.wikipedia.org/wiki/Timing_attack I would imagine that ads propagated through such a system would be pretty much impossible for an ad-blocker to identify within a low-enough latency window. In other words by the time the ad unit's URI is discovered by a blocking server and it's clients are notified the URI has already vanished as if it never existed. What's I find slightly humorous about this approach to tracking is that the scheme would closely resemble several of the "blackhat SEO" techniques which are frowned upon by Matt Cutts' "Quality Guidelines" for example "link schemes", "automatically generated content", "cloaking", and "sneaky redirects". Surely it's unfathomable to think that Google would one day resort to such forms of trickery in order to confuse other search engines :) https://support.google.com/webmasters/topic/6001971 https://support.google.com/webmasters/topic/6001971 By the way this is only something I came up with earlier today and definitely not something that I've even heard discussed although I'm not in the advertising business myself. In other words it's entirely possible that I could have missed something here.
  - anonred 11y ago
    While there's bound to be other (more efficient) solutions, blockers could start filtering by the content returned. This sort of behavior leads to an arms race, with ad blockers ultimately losing (cost to detect >> cost to circumvent).
    - solofounder1 11y ago
      I follow your thinking. The ad networks could begin transforming their content in subtle ways which the eye cannot detect but which could throw off simple pattern matching thereby forcing the blocker client to employ an algorithmic approach. see https://en.wikipedia.org/wiki/BPCS-Steganography https://en.wikipedia.org/wiki/BPCS-Steganography The networks would be able to utilize many cores in parallel to mutate the content, but the blocker client would have to run it's detection on mobile devices. The more processing the blocker client must perform the more burden it places on that relatively underpowered mobile CPU which increases latency. Also when you get into algorithmic detection you have to start considering false positive ratio because any noticeable false positives will break the user's expectation causing them to eventually lose confidence in the client's utility. As you rightly point out there may be both vectors for either side which neither of us has thought of though.
gorhill 11y ago
> You suggest elsewhere there is revenue sharing involved, but that is not true. It's the data sharing which is worrying. Exactly which entities have access to what data gathered by `ampproject.org`?
tombrossman 11y ago
Scanning your comments, I haven't learned about what tracking is accomplished by serving the https://cdn·ampproject·org/v0·js https://cdn·ampproject·org/v0·js file itself, can you please comment on what data (if any) is collected by being 'the' place all AMP sites phone home to on page load by default? Two other points, and I hope these are received as constructive criticism. 1- You only score 'B' on SSL labs for the domain serving the AMP JS file.[0] Maybe this is intentional so as to include support for Android devices that no longer get updates but it's not great security for the rest of us. 2- Your page explaining the project executes Google Analytics tracking code and has no privacy policy and does not disclose the fact that you are tracking visits. This is a breach of your very own Google Analytics T&C's[1] which read in part "...You must post a Privacy Policy and that Privacy Policy must provide notice of Your use of cookies that are used to collect data. You must disclose the use of Google Analytics, and how it collects and processes data...". Neither of these inspire confidence and I hope you can get at least one of them corrected soon. [0]https://www.ssllabs.com/ssltest/analyze.html?d=ampproject.org&s=74.125.224.40&latest https://www.ssllabs.com/ssltest/analyze.html?d=ampproject.or... [1]https://www.google.com/analytics/terms/us.html https://www.google.com/analytics/terms/us.html

felipeerias 11y ago

Taking into account that Google "happens to be" the largest ad company around, it is hard to not see this as a defensive move to protect themselves at a time when the disproportionately negative impact of ad-tech has put their business at the mercy of adblockers and native apps.

solofounder1 11y ago
In general, I think that there is an important conversation to be had about how this newly proposed cacheing tier would effect the overall cat and mouse game between tracking networks and ad blockers on mobile phones. Since the web community is being asked to choose to adopt a new technology, I don't think there's anything wrong with trying to reason about what would be technically possible to achieve in terms of tracking tech with this architecture. Here one rough estimate: If ads are all served locally (from a single domain) then it becomes technically feasible to utilize a short-lived rotating mutation URI generation scheme. Under such a tracking system each ad unit URI would be instantiated "just in time" to redirect a certain amount of load after which it would expire away. This JIT transient URI generator could be aware of the domain's application routing table so that it can dynamically spin out each new tracking/ad unit URI in a camouflaged form. In other words each URI could appear to be only a mutated variation of organic cached content. In computer security parlance this would establish a "covert channel" on top of HTTP via a timing attack vector (extremely short-lived URLs). https://en.wikipedia.org/wiki/Covert_channel https://en.wikipedia.org/wiki/Covert_channel https://en.wikipedia.org/wiki/Timing_attack https://en.wikipedia.org/wiki/Timing_attack I would imagine that ads propagated through such a system would be pretty much impossible for an ad-blocker to identify within a low-enough latency window. In other words by the time the ad unit's URI is discovered by a blocking server and it's clients are notified the URI has already vanished as if it never existed. What's I find slightly humorous about this approach to tracking is that the scheme would closely resemble several of the "blackhat SEO" techniques which are frowned upon by Matt Cutts' "Quality Guidelines" for example "link schemes", "automatically generated content", "cloaking", and "sneaky redirects". Surely it's unfathomable to think that Google would one day resort to such forms of trickery in order to confuse other search engines :) https://support.google.com/webmasters/topic/6001971 https://support.google.com/webmasters/topic/6001971 By the way this is only something I came up with earlier today and definitely not something that I've even heard discussed although I'm not in the advertising business myself. In other words it's entirely possible that I could have missed something here.
- anonred 11y ago
  While there's bound to be other (more efficient) solutions, blockers could start filtering by the content returned. This sort of behavior leads to an arms race, with ad blockers ultimately losing (cost to detect >> cost to circumvent).
  - solofounder1 11y ago
    I follow your thinking. The ad networks could begin transforming their content in subtle ways which the eye cannot detect but which could throw off simple pattern matching thereby forcing the blocker client to employ an algorithmic approach. see https://en.wikipedia.org/wiki/BPCS-Steganography https://en.wikipedia.org/wiki/BPCS-Steganography The networks would be able to utilize many cores in parallel to mutate the content, but the blocker client would have to run it's detection on mobile devices. The more processing the blocker client must perform the more burden it places on that relatively underpowered mobile CPU which increases latency. Also when you get into algorithmic detection you have to start considering false positive ratio because any noticeable false positives will break the user's expectation causing them to eventually lose confidence in the client's utility. As you rightly point out there may be both vectors for either side which neither of us has thought of though.

gorhill 11y ago

> You suggest elsewhere there is revenue sharing involved, but that is not true. It's the data sharing which is worrying. Exactly which entities have access to what data gathered by `ampproject.org`?

tombrossman 11y ago

Scanning your comments, I haven't learned about what tracking is accomplished by serving the https://cdn·ampproject·org/v0·js https://cdn·ampproject·org/v0·js file itself, can you please comment on what data (if any) is collected by being 'the' place all AMP sites phone home to on page load by default? Two other points, and I hope these are received as constructive criticism. 1- You only score 'B' on SSL labs for the domain serving the AMP JS file.[0] Maybe this is intentional so as to include support for Android devices that no longer get updates but it's not great security for the rest of us. 2- Your page explaining the project executes Google Analytics tracking code and has no privacy policy and does not disclose the fact that you are tracking visits. This is a breach of your very own Google Analytics T&C's[1] which read in part "...You must post a Privacy Policy and that Privacy Policy must provide notice of Your use of cookies that are used to collect data. You must disclose the use of Google Analytics, and how it collects and processes data...". Neither of these inspire confidence and I hope you can get at least one of them corrected soon. [0]https://www.ssllabs.com/ssltest/analyze.html?d=ampproject.org&s=74.125.224.40&latest https://www.ssllabs.com/ssltest/analyze.html?d=ampproject.or... [1]https://www.google.com/analytics/terms/us.html https://www.google.com/analytics/terms/us.html