Live data from Hacker News

AMP pages displaying your own domain

webmasters.googleblog.com

161–170 of 340 posts

Re: AMP pages displaying your own domain

#161
post #119

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 cryptog…

I think that most people are worried about Google using a controversial[0], draft web "standard" (Signed HTTP Exchanges), that introduces a major change in how the web works, in mass production, without trying to first resolve the problems raised with the proposal. [0] For instance, Mozilla considers the current specification to be harmful[1]. [1] https://mozilla.github.io/standards-positions/

It also puts a _lot_ of work on the publisher to implement these changes. Again.

(Unless you're using CloudFlare)

Re: AMP pages displaying your own domain

#162
post #139

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.

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.

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.

Re: AMP pages displaying your own domain

#164

Earlier quoted context omitted.

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 protecte…

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…

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.

Re: AMP pages displaying your own domain

#165
post #119

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 cryptog…

I simply don't trust Google to not change the rules later. What will stop Google from down-grading 2nd class URLs (ie, not hosted with google) to page 2 results? It's effectively the same thing as having no AMP at all, yet they cleverly got everyone on board with this tactic. Edit: I just skimmed through this... this looks _WORSE_ than having Google show their domain. This is some of the sneakiest most deceitful garb…

Sneaky because now you don't know what server a web page is coming from?

Because yes that's true, although cryptography it's maybe half true.

Re: AMP pages displaying your own domain

#166
post #84

Earlier quoted context omitted.

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.

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.

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?

Re: AMP pages displaying your own domain

#167
post #130

Earlier quoted context omitted.

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.

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.

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

Re: AMP pages displaying your own domain

#168
post #155

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.

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.

Re: AMP pages displaying your own domain

#169
post #161

Earlier quoted context omitted.

I think that most people are worried about Google using a controversial[0], draft web "standard" (Signed HTTP Exchanges), that introduces a major change in how the web works, in mass production, without trying to first resolve the problems raised with the proposal. [0] For instance, Mozilla considers the current specification to be harmful[1]. [1] https://mozilla.github.io/standards-positions/

It also puts a _lot_ of work on the publisher to implement these changes. Again. (Unless you're using CloudFlare)

Currently, it's difficult to implement however unlike rewriting a page in AMP, signing the page is a purely mechanical operation. All that's required is to improve the tooling, it is theoretically possible to be a one-click change for any website out there. Initially adding gzip support to a web server was difficult and out the reach of many webmasters, now it's basically universal.

Re: AMP pages displaying your own domain

#170
post #75

Earlier quoted context omitted.

That has never been different. Cloudflare & co are reverse proxies, for all intents and purposes from a user agent view, they are where the content is coming from. They are the ones pointed to in DNS, and they have valid SSL certs.

And how is this all that much different? In fact I would say it's more secure. DNS can be spoofed pretty easily. This is a cryptographically signed package. If anything, I'd have more faith in this changing my URL than a proxy via DNS. Just because Google invented it doesn't make it bad.

> In fact I would say it's more secure. DNS can be spoofed pretty easily. This is a cryptographically signed package

How is it more secure? If, as you say, DNS can be spoofed easily - I can easily get a certificate issued with the required extension and make a "cryptographically signed package".

Post reply on HN