Live data from Hacker News

AMP pages displaying your own domain

webmasters.googleblog.com

41–50 of 340 posts

Re: AMP pages displaying your own domain

#41
post #23

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.

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.

Re: AMP pages displaying your own domain

#42

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

Signed HTTP exchanges may be harmful, but Google is beginning to get enough dominance so they implement it and browsers with a minor market share must follow or are left behind.

Re: AMP pages displaying your own domain

#43
post #42

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

Signed HTTP exchanges may be harmful, but Google is beginning to get enough dominance so they implement it and browsers with a minor market share must follow or are left behind.

What happens if other browsers don't implement it? It seems like they'll just show CloudFlare or Google's domains, instead of the signing domain?

Re: AMP pages displaying your own domain

#44
post #9

Earlier quoted context omitted.

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

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.

Users like pages that load instantly, which AMP is a requirement for (via preloading).

Re: AMP pages displaying your own domain

#45
post #21

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.

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

Re: AMP pages displaying your own domain

#46
post #42

Earlier quoted context omitted.

Signed HTTP exchanges may be harmful, but Google is beginning to get enough dominance so they implement it and browsers with a minor market share must follow or are left behind.

What happens if other browsers don't implement it? It seems like they'll just show CloudFlare or Google's domains, instead of the signing domain?

The behavior for browsers without support is to show the google.com/amp URL as before, along with a small html-based bar with additional information about the original domain and share intents.

Re: AMP pages displaying your own domain

#47
post #13

Earlier quoted context omitted.

As a user, I like it.

The thing I didn't like about it was the URL, so I'm glad to see this change!

The experience on iOS remains profoundly buggy. The URL bar doesn't hide properly, scroll-to-top doesn't work, rotation is busted, text selection is wonky, reader mode is disabled. How I wish I could disable this monstrosity.

Re: AMP pages displaying your own domain

#48

Earlier quoted context omitted.

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.

Users like pages that load instantly, which AMP is a requirement for (via preloading).

AMP pages loaded through Google search with hot cache load slower than some of the websites I've developed when loaded with cold cache.

It's absurdly slow, uses tons of unnecessary JS, and it is a privacy nightmare because now I can't just use server-side GDPR and ePrivacy guideline compliant analytics anymore, but either have to give up analytics entirely, or have to use privacy-obliterating Google Analytics.

And if a user ever loads the page with JS disabled (which all my sites are designed to support), AMP breaks and just shows nothing at all for over 8 seconds.

Re: AMP pages displaying your own domain

#49

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

You may be thinking of this use cases section here: https://wicg.github.io/webpackage/draft-yasskin-webpackage-u...

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