
Announcing AMP Real URL - chdaniel
https://blog.cloudflare.com/announcing-amp-real-url/
======
AlexandrB
This is a "solution" to a "problem" that AMP itself created. And in the
process it creates additional complexity[1] and a new potential revenue
stream[2] for middlemen providing a service that shouldn't be necessary in the
first place.

Astounding.

And oh yeah:

> AMP Real URL is only supported in the Chrome browser at this time, but we
> are optimistic it will be supported more widely as its benefit to Internet
> users becomes clear.

Who needs web standards, right? [3]

[1] Especially egregious because it's making SSL identity validation even more
complex than it was before. I'm sure this will make getting security "right"
even harder.

[2] Or in this case a new barrier to competition:

> After speaking with publishers and with Internet users, we have decided not
> to charge for AMP Real URL. This is not because our customers haven’t been
> excited or willing to pay for it, AMP makes up a huge component of many
> site’s traffic. Our motivation is the same as for offering CDN or SSL
> services to millions of customers free of charge, we are here to help build
> a better Internet and improving AMP is a huge step in that direction.

Edit: [3] dfabulich (below) has correctly pointed out that this is in the
process of being standardized: [https://tools.ietf.org/html/draft-yasskin-
http-origin-signed...](https://tools.ietf.org/html/draft-yasskin-http-origin-
signed-responses-05)

Despite this, Firefox has currently marked this proposal as "harmful"
([https://mozilla.github.io/standards-
positions/](https://mozilla.github.io/standards-positions/)). It seems to me
as though Google may be ramming this one through despite objections.

~~~
dfabulich
> Who needs web standards, right?

This new thing (signed HTTP exchanges) is an IETF draft.
[https://tools.ietf.org/html/draft-yasskin-http-origin-
signed...](https://tools.ietf.org/html/draft-yasskin-http-origin-signed-
responses-05)

As usual, Chrome is the first browser to implement this, but they're
participating in the normal standards process. (Microsoft is in favor. The
Chrome team generally ships stuff if at least one other major browser vendor
approves.)

~~~
snek
Normally I'd rush to Chrome's defense here (see my post history) but I have to
agree with others about Chrome kind of breaking the process here. Other
browser vendors have large concerns with this spec, so it's quite surprising
that it's shipping at this scale.

~~~
Twirrim
Doesn't surprise me in the slightest. Chrome has done this before, e.g. with
QUIC.

------
ocdtrekkie
It's really unfortunate to see awful claims like "we are here to help build a
better Internet and improving AMP is a huge step in that direction" that are
blatantly dishonest and harmful to the Internet being promoted by Cloudflare
in this blog post. AMP is a horrible cancer the Internet is plagued with, and
we keep being told it's great even though _literally nobody wants it_.

Claims like "Many of the sites we have spoken to get as much as 50% of their
web traffic through AMP" ignore the fact that this is only true because it's
been forced down our throats without our consent.

Anyone implementing an AMP-based technology which doesn't come with a way for
users to decline to participate is actively harming the open web. I like
Cloudflare and a lot of what it does, but I'm really disappointed in them
today.

~~~
zackbloom
[I work at Cloudflare]

It's hard to build a great website, particularly one which works well on
mobile. AMP as a web framework makes it easier. There's nothing about that
value it which is intrinsically linked to any particular way of rendering AMP,
a good chunk of the web would be better off building on AMP independent of
Google. That doesn't mean every site should, there are developers and teams
who are capable and willing to build great sites and we support their right to
not have to use AMP. The need to use AMP-the-framework to get instant loading
is hopefully a temporary one partially fixed by signed exchanges.

The AMP cache is also made much less concerning and painful for users through
the use of signed exchanges. By ensuring the content is what was provided by
the origin we believe the Internet is becoming a more trustworthy place,
opening the door to sites being able to be served from wherever they will be
most performant.

~~~
martin_a
> It's hard to build a great website, particularly one which works well on
> mobile.

> The need to use AMP-the-framework to get instant loading is hopefully a
> temporary one partially fixed by signed exchanges.

You know what would really fix this? Developers doing their work. Deeply
knowing and understanding the consequences of their work and how everything
comes together in the end and leads to a slow website or not.

We don't need to put even more power in the hands of Google, because we (as in
"some developers") don't know how to do our job right and therefore punish the
internet as a whole.

There is no valid reason for the use of AMP. It's only there because a)
developers fucked up and b) Google forces you to use it. If we would fix a),
I'm not sure b) would even be a valid point anymore.

~~~
Vinnl
> You know what would really fix this? Developers doing their work.

That's merely replacing one problem by another, which is: how do you get
developers to do their work?

~~~
martin_a
You'll need people that _really_ love their work. I know that's hard to find
or to achieve, but it's possible to have some intrinsic motivation to deliver
better and better code each day, to grow with your tasks etc.

I think most people these days are in for the money and not for "the
challenge" which is why we see so much mediocre software. On the other hand
there is excellent software too, so there are people who really know what they
are doing.

------
maxyme
Mozilla's Position: "Mozilla has concerns about the shift in the web security
model required for handling web-packaged information. Specifically, the
ability for an origin to act on behalf of another without a client ever
contacting the authoritative server is worrisome, as is the removal of a
guarantee of confidentiality from the web security model (the host serving the
web package has access to plain text). We recognise that the use cases
satisfied by web packaging are useful, and would be likely to support an
approach that enabled such use cases so long as the foregoing concerns could
be addressed." [https://mozilla.github.io/standards-
positions/](https://mozilla.github.io/standards-positions/)

~~~
dfabulich
Apple's position: "The Security Considerations describe some bad things that
can happen even if the spec is properly implemented. Unsurprisingly, I think
those things are bad. No time to make actual technical contributions at this
time but I will consider it if this spec gets multi-vendor interest."
[https://twitter.com/othermaciej/status/951001352347402240](https://twitter.com/othermaciej/status/951001352347402240)

Microsoft is in favor.

~~~
comex
If by “Apple’s position” you mean “a 15-month-old tweet by one Apple
employee”.

Edit: And the spec has since gotten multi-vendor interest. From Microsoft:

> We're excited about the potential for this feature set to resolve some of
> the performance and privacy problems of alternative approaches, and we have
> been talking to publishers who are interested in utilizing these
> technologies to provide accelerated experiences.

[https://groups.google.com/a/chromium.org/d/msg/blink-
dev/gPH...](https://groups.google.com/a/chromium.org/d/msg/blink-
dev/gPH_BcOBEtc/QwdrwjmlDQAJ)

~~~
dfabulich
He's not a random employee.
[https://en.wikipedia.org/wiki/Maciej_Stachowiak](https://en.wikipedia.org/wiki/Maciej_Stachowiak)
"he is a leader of the development team responsible for the Safari web browser
and WebKit Framework"

For now, his tweet is all the signal we have from Apple.

~~~
sjwright
And considering Apple's strict policies around public communication, it's
pretty safe to describe it as a formal statement of the company's position.

~~~
saagarjha
People jumping to this conclusion is why employees are burdened with prefixing
everything they say with a disclaimer that they do not speak for their
employer :(

~~~
sjwright
I completely agree. My point was only about the reality of communications from
Apple employees, not asserting it as an ideal.

~~~
floatingatoll
Note also the Apple employee's reply upthread.

------
pupppet
Thumbs down to anyone enabling AMP’s success. Google should be measuring page
speed only, it’s none of their business what methods you used to achieve that
speed.

~~~
comex
You can improve your network request speed, but you can’t bring the time taken
down to literally zero, i.e. the speed if your page was already prefetched
while the user was looking at search results. Yet for privacy reasons,
prefetched results had to be served from a cache, yet the Web had no way for
Google to cache a page without literally rehosting it on its own domain –
which in turn required restrictions on JavaScript, to avoid random people’s
code being able to execute in the context of www.google.com. That explains
most of AMP.

On the other hand, AMP Real URL is based on Signed HTTP Exchanges, which allow
one site to send a cached copy of someone else’s site, in a much more
straightforward manner. In theory, Google could now drop the bulk of what’s
now known as “AMP” and cache arbitrary pages that indicate their willingness
to be cached. That they’re instead integrating this with AMP suggests they may
not drop it, which would be unfortunate. On the other hand, since Signed HTTP
Exchanges will remain a Chrome-only feature for the foreseeable future, it’s
arguably a bit early to expect Google to make that kind of commitment.

~~~
AlexandrB
> You can improve your network request speed, but you can’t bring the time
> taken down to literally zero, i.e. the speed if your page was already
> prefetched while the user was looking at search results.

Maybe I'm just old, but I don't understand why this is a worthwhile goal. Even
with its bloat the internet today is much, much faster than it was 15 years
ago and I'm quite happy to wait a few seconds for a page to load. In addition,
doesn't pre-fetching every result just waste bandwidth on mobile?

~~~
comex
Well, for one thing, internet speed depends on the quality of your connection,
which in the case of mobile networks varies wildly.

But personally, I’m a sucker for low latency across all of tech (and gaming as
well). That’s why I use Safari instead of Chrome, Terminal.app instead of
iTerm, C++ instead of Rust sometimes (compile times), and basically anything
else instead of Java (startup time), among other preferences. I even prefer
reading ebooks on normal screens rather than e-ink displays, simply because I
don’t want to wait between pressing “next page” and seeing the page show up.
Not surprisingly, then, I really appreciate website snappiness in general,
including links that load instantly due to prefetching. I can’t say I
appreciate AMP as it exists today, because the quick load comes with a host of
UX issues, but I have hope for the future.

Take that perspective how you will. I think I’m a bit of an outlier in just
how much latency bothers me, but pretty much everyone consciously or
subconsciously appreciates when it goes down. Probably including you: the
current speed might seem “fast enough” now, but if faster loading becomes the
norm and the other issues are dealt with, I bet you’d have a hard time going
back.

------
sudhirj
Despite all the hate against AMP, this will actually improve the state of a
decentralised web. Disconnecting the web packaging feature from the
application that birthed it, the format allows a website to sign its content
and create an immutable package that any server in the world can distribute -
with the signature allowing clients to trust where it came from and show the
origin address instead of the cache.

Isn't this exactly what the distributed web needs? This is a massive boon to
IPFS (a content hash can still show the proper origin name), a big blow to
censorship (a censored website could spread its content to a thousand
different servers, each served over HTTPS, and viewers would still the
original URL whichever cache they access), consensual permanent archiving, and
much more?

~~~
ocdtrekkie
Questions for you:

\- Who decides which HTTPS certs are valid? (Followup: Who decides which of
those your browser considers valid?)

\- Who operates the browsers you'd use to view this content which sees the
original URL, and have any of those companies deplatformed content on behalf
of government requests?

Which is to say, web packaging looks somewhat decentralized at a glance but
arguably still leaves the same handful of companies entirely in charge of
deciding what you view and how you view it. And it's entirely dependent on
your browser's developers being ethical and trustworthy, and choices on what
browser you use has just shrunk significantly in the past month alone.

~~~
magicalist
> _Who decides which HTTPS certs are valid?_

Wait wait wait, are you telling me signed exchanges _maintain the status quo_
on a problem they aren't intended to solve?

------
wtmt
> If your site has AMP Real URL enabled Cloudflare will digitally sign the
> content we provide to that crawler, cryptographically proving it was
> generated by you. That signature is all _a modern browser (currently just
> Chrome on Android)_ needs to show the correct URL in the address bar when a
> visitor arrives to your AMP content from Google’s search results.

Is the dig (emphasized above) about what constitutes “a modern browser” really
necessary? Is a modern browser now whichever one that supports something you
like?

------
judge2020
Based on the discussion from the Cloudflare announcement and here, I don't
think people understand why Amp was created and is being heavily pushed by
Google: global accessibility.

Many countries, including India, are just now getting widespread broadband
rollout. Due to its infancy, many ISPs have data caps and may even be
delivering data over 4G/LTE to homes. With AMP, Google and CF have the
privilege of driving all of this (search-driven) bandwidth to datacenters
within the same country, or at least the same continent, to the visitor. If
all of this content was really served from the origin, latency would be
considerably worse since the data will have to go through the undersea cables
and the performance issues that may occur with bad routing.

You could also say the Data Saver web proxy they run is to encourage these
users to browse the web without worrying as much about their phone data bill.

Google really wants everyone in these countries to be using and depending on
the Internet just as much as Americans use and depend on it, otherwise they
may miss out on advertising $$$ potential from a country that's ~4.5 times
more populated than the United States.

~~~
48309248302
That isn't a main reason. People are going to use the internet either way.
Google is making a power grab by breaking web standards (embrace, extend,
extinguish), and companies like Cloudflare are enabling them.

Mozilla has marked Signed HTTP Exchanges as harmful.

~~~
SquareWheel
I'm sorry but if you believe AMP breaks web standards, then you do not
understand AMP. It is built entirely from the ground up on web standards.

~~~
driverdan
AMP does not work unless you include a Google hosted JS file.

From [https://amp.dev/documentation/guides-and-
tutorials/learn/spe...](https://amp.dev/documentation/guides-and-
tutorials/learn/spec/amphtml?format=websites):

> AMP HTML documents MUST

> ...

> contain a <script async
> src="[https://cdn.ampproject.org/v0.js"></script>](https://cdn.ampproject.org/v0.js"></script>)
> tag inside their head tag.

That is not a web standard.

~~~
rum3
Wow that is disgusting. Why does it need to include remote code to function?
How can they even pretend this is an open standard when it has a backdoor?

------
anfilt
Sigh that last thing we need is more AMP.

~~~
reustle
If I understand correctly, the biggest problem was that google was hosting the
cached amp pages. If this instead sends the user to your own domain, viewing
your content which just happens to be hosted elsewhere, does that solve the
primary complaints? I know google was also exposing content directly on the
search results, but I feel that's a separate issue.

~~~
mmastrac
The problem is that the AMP standard is just generally poorly-thought-out, no
matter who hosts it. Instead of a subset of HTML, it's a weird mishmash of
everything that requires magic incantations to make things work for the
browsers of the time it was invented.

It's like NaCl/PNaCl - a good idea in theory, but created by a team that
didn't do a great job at speccing something that could be long lived and
satisfy other players than Google+Chrome.

~~~
throwawaymath
What's wrong with NaCl?

~~~
dfabulich
I believe the gp was referring to NaCl the Native Client
[https://developer.chrome.com/native-
client](https://developer.chrome.com/native-client)

Not the crypto library [https://nacl.cr.yp.to/](https://nacl.cr.yp.to/)

------
zackbloom
I work on AMP Real URL at Cloudflare and am happy answer any questions (live
from AMPConf in Tokyo)!

If you're looking for a super in-depth technical post which includes all sorts
of wonderful bits about the engineering and cryptography involved don't miss
[https://blog.cloudflare.com/real-urls-for-amp-cached-
content...](https://blog.cloudflare.com/real-urls-for-amp-cached-content-
using-cloudflare-workers/)

AMP Real URL was built by engineers Avery Harnish (started when Avery was an
intern!) and Gabbi Fisher, and is built on top of our Workers [1] tech.

1- [https://www.cloudflare.com/products/cloudflare-
workers/](https://www.cloudflare.com/products/cloudflare-workers/)

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

~~~
dfabulich
> okaying a replay attack

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

~~~
tyingq
I believe AMP required inserting a piece of Google controlled and hosted
JavaScript in your content from the very beginning. So the cat was pretty much
out of the bag on this already.

~~~
paavoova
So if you block this Google JS, you cannot access said AMP page? Does AMP
implicitly mandate users subscribe not only to said content provider but the
third-party AMP host?

~~~
tyingq
Yes, you have to include it.

 _" AMP pages must...Contain a <script async
src="[https://cdn.ampproject.org/v0.js](https://cdn.ampproject.org/v0.js)
"></script> tag inside their <head> tag."_

[https://amp.dev/documentation/guides-and-
tutorials/start/cre...](https://amp.dev/documentation/guides-and-
tutorials/start/create/basic_markup)

Their special tags[1] won't render without it, and I suspect Google won't
include it in their SERPS if it's not valid AMP.

[1] [https://amp.dev/documentation/guides-and-
tutorials/learn/spe...](https://amp.dev/documentation/guides-and-
tutorials/learn/spec/amphtml?format=websites#html-tags)

------
motyar
In related news:

Google signed exchanges, Instant-loading AMP pages from your own domain

[https://webmasters.googleblog.com/2019/04/instant-loading-
am...](https://webmasters.googleblog.com/2019/04/instant-loading-amp-pages-
from-your-own.html)

------
rob-olmos
Found this more lively page, apologies if cross-posting a comment is not
allowed:

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.

------
r1ch
I'm rather worried about how closely Cloudflare is working with Google in
pushing their proprietary stuff. I would have hoped they would be more neutral
and take a similar position as Mozilla.

------
m-p-3
I'll just keep using the Redirect AMP to HTML addon[1]. AMP links annoys me to
no end.

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

------
vortico
Who uses AMP? I've only ever heard of it on Hacker News but never seen it when
using Google or any news websites. What actions does a normal user have to
take to use AMP?

~~~
colejohnson66
Nothing. By default, Google will show you the AMP page when you tap a search
result if it’s available

~~~
vortico
It's not working for me. Do I have to use Chrome on Android? I just tested on
Firefox Linux, Chromium Linux, Safari iOS, and Firefox Android.

~~~
penagwin
Google anything news related, you'll see the symbol next to the URL you click,
and you'll notice it loads rather quickly too.

~~~
vortico
I can't see the lightning bolt icon. Commented here
[https://news.ycombinator.com/item?id=19682479](https://news.ycombinator.com/item?id=19682479)

------
christianmm
> _Importantly your site is still being served from Google’s AMP cache just as
> before; all of this comes without any cost to your SEO or web performance._

Glad to see they've addressed AMP's main leverage point

------
bjoko
I wonder if this will have any impact on AMP for Email as well.

[https://emailinnovations.com/the-email-is-being-amp-
ed/](https://emailinnovations.com/the-email-is-being-amp-ed/)

------
tambourine_man
Will the usability still suck? Can I tap the menu bar to go to the top?

------
cphoover
Glad cloudflare and Google are now ramming through de facto web standards
without consensus from the rest of web and browser developers...

------
verisimilitudes
>The promise of the AMP (Accelerated Mobile Pages) project was that it would
make the web, and, in particular, the mobile web, much more pleasant to surf.

That's, ostensibly, the goal, but anyone with an independent mind can tell
it's just about control.

>It was particularly aimed at publishers (such as news organizations) that
wanted to provide the best, fastest web experience for readers catching up on
news stories and in depth articles while on the move. It later became valuable
for any site which values their mobile performance including e-commerce
stores, job boards, and media sites.

What a harrowing paragraph.

>As well as the AMP HTML framework, AMP also made use of caches that store
copies of AMP content close to end users so that they load as quickly as
possible. Although this cache make loading web pages much, much faster they
introduce a problem: An AMP page served from Google’s cache has a URL starting
with [https://google.com/amp/](https://google.com/amp/). This can be
incredibly confusing for end users.

This wasn't an issue before TLS everywhere was pushed, was it? The same
organization that pushed for encryption, no matter how useless, Google, is now
there to solve the problem of caching encrypted pages, centrally of course.

>But the problems with the AMP cache approach are deeper than just some
confusion on the part of the user. By serving the page from Google’s cache
there’s no way for the reader to check the authenticity of the page; when it’s
served directly from, say, the BBC the user has the assurance of the domain
name, a green lock indicating that the SSL certificate is valid and can even
click on the lock to get details of the certificate.

There's already no foolproof way to do that. Rather than checking that it's
actually BBC and BBC has verified what it's delivering, you instead ask a
third party if this is the BBC and if what it's sending is true.

>That signature is all a modern browser (currently just Chrome on Android)
needs to show the correct URL in the address bar when a visitor arrives to
your AMP content from Google’s search results.

So, just as with ''DNS over HTTPS'' and other nonsense, this is yet another
thing they want to pile on.

>Importantly your site is still being served from Google’s AMP cache just as
before; all of this comes without any cost to your SEO or web performance.

Only fools and cretins care about SEO and ''web performance'' is solved by not
having so much JavaScript and actually bothering to optimize images you send.

>Brand Protection: Web users have been trained that the URL in the address bar
has significance. Having google.com at the top of a page of content hurts the
publisher’s ability to maintain a unique presence on the Internet.

Not violating people already trained is very important.

>Easier Analytics: AMP Real URL greatly simplifies web analytics for its users
by allowing all visitors, AMP or otherwise, to coexist on the same tracking
domain.

Anyone using anything more than HTTP server logs, which are already too
revealing, is likely a fool.

>Increased Screen Space: Historically when AMP was used room would be taken
for a “grey bar” at the top of your site to show the real URL. With AMP Real
URL that’s simply not necessary.

This sentence is only possible due to a dearth of independent implementations,
which communicates a great deal about this nonsense. Also, it's nice to see
Google beginning to kill URLs as it wanted to; lying in the UI is a good first
step.

>Content Signing: By relying on cryptographic techniques, AMP Real URL ensures
that the content delivered to visitors has not been manipulated protecting the
sites and brands it is used on. It’s now not possible for any external party
to add, remove, or modify the content of a site.

Remember when Cloudflare was spewing private information all over the
Internet?

>We are also taking this opportunity to sunset the other AMP products and
experiments we have built over the years like Ampersand and Firebolt. Those
products were innovative but we have learned that publishers value AMP
products which pair well with Google’s search results, not which live outside
it. Users of those older products were informed several weeks ago that they
will be gradually shut down to focus our attention on AMP Real URL.

Don't worry about this being shut down for the next big thing, though.

>Our motivation is the same as for offering CDN or SSL services to millions of
customers free of charge

You mean subverting the Internet through increasing centralization and also
enabling mass-spying by the perversion of the very encryption that's
ostensibly so important?

Does anyone actually think Cloudflare isn't a US government operation? They
have so much hardware and they get so much support from these other companies
that we know are paid off by the government.

------
paavoova
I don't understand why AMP is targeted at the "mobile web". What exactly makes
browsing the web on mobile different than other platforms?

~~~
wmf
The network is much slower and the CPU is much slower, so getting very good
performance requires extreme optimization.

~~~
watermelon0
Extreme optimization that can be achieved without AMP.

Performance of web pages is heavily dependent on the amount of assets and
their size. Hacker News loads extremely quickly without AMP, and the same can
be achieved for other sites. HTML/CSS (with a small amount of JS if really
needed) can achieve the same thing as AMP regarding the web page size and
rendering time.

CDNs are well established and can be used to serve content from a nearby
server, and HTTP/3 will reduce the number of round-trips needed.

~~~
gregable
If you have a round-trip-time of 1 second, it will take you 1 second to load a
text file with 1 byte in it. However, an amp page will have loaded before you
clicked, so it will take only the handful of millis in CPU time to swap frames
and display.

~~~
watermelon0
Like mentioned in another comment, HTML5 supports prefetching.

~~~
gregable
The problem with prefetching the publisher URL from a search results page is
that it leaks the user's query intent to an origin they have not visited,
which violates the user's privacy.

By prefetching a signed exchange from the same origin as the search results
page, privacy is preserved. Once the user clicks on a result, the user intent
can be shared with the third party origin, no problem, and is in the AMP
cache.

~~~
JohnFen
> By prefetching a signed exchange from the same origin as the search results
> page, privacy is preserved

How so? Unless I misunderstand (which is entirely possible), all that this
does is change where privacy is violated from the publisher to the search
engine.

~~~
gregable
If a Google search results page instructs your browser to request some bytes
to preload from a Google server, that request does not reveal anything new to
anyone. Google already knows it instructed your browser to preload, so knowing
that your browser mechanically followed that request tells it nothing new
about you or your behavior that it didn't already have another way to know.

Let's consider the alternative. Imagine you searched for [headache] and a
preload request was made to mayoclinic from your browser for their headache
document. Your browser when making that fetch would send to mayoclinic your
ip, any stored mayoclinic cookies, and the document URL that you prefetched
(not the precise query, but the approximate query is easy to guess). This is
sent to mayoclinic _even if_ you never click on that document at all, which is
not what you would expect privacy-wise.

Once you do click, mayoclinic can very easily log this visit even if the
document bytes were preloaded from elsewhere. They can use javascript
analytics or simply even load an image on their server
([https://amp.dev/documentation/components/amp-
pixel](https://amp.dev/documentation/components/amp-pixel)). And you as a user
are not surprised that clicking on mayoclinic shares your interest in the
document with mayoclinic.

~~~
JohnFen
> Let's consider the alternative

Ah, I understand now, thank you.

I guess the problem that I have is with the preload. Without that, then
neither Google nor the Mayo Clinic would get that data.

So, no preload for me.

