3 ms·

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 yoursel

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/ 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/ https://yoursite.com/cached-copy-of-amppackageexample.com/ then the browser would display https://amppackageexample.com/ 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.

tW4r 7y ago
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?
- abraham 7y ago
  Yes
- themacguffinman 7y ago
  Yes. You can see this among other planned use cases for the web packaging spec here https://wicg.github.io/webpackage/draft-yasskin-webpackage-use-cases.html#rfc.section.2.2.2 https://wicg.github.io/webpackage/draft-yasskin-webpackage-u...
  - IanCal 7y ago
    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.
    - themacguffinman 7y ago
      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.
      - IanCal 7y ago
        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=hi 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.
- gregable 7y ago
  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.
rum3 7y ago
How does the browser verify that the AMP is up to date?
- gregable 7y ago
  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.
  - e12e 7y ago
    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?
    - gregable 7y ago
      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-responses-02.html#rfc.section.3.7 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).
      - e12e 7y ago
        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?

tW4r 7y ago

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?

abraham 7y ago
Yes
themacguffinman 7y ago
Yes. You can see this among other planned use cases for the web packaging spec here https://wicg.github.io/webpackage/draft-yasskin-webpackage-use-cases.html#rfc.section.2.2.2 https://wicg.github.io/webpackage/draft-yasskin-webpackage-u...
- IanCal 7y ago
  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.
  - themacguffinman 7y ago
    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.
    - IanCal 7y ago
      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=hi 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.
gregable 7y ago
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.

rum3 7y ago

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

gregable 7y ago
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.
- e12e 7y ago
  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?
  - gregable 7y ago
    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-responses-02.html#rfc.section.3.7 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).
    - e12e 7y ago
      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?