3 ms·

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

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]

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]