Support signed exchange subresource prefetching and loading by extending the HTTP link header.
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.
Edge: No signals
Firefox: No signals
Safari: No signals
Web / Framework developers: No signals
This is a new feature only for signed exchanges. So the compatibility risk is limited.
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)?
Link to entry on the Chrome Platform Status
Requesting approval to ship?
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?
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.
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.