
AMP pages displaying your own domain - dfabulich
https://webmasters.googleblog.com/2019/04/instant-loading-amp-pages-from-your-own.html
======
IgorPartola
I can’t believe there is no way to opt out of AMP as the end user. The UX is
so terrible. Often times I will search for something and have a Reddit result
come back. When I tap the link, I get the AMP page which:

* does not show all comments, often ones I am actually looking for

* does not let me collapse comment sections

* uses the default white background theme which burns my retinas if I am looking at my phone in a dark environment

* shows overlay ads for the Reddit app that cover about 40% of the screen for no goddamn reason

* requires 2-3 separate actions to get to the original page

Yet I cannot find a browser extension or setting to tell AMP to fuck off.
Honestly AMP might be what finally gets me to switch search engines after many
years of using Google.

~~~
smilliken
You won't see AMP if you switch search engines.

~~~
dbbk
Bing implements AMP, and there's nothing technically stopping other search
engines from adding support.

Also, links in the Twitter app default to AMP as well.

~~~
IgorPartola
I wouldn't mind AMP as a feature as long as Google let me specify that I don't
want it.

------
Tepix
Using the signed exchange mechanism means you allow anyone to serve your
content. You will no longer know when it has been served and by whom. Instead,
Google will know more about what your users are consuming on your website than
you - despite HTTPS!

Also, there is no mechanism to limit who is allowed to serve your content for
you.

I see no technical reason why the content has to be prefetched from Google
instead of your own server.

It's also confusing for users and administrators. Want to block access to a
website in your network? Guess what: Your block will not be effective because
Google will proxy the data unbeknownst to the firewall.

~~~
zackbloom
The reason it has to be prefetched from not-you is to protect the users
privacy. Until they click a link it is not considered acceptable to leak their
search to the potential destination. Links have to be fetched from a third-
party who the search engine trusts not to share the data, that at the moment
is Google but will hopefully expand.

~~~
codedokode
Google already can do this by preloading a cached page from its own domain. So
this specification is unnecessary.

I think the real reason is that Google wants to build a walled garden, but
doesn't want the walls to be noticeable. Even with AMP, they display a header
that looks like a browser's address bar [1]

Also, on that page Google admits that it uses AMP Viewer to collect
information about users:

> Data collection by Google is governed by Google’s privacy policy.

Which is probably their real motication for creating AMP.

[1] [https://developers.google.com/search/docs/guides/about-
amp](https://developers.google.com/search/docs/guides/about-amp)

~~~
Ajedi32
> Google already can do this by preloading a cached page from its own domain.

That's what AMP already did. This spec is better because it ensures publishers
retain control over their own content, and doesn't confuse users by showing
"www.google.com" in the URL bar for content that didn't originate from Google.

~~~
codedokode
Publisher might want to display their URL in the address bar. But as a user I
want to see the actual URL, not what Google or publisher want to show me. I
don't want to see "example.com" in the address bar while I am actually
connected to Google via a TLS connection signed by Google's key and my IP
address is collected according to Google's privacy policy.

What confuses users is Google displaying a fake address bar [1] or browser
displaying the wrong URL.

[1]
[https://developers.google.com/search/docs/guides/images/amp0...](https://developers.google.com/search/docs/guides/images/amp07-signed-
exchange.png)

~~~
Ajedi32
The URL you see _is_ the actual URL. It doesn't matter where the content was
initially loaded from because the page is signed by the publisher's private
key (the publisher has full control over the page contents, Google can't alter
it).

~~~
codedokode
The content is served from Google's servers according to Google's (not
publisher's) privacy policy. While Google cannot alter the content, it sees
the unencrypted HTTP request. I don't want neither Google nor publisher to
control contents of my address bar.

~~~
Ajedi32
Google already knows the unencrypted contents of the page, and they know you
clicked on a link to it (from their search results page). The signed exchanges
system doesn't reveal any information to Google _or_ the publisher that they
don't already know.

Your browser controls the contents of the URL bar, not Google or the
publisher.

~~~
pvorb
But Google controls my browser.

~~~
codewiz
Have you tried changing browser? -- Written from my Chromium browser installed
from the Fedora Linux package repository.

~~~
pvorb
I actually use Firefox and avoid Google products where possible, but for the
majority of users Google _is_ controlling their browser.

------
jsnell
This is such a strange reaction from HN. The AMP cache URLs have been a top 3
complaint about AMP here. "I can't copy-paste URLs, it's hard for users to
understand which site they are on, it looks like the content is provided by
Google rather than the real provider", etc.

Now there's a solution that preserves the preloading and validation benefits
of AMP caches but maintains the original URLs, in a way that's
cryptographically sound, in the process of being standardized, and controlled
by the publisher. This gets launched much faster than one would have expected.
And suddenly everyone pretends that the AMP cache URLs were never a problem
and this is some kind of a power-grab.

~~~
cannedslime
My biggest quarrel with this is that its just another way for google to take
control over the internet. Does any other search provider than google use AMP?
Does any browser other than googles own support this? How busy are you? You
can't wait 0.5 seconds for an HTTP request? And you think its worth feeding
google with more precise data about your movements online than they already
have? And as a business integrating AMP, loose control over your own content
and platform? Why?

~~~
delroth
[https://blogs.bing.com/Webmaster-
Blog/September-2018/Introdu...](https://blogs.bing.com/Webmaster-
Blog/September-2018/Introducing-Bing-AMP-viewer-and-Bing-AMP-cache)

Disclaimer: I work at Google, nothing related to AMP or search.

~~~
ajmurmann
Bing is the best thing that ever happened to Google. It's the fig leave that
protects you from antitrust.

------
albertgoeswoof
Let’s hope AMP, like most google products, is shut down within the next 2-3
years

~~~
mrweasel
What's wrong with it exactly... beside being weird. I'm not a fan of
manipulating the URL the way they do with this change, but couldn't you just
opt to not use AMP if you don't like it?

Ideally people would develop fast sites on their own, but apparently they need
the help of Google.

~~~
untog
If you don't use AMP your search engine placement suffers. Often dramatically,
as all the pages in Google's top-most carousel are all AMP pages.

And AMP is a pain in the ass. It's sold as being "just HTML" but it isn't,
really. You can't even use an <img> tag, it has to be <amp-img>. So you have
to generate two versions of every page. Achievable for large companies but if
you don't have a lot of resources that's a big overhead. As is so often the
case, it helps concentrate all web traffic to a smaller and smaller number of
sites/publishers and shutting the rest out. That's not good.

------
Illniyar
We need to decouple two things that are mashed together in this post:

Web packaging and Signed exchanges seems benign and beneficial, you can sign a
particular page inside a package (let's say a zipped folder of some kind) and
now anyone can cache that data and show it, while both the browser and the
user knows that it's safe to display it. Since the AMP format is similar, it
seems quite beneficial to now have all your AMP content support this feature.
And anyone who made some of their pages AMP can use that same process to
support other Signed Exchanges (such as p2p networks or CDNs) . This is great
since it makes distributed caching much easier.

The bad part is that google search uses this signed exchange format not to
show the actual URL but rather put it in an iframe inside chrome (and only
chrome). The real question is whether we will be able to use this
functionality outside search, if I have my own site and show a large iframe
with signed exchange page, will I also be able to change the browser url bar?
mmph, probably not.

~~~
gregable
There is a little confusion here, understandable. Google search will not show
these signed exchanges in an iframe, the pages are full frame.

Try it for yourself. Using Chrome 73 or later (you probably already have
this), and a mobile browser (either a phone or mobile emulation), try the
query [amp dev success stories].

It will only use signed exchanges in Chrome because currently only Chrome
supports signed exchanges. The search engine explicitly looks for the browser
to state that it supports signed exchanges in an Accept header, like any other
new technology.

Yes, any page can use this. So, for example if you went and fetched a signed
exchange from [https://amppackageexample.com/](https://amppackageexample.com/)
(or any other site that supports one, this is just an example), you could then
serve that from your own server, more or less just like any other file (the
less is that you need to set the right Content-Type header, but it otherwise
works just like serving an image or a zip file).

Then, if a user visited the URL on your site [https://yoursite.com/cached-
copy-of-amppackageexample.com/](https://yoursite.com/cached-copy-of-
amppackageexample.com/) then the browser would display
[https://amppackageexample.com/](https://amppackageexample.com/) in the URL
bar, as though that URL had 301 redirected, but without the extra network
fetch.

Google search does exactly this, just loading a cached copy of the Signed
Exchange, and any other cache (or even any website) can do the same.

~~~
tW4r
Forgive my lack of know-how, but does this theoretically mean I could download
this _signed package_ to my computer along with the signature and use it later
to prove that the information was provided by the source according to the
signature?

~~~
themacguffinman
Yes. You can see this among other planned use cases for the web packaging spec
here [https://wicg.github.io/webpackage/draft-yasskin-
webpackage-u...](https://wicg.github.io/webpackage/draft-yasskin-webpackage-
use-cases.html#rfc.section.2.2.2)

~~~
IanCal
I'm not quite following which parts were or weren't needed for what's been
enabled in the post here, for the usecase of delivering a single offline
package that can be opened like a website, is there something that works yet?
Or a repo I should be following other than the spec?

Once I can create webpackages and deliver them to clients a lot of thing I
want to do become hugely easier and nicer.

~~~
themacguffinman
I believe Chrome has already shipped an implementation, I don't know any more
details unfortunately. It's still in the standardization process.

I know it's not exactly easy to follow but the only implementation repo I can
think of to follow right now is the Chromium repo.

~~~
IanCal
Oh interesting! I'll see what I can find there, thanks!

I also had a look in the blog and the "progressive web apps" might be the
right thing to look at. There's probably something subtle that's different but
I think I can use these to solve the actual problem I have.

[https://developers.google.com/web/updates/2019/03/nic73?hl=h...](https://developers.google.com/web/updates/2019/03/nic73?hl=hi)

edit - damn, I don't think this is right at all. Frustrating as it seems
pretty perfect but I have to serve from my own domain for 30s before a user
can install it :( I just want a single file way of delivering web content! It
seems like all the features are basically there, just with restrictions to
focus on different use cases.

------
codedokode
It's ridiculous. Google wants to keep users at its domain so much that it
invents a whole technology to substitute address bar contents. This shows how
harmful it is when a company has a significant market share in several
different areas (browsers and search engines).

I hope at least Mozilla doesn't adopt this technology and will show the true
URL.

This technology is complicated. Browser vendors have to implement all of this
only to please Google.

~~~
lucb1e
Indeed, Google just has too much market share.

Last week I blocked Google from my domains (blog: lucb1e.com/!130), hopefully
others will follow suit and degrade the search quality until people get better
results (at least for some more obscure content) elsewhere, or perhaps until
Google notices we are really not okay with their behaviour.

~~~
spartas
Are you blocking GoogleBot by IP range or User-Agent match? Why aren't you
using your robots.txt file to block GoogleBot instead or in addition to your
server-side logic?

~~~
lucb1e
Robots.txt was my first thought as well, but that is said to not actually
block your site from appearing in the results. They'll gather from other sites
what the page is about (think <a href=mysite/somepage>how to knit a
sweater</a>) and show that as title without page summary. Maybe if it looks
like the site is down, they won't bother.

Blocking is based on user agent, they seem to set that reliably and the IP
addresses change. You can do some reverse lookup magic but this was way easier
than looking up every single IP that visits my site.

------
strictnein
Remember the talk about how the Chrome team was going to "rethink" the navbar,
and what domain and site identity really mean? And people were a little
worried about this?

Turns out people were right to be suspicious. This is hot garbage. You can no
longer ask a user "What URL does your navbar say you're at?". It is no longer
a source of truth. They will actively be lied to.

~~~
Agebor
But what does it mean that you are on a particular URL?

For a long time already it's not being connecter to a particular physical
server. Now it's the next step - to be completely decoupled from the server
and just mean content instead.

~~~
propogandist
This is meant to offload tracking from just Google Analytics and SERP clicks,
which is used to track user behavior (but can be blocked) into services that
cannot be blocked beyond Google domains.

If Google hosts the website and is masking the resulting url, they're able to
have more visibility than Google analytics. They'll likely give this AMP some
SEO boost temporarily and that will get web admins to adopt the technology.

It's just like reCaptcha, which is used to track users across the web
(requires google.com + gstatic.com urls to load, which drops its own cookies
or scans existing ones), blocking recaptcha will break core web
functionality... and recaptcha v3 is even worse.

------
48309248302
This sounds terrible. Does it mean that browsers will begin lying to users and
say that the users are visiting the website's server when they are really
visiting a restricted version of the website that is hosted in Google's cache?
I don't want my content restricted or hosted in Google's cache.

AMP _doesn 't_ load in a privacy sensitive way. It's on Google's servers and
it takes many seconds to load if you have JavaScript disabled.

Also, the feature only works on Google Chrome and possibly Edge, which gives
another point to the article below.

[https://www.zdnet.com/article/former-mozilla-exec-google-
has...](https://www.zdnet.com/article/former-mozilla-exec-google-has-
sabotaged-firefox-for-years/)

AMP is a fundamentally bad idea that needs to disappear.

Edit: Mozilla has marked Signed HTTP Exchanges as harmful.

[https://mozilla.github.io/standards-
positions/](https://mozilla.github.io/standards-positions/)

~~~
gregable
The browser displays the URL from the origin that digitally signed the
unmodified content.

A browser already doesn't show you what server delivered the content. That
would be your wifi AP, cell phone tower, or ISP node. The internet has already
long established that we can trust content without trusting intermediaries.

There are two elements that are important: integrity and privacy. The content
integrity is protected via a digital signature, the "signed" part of "signed
http exchanges". The signature proves that the document hasn't been tampered
with.

Regarding privacy: The intermediary (a search engine in this case) already has
the content being delivered as a result of crawling it. It also knows the user
clicked on a link to get that content, and knows the user's ip address. Even
without AMP or Signed Exchanges, the privacy situation is the same. Once the
page is loaded, all further interactions with the origin are normal https
traffic, so later requests are not different in privacy either.

What this enables, for search results, is the ability to load the bytes of the
content before the user clicks a search result. If the browser prefetched
those bytes with the origin's awareness, then the user's privacy with respect
to the search query would be violated, making prefetch problematic. With this
setup, documents can be prefetched while preserving user privacy and after the
user clicks all browser behavior continues as normal from that point forward.

~~~
rando444
AMP allows Google to see exactly how you interact with every page on the
internet.

Just from the text of the pages you visit they can build a profile around you.
What your interests are, how much of an article you're likely to finish,
whether you're the type of person to highlight text as you read, etc.

Unless you live on an island with a poor satellite connection AMP is useless
as anything more than a corporate user data collection tool.

~~~
gregable
AMP documents don't share user data with Google, which can be trivially seen
by inspecting the network events that the page generates.

If the publisher chooses, they can send logging to Google Analytics, but this
is not part of AMP.

The typical argument otherwise is that the AMP javascript is loaded from
Google's cache, however these javascript resources allow for a very long cache
lifetime (1yr if the page came from the Google Cache), so relatively few page
loads will actually end up fetching them from the network for most users.

Edit: These resources are also on cookieless domains.

~~~
codedokode
> AMP documents don't share user data with Google, which can be trivially seen
> by inspecting the network events that the page generates.

Is there anything preventing Google from changing this later?

~~~
andrerm
No, if Google can change the way web works from day one they can change
anything they want. Don't forget Google is killing imap and dns already. Why
not http to?

~~~
codedokode
Also, Google explicitly states that it is collecting data in AMP Viewer [1]:

> The Google AMP Viewer is a hybrid environment where you can collect data
> about the user. Data collection by Google is governed by Google’s privacy
> policy.

I assume they collect information from HTTP request the browser sends when
requesting an AMP page.

[1] [https://developers.google.com/search/docs/guides/about-
amp#a...](https://developers.google.com/search/docs/guides/about-amp#about-
google-amp-viewer)

------
iandanforth
I feel like Google is pushing AMP and components too hard. I've started to
balk at the idea of using them even for explorations.

~~~
ganeshkrishnan
AMP is like Brussels Sprouts. If it's forced on you when you are young, you
will grow up hating it.

~~~
48309248302
Brussels sprouts are good for you. AMP is more like medical experiments
performed on you during an alien abduction.

~~~
Kiro
What's up with this extreme hatred for AMP? I personally love AMP.

~~~
Moru
Most people do not like to be forced to do things a certain way. Especially if
they have a working site already and now have to remake it from the ground up
just because some other actor decided it isn't good enough to get visitors.

Just you wait until you notice you can't go to town in your car any more. Only
teslas are allowed into city.

~~~
Kiro
That's a bad example for me personally since I think all cars should be banned
(except maybe electric cars but I haven't done the necessary research to see
the actual environmental impact). I haven't used my driver's license in years
and always take the train (I've also stopped flying).

But anyway, that's off topic. I understand that it's a pain for developers but
for users like me who are often on a bad connection it's a life saver.

------
p1mrx
Seems like a reasonable idea. The content server says "here, you hold this for
me", and the address bar only shows who originally signed it.

One could imagine replacing the serving layer with something like BitTorrent
or IPFS.

~~~
AgentME
Yeah, I think this feature and the signed exchanges standard both sound great.
It allows CDN-like servers to host content without having to be trusted to not
modify the content. That sounds like an improvement over the current CDN
situation.

Also, sites that link to other sites can preload the linked site's content
into the user's browser, without leaking the user's IP to the linked site, so
if the user doesn't follow the link, nothing about the user is revealed to the
linked site. That sounds like a performance and privacy improvement wrapped up
into one. I'm finding the rest of this discussion thread extremely
disappointing as it seems like most of the posts here are just "amp=bad and
amp people like this so it's also bad".

~~~
dane-pgp
Signed Exchanges could also remove some of the concerns around JavaScript
crypto, because there is a (potentially offline) key that signs the web app
you're running, so you're not vulnerable to hacks of the hosting environment
itself.

What's really needed is a way for the browser to lock a given web app/package
to a specific version (and hash), so that even if the signing key becomes
compromised, the app can't auto-update to a newer version containing malicious
code.

Combining this with something like Certificate/Binary Transparency would allow
browsers to check that they are not being uniquely targeted with a specially
altered version, and you could set a policy saying "Only auto-update to a
newer version of this web app if its hash has been published in a log for more
than a month (and/or endorsed by signatures from N out of M other
organisations I trust)".

------
rob-olmos
Semi-related, I think Web Packages and Signed Exchanges could have some
usefulness outside of Google's caches. One of their spec examples was for
verifiable web page archives.

Another idea it could be used for a wifi "drop box" (drop station?) when
there's no internet connection around. That isn't uncommon at some popular
spots up river into the woods in the US.

The idea is that as people enter the area, they can update the drop station
automatically for things like news or public posts with whatever they've
cached recently.

I'm pretty sure I read about this idea before the spec was drafted but I
couldn't find or remember the site, something like vehicle-transported data.

~~~
gregable
You may be thinking of this use cases section here:
[https://wicg.github.io/webpackage/draft-yasskin-
webpackage-u...](https://wicg.github.io/webpackage/draft-yasskin-webpackage-
use-cases.html)

~~~
rob-olmos
Thanks. IIRC the site I saw was from a few years ago, before the spec was
drafted. (I updated my post to be more clear). Pretty sure there was a few
photographs on the page out in the flat grasslands.

------
deevolution
AMP pages take forever to load, I hate seeing a white screen > 1 second. with
amp that's all I see on mobile. A white screen burning my eyeballs, seemingly
forever. And then I snap out of it and hit back to escape from AMPs empty
void.

~~~
Cthulhu_
I read in probably another HN thread that using an adblocker will actually
slow down an AMP page - there's a hardcoded 3 second CSS delay which is
cancelled if (via JS) it's detected the page is loaded.

------
bluetidepro
I would _pay_ google to be able to disable AMP permanently on mobile web
results. The experience is the absolute worst. I'm fine with them wanting to
ruin mobile web (that's their choice), but PLEASE let the users be able to
disable this terrible "feature."

~~~
mad182
This, x1000. I just can't believe there is no setting to turn it off.

------
sascha_sl
I want Google to die already.

It's so obvious why AMP is on the main google.com domain.

They're collecting your shit.

They're doing the same thing with ReCaptcha, also on the main google.com
domain.

Break this shitty company apart.

------
Illniyar
After reading all of the comments here, this seems like a good thing.

This fixes the main UI issues with how AMP is currently used in google search
- mainly the url not properly showing where the content is.

If secure exchange is treated the same as AMP pages in google search, I.E. SXG
content will be preloaded whether or not it's AMP, it would get rid of the
second complaint of AMP - that google's preloading of the content is an unfair
playing ground and that the only reason it's fast is because it's preloaded.

If SXG is treated the same as AMP in the carousal then that would fix the last
and most serious complaint about AMP.

As far as I can tell, google do seem to be moving in that route, so this
should be applauded not derided (the original fiasco that is AMP non-
withstanding)

------
dreamcompiler
Probably time for a congressional and/or DOJ inquiry into whether AMP is an
example of Google abusing its monopoly power in the search engine space.

------
millstone
The headline is an outright lie: these AMP pages are loaded from Google and
not your domain.

The new feature is that Google's browser displays your domain, obscuring the
fact that Google is doing the serving. The change is what is displayed, not
the server.

~~~
foota
At this point, if you ignore the amp aspect, how is this any different from
plain http caching?

~~~
carnagii
the consumer is being lied to about who is serving their request and who is
tracking their online activity as a result.

------
jonplackett
I hate AMP. Not just for google thinking they own the internet. They never
seem to load right on my phone and crash a lot too.

------
kuschku
So, when will Google roll out signed exchanges for plain HTML content? That's
much more interesting, and if combined with e.g. a restriction such as a
Lighthouse speed score of > 60, it'd be in all measurable ways better than
AMP.

Faster than AMP, more open than AMP, and all the benefits of AMP.

------
nessup
Does nothing for publishers' needs for deeper control and analytics. Just a
"feel good" gesture that results in additional complexity for everyone
involved. Google is not the only company in the world that knows how to load a
page efficiently.

~~~
gregable
The publisher's cookie-based analytics will operate on the origin in the URL
bar in this case. The document (though not the delivery server) will have
access to publisher origin cookies.

Conceptually, you can think of a signed exchange as a 301 redirect to a new
URL which has already been cached by the browser (so there is no 2nd network
event). The cache was populated by the contents of the signed exchange,
assuming the signature validates.

------
skilled
I wonder if Google is self-aware to the fact that majority of webmasters don't
give a shit about AMP.

~~~
notatoad
I wonder if any webmasters are self aware that their users like amp

~~~
stephenr
Users like pages that load quickly, which amp is not a requirement for.

Amp is designed to tighten googles grip on the web, nothing more.

~~~
eitally
No it isn't. It's designed to make the user experience better on sites that
frequently host Google ads (and also often contain a ton of bloat, 3rd party
js, poorly constructed DOMs, awful CSS, etc).

The only way Google could proactively "solve" this problem was by creating a
"standard", and then also offering to absorb end user traffic for sites that
adopted the standard. FWIW, AMP is an open standard not solely owned or
contributed to by Google.

[https://amp.dev/](https://amp.dev/)

~~~
abc-xyz
Why is that the only way? Seems like they could easily have achieved the same
result by significantly penalizing sites based on load time and number of
external requests.

~~~
mthoms
This question cuts right to the heart of the matter.

I've yet to see a Google engineer, executive, or "fanboy" address this
question adequately.

This thread will be no exception. Queue the crickets.

~~~
themacguffinman
Because users want relevant search results much more than fast websites.
Google already factors in a website's performance in their rankings, but
weighing it too much over content relevance will make search results worse.

~~~
mtberatwork
By that logic then, what's the point of AMP if Google is saying page load
speeds aren't really that big of a factor? Why go through through the trouble
of _deriving a whole new subset of HTML_?

~~~
themacguffinman
I discuss this in another reply chain:
[https://news.ycombinator.com/item?id=19681408](https://news.ycombinator.com/item?id=19681408)

------
Sephr
With the peerweb.com platform I will be providing a free-for-non-commercial-
use polyfill for Signed HTTP Exchanges which can be used for distributed p2p
content offloading.

Peerweb helps sites automatically offload all resources (including streaming
ugc video) to a decentralized p2p network.

ETA: ~1yr

------
jedberg
This feels like it solves the biggest _user_ complaint with AMP, which was the
ugly URLs and having to click an extra time to get the "real URL" for sharing.

It also at least helps slightly address one of the complaints of publishers,
which is that cookies and some analytics will work now.

But it still doesn't address the biggest complaints of publishers.

I'm guessing Google cares a lot more about the user experience than the
publisher experience, since users make up most of the traffic and all of the
ad consumption, so this is certainly good for them!

------
noncoml
Alternative title: why you shouldn’t be using Chrome.

Split Alphabet already.

~~~
lovehashbrowns
Yep, I'm off to the Firefox world. I hate amp with a passion. Straight
garbage.

------
chrisfinazzo
I'll just say this:

    
    
        Cache-Control: no-transform

~~~
cramforce
Signed Exchanges are basically that but with cryptographic guarantee of no
transform by caches. See
[https://github.com/WICG/webpackage/blob/master/explainer.md](https://github.com/WICG/webpackage/blob/master/explainer.md)

[Working on AMP at Google]

------
rum3
So now you can spoof a domain as long as you have the private part of the
certificate even though you don't have control over the domain?

If I understand this right then this seems to open up some doors for some new
email phishing scams.

~~~
gregable
This is true with TLS as well, though it also requires man-in-the-middling
(MITM) the connection. MITM is usually rather easy compared to stealing a
private key.

~~~
rum3
Yes but it is much harder to MITM if the users are in different parts of the
world.

Someone can buy a lookalike domain name using similar-looking UTF characters,
send out a bunch of email spam with an URI that looks like the original, and
once the user visits the webpage it instantly loads the AMP and suddently the
URL is authentic. There will only be a very quick url change from the punycode
url to the original that I doubt many will notice.

------
zjs
I found Cloudflare's post on this topic to be more useful:
[https://news.ycombinator.com/item?id=19678693](https://news.ycombinator.com/item?id=19678693)

------
NelsonMinar
If you're going to break the way the web works, you might as well break it
_hard_. At least that seems to be Google's philosophy with this unasked-for
inserting itself between people and publishers.

------
andy_ppp
Who is going to be in charge of the signing process? Can I sign the content
myself? Will Google eventually only sign content it deems appropriate? Can we
trust Google to always do the right thing?

~~~
gregable
Good question. The signing is done by the publisher, using the same digital
signature infrastructure that is used for TLS (https). So, the publisher alone
has the signing key, and any browser can verify the signature by comparing to
the public certificate, signed by a certificate authority.

------
throwaway66666
I 've stopped using google because of AMP. Only google can sabotage google at
this point, and I think this is how it will happen if they keep going this
way.

------
zaarn
I found the Cloudflare announcement to be more useful:
[https://blog.cloudflare.com/announcing-amp-real-
url/](https://blog.cloudflare.com/announcing-amp-real-url/)

I'm not entirely a fan of this, though it could have uses in other places;

Debian for example, could use this to enable HTTPS-like security without
requiring mirrors to upgrade their security to the late 2000's.

------
Illniyar
Here's the real question - how is this implemented in chrome? are signed
exchange website that are clicked in google search page and whose url is
switched is still running the google search page's code?

If this is so, and it only works for google search's page and not some generic
web strategy, this is a massive breach of browser/web-content separation,
bigger then even the auto-sign-in to google from chrome.

~~~
gregable
Good question.

Conceptually, you can think of a signed exchange as a 301 redirect to a new
URL which has already been cached by the browser (so there is no 2nd network
event). The cache was populated by the contents of the signed exchange,
assuming the signature validates.

There is no "reaching into the document" from the previous click or anything
weird like that.

~~~
Vinnl
I just wanted to say a quick thank you for going out of your way to answer to
many questions here. Despite the obviously hostile environment (I have some
reservations about AMP myself), your answers have been very clear, informative
and level-headed, so thanks for that.

~~~
gregable
I appreciate the comment. My goal here is simply to correct some of the
misunderstandings about the format, rather than express opinions.

------
cannedslime
There is just something about AMP that reeks of soylent drinking hipsters.
Everything from thinking requireing devs to use some abitrary CDN and tons of
obfuscated scripts for the most mundane things (like forms?) to the emoji in
the <html> tag... Eh no thanks. I get that exchangeable signed website
packages might be a good idea for various purposes. But no thanks I don't
measure my life in seconds.

------
dbbk
So now there's literally no way to 'break out' of the AMP version and get the
real webpage. Great.

------
craftinator
Can any Google engineers comment on the the large amount of negativity towards
AMP found in these HN comments (and pretty much every other HN forum
discussing AMP)? I can't imagine working on a project and seeing so many
people (especially given the average education level on HN) who can't stand
it. I want to hear from you guys about this!

------
Yuval_Halevi
one of the biggest issues i had with AMP is the URL (Which cause some of the
users in our site a confusion)

Implementing AMP while keeping my website URL is great. Glad to hear that
Cloudflare is already supporting this.

Will implement it now in my sites.

------
fiatjaf
Does AMP run on Firefox? I've been using Firefox since the Quantum launch and
haven't seen any AMP lately. I had completely forgotten this nightmare once
existed.

------
coldtea
This calls for several billions EU fine...

------
j0057
Seems dangerous for the web to mess with the URL bar, I get why Google wants
to do this.

------
stupidthrottle
For people who don’t like AMP, avoiding it is really easy:

Don’t use Google search.

That’s all. That’s really all there is to it. You should give it a try!

~~~
OrgNet
I've also seen HN users share AMP links ...

One example:
[https://news.ycombinator.com/item?id=19679136](https://news.ycombinator.com/item?id=19679136)
, luckily someone also provided the non-amp equivalent...

------
zulgan
what is happening?!!

~~~
andrerm
We lost Google but it's hard to let go

------
devoply
Ah okay so Google is the new Facebook walled garden.

~~~
908087
Google is trying to turn the entire internet into their own walled garden.

------
tannhaeuser
Wtf? I guess it's time to blacklist Google and their web of worthlessness. I
mean, using Google Search is literally "give me advertisement in disguise"
these days, and I don't understand what people expect from using it. An
effective remedy also seems to block all script; serves as a useful filter for
actual content rather than ad-infested clickbait, and the script-ladden pages
you can't view aren't worth your time and bandwidth anyway.

