Intent to Experiment: Signed HTTP Exchanges

[Kinuko Yasuda]

Contact emails

kin...@chromium.org, kou...@chromium.org, kenji...@chromium.org

Specs

Signed exchanges format:

https://wicg.github.io/webpackage/draft-yasskin-http-origin-signed-responses.html

Signed exchanges format: Implementation checkpoints (Chrome implements this):

https://wicg.github.io/webpackage/draft-yasskin-httpbis-origin-signed-exchanges-impl.html

Loading signed exchanges:

https://wicg.github.io/webpackage/loading.html

Summary

Signed HTTP Exchanges (or SXG) enables loading Web contents signed by the content publishers from anywhere, e.g. from a fast server, as if they came from the original publishers.  Enabling this via Origin-Trials would allow SXGs to be hosted by the registrant sites without requiring users to manually turn on the flag.

Link to “Intent to Implement” blink-dev discussion

https://groups.google.com/a/chromium.org/d/msg/blink-dev/n7cZXSTwBTY/l7rXucIwBAAJ

Goals for experimentation

To measure the real world impact of this feature before shipping. We will track the usage, error rates (especially for the SXG specific errors like certificate errors, validation errors and clock skews), stability and basic performance numbers.

Experimental timeline

We’d like to run this for one milestone to start with, starting with M71

(M71 cuts around Oct 11, will go Stable around beginning of Dec ~ end of Jan 2019)

Any risks when the experiment finishes?

Low.

We plan to have a separate sign-up for receiving the particular Accept header (i.e. Accept: “application/signed-exchange”) in incoming requests, and recommend that the interested sites also sign-up for the configuration.  For the sites that don’t register this one won’t receive the Accept header, and even for the sites that registered Chrome will stop sending the Accept header once the experiment finishes. Therefore the sites can safely rely on the header not to return SXGs (that may not be processed by the UA, which would result in downloading the file).  Also incompatible version of SXGs will still be redirected to its fallback URL (that is supposed to be consistent across format versions) therefore it shouldn’t harm user experiences.

Ongoing technical constraints

None.

Debuggability

The status of SXG loading (including its error status) are shown on DevTools.

Will this feature be supported on all five Blink platforms supported by Origin Trials (Windows, Mac, Linux, Chrome OS, and Android)?

Yes.

Link to entry on the feature dashboard

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

[Philip Jägenstedt]

LGTM to experiment, sounds very cool!

Possibly this is premature, but I wonder what the cross-browser testing strategy for this will be? Are the tests written for the implementation C++ unit tests, or something that could reasonably be shared?

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMWgRNaqPHmhv4nRFvSi6_6bSVKWb0uWuxQ64LfmQSKaX8y%2B%3DQ%40mail.gmail.com.

[Kinuko Yasuda]

On Fri, Sep 28, 2018 at 10:54 PM Philip Jägenstedt <foo...@chromium.org> wrote:

LGTM to experiment, sounds very cool!

Thanks!

 

Possibly this is premature, but I wonder what the cross-browser testing strategy for this will be? Are the tests written for the implementation C++ unit tests, or something that could reasonably be shared?

Very good question! Yes currently we have bunch of unittests written in C++ for Chrome's implementation, but we are thinking about adding a set of .tentative WPT tests shortly. The initial set of tests would rely on a particular test-only UA configuration (i.e. UA would skip certificate errors) but we believe it'd be still useful for testing the basic loading behaviors.

+Kunihiko Sakamoto (irori on github) can talk a bit more about the plan if more questions, and our past and current thinking/proposal can be found on this github issue too.

[Kunihiko Sakamoto]

JFYI, I've started adding tests in wpt/signed-exchange. Currently SXG and certificate files are checked-in as static files, assuming that test runner is configured to ignore signature expiration errors. In the future, we plan to generate exchanges on-the-fly during tests.

Kunihiko Sakamoto

2018年10月1日(月) 12:31 Kinuko Yasuda <kin...@chromium.org>:

On Fri, Sep 28, 2018 at 10:54 PM Philip Jägenstedt <foo...@chromium.org> wrote:

LGTM to experiment, sounds very cool!

Thanks!

 

Possibly this is premature, but I wonder what the cross-browser testing strategy for this will be? Are the tests written for the implementation C++ unit tests, or something that could reasonably be shared?

Very good question! Yes currently we have bunch of unittests written in C++ for Chrome's implementation, but we are thinking about adding a set of .tentative WPT tests shortly. The initial set of tests would rely on a particular test-only UA configuration (i.e. UA would skip certificate errors) but we believe it'd be still useful for testing the basic loading behaviors.

+ (irori on github) can talk a bit more about the plan if more questions, and our past and current thinking/proposal can be found on this github issue too.

[Philip Jägenstedt]

The signed-exchange setup in wpt is very cool, please let
ecosyst...@chromium.org know if you're having trouble with some
infra issue, or anything like that. Testing network stack is fairly
new territory in web-platform-tests, but it makes a lot of sense to do
so I think.

[Thiemo Nagel]

Would signed exchanges make it easier to use the web cache as cross-origin supercookie?

I'm thinking about something along these lines:

Setup: Configure example.com to not accept HTTP connections. Create and sign example.com/[a..z].

Write the cookie: Cast an identifier as a bitmask and download "1" bits out of the range example.com/[a..z] to the client.

Read the cookie: Determine which resources out of example.com/[a..z] exist on the client and interpret that bitmask as an identifier.

Kind regards,

Thiemo

[Jeffrey Yasskin]

Right now, the content of signed exchanges isn't put in the HTTP cache (https://wicg.github.io/webpackage/loading.html#mp-http-network-or-cache-fetch), so it's not an issue. However, I'd like to change that eventually, so let's show how to do your attack without signed exchanges:

Setup: Configure example.com to return "1" for requests with `Accept: Write` and "0" for requests with `Accept: Read`, without setting a `Vary` header.

Write the cookie: Cast an identifier as a bitmask, and `fetch('https://example.com/[a..z]', {headers: {accept: Write}})` for the 1 bits.

Read the cookie: Use `fetch('https://example.com/[a..z]', {headers: {accept: Read}})` to read bits of the identifier.

We could also do this without the Fetch API using a server that returned different responses depending on the difference in Accept headers between images, stylesheets, scripts, etc, again without `Vary: Accept`. 

I believe any cache partitioning that protects against this, will also prevent signed exchanges from exposing trackers across origins.

Jeffrey

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/958e5734-a41a-43d5-bbaa-7cdfcaedd4ec%40chromium.org.

[Thiemo Nagel]

Thanks for the explanation, Jeffrey!

Thiemo Nagel

Software Engineer

Google Germany GmbH, Erika-Mann-Straße 33, 80686 München

Geschäftsführer: Paul Manicle, Halimah DeLaine Prado

Registergericht und -nummer: Hamburg, HRB 86891

Sitz der Gesellschaft: Hamburg