3 ms·

The most interesting thing to me seems that they plan to decoupled signing of content from TLS connections. So that packages could be signed using normal TLS ce

by jopsen 9y ago

The most interesting thing to me seems that they plan to decoupled signing of content from TLS connections. So that packages could be signed using normal TLS certificates (or something like that). Hmm, so maybe in some future static-only sites will be able to sign a bundle with offline keys and not use TLS at all. Or maybe we just sign static bundle with a TLS key for our origin and upload the bundle to Google and other web caches. As in maybe the internet can be distributed again. I see lots of interesting potential in decoupling origin verification from TLS connections. Web Packaging Format Explainer: https://github.com/WICG/webpackage/blob/master/explainer.md https://github.com/WICG/webpackage/blob/master/explainer.md

geofft 9y ago
The thing I'm very curious to see is whether Google will permit uploading custom webpackages and whether it will treat them as equivalent to actual Google-blessed AMP webpackages in terms of results page placement. With some rules on the webpackages being small and not referencing too much external stuff, sure, but if I have an actual lightweight web page, I should be able to generate a pretty small webpackage containing my page and its CSS, with no reference to the AMP JS library or anything, and I should be able to send that to anyone who wants to cache/CDN my website. I'm imagining a world where a static site generator + Let's Encrypt automatically generates these webpackages for you and uploads them to Google, and also DuckDuckGo, Bing, etc. And when someone creates an HN or Reddit post, the HN / Reddit server checks to see if there is a webpackage available for that page and if it's not too many kilobytes, and serves that when you click on the link. That seems like it delivers on the original promise/vision of AMP, and also gets entirely out of the vendor lock-in problem that AMP has today and into something genuinely novel and good for the web.
tlrobinson 9y ago
Web Packaging sounds really interesting. I think there's a need for another layer of security in certain types of web applications (secure messaging, financial, cryptocurrency). It sounds like this is a "nice to have" use-case: https://github.com/WICG/webpackage/blob/master/draft-yasskin-webpackage-use-cases.md#third-party-security-review-security-review https://github.com/WICG/webpackage/blob/master/draft-yasskin... I've almost been able to abuse Service Workers for this purpose. After the Service Worker is installed on first load you can intercept any requests (including the HTML and JavaScript) and verify a signature on them using a key embedded in the Service Worker. The big problem is it seems like you can't reliably prevent the browser from trying to update the Service Worker itself, which is obviously a deal breaker. Also shift-reload bypasses the Service Worker completely.
majewsky 9y ago
> maybe in some future static-only sites will be able to sign a bundle with offline keys and not use TLS at all These two approaches are built for different threat models. Both protect you from tampering, but only TLS protects you from collecting metadata like what exact page you visited. Attackers can only observe which domain you visited.
- jopsen 9y ago
  True, so maybe we would still want TLS.. My thought was that it as a static site owner it would awesome to keep TLS keys offline. And only use them when content is updated. That way a server compromise is not so bad.
- WorldMaker 9y ago
  Glancing at the spec, these packages could have multiple pages or the entire sites' worth of pages for a static site, so it should still protect most of that metadata for packaged static sites. Someone might be able to collect that you downloaded the full package, but not have any idea of which pages within that bundle you visit. The spec also encourages/opens up the possibility of exchanging those bundles over peer-to-peer networks instead of HTTP, which further mitigates the threat of over-the-shoulder metadata collection.

by jopsen 9y ago

geofft 9y ago

The thing I'm very curious to see is whether Google will permit uploading custom webpackages and whether it will treat them as equivalent to actual Google-blessed AMP webpackages in terms of results page placement. With some rules on the webpackages being small and not referencing too much external stuff, sure, but if I have an actual lightweight web page, I should be able to generate a pretty small webpackage containing my page and its CSS, with no reference to the AMP JS library or anything, and I should be able to send that to anyone who wants to cache/CDN my website. I'm imagining a world where a static site generator + Let's Encrypt automatically generates these webpackages for you and uploads them to Google, and also DuckDuckGo, Bing, etc. And when someone creates an HN or Reddit post, the HN / Reddit server checks to see if there is a webpackage available for that page and if it's not too many kilobytes, and serves that when you click on the link. That seems like it delivers on the original promise/vision of AMP, and also gets entirely out of the vendor lock-in problem that AMP has today and into something genuinely novel and good for the web.

tlrobinson 9y ago

Web Packaging sounds really interesting. I think there's a need for another layer of security in certain types of web applications (secure messaging, financial, cryptocurrency). It sounds like this is a "nice to have" use-case: https://github.com/WICG/webpackage/blob/master/draft-yasskin-webpackage-use-cases.md#third-party-security-review-security-review https://github.com/WICG/webpackage/blob/master/draft-yasskin... I've almost been able to abuse Service Workers for this purpose. After the Service Worker is installed on first load you can intercept any requests (including the HTML and JavaScript) and verify a signature on them using a key embedded in the Service Worker. The big problem is it seems like you can't reliably prevent the browser from trying to update the Service Worker itself, which is obviously a deal breaker. Also shift-reload bypasses the Service Worker completely.

majewsky 9y ago

> maybe in some future static-only sites will be able to sign a bundle with offline keys and not use TLS at all These two approaches are built for different threat models. Both protect you from tampering, but only TLS protects you from collecting metadata like what exact page you visited. Attackers can only observe which domain you visited.

jopsen 9y ago
True, so maybe we would still want TLS.. My thought was that it as a static site owner it would awesome to keep TLS keys offline. And only use them when content is updated. That way a server compromise is not so bad.
WorldMaker 9y ago
Glancing at the spec, these packages could have multiple pages or the entire sites' worth of pages for a static site, so it should still protect most of that metadata for packaged static sites. Someone might be able to collect that you downloaded the full package, but not have any idea of which pages within that bundle you visit. The spec also encourages/opens up the possibility of exchanging those bundles over peer-to-peer networks instead of HTTP, which further mitigates the threat of over-the-shoulder metadata collection.