Hacker News Reader

Comment by superasn | Hacker News Reader

Yes this has been a big issue for a very long time now. Google wants to push a release where it will display the hostname of the amp site even if the content is being served from google.com[1].

Mozilla (and Apple) are strictly against it and thank god for Mozilla. If Google had a bigger market share this would already be something we would have been living with. I'm sure there are better sources for this, but here is the first result:

https://9to5google.com/2019/04/18/apple-mozilla-google-amp-s...

View on HN

Being completely against AMP for obvious reasons, I'm personally not against signed exchanges itself, this feature could spawn a whole new class of decentralised and harder to censor web hosting, that sounds like a great addition.

Going to also spawn a whole new class of semi-persistent malicious pages (say created via XSS) that once signed and captured can be continuously replayed to clients until expiration.

What? The signing allows the content to be mirrored in other locations with guarantees about consistency. It doesn't imply anything more about the content than SSL does.

If Google AMP is acts like a cache of content, then cache poisoning attacks are a concern. How those cached items expire will determine how long an attacker who poisons the cache can serve malicious content.

Why does Archive.org get a pass on this one? Signed responses mean that there's a very clear way to leverage the browser's domain blacklisting technology to stop the spread of malware, which isn't presently possible for any content mirrors on the web.

Archive.org makes it clear you are on archive.org. The URL shows archive.org. The page content shows archive.org at the top. [1]

Google AMP doesn't show Google on the page. Google is pushing for the URL to show the origin site's URL instead of Google[2].

If an attacker poisons a nytimes.com article served by Google AMP, how does a browser's domain blacklisting help? Block google? Block nytimes.com? Neither makes sense.

1. https://web.archive.org/web/20050401090916/http://www.google...

2. https://9to5google.com/2019/04/18/apple-mozilla-google-amp-s...

I believe you might be misunderstanding the idea behind signed exchanges. To be clear, Signed Exchanges are how AMP should have worked all along.

example.com generates a content bundle and signs it. Google.com downloads the bundle and decides to mirror it from their domain. Your browser downloads the bundle from google.com, and verifies that the signature comes from example.com. Your browser is now confident that the content did originate from example.com, and so can freely say that the "canonical URL" for the content is example.com.

Malicious.org does the same thing, and the browser spots that malicious.org is blocked. At this point it doesn't matter if the content came from google.com, because the browser knows that the content is signed by malicious.org and so it originated from there.

Hope this helps clarify. Obviously blacklisting isn't a great security mechanism; my point is just that signed exchanges don't really open any NEW vectors for attack.

I think the concern was more that if I can XSS example.com, Google is now serving that for some period of time after example.com's administrators notice + fix this. (In the absence of a mechanism to force AMP to immediately decache the affected page(s), that is.)

Yes, at what point does example.com lose control of their content and for how long?

I'm following.

Imagine that example.com builds the bundle by pulling data from a database. If an attacker can find a way to store malicious content in that database (stored XSS) and that content ends up in a signed bundle that Google AMP serves (similar to cache poisoning) then users will see malicious content. When the stored XSS is removed from the database, Google AMP may continue to serve the malicous signed bundle. So an extra step may be needed to clear the malicious content from Google AMP.

How exactly the attacker influences the bundle is going to be implementation dependent, so some sites may be safe while others are exploitable.

Signed exchanges can only serve static content, so it's not clear what you could do maliciously.

XSS?

I think most of the comments in this thread mean "malicious" in the sense of injecting malware (say, a BTC miner) or a phishing attach or something into the signed-exchange content. However, you also have to consider that the content (text, images) itself could be "malicious", in the sense of misinformation.

If, purely as a hypothetical, Russian operatives got a credible propaganda story posted on the NYT website 24 hours before the November elections, and an AMP-hosted version of it stayed live long after the actual post got removed from nyt.com, I'd certainly call that "malicious". Of course, just like archive.org, I suspect that in a case as high-profile as that, you'd see a human from the NYT on the phone with a human at Google to get the cached copy yanked ASAP, but maybe on a slightly smaller scale the delay could be hours-to-days, which is bad enough.

At that point, wouldn't the approach be to defend from the client side? Namely, we can instruct the client to not trust any content sign by such-and-such keys. This can be done by pushing out a certificate revocation, etc.

This would be pretty cool (remotely revoking signed exchanges), however it's not part of Google's proposal - Unless every previous security consideration about caches is accounted for in SX's, it's probably not safe to start faking the URL bar.

Certificate revocations do apply to signed exchanges.

Along with signing, we need explicit content cache busting and explicit allowed mirrors list (which can be revoked instantly). Then it would be at par with TLS + current cache busting mechanisms on top of TLS.

As long as javascript on the page has some way to inspect the signatures and where it was delivered from, you can implement cache busting, allowed mirrors, and invalidation yourself however you please.

I don't see how this tech would further help to make malicious pages created with XSS, any thoughts? It sounds like it's the same issue with or without signed exchanges.

Parent considers that the feature could be used to turn a temporary problem into a long-term problem. Sort of like how certificate pinning could be twisted to ransom an entire domain.

The point wasn't that this technology would uniquely enable XSS attacks, but rather that it could allow malicious actors to persist particular attacks for the duration of the validity of the signed content. Any brief vulnerability in a website now becomes serializable. They considered this already. Look in the draft "6.3. Downgrades":

"Signing a bad response can affect more users than simply serving a bad response, since a served response will only affect users who make a request while the bad version is live, while an attacker can forward a signed response until its signature expires. Publishers should consider shorter signature expiration times than they use for cache expiration times."

I see indeed, I don't think they are going with the right approach here, there should be an automatic way to upgrade signed content / check for updates, short signatures just destroys the benefits of the feature.

It's the only way to do it. TLS has shown that OCSP and the likes are not adding significant security and short certificate expiration is the only way to go.

The serving nodes are not necessarily under control of a well intended party that complies with upgrade requests.

And I don't see the issue with short expiry. The point of a cache is to reduce load, not to entirely eliminate it. Even with a 5m expiry, it's still 5 orders of magnitude better than having a 100+ QPS on your server.

Not continuously. The signed content includes an expiration date, which the publisher controls.

This expiration can also never be set more than 7 days in the future.

> this feature could spawn a whole new class of decentralised and harder to censor web hosting

How so?

https://docs.ipfs.io/concepts/dnslink/ this is how it should be

There is an issue opened around supporting HTTP exchanges for IPFS in the browser as well.

https://github.com/ipfs/in-web-browsers/issues/121

No... no, it would not. It would centralize web hosting and make it less censorship resistant.

Sure, you could move it somewhere else and have it show up in the address bar the same, but the actual URL has changed and you need to somehow get the new URL into people's hands. And ultimately you've centralized a lot of websites under a smaller number of service providers which, before, would have been on their own domains.

I'm not sure what you describe there but it sounds much more complicated than it is.

Isn't signed exchanges basically CDN's without having to setup DNS? It's in theory no different than using CloudFlare to serve your content, except any CDN can just serve it without giving them access to your domain.

Or you could store signed exchanges on platforms like Dat or IPFS and get real decentralization.

Right, the point is that anyone can serve the content through any platform, which is why it allows decentralization. But I just don't understand why people are hanging so tightly to the idea that a URL is a direct path to a server, because that just isn't true.

What you describe sounds a lot like URL spoofing, which is already pretty much used entirely to trick and scam unsuspecting users into clicking malicious links. Signed exchanges would just be an even harder to detect version of this.

Signed exchanges make it super easy to detect fraud. You can verify the signature...

No, with signed exchange your browser verifies that the original site really did produce the content you are viewing.

I don’t really think Google’s plan is that weird. And it would be amazing for decentralized networks, archiving, and offline web apps. Google can’t just serve nyt.com — they can serve a specific bundle of resources published and signed by nyt.com verified by your browser to be authentic and unmodified.

+1. The way I think about it is that signed exchanges are basically a way of getting the benefits of a CDN without turning over the keys to your entire kingdom to a third party. Instead you just allow distribution of a single resource (perhaps a bundle), in a crytographically verifiable way.

Stated another way, with a typical CDN setup the user has to trust their browser, the CDN, and the source. With signed exchanges we're back to the minimal requirement of trusting the browser and the source; the distributor isn't able to make modifications.

It seems like there is a risk that an old version of a bundle will get served instead of a new one by an arbitrary host? Maybe the bundle should have a list of trusted mirrors?

Alternatively super short expiry times. It doesn't seem like it would be that concerning to have another site serving a bundle that was 5 minutes out of date. It doesn't seem like it should be too much load to be caching content every 5 minutes.

There is a publisher selected expiration date as part of the signed exchange which the client inspects. The expiration also cannot be set to more than 7 days in the future on creation. This minimizes, but of course does not eliminate, this risk.

It also makes signed exchanges completely unusable for delivering packages offline. (E.g. the USB stick scenario)

What a bummer.

Browsers could have a setting to optionally display the content anyway, along with a warning to the effect of "site X is trying to show an archive of site Y", similar to how we currently handle expired or self-signed SSL certificates.

> a way of getting the benefits of a CDN without turning over the keys to your entire kingdom to a third party.

https://blog.cloudflare.com/keyless-ssl-the-nitty-gritty-tec... is a thing now.

The session key, which is given carte blanche by the TLS cert to sign whatever it wants under the domain, is still controlled by Cloudflare.

To put it simply, Cloudflare still controls the content. The proposal here would avoid that, by allowing Cloudflare to transmit only pre-signed content.

Your browser would have a secure tunnel to CloudFlare which is encrypted with their key. But then that tunnel would deliver a bundle of resources verified your browser differently that CF doesn’t have the key for.

I could see some sort of alternative URL bar ("https://nyt.com/somearticle/ | served by https://somecdn.example.org/blah"), but complete replacement is far too dangerous and confusing in that it is completely hidden.

The New York Times surely already serves their pages through a CDN, silently, and with the CDN having the full technical capability to modify the pages arbitrarily. Signed exchange allows anyone to serve pages, without the ability to modify them in any way.

(Disclosure: I work for Google, speaking only for myself)

My objection is that it's no longer clear if you're dealing with content addressing or server addressing. If I see example.com in the URL bar, is it a server pointed from the DNS record example.com (a CDN that server tells me to visit), or am I seeing content from example.com? If I click a link and it doesn't load, is it because example.com is suddenly down, or has it been down this whole time? Is the example.com server slow, or is the cache slow? Am I seeing the most recent version of this content from example.com, or did the cache miss an update?

What if there was a `publisher://...` or `content-from://...` or `content://...` protocol, somehow? (visible in the address bar, maybe a different icon too, so one would know wasn't normal https:)

And by hovering, or one-clicking, a popup could show both the distributor's address (say, CloudFlare), and the content's/publisher's address (say, NyT)?

The AMP spec REQUIRES you include a Google controlled JavaScript URL with the AMP runtime. So technically the whole signing bit is a little moot, given that the JS could do whatever it wanted.

The same could be said of any CDN hosted javascript library. For example: jquery. There is an open intent to implement support for publishers self-hosting the AMP library as well.

You missed the required part.

For most JS served by CDN, you can (and should) use Subresource Integrity to verify the content. At least the last time I was involved in an AMP project, Google considered AMP to be an "evergreen" project and did not allow publishers to lock in to a specific version.

Long term versions are now supported, so publishers can lock in a specific version.

Publisher hosted copies are in the pipeline, as I referenced in the parent comment. My choice of verbiage was a bit confusing it appears.

I don't think it's your wording that's confusing. You are contradicting the AMP documentation.

AMP's documentation seems to indicate that the LTS is stable only for one month (new features released via the same URL each month), and so is not compatible with SRI (see https://github.com/ampproject/amphtml/blob/master/contributi...)

You can specify a version (ie, https://cdn.ampproject.org/rtv/somenum/v0.js), but the AMP validator complains about that.

> The same could be said of any CDN hosted javascript library

Yes, and? What’s your point? It’s actually a security weakness to include third party JS. The whole thing runs on trust.

What's an open intent? Where is this documented?

AMP spec: https://amp.dev/documentation/guides-and-tutorials/learn/spe...

"AMP HTML documents MUST..."

"The AMP runtime is loaded via the mandatory <script src="https://cdn.ampproject.org/v0.js"></script> tag in the AMP document <head>."

Do a whois on ampproject.org:

"Registrant Organization: Google LLC Registrant State/Province: CA Registrant Country: US Admin Organization: Google LLC"

Note that jQuery, as mentioned in some GP comment has no such requirement. Google AMP is quite unique in this regard. This is NOT some general CDN type issue. Also...agreed, WTF is "open intent"?

https://github.com/ampproject/amphtml/issues/25873

Note "open", i.e., unresolved. Perhaps in a less positive light, "how to enabled signed exchanges/AMP without controlling it".

Correct. Open as in not resolved yet, but intended to be resolved in the future.

The plan is bad because google currently tracks all of your activities inside AMP hosted pages site in their support article.

Google controls the AMP project and the AMP library. They can start rewriting all links in AMP containers to Google’s AMP cache and track you across the entire internet, even when you are 50 clicks away from google.com.

Publishers who use AMP were already allowing Google to track everything through either Analytics or Ads.

Likewise, AMP pages are mostly accessed from Google search that's already tracked.

As a user I can choose to block GA, either through URL blocking or through legally mandated cookie choices in some regions (e.g. France). When served from Google I have no choice in the matter.

If you can block GA at the client, you can block google.com at the client, no?

Not if I want AMP pages. (I mean, I don’t, but there are presumably people who do.)

While that's theoretically possible, the library can be inspected and does not do these things.

Could Google give specific persons different versions or is technically impossible?

It's very possible indeed.

Technically yes, but not very practically. The domain is cookieless, so it would be difficult to even identify a specific user, other than by IP. Also, the JavaScript resource is delivered from the cache with a 1 year expiry, which means most times it's loaded it will be served from browser cache rather than the web.

How is google.com cookieless?

The AMP javascript is served on the cdn.ampproject.org domain, not google.com.

> the library can be inspected

Really? Could you publish how you are inspecting an unknown program to determine if it exhibits a specific behavior? There are a lot of computer scientists interested in your solution to the halting problem.

Joking aside, we already know from the halting problem[1] that it you cannot determine if a program will execute the simplest behavior: halting. Inspecting a program for more complex behaviors is almost always undecidable[2].

In this particular situation where Google is serving an unknown Javascript program, a look at the company's history and business model suggests that the probability they are using that Javascript to track use behavior is very high.

[1] https://en.wikipedia.org/wiki/Halting_problem

[2] https://en.wikipedia.org/wiki/Undecidable_problem

By reading the source code?

    def divisors(n):
        for d in range(1, n):
            if n % d == 0:
                yield d

    n = 1
    while True:
        if n == sum(divisors(n)):
            break
        n += 2
    print(n)

I don’t know if this program halts. But I’m pretty sure it won’t steal my data and send it to third parties. Why? Because at no point does it read my data or communicate with third parties in any way: it would have to have those things programmed into it for that to be a possibility. At no point I had to solve the halting problem to know this.

Also, if I execute a program and it does exhibit that behaviour, that’s a proof right there.

The same kind of analysis can be applied to Google’s scripts: look what data it collects and where it pushes data to the outside world. If there are any undecidable problems along the way, then Google has no plausible deniability that some nefarious behaviour is possible. Now, whether that is a practical thing to do is another matter; but the halting problem is just a distraction.

> I don’t know if this program halts.

Be cool if you did ;)

If you didn't catch the joke: It is currently unknown whether there are any odd perfect numbers (and the program halts on encountering the first).

https://en.wikipedia.org/wiki/Perfect_number

https://oeis.org/A000396

> at no point does it read my data

Tracking doesn't require reading any of your data. All that is necessary is to trigger some kind of signal back to Google's servers on whatever user behavior they are interested in tracking.

> or communicate with third parties

Third parties like Google? Which is kind of the point?

> [example source code]

Of course you can generate examples that are trivial to inspect. Real world problems are far harder to understand. Source is minified/uglified/obfuscated, and "bad" behaviors might intermingle with legitimate actions.

Instead of speculating, here is Google's JS for AMP pages:

https://cdn.ampproject.org/v0.js

How much tracking does that library implement? What data does it exfiltrate from the user's browser back to Google? It obviously communicates with Google's servers; can you characterize if these communications are "good" or "bad"?

Even if you spent the time and effort to manually answer these questions, the javascript might change at any time. Unless you're willing to stop using all AMP pages every time Google changes their JS and you perform another manual inspection, you are going to need some sort of automated process that can inspect and characterize unknown programs. Which is where you will run into the halting problem.

Funny how people can literally "forget" that Google is a third party. Probably people at Google believe they are not third parties. Not even asking or trust, just assuming it. No other alternatives. Trust relationship by default.

> Could you publish how you are inspecting an unknown program to determine if it exhibits a specific behavior? There are a lot of computer scientists interested in your solution to the halting problem.

This has nothing to do with the halting problem because that is concerned about for all possible programs not some programs.

We obviously know if some programs halt.

    while true: nop

Is an infinite loop.

    X = 1
    Y = X + 2

Halts.

More complex behaviours can be easier. Neither of my programs there make network calls.

They have the log files.

In what ways is this different/similar from "content centric networking"?

https://m.youtube.com/watch?v=gqGEMQveoqg

(Google Tech Talk from Van Jacobsen on CCN many years ago)

AMP is happening and CCN is not.

Do you mean to say that is the only difference?

No, there are many differences but they don't matter. Since CCN is not economically feasible, none of the technical details matter.

Why is CCN not economically feasible?

Why do they need a special extension though? What's wrong with DNS?

Signed exchanges are an extension to digital certificates, such as used for TLS. This is independent of DNS.

That's not why Google (the corporation) wants this to happen. This is not about technical capabilities but about power.

They cannot be allowed to become the gatekeeper for the web.

They already are. The question is not how we're going to stop that from happening but how we are going to roll it back.

Why would it be amazing for decentralized networks and offline web apps?

If I publish mycoolthing.com/thing, it could be mirrored over a P2P network as peer1.com/rehosted/mycoolthing.com/thing, peer2.com/rehosted/mycoolthing.com/thing, etc., in a way that would make it evident to end-users not familiar with the protocol that the content is from mycoolthing.com.

AMP is of course not P2P.

I think the point is that signed exchanges ( https://developers.google.com/web/updates/2018/11/signed-exc...) could potentially be useful, if separated from AMP, and made an actually secure thing. Like, for example, the spec doesn't require specific Google controlled js URLS to be in the content.

Signed exchanges is actually separate spec from AMP. The browser implements it independently. There is no requirement for AMP pages to use signed exchanges nor for signed exchanges to be AMP.

How does centralizing content on Google from multiple sources improve decentralization? The web is already decentralized. That's why it is a web.

AMP is a scourge. It's a bad idea being pushed by bad actors.

> How does centralizing content on Google from multiple sources improve decentralization?

It actually makes perfect sense in Doublespeak. /s

They’re suggesting a web technology which would allow any website to host content for any other website, under the original site’s URL, as long as the bundle is signed by the original site. That could be quite interesting of a site like archive.org, as the url bar could show the original url.

But AMP is a much narrower technology, I’d imagine only Google would be able to impersonate other websites, essentially centralised as you say. The generic idea would just be a distraction to push AMP.

Everything would be so much better if the original websites were not so overloaded with trackers, ads and banners, then there would be no need for these “accelerated” versions.

I think this is possible already, but should not override the displayed URL for the content.

Create a new “original URL” field or something.

I see where you are going, but what if my website is updated?Is the archive at address _myurl_ invalidated, or is there a new address where it can be found? I am thinking of reproducible URLs for academic references or qualified procedures, for example, which might or might not matter in the intended use case.

Could there be net-neutrality-like questions in all this as well?

Google is not a single server. Think of Google as a CDN.

So it's decentralized because Google has multiple servers? And here I was, thinking that Google runs everything from a single IBM mainframe.

What you're saying would be described as distributed... Not decentralized.

Seems to me like it's easy to forget there's a difference between those two..

The current implementation of the AMP cache servers obviously doesn't help the decentralization.

I think what Spivak is saying though is right. If we could move from location addressing (dns+ip) to content-addressing , but not via the AMP cache servers, in general, anyone could serve any content on the web. Add in signing of the content addressing, and now you can also verify that content is coming from NYTimes for example.

Also, I'd say that the internet (transports, piping, glue) is decentralized. The web is not. Nothing seems to work with each other and most web properties are fighting against each other, not together. Not at all like the internet is built. The web is basically ~10 big silos right now, that would probably kill their API endpoints if they could.

I think this would require an entirely new user interface to make it abundantly clear that publisher and distributor are seperate roles and can be seperate entities.

I don't think this should be shoehorned into the URL bar or into some meta info that no one ever reads hidden behind some obscure icon.

Isn't it already the case though with CloudFlare and other CDNs serving most of the content? Very few people really get their content from the actual source server anymore.

That's a good point. I just feel that there is an important distinction to be made between purely technical distribution infrastructure like Cloudflare's and the sort of recontextualisation that happens when you publish a video on Youtube. I'm not quite sure where in between these two extremes AMP is positioned.

Thank you for this explanation. AMP has put a really bad taste in my mouth but what you describe here does have some interesting implications. Something to consider for sure.

Please fact check me on this, but the ostensible initial justification for AMP wasn't decentralization, but speed. Businesses had started bloating up their websites with garbage trackers and other pointless marketing code that slowed down performance to unbrowsable levels. Some websites would cause your browser to come close to freezing because of bloat. So Google tried to formalize a small subset of technologies for publishers to use to allow for lightning fast reading, in other words, saving them from themselves. AMP might be best viewed as a technical attempt to solve a cultural problem: you could already achieve fast websites by being disciplined in the site you build, Google was just able to use its clout to force publishers to do it. As for what it’s morphed into, I’m not really a fan because google is trying to capitalize on it and publishers are trying various tricks to introduce bloat back into AMP anyway. The right answer might be just for Google to drop it and rank page speed for normal websites far higher than it already does.

How is it not weird that I see a domain name in the URL bar that has nothing to do with the domain I actually requested content from?

It's completely moving away from the client/server model to something else.

Perhaps that's a great thing to do, but it's not something to do quietly.

Just hearing about this from the thread, I'm getting a IPFS vibe from this. It would be interesting to see that tech get more native integration with the browser from this idea.

I agree, if we finally got a way to have working bundles on the web, that would be extremely useful. (And would also restore some of the capabilities of browsers to work without internet connection).

It seems to me, a lot of the security concerns come from the requirements to make pages served live and pages served from bundles indistinguishable to a user - a requirement that really only makes sense if you're Google and want to make people trust your AMP cache more.

I'd be excited about an alternative proposal for bundles that explicitly distinguishes bundle use in the URL (and also uses a unique origin for all files of the bundle).

I believe the issue with this is that users already largely don't understand decorations in the URL. For example, the difference between a lock and an extended verification certificate bubble. Educating a user on what a bundle URL means technically may be exceedingly challenging.

The problem is ownership. Google is “stealing” or caching content for what they consider a better web.

I don’t support ads but I also don’t support Google serving a version of the page that steals money from content creators. So, therein lies the problem: choice.

I can imagine a future where amp is ubiquitous and Google begins serving ads on amp content. Luckily, companies have to make money and amp is not in most people’s or company’s best interests.

If amp was opt-in only, this would be much more ethically sound.

Signed exchanges guarantee that the content cannot be modified by the cache, such as ad injection.

Google has never injected ads into any cache served AMP document (technically if the publisher uses AdSense, this is false, but that's not the point you are making).

It's difficult to follow what definition of theft is being suggested. The cache does not modify the document rendering, it's essentially a proxy. In a semantic sense, this is no different than your ISP delivering the page or your WiFi router.

Remember when Google was telling us that third-party cookies are there to protect us, and Safari/Firefox/Edge are just reckless and pose a risk to users by blocking them?

Please provide a link, I could only find this, which suggests Google has reversed course:

https://www.techradar.com/uk/news/google-is-phasing-out-thir...

> By undermining the business model of many ad-supported websites, blunt approaches to cookies encourage the use of opaque techniques such as fingerprinting (an invasive workaround to replace cookies), which can actually reduce user privacy and control.

https://blog.chromium.org/2020/01/building-more-private-web-...

I'm going to copy paste my older comment on this:

I find their "removing 3rd party cookies will incentivise businesses to rely on fingerprinting" discourse dangerous.

It implies that other browser vendors (Mozilla, Safari/WebKit, new Edge) are in fact making the Web a more dangerous place.

I believe it's dangerous because it creates a harmful, unproductive PR narrative—people might just assume this is a true statement, without learning about both sides of the problem. I'm not trying to strip anyone of agency, I just don't think most of my friends would have time to research this topic and might decide to follow the main opinion instead.

The answer I'd like to hear: Yes, it does push some actors towards fingerprinting, but preventing fingerprinting should be dealt with regardless. Changes should happen both on legislative and browser-vendor level.

Thank you for the additional background.

Thanks for asking, we need more comments like yours

Sounds a bit like: "By locking your door, you only encourage thieves to break your window, which can actually increase the damage they cause you."

Precisely.

Have a look at this: https://blog.cloudflare.com/announcing-amp-real-url/

Cloudflare allow using of same domain to use AMP. In this case, content is served from Cloudflare CDN.

It's called Signed Exchange and it's the same thing the comment you replied to is about.

Note the Cloudflare hosted AMP pages still mandate AMP requirements, like including a Google controlled JS uri in your content. Signing is moot if you allow Google to run arbitrary JS on your content. They haven't abused it yet, but it's allowed by spec. Subresource integrity isn't mandated, explained, or recommended.

I'm still waiting for general support of addons for the next version of Firefox on mobile just so that I can have the Redirect AMP to HTML[1] addon.

[1]: https://addons.mozilla.org/firefox/addon/amp2html/

I'm on Firefox on a mobile device. That addon has a redirection link [1] specifically for Firefox' mobile version.

As I didn't know about this addon, thanks for sharing it.

[1] https://addons.mozilla.org/en-US/android/addon/amp2html/

Here's a user script to get rid of AMP (I use it with adguard): https://userscripts.adtidy.org/release/disable-amp/1.0/disab...

This has been discussed over & over again and there is no representation from amp team to make it any better. I was surprised to realise how much my life changed when I started using firefox + duckduckgo. Full time, at work & home, on macOS & android.

Aren't we essentially reinventing http proxies with this?

Just having this idea already tells how important it is to actively resist Google.

One should never forget that at a certain point, Google will likely invoke the looser's argument ("protect you from terrorists and pedophiles") to require proof of identity prior to granting access to any resource or service it controls.

Anything that helps them advance in that direction must be fought fiercely.

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.

Is NYTimes's use of Fastly also a cover-up?

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.

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.

That's exactly what Google wants to change, and what Mozilla is opposing.

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.

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 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.

> 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.

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".

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

Holy mackerel

has the mainstream web jumped the shark ?

Well, it's the going opinion of HN for years that the main problem with AMP is it shows the actual origin instead of the proxied origin. Lying about the URL is something hundreds of HN comments have angrily demanded.

Why do you say that? I don’t think people want it to show the “proxied origin”, they want AMP to get out of the way and google to link to the real website.

No. The complaint is that Google is redirecting the content to servers that they control.

This is not correct. Anyone can host AMP. See, for example, amp.cnn.com. Google hosts AMP content for its customers who elect to use that service. It’s not a nefarious plot.

Reply on news.ycombinator.com