4 ms·

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

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.

gregable 8y ago
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 8y 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 8y ago
    Yes
  - themacguffinman 8y 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 8y 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 8y 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 8y 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 8y ago

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 8y 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 8y ago
  Yes
- themacguffinman 8y 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 8y 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 8y 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 8y 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.