Subresource prefetching+loading via Signed HTTP Exchange

[horo-t]

Góðan dag TAG！

I'm requesting a TAG review of:

• Name: Subresource prefetching+loading via Signed HTTP Exchange
• Specification URL: Extend link HTTP header to support subresource signed exchange loading WICG/webpackage#347
• Explainer, Requirements Doc, or Example code: Explainer
• Tests: not yet
• Primary contacts: @horo-t

We'd prefer the TAG provide feedback as (please select one):

• open issues in our Github repo for each point of feedback
• open a single issue in our Github repo for the entire review
• leave review feedback as a comment in this issue and @-notify [@kinu @jyasskin @sleevi]

[annevk]

Do you have a specification URL that's not a long discussion?

Also, given how prefetching itself still isn't defined from first principles, I'm rather concerned about adding yet more complexity on top.

[horo-t]

Sorry we don't have formal specification yet.
The Proposal section in the Explainer may be easier to understand.

[torgo]

Discussed at f2f 22-05-2019.

[torgo]

@horo-t we are picking this up now at our f2f (in Google's Tokyo office btw). It looks like there has been some progress on the WICG web packaging issue that you have referenced above. Can you let us know what the latest status of this is and what type of feedback you would most like to see from the TAG that could help? I see from WICG/webpackage#347 (comment) that there are now 2 explainers? Where would you like the TAG to focus?

[horo-t]

During the spec discussion, we focused on how to prevent user tracking.
As described at Security and Privacy Considerations, this feature only exposes 1 bit information because UAs can use the cached signed exchange only if the required signed exchanges are all available.

I'd like the TAG to check if following sound reasonable:

• The overall use-case / considerations we've made for privacy.
• Iintroducing a new rel=allowed-alt-sxg link header.
  This new "allowed-alt-sxg" link header is only for signed exchange.
• Extending the usage of the existing rel=alternate link header.
  The alternate link headers are already widely used for several use cases.

Let me also share our current status in Chromium.
We have implemented in Chromium, and we are planing to start Origin Trial soon.

[torgo]

@horo-t we are working through this now. Can you provide any feedback from your origin trial?

[torgo]

@lknik can you take a look at their answers to the security & privacy questionnaire?

[torgo]

I've put this in "proposed closing" for now as if we are happy with the proposal and with the answers to the security & privacy questionnaire then we might be ready to close this one off.

[ylafon]

The extension of rel=alternate seems fine to me, if you consider that it is an alternate format, as it requires specific handling, and not just an alternate URL. (rel=duplicate has been used for the latter use case, not sure about its implementation state). Introducing a specific new link header seems also fine (allowed-alt-xsg).

[horo-t]

I received a feedback that the user agent should send a NEL (Network Error Logging) report when there was a the header-integrity mismatch while handling subresource signed exchanges. (https://crbug.com/1025074)

I will update the explainer.

[hadleybeeman]

Since we've had no comments since we proposed closing this issue, and everyone seems happy, we are now closing it. Feel free to open another issue if you'd like to start a new discussion!