Intent to Implement: Subresource prefetching+loading via Signed HTTP Exchange

[Tsuyoshi Horo]

Contact emails

ho...@chromium.org

Explainer

https://docs.google.com/document/d/1tARwhN_yymddnhyGrYmmM8b9RP0RKPKW_6T9yEI5CAg/edit?usp=sharing

 

Spec issue

https://github.com/WICG/webpackage/issues/347

 

TAG review

https://github.com/w3ctag/design-reviews/issues/352

 

Summary

Support signed exchange subresource prefetching and loading by extending the HTTP link header.

 

Motivation

Signed Exchanges allow a distributor to distribute content signed by a publisher and have the UA show the publisher's URL, give scripts access to the publisher's local storage, etc.  However, the URLs of subresources are fixed in the signed top-level HTML file, which prevents their loads from taking advantage of any signed versions that might be prefetched the distributor's origin. To allow the subresources to be prefetched from the same distributor as the top-level page,the publisher needs to change the subresource URLs in the HTML to point to each distributors’ URL and needs to sign for each distributor.

 

We want to allow publishers to create a single signed top-level HTML file that allows its subresources to be prefetched from a variety of distributors.

 

Interoperability risk

Edge: No signals

Firefox: No signals

Safari: No signals

Web / Framework developers: No signals

Compatibility risk

This is a new feature only for signed exchanges. So the compatibility risk is limited.

 

Debuggability

DevTools will shows the information about signed exchange subresource prefetching and loading in the Network tab.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes

 

Link to entry on the Chrome Platform Status

https://www.chromestatus.com/features/5126805474246656

 

Requesting approval to ship?

No

[Craig Francis]

This looks like a security nightmare... is this just being built to support AMP (Accelerated Mobile Pages), so publishers that are hosting stuff on google.com can have their content look like it comes from their domain, while allowing google.com to access the local storage on the publishers website?

[Tsuyoshi Horo]

On Fri, Mar 15, 2019 at 12:39 AM Craig Francis <craig....@gmail.com> wrote:

This looks like a security nightmare... is this just being built to support AMP (Accelerated Mobile Pages), so publishers that are hosting stuff on google.com can have their content look like it comes from their domain, while allowing google.com to access the local storage on the publishers website?

Thank you for your comments.

No.

This feature doesn't allow the distributors to inject arbitrary contents to the publisher's page.

This feature allows the distributors to serve the subresources which have been signed by the publisher.

 

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/5d7c6e2d-ea7d-4b25-a43d-869ef79d4eb2%40chromium.org.

[Craig Francis]

Hi Horo,

I mis-spoke when saying that google.com could access the local storage, I meant to say that the signed content could access it (in terms of a feature).

And I'm probably more concerned about the first sentence, regarding "Signed Exchanges", rather than the sub-resources.

"Signed Exchanges allow a distributor to distribute content signed by a publisher and have the UA show the publisher's URL, give scripts access to the publisher's local storage, etc"

I'm under the impression that Site Isolation in Chrome has been a pain to implement (especially with iframes), and I suspect this will cause more complexity, as you will presumably be doing the initial load under the distributors origin, then switching over to the publishers once the checks are complete.

The Explainer document also indicates how complicated this process will be, and complicated systems often include mistakes.

Can you honestly say Chrome is going to have a perfect implementation? There is a strong possibility that someone malicious could find and exploit browser implementation mistakes to do things they shouldn't be able to... like getting access to the target websites local storage, or being able to create phishing pages.

I'm also keeping in mind the mistake HPKP was (which allowed someone malicious to hold a website to ransom if they could compromise a websites server)... I have a horrible feeling that will allow perfectly valid exploits to happen as well... e.g. someone malicious, who has been able to gain access to the target website/servers, could create malicious content, host it on a different server, and have it signed by the target website.

Craig

[Jeffrey Yasskin]

On Fri, Mar 15, 2019 at 9:46 AM Craig Francis <craig....@gmail.com> wrote:

Hi Horo,

I mis-spoke when saying that google.com could access the local storage, I meant to say that the signed content could access it (in terms of a feature).

And I'm probably more concerned about the first sentence, regarding "Signed Exchanges", rather than the sub-resources.

Then this is the wrong thread to discuss it.

 

"Signed Exchanges allow a distributor to distribute content signed by a publisher and have the UA show the publisher's URL, give scripts access to the publisher's local storage, etc"

I'm under the impression that Site Isolation in Chrome has been a pain to implement (especially with iframes), and I suspect this will cause more complexity, as you will presumably be doing the initial load under the distributors origin, then switching over to the publishers once the checks are complete.

Please read the Signed Exchanges specifications at https://github.com/WICG/webpackage/ before guessing.

Jeffrey