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.
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.
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.
> 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.
I think the subtle shift of view here is that the URL shows the address where the content is located, more so than where the content was actually fetched from.
An example of where this occurs today is caching. You could be hitting a cache anywhere along the way. Hell you could be seeing an "offline" version, but the website would still show you the "address" of the content.
This is no different, you're hitting a different cache, but the "URL" you see is the canonical address of the content you are looking at, not where it was actually fetched from.
> I think the subtle shift of view here is that the URL shows the address where the content is located, more so than where the content was actually fetched from.
The only sense in which content is located anywhere is as data on a memory device somewhere. With the traditional URI in which the host part of the authority is an address of or a domain name pointing towards an actual host, you have a better indication of where the content is located than you do if this is misrepresented as being some other domain name which in fact does not at all refer to the location of the content.
The shift, if any, is that people may be less interested in where the content is located and more interested in its publishing origin.
> An example of where this occurs today is caching. You could be hitting a cache anywhere along the way. Hell you could be seeing an "offline" version, but the website would still show you the "address" of the content.
Yes, because that's how domain names work.
> This is no different, you're hitting a different cache, but the "URL" you see is the canonical address of the content you are looking at, not where it was actually fetched from.
It's different in the sense that a host name as displayed by the browser then has multiple, conflicting meanings that have no standardized precedent.
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-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.
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.
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.
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.
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.
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.
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".
