Live data from Hacker News

AMP pages displaying your own domain

webmasters.googleblog.com

151–160 of 340 posts

Re: AMP pages displaying your own domain

#151

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…

How does the browser verify that the AMP is up to date?

Re: AMP pages displaying your own domain

#152
post #148

Earlier quoted context omitted.

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…

> You can't wait 0.5 seconds for an HTTP request? I don't have links to hand but everything I've seen shows real dropoffs in users as you increase the time. Once you're looking at low numbers of seconds you're looking at significant numbers of users simply abandoning the site. Half a second extra is not insignificant, and the user experience changes a lot between things that feel instant and things that have a notice…

Yes but you don't need AMP to have a fast loading website or even one that applies the same principles as AMP when it comes to having inline CSS, loading scripts async etc. The biggest problem in all of this is usually ads and analytics anyways.

Re: AMP pages displaying your own domain

#153
post #129

Earlier quoted context omitted.

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?

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

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.

Re: AMP pages displaying your own domain

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

Because literally the entire private reason for AMP is a power grab.

Not the public reason, but absolutely the private reason.

If Google, Apple, Amazon, Microsoft, or whatever publicly traded company makes a move its for money and power and preferably power, since that yields even more money.

AMP on web and email is the perfection of embrace, extend and extinguish

Re: AMP pages displaying your own domain

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

Re: AMP pages displaying your own domain

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

As bad as the URLs were, at least you could edit them to get back to the non-AMP version if you were technically literate enough. Now there'll be no distinction, you could get sent to an AMP link from Google which is a lesser experience than the 'real' site and have no way of getting out.

Re: AMP pages displaying your own domain

#157

Earlier quoted context omitted.

> And how is this all that much different? It changes the meaning of the address bar from "this is who I'm talking to" to "this is who (at some point in time) signed this content".

But when there is a CDN there, "who I'm talking to" is really just an intermediary who pretends to be you, and may have in fact modified the content. With this, it is still an intermediary pretending to be you, but at least now the package is signed and can be verified.

The CDN is you, for all intents and purposes. It's your agent in the back and forth, as much as your hosting provider would be. A third-party cache isn't.

I don't mind that you can sign and verify content, that's fine and useful. I'm just not a fan of changing the address bar's meaning.

Re: AMP pages displaying your own domain

#158
post #129

Earlier quoted context omitted.

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?

You could prove the document was signed using the source's private key. That does prove the document was signed by the source if you can prove that only the source had access to the key.

Re: AMP pages displaying your own domain

#159
post #151

Earlier quoted context omitted.

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…

How does the browser verify that the AMP is up to date?

Good question. The publisher signs an expiration timestamp in the Signed HTTP Exchange. The publisher can choose this timestamp and the browser will not respect signatures with expirations in the past. Note also that the specification requires, and browsers enforce, that the expiration cannot be more than 7 days in the future.

Re: AMP pages displaying your own domain

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

Most people agree that URL spoofing is bad. I'm not sure why google should get a pass.
Post reply on HN