6 ms·

> Google can choose today which site (original or AMP cache) to show in their search results. Today, as an end user, I know, via the URL, when I land on a Googl

> Google can choose today which site (original or AMP cache) to show in their search results. Today, as an end user, I know, via the URL, when I land on a Google AMP site. Ok why is this an issue? Note that HN is a bad place for this kind of socratic method discussion, we'll both quickly run out of the ability to post replies. Assume I'm someone who doesn't share whatever values you share about the purity of the url bar or whatever. Why is you being unable to know whether or not the content came from Google's IP or mysite's IP relevant to anyone as long as it's the same content (which signed exchanges ensure)?

wizzwizz4 6y ago
Centralised collection of metadata, without the users having any way of knowing it's going on.
tyingq 6y ago
Combined with that second thing I mentioned (required Google hosted JS), it is total control by Google with no straightforward way for me to detect it, block it or go around it, as I can today.
- joshuamorton 6y ago
  So if I understand correctly, your threat model is "Google will inject unwanted JS into a JS blob they host (like the amp.js from Google's CDN) and this will do nefarious (for some definition of nefarious) things to me without me knowing." How is this different than today, where many sites use js from google, either as a cdn or part of the ads infrastructure? I guess you can block some of those, but blocking the jquery provided by google's CDN isn't going to work too well. (And further, what kind of nefarious thing do you fear Google will do? How likely is it that they will do so, in your opinion?)
  - tyingq 6y ago
    >>what kind of nefarious thing do you fear Google will do Well, the headline is one good example. That google controlled JS is EXACTLY how they removed access to the original URL...on somebody else's page that isn't theirs. "Signed exchanges" doesn't fix that either. It's also how they hijack the back button and swipe events for carousel navigated pages.
    - joshuamorton 6y ago
      > That google controlled JS is EXACTLY how they removed access to the original URL...on somebody else's page that isn't theirs. No, the Google AMP cache adds the header bar. That isn't added by the Google controlled AMP js. Let me repeat this: The AMP js didn't change. Google's AMP cache implementation changed. (if you disagree with this, please post the diff of the AMP js that removed the url bar, the js is opensource at [0]) > "Signed exchanges" doesn't fix that either. Yes it does, in two ways: 1. It would prevent Google from mucking with the embedded page at all, like they do now. 2. It would remove the need for me to have the url redirect, since the url bar would point to the original site. [0]: https://github.com/ampproject/amphtml/commits/master https://github.com/ampproject/amphtml/commits/master
      - tyingq 6y ago
        Apologies, you're right in that they aren't using it that way. They could, and the examples of the top bar, swipes, and back button hijacking seem to indicate they aren't averse to it. Those things caused me to lose trust in AMP. That they chose to do it via a "proxy" instead of their hosted javascript doesn't make me trust them more.
  - kbenson 6y ago
    > How is this different than today, where many sites use js from google, either as a cdn or part of the ads infrastructure? It's different because it's a requirement. nytimes.com is moving to phase out all third-party advertising data, so presumably they could design their page such that it only accesses their resources. With a signed exchange, that would allow them to nicely compartmentalize and contain privacy to their site, if they aren't required to load and run some Google supplied JavaScript. The argument that Google already knows that someone visited the page so it's no big deal is not compelling, since there is a big different in knowing someone clicked to visit a page, and having carte blanche over loading your own code on the page in question. Can you include the AMP rquiers JS inline such that it implement an AMP spec version, or do you need to load it externally? If you can supply it inline, that's great, and what people would want (as long as it doesn't load additional third party resources). If you can't then you're providing Google with an extra level of control that's not really needed, and that's what people are against. > (And further, what kind of nefarious thing do you fear Google will do? How likely is it that they will do so, in your opinion?) If we go forth only considering what we think people will do, and not limiting what they can do, we're destined to be upset with the outcome. If not from Google itself, then in twenty years when someone buys Google, or Google sells off a division that houses information, or there's a breach and it's exposed, or some other company rides on Google's coattails and uses the same precedence to get data but is less trustworthy. The point is that some people don't want to share this information, and would choose not to do so if there was an easy way to tell when it was being gathered. Fighting against new methods that seek to make it implicit instead of explicit is the only real way to do that. 1: https://www.axios.com/new-york-times-advertising-792b3cd6-4bdb-47c3-9817-36601211a79d.html https://www.axios.com/new-york-times-advertising-792b3cd6-4b...
    - joshuamorton 6y ago
      > With a signed exchange, that would allow them to nicely compartmentalize and contain privacy to their site, if they aren't required to load and run some Google supplied JavaScript. Then I'd direct you to Gregable's comment (who is a person who actually works on AMP) that > the AMP project is actively working to move the origin (control/host) of the AMP Javascript to the publisher's own domain, as well as allow a version served on an origin owned by the OpenJS Foundation, rather than Google. So while this isn't supported yet, the people working on it do ant that. > If we go forth only considering what we think people will do, and not limiting what they can do, we're destined to be upset with the outcome. If not from Google itself, then in twenty years when someone buys Google, or Google sells off a division that houses information, or there's a breach and it's exposed, or some other company rides on Google's coattails and uses the same precedence to get data but is less trustworthy. I'm unconvinced by such slippery slope arguments, given that the pushback were Google to do something like inject nefarious js would be swift. They've had the ability to do so for, well, 20 years now. They haven't yet.
  - yyyk 6y ago
    Today, many (most) sites do not use js from Google or hosted by Google. Google is pushing them to use Google infrastructure by way of AMP and that's the wrong direction.
  - deleted 6y ago
    [deleted]
DevKoala 6y ago
Because now every asset you download from the web is a Google tracking resource. Is it really unclear what’s going on? When you perform a GET request for these assets you are being monitored. These requests end up being part of the profile built for you which is used for advertisement targeting and content recommendation. PS: You work for Google. Do you work on this project?
- joshuamorton 6y ago
  > When you perform a GET request for these assets you are being monitored. You'll only ever retrieve Google AMP cache results from the Google search page, where they were already able to track if you made such a request, since the link you clicked has trackers in it. So from that perspective, nothing changes. > PS: You work for Google. Do you work on this project? No, I work on mostly internal infrastructure. My interest in AMP is simply that I don't dislike the AMP "experience", it's fine. But more importantly, I legitimately don't get the HN hysteria around AMP. Returning to your concern, literally nothing changes with AMP vs non-AMP. I don't get it. The most compelling concern I've heard is that it's annoying to have to couple parts of your infra to AMP-standard stuff. And I sort of understand that. But even that isn't different than previous SEO/ranking changes that required changes to the page.
  - DevKoala 6y ago
    > You'll only ever retrieve Google AMP cache results from the Google search page, where they were already able to track if you made such a request, since the link you clicked has trackers in it. So from that perspective, nothing changes. I am not affected, I don’t use Google search. The problem is for individuals who use Google search and now don’t have an option to avoid in deep tracking. The difference between regular pixel trackers and multiple data points associated with every resource a site serves is immense. I work in ad-tech, not particularly in the identification side, but I started multiple projects in that end. From experience, a regular tracker can be fooled, but you cannot fool every resource request. One of the things I did to identify ad fraud bots was actually drive them to a site in which I controlled every resource. The resource request fingerprint for bots was easily distinguishable from real people. Moreover, some humans exhibited navigation patterns that were distinguishable from other humans. I remember I caught a QA person doing a shoddy job of testing the front end once due to it. That is the kind of power that Google is acquiring as more and more sites choose to use AMPs. It is scary to think that a single identity has that power.
kovac 6y ago
You asked how and he answered. Whether it's an issue or not is a separate matter that none of us are going to agree on.

wizzwizz4 6y ago

Centralised collection of metadata, without the users having any way of knowing it's going on.

tyingq 6y ago

Combined with that second thing I mentioned (required Google hosted JS), it is total control by Google with no straightforward way for me to detect it, block it or go around it, as I can today.

joshuamorton 6y ago
So if I understand correctly, your threat model is "Google will inject unwanted JS into a JS blob they host (like the amp.js from Google's CDN) and this will do nefarious (for some definition of nefarious) things to me without me knowing." How is this different than today, where many sites use js from google, either as a cdn or part of the ads infrastructure? I guess you can block some of those, but blocking the jquery provided by google's CDN isn't going to work too well. (And further, what kind of nefarious thing do you fear Google will do? How likely is it that they will do so, in your opinion?)
- tyingq 6y ago
  >>what kind of nefarious thing do you fear Google will do Well, the headline is one good example. That google controlled JS is EXACTLY how they removed access to the original URL...on somebody else's page that isn't theirs. "Signed exchanges" doesn't fix that either. It's also how they hijack the back button and swipe events for carousel navigated pages.
  - joshuamorton 6y ago
    > That google controlled JS is EXACTLY how they removed access to the original URL...on somebody else's page that isn't theirs. No, the Google AMP cache adds the header bar. That isn't added by the Google controlled AMP js. Let me repeat this: The AMP js didn't change. Google's AMP cache implementation changed. (if you disagree with this, please post the diff of the AMP js that removed the url bar, the js is opensource at [0]) > "Signed exchanges" doesn't fix that either. Yes it does, in two ways: 1. It would prevent Google from mucking with the embedded page at all, like they do now. 2. It would remove the need for me to have the url redirect, since the url bar would point to the original site. [0]: https://github.com/ampproject/amphtml/commits/master https://github.com/ampproject/amphtml/commits/master
    - tyingq 6y ago
      Apologies, you're right in that they aren't using it that way. They could, and the examples of the top bar, swipes, and back button hijacking seem to indicate they aren't averse to it. Those things caused me to lose trust in AMP. That they chose to do it via a "proxy" instead of their hosted javascript doesn't make me trust them more.
- kbenson 6y ago
  > How is this different than today, where many sites use js from google, either as a cdn or part of the ads infrastructure? It's different because it's a requirement. nytimes.com is moving to phase out all third-party advertising data, so presumably they could design their page such that it only accesses their resources. With a signed exchange, that would allow them to nicely compartmentalize and contain privacy to their site, if they aren't required to load and run some Google supplied JavaScript. The argument that Google already knows that someone visited the page so it's no big deal is not compelling, since there is a big different in knowing someone clicked to visit a page, and having carte blanche over loading your own code on the page in question. Can you include the AMP rquiers JS inline such that it implement an AMP spec version, or do you need to load it externally? If you can supply it inline, that's great, and what people would want (as long as it doesn't load additional third party resources). If you can't then you're providing Google with an extra level of control that's not really needed, and that's what people are against. > (And further, what kind of nefarious thing do you fear Google will do? How likely is it that they will do so, in your opinion?) If we go forth only considering what we think people will do, and not limiting what they can do, we're destined to be upset with the outcome. If not from Google itself, then in twenty years when someone buys Google, or Google sells off a division that houses information, or there's a breach and it's exposed, or some other company rides on Google's coattails and uses the same precedence to get data but is less trustworthy. The point is that some people don't want to share this information, and would choose not to do so if there was an easy way to tell when it was being gathered. Fighting against new methods that seek to make it implicit instead of explicit is the only real way to do that. 1: https://www.axios.com/new-york-times-advertising-792b3cd6-4bdb-47c3-9817-36601211a79d.html https://www.axios.com/new-york-times-advertising-792b3cd6-4b...
  - joshuamorton 6y ago
    > With a signed exchange, that would allow them to nicely compartmentalize and contain privacy to their site, if they aren't required to load and run some Google supplied JavaScript. Then I'd direct you to Gregable's comment (who is a person who actually works on AMP) that > the AMP project is actively working to move the origin (control/host) of the AMP Javascript to the publisher's own domain, as well as allow a version served on an origin owned by the OpenJS Foundation, rather than Google. So while this isn't supported yet, the people working on it do ant that. > If we go forth only considering what we think people will do, and not limiting what they can do, we're destined to be upset with the outcome. If not from Google itself, then in twenty years when someone buys Google, or Google sells off a division that houses information, or there's a breach and it's exposed, or some other company rides on Google's coattails and uses the same precedence to get data but is less trustworthy. I'm unconvinced by such slippery slope arguments, given that the pushback were Google to do something like inject nefarious js would be swift. They've had the ability to do so for, well, 20 years now. They haven't yet.
- yyyk 6y ago
  Today, many (most) sites do not use js from Google or hosted by Google. Google is pushing them to use Google infrastructure by way of AMP and that's the wrong direction.
- deleted 6y ago
  [deleted]

DevKoala 6y ago

Because now every asset you download from the web is a Google tracking resource. Is it really unclear what’s going on? When you perform a GET request for these assets you are being monitored. These requests end up being part of the profile built for you which is used for advertisement targeting and content recommendation. PS: You work for Google. Do you work on this project?

joshuamorton 6y ago
> When you perform a GET request for these assets you are being monitored. You'll only ever retrieve Google AMP cache results from the Google search page, where they were already able to track if you made such a request, since the link you clicked has trackers in it. So from that perspective, nothing changes. > PS: You work for Google. Do you work on this project? No, I work on mostly internal infrastructure. My interest in AMP is simply that I don't dislike the AMP "experience", it's fine. But more importantly, I legitimately don't get the HN hysteria around AMP. Returning to your concern, literally nothing changes with AMP vs non-AMP. I don't get it. The most compelling concern I've heard is that it's annoying to have to couple parts of your infra to AMP-standard stuff. And I sort of understand that. But even that isn't different than previous SEO/ranking changes that required changes to the page.
- DevKoala 6y ago
  > You'll only ever retrieve Google AMP cache results from the Google search page, where they were already able to track if you made such a request, since the link you clicked has trackers in it. So from that perspective, nothing changes. I am not affected, I don’t use Google search. The problem is for individuals who use Google search and now don’t have an option to avoid in deep tracking. The difference between regular pixel trackers and multiple data points associated with every resource a site serves is immense. I work in ad-tech, not particularly in the identification side, but I started multiple projects in that end. From experience, a regular tracker can be fooled, but you cannot fool every resource request. One of the things I did to identify ad fraud bots was actually drive them to a site in which I controlled every resource. The resource request fingerprint for bots was easily distinguishable from real people. Moreover, some humans exhibited navigation patterns that were distinguishable from other humans. I remember I caught a QA person doing a shoddy job of testing the front end once due to it. That is the kind of power that Google is acquiring as more and more sites choose to use AMPs. It is scary to think that a single identity has that power.

kovac 6y ago

You asked how and he answered. Whether it's an issue or not is a separate matter that none of us are going to agree on.