Comment by Illniyar | Hacker News Reader

Comment by Illniyar | Hacker News Reader

Parent Full thread

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 your AMP content support this feature. And anyone who made some of their pages AMP can use that same process to support other Signed Exchanges (such as p2p networks or CDNs) . This is great since it makes distributed caching much easier.

The bad part is that google search uses this signed exchange format not to show the actual URL but rather put it in an iframe inside chrome (and only chrome). The real question is whether we will be able to use this functionality outside search, if I have my own site and show a large iframe with signed exchange page, will I also be able to change the browser url bar? mmph, probably not.

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.

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.

I believe Chrome has already shipped an implementation, I don't know any more details unfortunately. It's still in the standardization process.

I know it's not exactly easy to follow but the only implementation repo I can think of to follow right now is the Chromium repo.

Oh interesting! I'll see what I can find there, thanks!

I also had a look in the blog and the "progressive web apps" might be the right thing to look at. There's probably something subtle that's different but I think I can use these to solve the actual problem I have.

https://developers.google.com/web/updates/2019/03/nic73?hl=h...

edit - damn, I don't think this is right at all. Frustrating as it seems pretty perfect but I have to serve from my own domain for 30s before a user can install it :( I just want a single file way of delivering web content! It seems like all the features are basically there, just with restrictions to focus on different use cases.

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.

Yes

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.

Wouldn't it be better to borrow from HTTP and allow a head request to the original source - with a reply of a current signature?

Isn't this whole exercise really just adapting public key signatures on top of old school caching?

With a http proxy you ask for an url, the proxy fetches or serves on behalf of the owner. This adds some circumvention around the way tls/ssl breaks that type of caching. But it should still be able to do a head-like request for a current signature - with no need to download the content again if it is unchanged?

There is in fact some draft language around this kind of a mechanism to update a signature to extend the lifetime of the document by fetching a remote URL. See https://tools.ietf.org/id/draft-yasskin-http-origin-signed-r... .

Doing this on every page load breaks either user privacy (by making the origin fetch before the user clicks) or the preload performance gain itself (by blocking load while waiting for this round trip).

But if the signature is expired, preload would fail anyway, which would trigger a regular load "on click" - but that click should maybe result in a head request for possibly just getting an updated signature?

The intermediary (Google in this case) can choose not to serve an expired exchange.

Reply on news.ycombinator.com