5 ms·

SXG[0] looks promising - allows signing (and subsequently caching externally) whole HTTP exchanges. This may be useful for improving security, especially of CD

by nes350 8y ago

SXG[0] looks promising - allows signing (and subsequently caching externally) whole HTTP exchanges. This may be useful for improving security, especially of CDNs. Binary Transparency seems to be one of the use cases mentioned in the spec[1] - perhaps someday this would be used for an unified scheme for signing application packages/updates, without reinventing the wheel every time. [0]: https://developers.google.com/web/updates/2019/03/nic73#sgx https://developers.google.com/web/updates/2019/03/nic73#sgx [1]: https://wicg.github.io/webpackage/draft-yasskin-http-origin-signed-responses.html#rfc.appendix.A.4 https://wicg.github.io/webpackage/draft-yasskin-http-origin-...

Leace 8y ago
SXG is primarily designed for AMP so that the browser can display the origin in the address bar while the content is being served from Google. Currently only one CA provides paid certificates with a special extension so that the cert can be used to sign SXG files [0]. [0]: https://www.digicert.com/account/ietf/http-signed-exchange.php https://www.digicert.com/account/ietf/http-signed-exchange.p... As for binary transparency it's not enough to stamp the certificate (that's what CT logs do). The artifact would have to be stamped and published in a widely accessible source. Actually Binary Transparency doc published by Mozilla [1] creates a new regular certificate for new published binary thus utilizing CT infrastructure as it is today. [1]: https://wiki.mozilla.org/Security/Binary_Transparency https://wiki.mozilla.org/Security/Binary_Transparency If we're at Mozilla, it's also interesting to see what's their position on SXG [2]. There is only one spec there with that status there. [2]: https://mozilla.github.io/standards-positions/ https://mozilla.github.io/standards-positions/
- Ajedi32 8y ago
  FWIW, Mozilla's current objections to the standard don't really make sense. See: https://github.com/mozilla/standards-positions/issues/29#issuecomment-459547918 https://github.com/mozilla/standards-positions/issues/29#iss... It seems the real issue at the moment is that it just isn't a high priority for them.
  - Leace 8y ago
    Thanks for the link! Subscribed.
- OrgNet 8y ago
  > SXG is primarily designed for AMP so that the browser can display the origin in the address bar while the content is being served from Google. Displays the origin of the content?
  - Leace 8y ago
    Instead of ugly "https://www.google.com/amp/www.example.com/amp.doc.html" https://www.google.com/amp/www.example.com/amp.doc.html" links as it displays them now when clicking AMP result on Google.com it would display "https://example.com/amp.doc.html" https://example.com/amp.doc.html" even though example.com was not contacted at all.
    - OrgNet 8y ago
      Google wants to hide that she is dominating the world of information?
kinlan 8y ago
> unified scheme for signing application packages/updates This is one of our longer term visions for the API, not there just yet.

by nes350 8y ago

Leace 8y ago

SXG is primarily designed for AMP so that the browser can display the origin in the address bar while the content is being served from Google. Currently only one CA provides paid certificates with a special extension so that the cert can be used to sign SXG files [0]. [0]: https://www.digicert.com/account/ietf/http-signed-exchange.php https://www.digicert.com/account/ietf/http-signed-exchange.p... As for binary transparency it's not enough to stamp the certificate (that's what CT logs do). The artifact would have to be stamped and published in a widely accessible source. Actually Binary Transparency doc published by Mozilla [1] creates a new regular certificate for new published binary thus utilizing CT infrastructure as it is today. [1]: https://wiki.mozilla.org/Security/Binary_Transparency https://wiki.mozilla.org/Security/Binary_Transparency If we're at Mozilla, it's also interesting to see what's their position on SXG [2]. There is only one spec there with that status there. [2]: https://mozilla.github.io/standards-positions/ https://mozilla.github.io/standards-positions/

Ajedi32 8y ago
FWIW, Mozilla's current objections to the standard don't really make sense. See: https://github.com/mozilla/standards-positions/issues/29#issuecomment-459547918 https://github.com/mozilla/standards-positions/issues/29#iss... It seems the real issue at the moment is that it just isn't a high priority for them.
- Leace 8y ago
  Thanks for the link! Subscribed.
OrgNet 8y ago
> SXG is primarily designed for AMP so that the browser can display the origin in the address bar while the content is being served from Google. Displays the origin of the content?
- Leace 8y ago
  Instead of ugly "https://www.google.com/amp/www.example.com/amp.doc.html" https://www.google.com/amp/www.example.com/amp.doc.html" links as it displays them now when clicking AMP result on Google.com it would display "https://example.com/amp.doc.html" https://example.com/amp.doc.html" even though example.com was not contacted at all.
  - OrgNet 8y ago
    Google wants to hide that she is dominating the world of information?

kinlan 8y ago

> unified scheme for signing application packages/updates This is one of our longer term visions for the API, not there just yet.