5 ms·

Isn't this basically like a CDN or a PoP cache?

by dqpb 6y ago

IncRnd 6y ago
Not exactly. For a CDN to work, the DNS is repointed towards the CDN's servers. In this case, Google is trying to cover-up that Google and not NYTimes is serving the page.
- wmf 6y ago
  Is NYTimes's use of Fastly also a cover-up?
  - IncRnd 6y ago
    Google by definition wants to cover-up the domain name that serves amp web pages. Over half of the article discusses that. For your question about fastly, I already answered that in the comment you replied. The fastly CDN requires that the DNS is configured to point at fastly servers. Take a look at https://docs.fastly.com/en/guides/sign-up-and-create-your-first-service https://docs.fastly.com/en/guides/sign-up-and-create-your-fi... under "Start serving traffic through Fastly". Once you’re ready, all you need to do to complete your service setup and start serving traffic through Fastly is set your domain's CNAME DNS record to point to Fastly. For more information, see the instructions in our Adding CNAME records guide." A CNAME record is a dns mechanism that aliases an alternate domain for a canonical domain.
    - wmf 6y ago
      Users don't see DNS records. In the old world they click on a nytimes.com link and get something served from a Fastly server, but in the future AMP world they click on nytimes.com and get it served from a Google server. It isn't different.
      - IncRnd 6y ago
        You bring up an interesting point - if AMP hosting is the same as a CDN, then why do companies use both solutions? "Because they appear the same" doesn't mean they are the same. AMP requires that you consume other Google products, which requires that additional JS is loaded. When your mobile site doesn't use AMP, Google limits SEO rankings your mobile site can have. Google AMP requires your pages meet Google's Content Policies or they won't host them. AMP and CDN delivered pages are architected differently and Google imposes restrictions and requirements that don't exist in a CDN.
      - rocho 6y ago
        It's very different. And the difference lies in the URL bar. When you use a CDN, your visitors will still see your domain. With Amp, they see google.com.
        tsimionescu 6y ago
        That's exactly what Google wants to change, and what Mozilla is opposing.
      - simias 6y ago
        I agree with you, if I understand the signed exchange proposal correctly the trust model is effectively similar (NYT explicitly opts to let Fastly pretend to be them through their DNS config in the same way that a signed exchange would let them explicitly opt into letting Google pretend to be them). I'm still opposed to the change, I see this centralization of the web through CDNs as a bad thing, I don't want to make it easier.
        jefftk 6y ago
        The trust model is pretty different: in the traditional model NYT has to trust their CDN to serve the content unmodified. In the signed exchange model, any modification will cause the content not to validate, and the browser will reject it.
  - boomlinde 6y ago
    Does NYTimes' use of Fastly subvert the meaning of the URL by literally covering it up in the address bar? Nope? Not the same thing, then. Personally I don't think there's anything wrong with the fundamental concept of signed exchanges. The only problem is that it's just that: a signed exchange of content, which should have nothing to do with the domain name authority in the URL. By all means, display "Content from: a.com" in a box next to the URL, but don't change b.com to a.com in the URL as though it doesn't already have a well defined meaning.
    - ehsankia 6y ago
      > the meaning of the URL The issue is that the technical meaning of the URL is very far from what most user think of. Is the URL an address for NYT's server? Not really because you are actually hitting Fastly's server. So when NYT sets up a magical DNS config, it suddenly is fine, but using crypto to sign the package and serve it on a CDN that way, then it's suddenly "subverting the meaning of the URL"? We can have a real discussion of what the meaning of a URL is, but I think your interpretation is unfair. I think it's entirely fair to argue that it makes sense for URLs to be an address to a specific content.
      - boomlinde 6y ago
        > The issue is that the technical meaning of the URL is very far from what most user think of. My argument is not really concerned with what most users think of, but humor me, what do they think of? > So when NYT sets up a magical DNS config, it suddenly is fine, but using crypto to sign the package and serve it on a CDN that way, then it's suddenly "subverting the meaning of the URL"? Yes, because HTTP/S scheme URLs have a definition that implies a meaning, which is subverted when you create exceptions to that meaning. NYT setting up a "magical" DNS config that resolves to some third party server is perfectly fine by that definition, and resolving one FQDN while displaying another is not. It's not sudden, this standard has existed in one form or another since 1994. > We can have a real discussion of what the meaning of a URL is Yeah, let's do that instead of harping on about what's fair and unfair. It's not a matter of fairness, it's a matter of standardized definitions. By all means, create a new "amp:" URI scheme where the naming authority refers to whoever signed the data and resolves to your favorite AMP cache, but don't call it http or https.
- deleted 6y ago
  [deleted]
matheist 6y ago
Not if nyt hasn't authorized google to act on their behalf. "Yes we will serve your stuff on your behalf at your request, now that you have stuck your sign on our door via a DNS record" vs "We're putting your sign on our door because as the authors of a browser we can do that, whether you like it or not".
- remexre 6y ago
  NYT in fact has to go through non-trivial technical effort to authorize Google to act on their behalf.

Isn't this basically like a CDN or a PoP cache?

by dqpb 6y ago

Isn't this basically like a CDN or a PoP cache?

Not exactly. For a CDN to work, the DNS is repointed towards the CDN's servers. In this case, Google is trying to cover-up that Google and not NYTimes is serving the page.

wmf 6y ago
Is NYTimes's use of Fastly also a cover-up?
- IncRnd 6y ago
  Google by definition wants to cover-up the domain name that serves amp web pages. Over half of the article discusses that. For your question about fastly, I already answered that in the comment you replied. The fastly CDN requires that the DNS is configured to point at fastly servers. Take a look at https://docs.fastly.com/en/guides/sign-up-and-create-your-first-service https://docs.fastly.com/en/guides/sign-up-and-create-your-fi... under "Start serving traffic through Fastly". Once you’re ready, all you need to do to complete your service setup and start serving traffic through Fastly is set your domain's CNAME DNS record to point to Fastly. For more information, see the instructions in our Adding CNAME records guide." A CNAME record is a dns mechanism that aliases an alternate domain for a canonical domain.
  - wmf 6y ago
    Users don't see DNS records. In the old world they click on a nytimes.com link and get something served from a Fastly server, but in the future AMP world they click on nytimes.com and get it served from a Google server. It isn't different.
    - IncRnd 6y ago
      You bring up an interesting point - if AMP hosting is the same as a CDN, then why do companies use both solutions? "Because they appear the same" doesn't mean they are the same. AMP requires that you consume other Google products, which requires that additional JS is loaded. When your mobile site doesn't use AMP, Google limits SEO rankings your mobile site can have. Google AMP requires your pages meet Google's Content Policies or they won't host them. AMP and CDN delivered pages are architected differently and Google imposes restrictions and requirements that don't exist in a CDN.
    - rocho 6y ago
      It's very different. And the difference lies in the URL bar. When you use a CDN, your visitors will still see your domain. With Amp, they see google.com.
      - tsimionescu 6y ago
        That's exactly what Google wants to change, and what Mozilla is opposing.
    - simias 6y ago
      I agree with you, if I understand the signed exchange proposal correctly the trust model is effectively similar (NYT explicitly opts to let Fastly pretend to be them through their DNS config in the same way that a signed exchange would let them explicitly opt into letting Google pretend to be them). I'm still opposed to the change, I see this centralization of the web through CDNs as a bad thing, I don't want to make it easier.
      - jefftk 6y ago
        The trust model is pretty different: in the traditional model NYT has to trust their CDN to serve the content unmodified. In the signed exchange model, any modification will cause the content not to validate, and the browser will reject it.
- boomlinde 6y ago
  Does NYTimes' use of Fastly subvert the meaning of the URL by literally covering it up in the address bar? Nope? Not the same thing, then. Personally I don't think there's anything wrong with the fundamental concept of signed exchanges. The only problem is that it's just that: a signed exchange of content, which should have nothing to do with the domain name authority in the URL. By all means, display "Content from: a.com" in a box next to the URL, but don't change b.com to a.com in the URL as though it doesn't already have a well defined meaning.
  - ehsankia 6y ago
    > the meaning of the URL The issue is that the technical meaning of the URL is very far from what most user think of. Is the URL an address for NYT's server? Not really because you are actually hitting Fastly's server. So when NYT sets up a magical DNS config, it suddenly is fine, but using crypto to sign the package and serve it on a CDN that way, then it's suddenly "subverting the meaning of the URL"? We can have a real discussion of what the meaning of a URL is, but I think your interpretation is unfair. I think it's entirely fair to argue that it makes sense for URLs to be an address to a specific content.
    - boomlinde 6y ago
      > The issue is that the technical meaning of the URL is very far from what most user think of. My argument is not really concerned with what most users think of, but humor me, what do they think of? > So when NYT sets up a magical DNS config, it suddenly is fine, but using crypto to sign the package and serve it on a CDN that way, then it's suddenly "subverting the meaning of the URL"? Yes, because HTTP/S scheme URLs have a definition that implies a meaning, which is subverted when you create exceptions to that meaning. NYT setting up a "magical" DNS config that resolves to some third party server is perfectly fine by that definition, and resolving one FQDN while displaying another is not. It's not sudden, this standard has existed in one form or another since 1994. > We can have a real discussion of what the meaning of a URL is Yeah, let's do that instead of harping on about what's fair and unfair. It's not a matter of fairness, it's a matter of standardized definitions. By all means, create a new "amp:" URI scheme where the naming authority refers to whoever signed the data and resolves to your favorite AMP cache, but don't call it http or https.
deleted 6y ago
[deleted]

matheist 6y ago

Not if nyt hasn't authorized google to act on their behalf. "Yes we will serve your stuff on your behalf at your request, now that you have stuck your sign on our door via a DNS record" vs "We're putting your sign on our door because as the authors of a browser we can do that, whether you like it or not".

remexre 6y ago
NYT in fact has to go through non-trivial technical effort to authorize Google to act on their behalf.