Add an explainer for subresource signed exchanges #542

horo-t · 2019-12-04T02:05:19Z

I uploaded explainer documents of subresource signed exchanges to my
repository (https://github.com/horo-t/subresource-signed-exchange).
But they should be in this webpackage repository.
So this patch copies them from "horo-t/subresource-signed-exchange"
repository.

Spec issue: #347
TAG review: w3ctag/design-reviews#352

I uploaded explainer documents of subresource signed exchanges to my repository (https://github.com/horo-t/subresource-signed-exchange). But they should be in this webpackage repository. So this patch copies them from "horo-t/subresource-signed-exchange" repository. Spec issue: WICG#347 TAG review: w3ctag/design-reviews#352

jyasskin

I didn't get to the Signed Exchange subresource substitution or fully review the security questionnaire for the rel=alternate explainer.

jyasskin · 2019-12-04T21:54:40Z

explainers/signed-exchange-alternate-link-explainer.md

@@ -0,0 +1,164 @@
+# Signed Exchange alternate link
+## Introduction
+We want to extend the usage of the existing [rel=alternate](https://html.spec.whatwg.org/multipage/links.html#rel-alternate) link header for signed exchange. Using this link header, the content publishers can declare that the resource is available in signed exchange format. This can be used both by the crawlers of aggregator sites  (SNS, News site, search engine..) and by the UAs. The crawlers can cache and serve the signed exchange of the content in their own server. The UAs can provide the users with a way to save the page in signe exchange format. And also signed exchange alternate links can be used to recursively prefetch appropriate subresource signed exchanges while prefetching the main resource signed exchange.


Suggested change

We want to extend the usage of the existing [rel=alternate](https://html.spec.whatwg.org/multipage/links.html#rel-alternate) link header for signed exchange. Using this link header, the content publishers can declare that the resource is available in signed exchange format. This can be used both by the crawlers of aggregator sites (SNS, News site, search engine..) and by the UAs. The crawlers can cache and serve the signed exchange of the content in their own server. The UAs can provide the users with a way to save the page in signe exchange format. And also signed exchange alternate links can be used to recursively prefetch appropriate subresource signed exchanges while prefetching the main resource signed exchange.

We want to allow the publisher of a resource to declare that a signed exchange is available holding the content of either that resource or one of its subresources. We expect aggregator sites (SNS, News site, search engine..) to use this to cache the signed version of a resource in order to serve it to their users. We expect UAs to use this to allow users to save the page in signed exchange format. When the publisher identifies a same-origin signed exchange for a cross-origin subresource, the UA can use that information to recursively prefetch the subresource without exposing its speculative activity across origins.

[`<link rel="alternate" type="application/signed-exchange" href=...>`](https://html.spec.whatwg.org/multipage/links.html#rel-alternate) and the equivalent `Link` header are already defined to declare that the referenced document is a reformulation of the current document as a signed exchange. To offer signed exchanges for subresources, we propose to use the [`anchor` parameter](https://tools.ietf.org/html/rfc8288#section-3.2) to identify the replaced subresource. This may be the first use of the `anchor` parameter in the web platform.

jyasskin · 2019-12-04T23:56:05Z

explainers/signed-exchange-alternate-link-explainer.md

@@ -0,0 +1,164 @@
+# Signed Exchange alternate link
+## Introduction
+We want to extend the usage of the existing [rel=alternate](https://html.spec.whatwg.org/multipage/links.html#rel-alternate) link header for signed exchange. Using this link header, the content publishers can declare that the resource is available in signed exchange format. This can be used both by the crawlers of aggregator sites  (SNS, News site, search engine..) and by the UAs. The crawlers can cache and serve the signed exchange of the content in their own server. The UAs can provide the users with a way to save the page in signe exchange format. And also signed exchange alternate links can be used to recursively prefetch appropriate subresource signed exchanges while prefetching the main resource signed exchange.


Could you wrap lines at 80 columns?

jyasskin · 2019-12-04T23:57:02Z

explainers/signed-exchange-alternate-link-explainer.md

@@ -0,0 +1,164 @@
+# Signed Exchange alternate link
+## Introduction
+We want to extend the usage of the existing [rel=alternate](https://html.spec.whatwg.org/multipage/links.html#rel-alternate) link header for signed exchange. Using this link header, the content publishers can declare that the resource is available in signed exchange format. This can be used both by the crawlers of aggregator sites  (SNS, News site, search engine..) and by the UAs. The crawlers can cache and serve the signed exchange of the content in their own server. The UAs can provide the users with a way to save the page in signe exchange format. And also signed exchange alternate links can be used to recursively prefetch appropriate subresource signed exchanges while prefetching the main resource signed exchange.


Suggested change

We want to extend the usage of the existing [rel=alternate](https://html.spec.whatwg.org/multipage/links.html#rel-alternate) link header for signed exchange. Using this link header, the content publishers can declare that the resource is available in signed exchange format. This can be used both by the crawlers of aggregator sites (SNS, News site, search engine..) and by the UAs. The crawlers can cache and serve the signed exchange of the content in their own server. The UAs can provide the users with a way to save the page in signe exchange format. And also signed exchange alternate links can be used to recursively prefetch appropriate subresource signed exchanges while prefetching the main resource signed exchange.

We want to extend the usage of the existing [rel=alternate](https://html.spec.whatwg.org/multipage/links.html#rel-alternate) link header for signed exchange. Using this link header, the content publishers can declare that the resource is available in signed exchange format. This can be used both by the crawlers of aggregator sites (social networks, News site, search engine..) and by the UAs. The crawlers can cache and serve the signed exchange of the content in their own server. The UAs can provide the users with a way to save the page in signe exchange format. And also signed exchange alternate links can be used to recursively prefetch appropriate subresource signed exchanges while prefetching the main resource signed exchange.

I think SNS means "social networking service", from https://en.wikipedia.org/wiki/SNS, but I had to look it up. We should expand acronyms at least the first time we use them, but I think we can just avoid this one.

jyasskin · 2019-12-04T23:57:43Z

explainers/signed-exchange-alternate-link-explainer.md

@@ -0,0 +1,164 @@
+# Signed Exchange alternate link
+## Introduction
+We want to extend the usage of the existing [rel=alternate](https://html.spec.whatwg.org/multipage/links.html#rel-alternate) link header for signed exchange. Using this link header, the content publishers can declare that the resource is available in signed exchange format. This can be used both by the crawlers of aggregator sites  (SNS, News site, search engine..) and by the UAs. The crawlers can cache and serve the signed exchange of the content in their own server. The UAs can provide the users with a way to save the page in signe exchange format. And also signed exchange alternate links can be used to recursively prefetch appropriate subresource signed exchanges while prefetching the main resource signed exchange.


Suggested change

We want to extend the usage of the existing [rel=alternate](https://html.spec.whatwg.org/multipage/links.html#rel-alternate) link header for signed exchange. Using this link header, the content publishers can declare that the resource is available in signed exchange format. This can be used both by the crawlers of aggregator sites (SNS, News site, search engine..) and by the UAs. The crawlers can cache and serve the signed exchange of the content in their own server. The UAs can provide the users with a way to save the page in signe exchange format. And also signed exchange alternate links can be used to recursively prefetch appropriate subresource signed exchanges while prefetching the main resource signed exchange.

We want to extend the usage of the existing [rel=alternate](https://html.spec.whatwg.org/multipage/links.html#rel-alternate) link header for signed exchange. Using this link header, the content publishers can declare that the resource is available in signed exchange format. This can be used both by the crawlers of aggregator sites (SNS, News site, search engine..) and by the UAs. The crawlers can cache and serve the signed exchange of the content in their own server. The UAs can provide the users with a way to save the page in signed exchange format. And also signed exchange alternate links can be used to recursively prefetch appropriate subresource signed exchanges while prefetching the main resource signed exchange.

jyasskin · 2019-12-04T23:57:54Z

explainers/signed-exchange-alternate-link-explainer.md

+            rel="prefetch">
+      <a href="https://feed.example/article.html.sxg">feed.example</a>
+      ```
+   - While the user of the UA is browsing an article (article.html), and if there is a signed exchange alternate link, the UA can provide the user with a way to save the page in signe exchange format. The saved file can be used to share with other users.


Suggested change

- While the user of the UA is browsing an article (article.html), and if there is a signed exchange alternate link, the UA can provide the user with a way to save the page in signe exchange format. The saved file can be used to share with other users.

- While the user of the UA is browsing an article (article.html), and if there is a signed exchange alternate link, the UA can provide the user with a way to save the page in signed exchange format. The saved file can be used to share with other users.

jyasskin · 2019-12-05T00:27:02Z

explainers/signed-exchange-alternate-link-explainer.md

+              type="application/signed-exchange;v=b3";
+              anchor="https://cdn.publisher.example/lib.js"
+      ```
+   1. And the inner response of the main resource signed exchange (article.html.sxg) has a preload header and an allowed-alt-sxg header:


Suggested change

1. And the inner response of the main resource signed exchange (article.html.sxg) has a preload header and an allowed-alt-sxg header:

To prevent an attacker from loading an incompatible version of the subresource, the resource _inside_ the signed exchange has to identify the exact version of the replacement signed exchange using a `Link: ... rel="allowed-alt-sxg"` with the hash of the signed headers (which themselves include a hash of the content).

To prevent a tracker from conveying a user ID in their choice of which subresources to prefetch, the inner resource has to preload the same subresources that the aggregator prefetches.

jyasskin · 2019-12-05T00:27:41Z

explainers/signed-exchange-alternate-link-explainer.md

+              header-integrity="sha256-XXXXXX"
+      ```
+1. The UA recursively prefetches lib.js.sxg.
+1. If the user clicks a link the article’s signed exchange, both the main resource of the article and the script are loaded from the prefetched signed exchanges.


Suggested change

1. If the user clicks a link the article’s signed exchange, both the main resource of the article and the script are loaded from the prefetched signed exchanges.

If the user navigates to the expected article, both the main resource of the article and the script subresource are loaded from the prefetched signed exchanges.

jyasskin · 2019-12-05T00:30:41Z

explainers/signed-exchange-alternate-link-explainer.md

+If a UA supports WebP, the UA should prefetch **image_webp.sxg** which content is WebP format. Otherwise the UA should prefetch **image_jpeg.sxg** which content is JPEG format.
+
+## Security and Privacy Considerations
+The UA must fetch the alternate signed exchange subresource (lib.js.sxg) even if there is the original subresource (lib.js) in the HTTPCache. Otherwise it leaks the state of publisher’s site to the distributor of the signed exchange.


Also, to prevent tracking (user ID transfer), if the aggregator failed to prefetch a subresource that the main resource preloads, the UA must drop all of the subresource prefetches. If the aggregator prefetches a superset of the preloaded subresources, the UA must drop the ones that weren't preloaded.

jyasskin · 2019-12-05T00:47:35Z

explainers/signed-exchange-alternate-link-explainer.md

+1. If exists, prefetches the matching signed exchange instead of prefetching the original resource URL.
+1. The prefetched signed exchange will be stored to the SignedExchangeCache of the Document. And it will be passed to the next Document and used while processing the preload link header. This behavior is written in [Signed Exchange subresource substitution explainer](./signed-exchange-subresource-subtitution-explainer.md).
+
+## Detailed design discussion


Probably just remove this sub-header.

jyasskin · 2019-12-05T00:53:30Z

explainers/signed-exchange-alternate-link-explainer.md

+1. If the user clicks a link the article’s signed exchange, both the main resource of the article and the script are loaded from the prefetched signed exchanges.
+
+## Proposal
+While processing preload link HTTP headers in prefetched main resource signed exchange’s inner response:


Suggested change

While processing preload link HTTP headers in prefetched main resource signed exchange’s inner response:

While prefetching an HTML resource:

Then write an explicit loop that checks if every preload has a matching and allowed prefetch before deciding to use all of the prefetches.

horo-t

Thank you for the review.

horo-t · 2019-12-05T08:30:30Z

explainers/signed-exchange-alternate-link-explainer.md

@@ -0,0 +1,164 @@
+# Signed Exchange alternate link
+## Introduction
+We want to extend the usage of the existing [rel=alternate](https://html.spec.whatwg.org/multipage/links.html#rel-alternate) link header for signed exchange. Using this link header, the content publishers can declare that the resource is available in signed exchange format. This can be used both by the crawlers of aggregator sites  (SNS, News site, search engine..) and by the UAs. The crawlers can cache and serve the signed exchange of the content in their own server. The UAs can provide the users with a way to save the page in signe exchange format. And also signed exchange alternate links can be used to recursively prefetch appropriate subresource signed exchanges while prefetching the main resource signed exchange.


horo-t · 2019-12-05T08:32:25Z

explainers/signed-exchange-alternate-link-explainer.md

@@ -0,0 +1,164 @@
+# Signed Exchange alternate link
+## Introduction
+We want to extend the usage of the existing [rel=alternate](https://html.spec.whatwg.org/multipage/links.html#rel-alternate) link header for signed exchange. Using this link header, the content publishers can declare that the resource is available in signed exchange format. This can be used both by the crawlers of aggregator sites  (SNS, News site, search engine..) and by the UAs. The crawlers can cache and serve the signed exchange of the content in their own server. The UAs can provide the users with a way to save the page in signe exchange format. And also signed exchange alternate links can be used to recursively prefetch appropriate subresource signed exchanges while prefetching the main resource signed exchange.


horo-t · 2019-12-05T08:35:22Z

explainers/signed-exchange-alternate-link-explainer.md

+We want to extend the usage of the existing [rel=alternate](https://html.spec.whatwg.org/multipage/links.html#rel-alternate) link header for signed exchange. Using this link header, the content publishers can declare that the resource is available in signed exchange format. This can be used both by the crawlers of aggregator sites  (SNS, News site, search engine..) and by the UAs. The crawlers can cache and serve the signed exchange of the content in their own server. The UAs can provide the users with a way to save the page in signe exchange format. And also signed exchange alternate links can be used to recursively prefetch appropriate subresource signed exchanges while prefetching the main resource signed exchange.
+
+## Use Cases
+### Signed Exchange discovery of main resource


Deleted this whole sub-section.

horo-t · 2019-12-05T08:42:17Z

explainers/signed-exchange-alternate-link-explainer.md

+1. The crawler fetches and verifies the subresource signed exchange (lib.js.sxg).
+1. The aggregator site will serve the signed exchanges (article.html.sxg and lib.js.sxg) from their own server.
+
+1. While a user is browsing the aggregator site (https://feed.example), a prefetch link element is inserted because the use is likely to want to read the article.


horo-t · 2019-12-05T08:42:22Z

explainers/signed-exchange-alternate-link-explainer.md

+   - While the user of the UA is browsing an article (article.html), and if there is a signed exchange alternate link, the UA can provide the user with a way to save the page in signe exchange format. The saved file can be used to share with other users.
+
+### Recursive subresource signed exchange prefetch
+1. A crawler of an aggregator site fetches an article (https://publisher.example/article.html).


horo-t · 2019-12-05T08:48:57Z

explainers/signed-exchange-alternate-link-explainer.md

+              header-integrity="sha256-XXXXXX"
+      ```
+1. The UA recursively prefetches lib.js.sxg.
+1. If the user clicks a link the article’s signed exchange, both the main resource of the article and the script are loaded from the prefetched signed exchanges.


horo-t · 2019-12-05T08:56:41Z

explainers/signed-exchange-alternate-link-explainer.md

+1. If exists, prefetches the matching signed exchange instead of prefetching the original resource URL.
+1. The prefetched signed exchange will be stored to the SignedExchangeCache of the Document. And it will be passed to the next Document and used while processing the preload link header. This behavior is written in [Signed Exchange subresource substitution explainer](./signed-exchange-subresource-subtitution-explainer.md).
+
+## Detailed design discussion


horo-t · 2019-12-05T09:22:22Z

explainers/signed-exchange-alternate-link-explainer.md

+If a UA supports WebP, the UA should prefetch **image_webp.sxg** which content is WebP format. Otherwise the UA should prefetch **image_jpeg.sxg** which content is JPEG format.
+
+## Security and Privacy Considerations
+The UA must fetch the alternate signed exchange subresource (lib.js.sxg) even if there is the original subresource (lib.js) in the HTTPCache. Otherwise it leaks the state of publisher’s site to the distributor of the signed exchange.


horo-t · 2019-12-05T09:37:34Z

explainers/signed-exchange-alternate-link-explainer.md

+1. If the user clicks a link the article’s signed exchange, both the main resource of the article and the script are loaded from the prefetched signed exchanges.
+
+## Proposal
+While processing preload link HTTP headers in prefetched main resource signed exchange’s inner response:


horo-t · 2019-12-05T09:37:47Z

explainers/signed-exchange-alternate-link-explainer.md

@@ -0,0 +1,164 @@
+# Signed Exchange alternate link
+## Introduction
+We want to extend the usage of the existing [rel=alternate](https://html.spec.whatwg.org/multipage/links.html#rel-alternate) link header for signed exchange. Using this link header, the content publishers can declare that the resource is available in signed exchange format. This can be used both by the crawlers of aggregator sites  (SNS, News site, search engine..) and by the UAs. The crawlers can cache and serve the signed exchange of the content in their own server. The UAs can provide the users with a way to save the page in signe exchange format. And also signed exchange alternate links can be used to recursively prefetch appropriate subresource signed exchanges while prefetching the main resource signed exchange.


explainers/signed-exchange-alternate-link-explainer.md

explainers/signed-exchange-subresource-subtitution-explainer.md

jyasskin · 2019-12-07T00:20:14Z

explainers/signed-exchange-subresource-subtitution-explainer.md

+script.js.sxg and image.jpg.sxg), the UA must check that there is no error in
+the all signed exchanges (eg: sig matching, URL matching, Merkle Integrity
+error) before processing the content of the signed exchanges. This is intended
+to prevent the distributor from encoding a tracking ID into the set of


And to prevent the distributor from selecting a version of the subresource that isn't compatible with the selected version of the main resource, which might introduce a security hole.

horo-t

Merged to one explainer.
https://github.com/horo-t/webpackage/blob/add-subresource-signed-exchange/explainers/signed-exchange-subresource-subtitution-explainer.md

Please review this.

explainers/signed-exchange-alternate-link-explainer.md

explainers/signed-exchange-subresource-subtitution-explainer.md

jyasskin · 2019-12-09T22:10:54Z

explainers/signed-exchange-subresource-subtitution-explainer.md

+
+## Introduction
+
+We want to allow content publishers to declare that the UA can load the specific


This should start by describing the user-facing problem we want to solve, as described in https://github.com/w3ctag/w3ctag.github.io/blob/master/explainers.md.

Here, that might be the following, but please double-check that it actually captures what you mean, and that it's reasonable readable:

Users want to see the result of their clicks as fast as possible. This goal benefits from letting a site tell the UA to prenavigate to the particular outbound link(s) it thinks the user is most likely to click on. However, naively prenavigating to a cross-origin link leaks that user visited the referring page, which the referrer shouldn't do before the user has clicked. The referrer can safely prenavigate to a referrer-origin signed exchange for the top-level HTML of that link, but the UA still can't prefetch that link's subresources without leaking the same information about the user.

We want the referrer to be able to identify that a particular subresource of a prenavigated link is available as a signed exchange served by their own organization. The Link: <subresource.sxg>; rel="alternate", type="application/signed-exchange"; anchor="subresource" header is already defined to identify such alternate forms, where the anchor parameter states that the alternate form is for a resource other than the one the Link header is attached to.

Arbitrarily replacing a target link's subresources is unsafe for several reasons, so we propose that the target link opt into particular replacements by including a link with rel=allowed-alt-sxg.

We think the ` formulation is also useful for two other purposes:

Identifying to a UA or web crawler that the page they're visiting is available as a signed exchange that the user or crawler could download and then send to other users peer-to-peer. This doesn't need either rel=allowed-alt-sxg or the anchor parameter.

Identifying that some cross-origin subresources are available as same-origin signed exchanges. This needs the anchor parameter, but as long as the instruction to replace subresources is embedded in the document whose subresources are being replaced, it doesn't need rel=allowed-alt-sxg.

I think we don't need "We think ..." in this explainer.
They are out of scope of this explainer.

explainers/signed-exchange-subresource-subtitution-explainer.md

jyasskin · 2019-12-10T00:44:23Z

explainers/signed-exchange-subresource-subtitution-explainer.md

+## [Self-Review Questionnaire: Security and Privacy](https://www.w3.org/TR/security-privacy-questionnaire/)
+1. What information might this feature expose to Web sites or other parties, and
+for what purposes is that exposure necessary?
+   - The existence of the alternative signed exchange in HTTP Cache is exposed.


Is this true? Who is it exposed to and under what circumstances? When is the alternative SXG even in the HTTP cache? Which partition?

Changed to

This feature exposes the 1 bit information "the referrer page has prefetched the signed exchange subresources or not" to the publisher.

jyasskin · 2019-12-10T00:45:44Z

explainers/signed-exchange-subresource-subtitution-explainer.md

+   - The existence of the alternative signed exchange in HTTP Cache is exposed.
+1. Is this specification exposing the minimum amount of information necessary to
+power the feature?
+   - Yes. This proposal has limitations such as "all subresource SXG must be


Say what the limitations accomplish here, not just that some phrases exist in other parts of this document.

Added

Thanks to these limitations, this feature exposes only 1 bit information to the publisher.

jyasskin · 2019-12-10T00:49:18Z

explainers/signed-exchange-subresource-subtitution-explainer.md

+   even if the original subresource exists in HTTPCache".
+1. How does this specification deal with personal information or
+personally-identifiable information or information derived thereof?
+   - Signed Exchange should not include personal information.


Also, any personal information that was incorrectly included in a signed exchange would be the information of the aggregator that fetched the SXG, and not the end user.

The use of <link rel=alternate> to identify the SXG for the current page could inform the UA to omit credentials in fetching that SXG, which would prevent any personal information from being accidentally included.

horo-t

Thank you very much for reviewing.

horo-t · 2019-12-10T07:39:50Z

explainers/signed-exchange-subresource-subtitution-explainer.md

+## Can’t we merge allowed-alt-sxg to preload header?
+If we can declare the header-integrity value in the existing preload link HTTP
+header, we don’t need to introduce a new "allowed-alt-sxg" link HTTP header. But
+it becomes complicated when supporting the


Done.
If we change the syntax of imagesrcset, existing browsers may not understand the new syntax. I think we should avoid it.

explainers/signed-exchange-subresource-subtitution-explainer.md

horo-t · 2019-12-10T07:44:17Z

explainers/signed-exchange-subresource-subtitution-explainer.md

+this only exposes 1 bit information (= yes or no) because UAs can use the cached
+signed exchange only if the required signed exchanges are all available.
+- The UA can use the prefetched signed exchange subresources, only when they
+were prefetched in the referrer page. This is intended to avoid leaking the


Done.
Ah, yes. We may be able to allow same-origin navigations.
But I prefer stricter restrictions for privacy and security.

explainers/signed-exchange-subresource-subtitution-explainer.md

horo-t · 2019-12-10T09:04:40Z

explainers/signed-exchange-subresource-subtitution-explainer.md

+
+# Detailed design discussion
+## Header integrity of signed exchange
+The `header-integrity` parameter of the `allowed-alt-sxg` link is the SHA256


Done.
How about this?

horo-t · 2019-12-10T09:12:00Z

explainers/signed-exchange-subresource-subtitution-explainer.md

+failure.
+
+## Multiple subresource signed exchanges
+If there are multiple matching subresource signed exchanges (example:


Changed to

If there are multiple subresource preloads that are provided by prefetches on
the previous page in signed exchange format

explainers/signed-exchange-subresource-subtitution-explainer.md

horo-t · 2019-12-10T09:18:12Z

explainers/signed-exchange-subresource-subtitution-explainer.md

+(https://cdn.feed.example/cdn.publisher.example/lib.js.sxg) while processing the
+prefetch link element  (`<link rel="prefetch"
+href="https://cdn.feed.example/cdn.publisher.example/lib.js.sxg" as="script">`)
+even if there is the original subresource (http://cdn.publisher.example/lib.js)


Done.

If we don't need to think about privacy, when the HTTP cache has "lib.js", UAs don't need to fetch "lib.js.sxg" when the UA see rel=preload and rel=allowed-alt-sxg and rel=alternate for better performance. But we can't do that for the privacy reason.

jyasskin

This looks much better! Thank you for bearing with the long review.

I'm approving now, but feel free to ask for another round if you have more questions about my comments here.

jyasskin · 2019-12-13T00:17:00Z

explainers/signed-exchange-subresource-subtitution-explainer.md

+
+While a user is browsing an aggregator site (https://feed.example), the
+aggregator guesses that the user is likely to want to read a particular article
+(https://publisher.example/article.html) and so inserts a prefetch link pointing


I don't have a feeling for whether we're going to want prefetch or prenavigate here. I bet the TAG will ask too, so have an answer ready.

Added Note.

explainers/signed-exchange-subresource-subtitution-explainer.md

jyasskin · 2019-12-13T00:23:07Z

explainers/signed-exchange-subresource-subtitution-explainer.md

+
+# Proposal
+
+- While prenavigating an HTML resource in signed exchange format:


"prenavigating" or "prefetching"?

Added a link to the github issue.

explainers/signed-exchange-subresource-subtitution-explainer.md

horo-t

Thank you very much!

horo-t · 2019-12-23T03:10:43Z

explainers/signed-exchange-subresource-subtitution-explainer.md

+
+While a user is browsing an aggregator site (https://feed.example), the
+aggregator guesses that the user is likely to want to read a particular article
+(https://publisher.example/article.html) and so inserts a prefetch link pointing


Added Note.

explainers/signed-exchange-subresource-subtitution-explainer.md

horo-t · 2019-12-23T08:13:36Z

explainers/signed-exchange-subresource-subtitution-explainer.md

+
+# Proposal
+
+- While prenavigating an HTML resource in signed exchange format:


Added a link to the github issue.

explainers/signed-exchange-subresource-subtitution-explainer.md

horo-t requested review from jyasskin and kinu December 4, 2019 02:05

jyasskin requested changes Dec 5, 2019

View reviewed changes

Incorporated jyasskin's comment

3a44a08

horo-t commented Dec 5, 2019

View reviewed changes

jyasskin requested changes Dec 7, 2019

View reviewed changes

horo-t added 2 commits December 9, 2019 17:57

Incorporated jyasskin's comment

32b9a33

merge to one explainer

02ab3eb

horo-t commented Dec 9, 2019

View reviewed changes

jyasskin changed the title ~~Add two explainers of subresource signed exchanges~~ Add an explainer for subresource signed exchanges Dec 9, 2019

jyasskin requested changes Dec 10, 2019

View reviewed changes

Incorporated jyasskin's comment

82bbcba

horo-t commented Dec 10, 2019

View reviewed changes

jyasskin approved these changes Dec 13, 2019

View reviewed changes

Incorporated jyasskin's comment

a67da35

horo-t commented Dec 23, 2019

View reviewed changes

horo-t merged commit f1a5a96 into WICG:master Jan 6, 2020

horo-t deleted the add-subresource-signed-exchange branch January 6, 2020 04:12

-We want to extend the usage of the existing [rel=alternate](https://html.spec.whatwg.org/multipage/links.html#rel-alternate) link header for signed exchange. Using this link header, the content publishers can declare that the resource is available in signed exchange format. This can be used both by the crawlers of aggregator sites  (SNS, News site, search engine..) and by the UAs. The crawlers can cache and serve the signed exchange of the content in their own server. The UAs can provide the users with a way to save the page in signe exchange format. And also signed exchange alternate links can be used to recursively prefetch appropriate subresource signed exchanges while prefetching the main resource signed exchange.
+We want to allow the publisher of a resource to declare that a signed exchange is available holding the content of either that resource or one of its subresources. We expect aggregator sites (SNS, News site, search engine..) to use this to cache the signed version of a resource in order to serve it to their users. We expect UAs to use this to allow users to save the page in signed exchange format. When the publisher identifies a same-origin signed exchange for a cross-origin subresource, the UA can use that information to recursively prefetch the subresource without exposing its speculative activity across origins.
+[`<link rel="alternate" type="application/signed-exchange" href=...>`](https://html.spec.whatwg.org/multipage/links.html#rel-alternate) and the equivalent `Link` header are already defined to declare that the referenced document is a reformulation of the current document as a signed exchange. To offer signed exchanges for subresources, we propose to use the [`anchor` parameter](https://tools.ietf.org/html/rfc8288#section-3.2) to identify the replaced subresource. This may be the first use of the `anchor` parameter in the web platform.

	- While the user of the UA is browsing an article (article.html), and if there is a signed exchange alternate link, the UA can provide the user with a way to save the page in signe exchange format. The saved file can be used to share with other users.
	- While the user of the UA is browsing an article (article.html), and if there is a signed exchange alternate link, the UA can provide the user with a way to save the page in signed exchange format. The saved file can be used to share with other users.

-. And the inner response of the main resource signed exchange (article.html.sxg) has a preload header and an allowed-alt-sxg header:
+To prevent an attacker from loading an incompatible version of the subresource, the resource _inside_ the signed exchange has to identify the exact version of the replacement signed exchange using a `Link: ... rel="allowed-alt-sxg"` with the hash of the signed headers (which themselves include a hash of the content).
+To prevent a tracker from conveying a user ID in their choice of which subresources to prefetch, the inner resource has to preload the same subresources that the aggregator prefetches.

	1. If the user clicks a link the article’s signed exchange, both the main resource of the article and the script are loaded from the prefetched signed exchanges.
	If the user navigates to the expected article, both the main resource of the article and the script subresource are loaded from the prefetched signed exchanges.

	While processing preload link HTTP headers in prefetched main resource signed exchange’s inner response:
	While prefetching an HTML resource:


		## Introduction

		We want to allow content publishers to declare that the UA can load the specific


		# Proposal

		- While prenavigating an HTML resource in signed exchange format:

Add an explainer for subresource signed exchanges #542

Add an explainer for subresource signed exchanges #542

Conversation

horo-t commented Dec 4, 2019

jyasskin left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

horo-t left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

horo-t left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

horo-t left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jyasskin left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

horo-t left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment