4 ms·

So is this basically the server okaying a replay attack? I'm looking through the technical post but it hasn't clicked yet.

zackbloom 7y ago
That's kind of a funny way of thinking about it, buy yes? Loading an AMP page is (hopefully) an action which isn't mutating any state, so I would say it's more similar to how a CDN works. You decide you are interested in having a cache respond to a given request in a specific way, and it responds to requests which look a certain way with that response. In this case it's significantly more secure though, as the exact request and response are signed and a third-party you trust (your browser) is deciding if that signature matches.
floatingatoll 7y ago
Analogy: Squid caching with a signature from your SSL certificate that proves it was valid as of when you signed it, so that the browser can trust the Squid cache and display the URL that’s in the signed plaintext with a domain matching that of the certificate that signed the cache blob. Today’s browsers trust all user-configured proxies implicitly and no other proxies at all, so providing a signed copy of the GET-only AMP content, it can be safely cached (the “replay attack”) without needing to trust the cache, because it’s signed plaintext.
dfabulich 7y ago
> okaying a replay attack When you permit a proxy to replay your content, it's just caching. It's not an "attack." (If the proxy can replay your content without your permission, that would be an attack.)
- tyingq 7y ago
  I believe AMP required inserting a piece of Google controlled and hosted JavaScript in your content from the very beginning. So the cat was pretty much out of the bag on this already.
  - themacguffinman 7y ago
    They're certainly not doing it without the website owner's permission. It's disingenuous to call it an attack.
    - tyingq 7y ago
      Yes, that's fair. I meant more in terms of ceding control...that's a prerequisite for AMP, and always has been.
  - paavoova 7y ago
    So if you block this Google JS, you cannot access said AMP page? Does AMP implicitly mandate users subscribe not only to said content provider but the third-party AMP host?
    - tyingq 7y ago
      Yes, you have to include it. "AMP pages must...Contain a <script async src="https://cdn.ampproject.org/v0.js https://cdn.ampproject.org/v0.js "></script> tag inside their <head> tag." https://amp.dev/documentation/guides-and-tutorials/start/create/basic_markup https://amp.dev/documentation/guides-and-tutorials/start/cre... Their special tags[1] won't render without it, and I suspect Google won't include it in their SERPS if it's not valid AMP. [1] https://amp.dev/documentation/guides-and-tutorials/learn/spec/amphtml?format=websites#html-tags https://amp.dev/documentation/guides-and-tutorials/learn/spe...

zackbloom 7y ago

That's kind of a funny way of thinking about it, buy yes? Loading an AMP page is (hopefully) an action which isn't mutating any state, so I would say it's more similar to how a CDN works. You decide you are interested in having a cache respond to a given request in a specific way, and it responds to requests which look a certain way with that response. In this case it's significantly more secure though, as the exact request and response are signed and a third-party you trust (your browser) is deciding if that signature matches.

floatingatoll 7y ago

Analogy: Squid caching with a signature from your SSL certificate that proves it was valid as of when you signed it, so that the browser can trust the Squid cache and display the URL that’s in the signed plaintext with a domain matching that of the certificate that signed the cache blob. Today’s browsers trust all user-configured proxies implicitly and no other proxies at all, so providing a signed copy of the GET-only AMP content, it can be safely cached (the “replay attack”) without needing to trust the cache, because it’s signed plaintext.

dfabulich 7y ago

> okaying a replay attack When you permit a proxy to replay your content, it's just caching. It's not an "attack." (If the proxy can replay your content without your permission, that would be an attack.)

tyingq 7y ago
I believe AMP required inserting a piece of Google controlled and hosted JavaScript in your content from the very beginning. So the cat was pretty much out of the bag on this already.
- themacguffinman 7y ago
  They're certainly not doing it without the website owner's permission. It's disingenuous to call it an attack.
  - tyingq 7y ago
    Yes, that's fair. I meant more in terms of ceding control...that's a prerequisite for AMP, and always has been.
- paavoova 7y ago
  So if you block this Google JS, you cannot access said AMP page? Does AMP implicitly mandate users subscribe not only to said content provider but the third-party AMP host?
  - tyingq 7y ago
    Yes, you have to include it. "AMP pages must...Contain a <script async src="https://cdn.ampproject.org/v0.js https://cdn.ampproject.org/v0.js "></script> tag inside their <head> tag." https://amp.dev/documentation/guides-and-tutorials/start/create/basic_markup https://amp.dev/documentation/guides-and-tutorials/start/cre... Their special tags[1] won't render without it, and I suspect Google won't include it in their SERPS if it's not valid AMP. [1] https://amp.dev/documentation/guides-and-tutorials/learn/spec/amphtml?format=websites#html-tags https://amp.dev/documentation/guides-and-tutorials/learn/spe...