Live data from Hacker News

AMP pages displaying your own domain

webmasters.googleblog.com

121–130 of 340 posts

Re: AMP pages displaying your own domain

#121
post #54

Earlier quoted context omitted.

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.

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.

What's the difference between influencing positions and visibility based on AMP support vs overall page performance?

If visibility is influenced by AMP then Google benefits, users using Google services likely benefit, web developers suffer, users not using Google services to view the content continue to suffer (because companies will continue to maintain two versions of the website, a bloated version with 100 external tracking requests that will be shared on twitter/reddit/facebook/hn/etc, and an AMP version that will only appear on Googles services), and the internet as a whole suffer. Whereas if visibility is influenced by page speed+external requests then everyone would benefit.

Re: AMP pages displaying your own domain

#122
post #98

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.

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

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

Re: AMP pages displaying your own domain

#123

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

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/ (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/ then the browser would display 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.

Re: AMP pages displaying your own domain

#124

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.

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.

Re: AMP pages displaying your own domain

#125
post #112

Earlier quoted context omitted.

They can't if you block all their shitty domains and don't use google services. Things that many privacy-conscious users do.

If (or when) the share of that privacy-conscious users will rise, Google might motivate webmasters to compile GA scripts in the main JS script, and considering pretty much any website now a days just doesn't show content with no Javascript enabled, it would be much harder to avoid.

I browse mostly without javascript on and that's not true; easily more than half of websites work just fine without it, and that number goes far up if you accept some lack of features. Though there are some that indeed don't work at all.

Although your point is well taken that there could be ways to sneakily track users eventually despite the aforementioned measures, and potentially even without javascript being required (though I doubt that share of privacy-concious users will ever raise significantly - most people simply don't care).

Re: AMP pages displaying your own domain

#126
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…

Fair enough but there is now zero need to load them from the AMP cache at all - this security model could allow News Carousel to load them from the originating site and still have access to the pre-rendering instant load magic/lies that AMP provides.

It feels a little dodgy to me this standard and a bit embrace extend but I'll see how it plays out and reserve judgement until we see this happening in the wild and how well it works. Personally I'd like to be informed in the browser chrome that it was being served via this mechanism rather than me visiting the original site.

Can you maybe see that people feel the browser is now lying to them about where the content is coming from?

Re: AMP pages displaying your own domain

#127
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 garbage I could have ever imagined.

Just no way. Need convincing? Look at the animated gif half way down:

https://3.bp.blogspot.com/-Xqfy7IhiTzc/XLY7goySWzI/AAAAAAAAD...

Re: AMP pages displaying your own domain

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

If they actually cared that much about making the results "relevant", they wouldn't mix a bunch of irrelevant suggestions into the results page, each marked with "missing: " pointing out exactly how they ignored part of the user's request.

Re: AMP pages displaying your own domain

#129

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

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…

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?

Re: AMP pages displaying your own domain

#130

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.

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.
Post reply on HN