Hacker News Reader

Comment by gregable | Hacker News Reader

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.

View on HN

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