Intent to Ship: Signed HTTP Exchanges (SXG)

[Kouhei Ueno]

Contact emails

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

Explainer

https://developers.google.com/web/updates/2018/11/signed-exchanges

Spec

Signed Exchanges format:

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

Loading signed exchanges:

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

Tag Review:

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

Summary

Support application/signed-exchange format of origin-signed HTTP Exchanges in Chrome’s loading pipeline, so that signed Web documents can be loaded and navigated as if they came from particular origins regardless of where they are actually served from.

Link to “Intent to *” blink-dev discussion

• Intent to Implement: Origin-Signed HTTP Exchanges (Part of Web Packaging)

• Intent to Experiment: Signed HTTP Exchanges

• Intent to Extend Origin Trial: Signed HTTP Exchanges

Link to Origin Trial feedback summary

Origin Trial feedback summary (as of Jan 10, 2019)

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

Yes

Demo link

http://sxg-test.appspot.com/

Note: Need to enable chrome://flags/#allow-sxg-certs-without-extension

Debuggability

The status of Signed HTTP Exchange loading (including its error status) are shown on DevTools.

Risks

Interoperability - Medium:

Other browser engines have not signed on, but the versioning scheme gives us the confidence that we can make breaking changes if necessary. We are adding shared test suites in Web Platform Tests to welcome other implementers.

Edge: No direct public signals (platform dashboard entry);

Firefox: “Harmful”: https://mozilla.github.io/standards-positions/

• We addressed the concern about a decrease in confidentiality on the IETF mailing list.

• The concern about "contacting the authoritative server" is shared with "secondary certificates", which are continuing through the IETF process. We're actively watching the discussion around that specification for mitigations we can adopt for signed exchanges. See the "Security" section below.

Safari:

• Public skepticism expressed at the onset

Web developers: Multiple publishers, teams, projects and AMP are showing interest.

• Cloudflare support for Signed Exchange for a live demo at Chrome Dev Summit, and actively investing in it for a future milestone.

• AMP partners interested and experimenting, e.g. 1-800 flowers at CDS.

• Yahoo Japan, Microsoft Bing, Baidu Search, Google Search and AMP interested and/or experimenting.

• DigiCert built support for Signed Exchange Certificates.

• Protocol Labs experimenting with Signed Exchange on top of IPFS.

Compatibility - Low:

Signed exchanges include a "fallback URL" in a fixed location, so as we change the spec or completely remove support, browsers will at worst do an extra redirect to the original URL. Sites using old versions will lose any performance advantage, but will still work. The Accept header tells servers which version of the signed exchange format to send.

Security

The draft lists several security concerns, especially that: Signed HTTP Exchanges

1. relax the on-path restriction for attackers with an illegitimate certificate,

2. relax the on-path restriction for attackers with a stolen private key, and

3. allow attackers to continue using buggy code for up to 7 days after it's fixed on the real server.

Individual domains opt into these security risks by acquiring a certificate with the "CanSignHttpExchanges" extension. The intent of this explicit extension is to ensure that additional steps are taken by site operators to protect the key from compromise, to mitigate the relaxation of the on-path requirement. To mitigate the risk of illegitimate certificates, SXG requires certificates comply with Chrome’s Certificate Transparency (CT) policy, regardless of issuance date. Mis-issuance by a CA that issues one of these super-powered certificates allows the attacker to MITM for at least approximately 2 weeks, depending on how closely the compromised origin watches the CT logs, and whether the CA hands the attacker future-dated OCSP signatures.

We addressed the security concerns we have received since the Intent-to-Implement. For example, as stated above signed exchanges now require a certificate with CanSignHttpExchanges extension+SCT+OCSP. We revised the format to avoid re-serializing of the received bytes.

Ergonomics

We expect Signed HTTP Exchanges to be used with prefetch. Signed HTTP Exchanges enable faster page loads while preserving user privacy.

In the future, we expect Signed HTTP Exchanges to be used along other navigation performance/UX primitives we are exploring such as Portals.

Activation

We have a set of Go tools on public github repository for generating and examining Signed HTTP Exchanges.

Is this feature fully tested by web-platform-tests? Link to test suite results from wpt.fyi.

Yes. https://wpt.fyi/results/signed-exchange?label=master

Entry on the feature dashboard

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

--

kouhei

[Andrew Ayer]

A concern with eliminating the on-path requirement for attackers is that
it would allow a vulnerability in a CA's domain validation process,
or a mistake by site operators (such as a site with user-uploaded
content not locking down .well-known, or an email provider not locking
down the domain's administrative email addresses) to be leveraged by
unsophisticated attackers who don't have the ability to conduct more
sophisticated attacks like BGP hijacks.

For example, here are some simple vulnerabilities from the last few
years that made it possible to obtain illegitimate certificates:

https://thehackerblog.com/keeping-positive-obtaining-arbitrary-wildcard-ssl-certificates-from-comodo-via-dangling-markup-injection/index.html
https://www.agwa.name/blog/post/domain_validation_vulnerability_in_symantec_ca
https://raymii.org/s/blog/How_I_got_a_valid_SSL_certificate_for_my_ISPs_main_website.html
https://bugzilla.mozilla.org/show_bug.cgi?id=1311713
https://bugzilla.mozilla.org/show_bug.cgi?id=1484766

Without SXG, a certificate obtained using one of these vulnerabilities
would have been useless to an attacker without the ability to get on-path,
which requires more sophistication than obtaining the illegitimate
certificate.

If SXG had existed, the attacker wouldn't have had this additional
requirement, making it much easier for an unsophisticated attacker to
use one of these vulnerabilities in an actual attack against users.

There are likely to be more vulnerabilities like these ones in the
future, so I think SXG should try to mitigate the risk. For example,
it could require domain owners who want to use SXG to opt-in by
publishing a special CAA record. CAs would be required by policy to
check for this CAA record before issuing a certificate with the
CanSignHttpExchanges extension.

It may also be a good idea to limit the lifetime of certificates used
in SXG, to reduce the amount of time that an illegitimate certificate
can be used, in case an attacker exploits a CA vulnerability to obtain
future-dated good OCSP responses.

Regards,
Andrew

On Wed, 16 Jan 2019 16:32:14 +0900
"'Kouhei Ueno' via blink-dev" <blin...@chromium.org> wrote:

> Contact emails
>
> kou...@chromium.org, kin...@chromium.org, kenji...@chromium.org
>
> Explainer
>
> https://developers.google.com/web/updates/2018/11/signed-exchanges
>
> Spec
>
> Signed Exchanges format:
>
> https://wicg.github.io/webpackage/draft-yasskin-http-origin-signed-responses.html
>
> Loading signed exchanges:
>
> https://wicg.github.io/webpackage/loading.html
>
> Tag Review:
>
> https://github.com/w3ctag/design-reviews/issues/235
>
> Summary
>
> Support application/signed-exchange format of origin-signed HTTP
> Exchanges

> <https://wicg.github.io/webpackage/draft-yasskin-http-origin-signed-responses.html>
> in Chrome___s loading pipeline, so that signed Web documents can be

> loaded and navigated as if they came from particular origins
> regardless of where they are actually served from.
>

> Link to ___Intent to *___ blink-dev discussion
>
> -

>
> Intent to Implement: Origin-Signed HTTP Exchanges (Part of Web
> Packaging)

> <https://groups.google.com/a/chromium.org/forum/?fromgroups#!searchin/blink-dev/Signed$20HTTP$20Exchanges%7Csort:date/blink-dev/n7cZXSTwBTY/Ham62KVeAgAJ>
> -

>
> Intent to Experiment: Signed HTTP Exchanges

> <https://groups.google.com/a/chromium.org/d/msg/blink-dev/MKHe54W996c/1E51GLbvAQAJ>
> -

>
> Intent to Extend Origin Trial: Signed HTTP Exchanges

> <https://groups.google.com/a/chromium.org/d/msg/blink-dev/gJB_mlA6joQ/XUIPLvryBgAJ>

>
>
> Link to Origin Trial feedback summary
>
> Origin Trial feedback summary (as of Jan 10, 2019)

> <https://docs.google.com/document/d/1Zkcu_8Wmav33xKni6hnnyn4HBGfVBcLTdLB3tqG9dcU/edit#>

>
> Is this feature supported on all six Blink platforms (Windows, Mac,
> Linux, Chrome OS, Android, and Android WebView)?
>
> Yes
>
> Demo link
>
> http://sxg-test.appspot.com/
>
> Note: Need to enable chrome://flags/#allow-sxg-certs-without-extension
>
> Debuggability
>
> The status of Signed HTTP Exchange loading (including its error
> status) are shown on DevTools.
>
> Risks
>
> Interoperability - Medium:
>
> Other browser engines have not signed on, but the versioning scheme
> gives us the confidence that we can make breaking changes if
> necessary. We are adding shared test suites in Web Platform Tests to
> welcome other implementers.
>
> Edge: No direct public signals (platform dashboard entry

> <https://developer.microsoft.com/en-us/microsoft-edge/platform/status/originsignedhttpexchanges/
> > );
>
> Firefox: ___Harmful___: https://mozilla.github.io/standards-positions/
>
> -
>
> We addressed
> <https://lists.w3.org/Archives/Public/ietf-http-wg/2018JanMar/0089.html>

> the concern about a decrease in confidentiality on the IETF

> mailing list. -

>
> The concern about "contacting the authoritative server" is shared
> with "secondary
> certificates"

> <https://datatracker.ietf.org/doc/draft-ietf-httpbis-http2-secondary-certs/

> >, which are continuing through the IETF process. We're actively
> >watching the
> discussion around that specification for mitigations we can adopt
> for signed exchanges. See the "Security" section below.
>
> Safari:
>

> -
>
> Public skepticism expressed
> <https://twitter.com/othermaciej/status/950997728275804160> at the

> onset
>
>
> Web developers: Multiple publishers, teams, projects and AMP

> <https://amphtml.wordpress.com/2018/01/09/improving-urls-for-amp-pages/amp/
> > are showing interest.
>
> -

>
> Cloudflare support for Signed Exchange

> <https://blog.cloudflare.com/real-urls-for-amp-cached-content-using-cloudflare-workers/

> > for a live demo at Chrome Dev Summit, and actively investing in it
> > for a
> future milestone.

> -

>
> AMP partners interested and experimenting, e.g. 1-800 flowers at

> CDS. -

>
> Yahoo Japan, Microsoft Bing, Baidu Search, Google Search and AMP
> interested and/or experimenting.

> -

>
> DigiCert built support for Signed Exchange Certificates

> <https://www.digicert.com/account/ietf/http-signed-exchange.php>.
> -

>
> Protocol Labs experimenting with Signed Exchange

> <https://github.com/ipfs/in-web-browsers/issues/121> on top of

> IPFS.
>
>
> Compatibility - Low:
>
> Signed exchanges include a "fallback URL" in a fixed location, so as
> we change the spec or completely remove support, browsers will at
> worst do an extra redirect to the original URL. Sites using old
> versions will lose any performance advantage, but will still work.
> The Accept header tells servers which version of the signed exchange
> format to send.
>
> Security
>
> The draft

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

> lists several security concerns, especially that: Signed HTTP
> Exchanges
>

> 1.

>
> relax the on-path restriction for attackers with an illegitimate
> certificate,

> 2.

>
> relax the on-path restriction for attackers with a stolen private
> key, and

> 3.

>
> allow attackers to continue using buggy code for up to 7 days
> after it's fixed on the real server.
>
> Individual domains opt into these security risks by acquiring a
> certificate with the "CanSignHttpExchanges" extension. The intent of
> this explicit extension is to ensure that additional steps are taken
> by site operators to protect the key from compromise, to mitigate the
> relaxation of the on-path requirement. To mitigate the risk of
> illegitimate certificates, SXG requires certificates comply with

> Chrome___s Certificate Transparency (CT) policy, regardless of issuance

> date. Mis-issuance by a CA that issues one of these super-powered
> certificates allows the attacker to MITM for at least approximately 2
> weeks, depending on how closely the compromised origin watches the CT
> logs, and whether the CA hands the attacker future-dated OCSP
> signatures.
>
> We addressed the security concerns we have received since the
> Intent-to-Implement. For example, as stated above signed exchanges now
> require a certificate with CanSignHttpExchanges extension+SCT+OCSP. We
> revised the format to avoid re-serializing of the received bytes.
>
> Ergonomics
>
> We expect Signed HTTP Exchanges to be used with prefetch

> <https://www.w3.org/TR/resource-hints/>. Signed HTTP Exchanges enable

> faster page loads while preserving user privacy.
>
> In the future, we expect Signed HTTP Exchanges to be used along other
> navigation performance/UX primitives we are exploring such as Portals

> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAEgCuoFCjJhHW9RowBCrzrd8sfBKUNK8bJgf8A0nCnJKjycudw>
> .

>
> Activation
>
> We have a set of Go tools

> <https://github.com/WICG/webpackage/tree/master/go/signedexchange> on

> public github repository for generating and examining Signed HTTP
> Exchanges.
>
> Is this feature fully tested by web-platform-tests

> <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md>?

> Link to test suite results from wpt.fyi

> <https://wpt.fyi/results/?label=experimental>.
>
> Yes. https://wpt.fyi/results/signed-exchange?label=master
>
> Entry on the feature dashboard <http://www.chromestatus.com/>
>
> https://www.chromestatus.com/features/5745285984681984
>
> --
> kouhei
>
> --
> 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
> +unsub...@chromium.org. To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPVAxLW%2BML%2BS0kaBFfPS%2B%3DE6hiHNzipsFYPSxSYtJhoLc3Zewg%40mail.gmail.com.

[Jeffrey Yasskin]

Thanks for the comments!

CAA seems like a plausible additional way to opt into these certificates. I can look into the structure of CAA records and propose something, but if you already have an idea for exactly what to specify, I'm happy just to copy that.

Also +Clint from Digicert who's given some feedback on the CanSignHttpExchanges extension. Clint, do you have any opinions here?

It may also be a good idea to limit the lifetime of certificates used
in SXG, to reduce the amount of time that an illegitimate certificate
can be used, in case an attacker exploits a CA vulnerability to obtain
future-dated good OCSP responses.

Yep. It seems better in the long run to forbid CAs from signing that a certificate will still be un-revoked at a future date, but since we can't have nice things, I'm happy to specify some limit to the lifetime of certificates with the CanSignHttpExchanges extension. What should that limit be?

Devin, do you have some feeling for the shortest certificate lifetime publishers and SXG caches will tolerate?

Regards,
Andrew



To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/20190116134134.ad2dd08024dc9cf6d9a7a24a%40andrewayer.name.

[Devin Mullins]

 

It may also be a good idea to limit the lifetime of certificates used
in SXG, to reduce the amount of time that an illegitimate certificate
can be used, in case an attacker exploits a CA vulnerability to obtain
future-dated good OCSP responses.

Yep. It seems better in the long run to forbid CAs from signing that a certificate will still be un-revoked at a future date, but since we can't have nice things, I'm happy to specify some limit to the lifetime of certificates with the CanSignHttpExchanges extension. What should that limit be?

Devin, do you have some feeling for the shortest certificate lifetime publishers and SXG caches will tolerate?

I don't have any insight into what publishers will tolerate other than to note that Let's Encrypt seems popular enough. Which, I suppose, is to say that it depends on whether there's tooling in place to update them on all the servers.

SXG generators will have to add support for short cert lifetimes, but this seems pretty easy and was on my TODO list for amppackager anyhow.

As far as what caches will tolerate, I don't think there would be a significant distinction between cert expiry and OCSP expiry, offhand. For instance, I think it would be of no impact if certs had 14-day lifetimes with refresh before the 7-day point. But I'll ruminate a bit more.

[Clint Wilson]

Thanks Jeffrey!

 

From: Jeffrey Yasskin <jyas...@chromium.org>

Sent: Wednesday, January 16, 2019 4:32 PM

To: Andrew Ayer <ag...@andrewayer.name>; Clint Wilson <clint....@digicert.com>

Cc: Kouhei Ueno <kou...@google.com>; 'Kouhei Ueno' via blink-dev <blin...@chromium.org>; Devin Mullins <twi...@google.com>

Subject: Re: [blink-dev] Intent to Ship: Signed HTTP Exchanges (SXG)

 

Thanks for the comments!

[CW] - CAA is definitely tractable as an option and I’d support that, though it would require a bit of time to build out that logic. That doesn’t, however, feel like it truly belongs in an IETF document and would fit better into the BRs or similar policies, assuming the underlying expectation that these certificates require public trust remains true. What did you have in mind around where this policy should exist? Similarly, if we’re operating under the assumption that we can expect policy enforcement of checking CAA, can we retain the same benefits in other ways, like requiring specific domain validation methods (such as 3.2.2.4.7-based DNS verification) be utilized by the issuing CA? That type of change could be implemented quicker, from my perspective, but I want to be sure that would adequately address the concerns you raise.

 

It may also be a good idea to limit the lifetime of certificates used

in SXG, to reduce the amount of time that an illegitimate certificate

can be used, in case an attacker exploits a CA vulnerability to obtain

future-dated good OCSP responses.

 

Yep. It seems better in the long run to forbid CAs from signing that a certificate will still be un-revoked at a future date, but since we can't have nice things, I'm happy to specify some limit to the lifetime of certificates with the CanSignHttpExchanges extension. What should that limit be?

 

Devin, do you have some feeling for the shortest certificate lifetime publishers and SXG caches will tolerate?

 

[CW] - I like the idea of short-lived certs here, somewhere in the same range as an OCSP response’s validity. Something around 7-10 days would be a nice target IMO, but even restricting to 30-90 days would be a substantial improvement.

 

Regards,

Andrew

[eri...@microsoft.com]

Please move Edge into the Supportive column; we expect to support these features in the next major release of the Edge browser.

We're excited about the potential for this feature set to resolve some of the performance and privacy problems of alternative approaches, and we have been talking to publishers who are interested in utilizing these technologies to provide accelerated experiences. Longer term, we're hearing significant interest in the evolution of these primitives to encompass the notion of "Archivable content" whereby a user can have confidence that a given package of content was authoritatively served by the origin at some point in the past, even if that origin is no longer serving it. Similarly, other stakeholders are interested in evolving these features for offline or peer-to-peer scenarios (e.g. educational ebooks content). We expect implementation experience with these features as a replacement for alternative approaches (e.g. AMP) will help guide proposals for such evolution. 

We do have some concerns about the complexity of the feature (both for implementers and publishers) but at present do not have any proposals to bring, and we're heartened to see the investments from DigiCert/Cloudflare and others. 

thanks,

-Eric Lawrence

Edge Networking

[Andrew Ayer]

On Thu, 17 Jan 2019 00:33:13 +0000
Clint Wilson <clint....@digicert.com> wrote:

> [CW] - CAA is definitely tractable as an option and I’d support that,
> though it would require a bit of time to build out that logic. That
> doesn’t, however, feel like it truly belongs in an IETF document and
> would fit better into the BRs or similar policies, assuming the
> underlying expectation that these certificates require public trust
> remains true. What did you have in mind around where this policy
> should exist?

The BRs.

> Similarly, if we’re operating under the assumption that
> we can expect policy enforcement of checking CAA, can we retain the
> same benefits in other ways, like requiring specific domain
> validation methods (such as 3.2.2.4.7-based DNS verification) be
> utilized by the issuing CA? That type of change could be implemented
> quicker, from my perspective, but I want to be sure that would
> adequately address the concerns you raise.

Restricting to 3.2.2.4.7-based DNS verification would certainly
reduce the attack surface but I don't think it's sufficient since it's
not an explicit opt-in, and because validations can be reused for
quite a long time, whereas CAA has to be checked no earlier than 8
hours before issuance.

Regards,
Andrew

[Andrew Ayer]

On Wed, 16 Jan 2019 15:31:40 -0800
Jeffrey Yasskin <jyas...@chromium.org> wrote:

> CAA seems like a plausible additional way to opt into these
> certificates. I can look into the structure of CAA records and
> propose something, but if you already have an idea for exactly what
> to specify, I'm happy just to copy that.

I don't have anything specific in mind, but it probably makes the most
sense to define a parameter to the issue and issuewild properties. For
instance:

example.com. IN CAA 0 issue "example.net; cansignhttpexchanges=yes"

For an example of an I-D that defines new CAA parameters, see
https://tools.ietf.org/html/draft-ietf-acme-caa-06

> Yep. It seems better in the long run to forbid CAs from signing that a
> certificate will still be un-revoked at a future date, but since we
> can't have nice things, I'm happy to specify some limit to the
> lifetime of certificates with the CanSignHttpExchanges extension.
> What should that limit be?

7-14 day range would be great.

Regards,
Andrew

[mcac...@mozilla.com]

On Wednesday, January 16, 2019 at 6:32:32 PM UTC+11, Kouhei Ueno wrote:

Spec

Signed Exchanges format:

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

Loading signed exchanges:

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

Mozilla folks are wondering what Google's plan is for standardization of these specs? There is concern because WICG have no official standing - just intended for developing ideas.

Are the specs being adopted into some IETF Working Group (I see the IETF's HTTP's mailing list is being used)? 

Would be great to see some kind of standardization plan before this ships.

[Jeffrey Yasskin]

We've talked in the IETF about either the HTTPWG adopting the signed-exchanges spec, or creating a Web Packaging WG to hold both signed exchanges and bundles. I need to write a draft charter for the second, regardless, and I'll ask the HTTPWG chairs if they've developed any preferences.

The Loading spec will eventually need to merge into Fetch, and I haven't planned for it to live anywhere other than the WICG while it doesn't yet have the 2 implementations needed to change Fetch. It's possible that the Fetch editors will prefer that the non-monkeypatch parts wind up in a separate WHATWG or W3C specification.

Do you or Mozilla have any preferences?

Thanks,

Jeffrey

[Jeffrey Yasskin]

On Thu, Jan 17, 2019 at 11:18 AM Andrew Ayer <ag...@andrewayer.name> wrote:

On Wed, 16 Jan 2019 15:31:40 -0800
Jeffrey Yasskin <jyas...@chromium.org> wrote:

> CAA seems like a plausible additional way to opt into these
> certificates. I can look into the structure of CAA records and
> propose something, but if you already have an idea for exactly what
> to specify, I'm happy just to copy that.

I don't have anything specific in mind, but it probably makes the most
sense to define a parameter to the issue and issuewild properties.  For
instance:

example.com. IN CAA 0 issue "example.net; cansignhttpexchanges=yes"

For an example of an I-D that defines new CAA parameters, see
https://tools.ietf.org/html/draft-ietf-acme-caa-06

Thanks! https://github.com/WICG/webpackage/pull/377 tries to do this.

> Yep. It seems better in the long run to forbid CAs from signing that a
> certificate will still be un-revoked at a future date, but since we
> can't have nice things, I'm happy to specify some limit to the
> lifetime of certificates with the CanSignHttpExchanges extension.
> What should that limit be?

7-14 day range would be great.

With that short a lifetime, maybe we can get rid of the use of OCSP.

Should we also say anything about whether the private key can be re-used across subsequent certificates for the same domain?

Jeffrey

[Jeffrey Yasskin]

Kinuko reminded me that we have a Fetch issue to resolve the monkeypatches, where we can discuss when and how to do that: https://github.com/whatwg/fetch/issues/784.

[mcac...@mozilla.com]

On Friday, January 18, 2019 at 11:19:26 AM UTC+11, Jeffrey Yasskin wrote:

We've talked in the IETF about either the HTTPWG adopting the signed-exchanges spec, or creating a Web Packaging WG to hold both signed exchanges and bundles. I need to write a draft charter for the second, regardless, and I'll ask the HTTPWG chairs if they've developed any preferences.

It's good to hear that those discussions are happening. From a Mozilla perspective, we are still worried about this being a single engine solution (though its encouraging to see Microsoft above expressing interest).  

 

The Loading spec will eventually need to merge into Fetch, and I haven't planned for it to live anywhere other than the WICG while it doesn't yet have the 2 implementations needed to change Fetch.

Right, the same concern applies at the WICG: ideally, incubation involves multiple implementers... as happened with Feature Policy, IntersectionObserver, event listener options. All serve as ideal incubation examples, to name a few. The perception at Mozilla is that this hasn't happened with Signed Exchanges, and that the WICG process has been somewhat circumvented to legitimize a technology that has limited buy-in from other engines.    

That's not to say that folks working on Signed Exchanges have not made a good-faith effort to engage other browser vendors: On the contrary, clearly you all have through the HTTP mailing list, the Mozilla Positions thread, etc. But the perception and concern remains that, despite those efforts, this remains a single vendor solution being pushed onto the Web - and one that Mozilla has serious concerns about being harmful to the Web at large.

Obviously, Mozilla can't tell the Blink project not to ship something. But we remain extremely concerned about the impact of this technology at scale (as in our stated position on the technology).  

 

It's possible that the Fetch editors will prefer that the non-monkeypatch parts wind up in a separate WHATWG or W3C specification.

 That makes sense. I've cc'ed Anne and a few other folks in case they have anything to add. 

[Yoav Weiss]

On Fri, Jan 18, 2019 at 4:57 AM <mcac...@mozilla.com> wrote:

On Friday, January 18, 2019 at 11:19:26 AM UTC+11, Jeffrey Yasskin wrote:

We've talked in the IETF about either the HTTPWG adopting the signed-exchanges spec, or creating a Web Packaging WG to hold both signed exchanges and bundles. I need to write a draft charter for the second, regardless, and I'll ask the HTTPWG chairs if they've developed any preferences.

It's good to hear that those discussions are happening. From a Mozilla perspective, we are still worried about this being a single engine solution (though its encouraging to see Microsoft above expressing interest).  

 

The Loading spec will eventually need to merge into Fetch, and I haven't planned for it to live anywhere other than the WICG while it doesn't yet have the 2 implementations needed to change Fetch.

Right, the same concern applies at the WICG: ideally, incubation involves multiple implementers... as happened with Feature Policy, IntersectionObserver, event listener options. All serve as ideal incubation examples, to name a few. The perception at Mozilla is that this hasn't happened with Signed Exchanges, and that the WICG process has been somewhat circumvented to legitimize a technology that has limited buy-in from other engines.    

Can you expand on how the WICG process have been circumvented here?

 

That's not to say that folks working on Signed Exchanges have not made a good-faith effort to engage other browser vendors: On the contrary, clearly you all have through the HTTP mailing list, the Mozilla Positions thread, etc. But the perception and concern remains that, despite those efforts, this remains a single vendor solution being pushed onto the Web - and one that Mozilla has serious concerns about being harmful to the Web at large.

Obviously, Mozilla can't tell the Blink project not to ship something. But we remain extremely concerned about the impact of this technology at scale (as in our stated position on the technology).  

 

It's possible that the Fetch editors will prefer that the non-monkeypatch parts wind up in a separate WHATWG or W3C specification.

 That makes sense. I've cc'ed Anne and a few other folks in case they have anything to add. 

--

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/8dff0159-9dc5-42e6-9b5b-6820232757b0%40chromium.org.

[mcac...@mozilla.com]

On Friday, January 18, 2019 at 4:27:47 PM UTC+11, Yoav Weiss wrote:

Can you expand on how the WICG process have been circumvented here?

The perception is that despite folks from WebKit and Mozilla expressing concerns, incubation of the spec continued by a single vendor to the point where it's now about to ship (with little buy-in from others during the incubation process itself).

This is different from how we would ideally like to see incubations happen: where a lot folks from different browser engines collaborate, or experiment, or implement together.  

[Yoav Weiss]

On Fri, Jan 18, 2019 at 6:43 AM <mcac...@mozilla.com> wrote:

On Friday, January 18, 2019 at 4:27:47 PM UTC+11, Yoav Weiss wrote:

Can you expand on how the WICG process have been circumvented here?

The perception is that despite folks from WebKit and Mozilla expressing concerns, incubation of the spec continued by a single vendor to the point where it's now about to ship (with little buy-in from others during the incubation process itself).

Currently the process doesn't include any requirement for multi-engine support, and even if it did, up until recently, this proposal would have passed the bar.

This is different from how we would ideally like to see incubations happen: where a lot folks from different browser engines collaborate, or experiment, or implement together.   

--
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/273d997f-fa20-4b76-a8cf-0af743f92314%40chromium.org.

[Kinuko Yasuda]

Hi,

On Fri, Jan 18, 2019 at 3:18 PM Yoav Weiss <yo...@yoav.ws> wrote:

On Fri, Jan 18, 2019 at 6:43 AM <mcac...@mozilla.com> wrote:

On Friday, January 18, 2019 at 4:27:47 PM UTC+11, Yoav Weiss wrote:

Can you expand on how the WICG process have been circumvented here?

The perception is that despite folks from WebKit and Mozilla expressing concerns, incubation of the spec continued by a single vendor to the point where it's now about to ship (with little buy-in from others during the incubation process itself).

I'd like to clarify one point that this intent to ship is definitely not meant to be a last call.  We actually expect that we will have further feedback as the spec and other implementations mature, and therefore we’ve designed the versioning with the expectation that we can make breaking changes even after we ship.

After sending the intent to implement about a year ago we’ve been working hard to address the concerns that have been expressed, as well as trying to engage with the community and other browser vendors. That's said we're aware that this intent might be still sent before other implementors had enough time to evaluate this in detail, and therefore we are committed to keep doing that (and again, can make breaking changes whenever necessary).

If your side will have more feedback on the feature we’d definitely love to hear and address them together.

 

Currently the process doesn't include any requirement for multi-engine support, and even if it did, up until recently, this proposal would have passed the bar.

This is different from how we would ideally like to see incubations happen: where a lot folks from different browser engines collaborate, or experiment, or implement together.   

--
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/273d997f-fa20-4b76-a8cf-0af743f92314%40chromium.org.

--
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/CACj%3DBEjvuehzJ11%2BGg_KDH1mihMpMu%2B629W0N1w2QJiUK8XQ-Q%40mail.gmail.com.

[Andrew Ayer]

On Thu, 17 Jan 2019 16:49:46 -0800

Jeffrey Yasskin <jyas...@chromium.org> wrote:

> On Thu, Jan 17, 2019 at 11:18 AM Andrew Ayer <ag...@andrewayer.name>
> wrote:
>
> > On Wed, 16 Jan 2019 15:31:40 -0800
> > Jeffrey Yasskin <jyas...@chromium.org> wrote:
> >
> > > CAA seems like a plausible additional way to opt into these
> > > certificates. I can look into the structure of CAA records and
> > > propose something, but if you already have an idea for exactly
> > > what to specify, I'm happy just to copy that.
> >
> > I don't have anything specific in mind, but it probably makes the
> > most sense to define a parameter to the issue and issuewild
> > properties. For instance:
> >
> > example.com. IN CAA 0 issue "example.net; cansignhttpexchanges=yes"
> >
> > For an example of an I-D that defines new CAA parameters, see
> > https://tools.ietf.org/html/draft-ietf-acme-caa-06
>
>
> Thanks! https://github.com/WICG/webpackage/pull/377 tries to do this.

Awesome! I left some feedback on the pull request.

> > Yep. It seems better in the long run to forbid CAs from signing
> > that a
> > > certificate will still be un-revoked at a future date, but since
> > > we can't have nice things, I'm happy to specify some limit to the
> > > lifetime of certificates with the CanSignHttpExchanges extension.
> > > What should that limit be?
> >
> > 7-14 day range would be great.
> >
>
> With that short a lifetime, maybe we can get rid of the use of OCSP.

I think that would be great. OCSP doesn't add any value when the cert
lifetime is so short. Getting rid of it would be a nice simplification
for the implementers of SXG generators, and one less service dependency
for publishers.

> Should we also say anything about whether the private key can be
> re-used across subsequent certificates for the same domain?

No opinion. I don't think it's necessary to address the original concerns
about exasperating domain validation vulnerabilities.

Regards,
Andrew

[Rick Byers]

I'm going to recuse myself from this intent since I've been somewhat close to this. But I just wanted to say that I think the time has come to ship this (ideally for the M73 branch on Thursday if possible). I'm confident that the versioning and fallback model will permit us to make breaking changes as necessary if / when additional implementations begin, and that the risks of this feature are justified by the immense benefit it will prove to have for the open web (and if it turns out we're wrong, we will be able to safely remove it leaving only a tiny bit of code to find and redirect to the fallback URL in a package).

Rick

--
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/20190122121316.6e4c9d423cb5d75e6b4f58af%40andrewayer.name.

[Kouhei Ueno]

Thank you for your feedback.

Let me try to summarize the current state of the discussions:

• Mitigating the BGP hijack risk via requiring CAA record to issue certificates.

• We believe this is a great idea and will address this via the spec PR #377.

• Require shorter lifetime for SXG certs.

• We are convinced that SXG certs should have a shorter maximum lifetime than the 2-year maximum for TLS certificates. We plan to specify a maximum lifetime of 90d to bound the latency for making any other changes, and then continue discussing what the maximum should actually be.

• We don’t think we need to enforce this maximum lifetime in Chrome 73, although we might in Chrome 74, and let’s seek consensus on exactly how many days the lifetime requirement should say (github).

• Specification plan post-WICG

• IETF: jyasskin: We'll be presenting progress to the IETF HTTPWG at the end of March. Then we plan to hold a BOF for a new WPACK WG at IETF105 in July, which will own the IETF parts of both signed exchanges and bundles.

• Loading spec: We have filed an issue in the fetch spec github repo to merge the Loading spec's monkeypatches, and we'll do this as soon as the Fetch editor feels there's enough cross-implementation buy-in.

--

kouhei

--

kouhei

[Kinuko Yasuda]

To gather more data points let me invite Devin again and Greg (from AMP team) to see if they have any extra feedback from the consumer pov, e.g. if you felt the design is right, or were comfortable with the trade-offs it makes around security, impact on the ability to repudiate content and etc.  Devin, Greg-- do you mind sharing a little more from the OT experience?  (I remember that you filed some bugs against spec and impl)

Also as another voice from customers let me reshare this blog post from Cloudflare, which details their experience of how they supported (and will support) the feature on their infra for the live demo experiment (and for future milestones).

(And also: any further feedback from anyone who examined or actually tried out this feature is really welcome, please feel free to chime in!)

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPVAxLWq_98rE0WvKDf6RPhWBWGKWft4k62shPMX-yPdkLyuoQ%40mail.gmail.com.

[twi...@google.com]

Hi Kinuko, I'm happy to provide some feedback.

First off, AMP project is excited to have a solution to a major pain point for users and publishers alike -- proper URL attribution and proper origins for things like cookies, local storage, and CORS -- while maintaining two major pillars of AMP’s ability to provide good UX -- privacy-preserving prefetch and and AMPHTML validation.

In terms of the tradeoffs, I think it’s feasible for content publishers and distributors to generate signed exchanges, and feasible for intermediaries to cache them and serve them to supporting browsers. On the other hand, in regards to cross-cutting concerns such as security and privacy, Jeffrey and Kouhei have been very thorough in soliciting feedback from domain experts, and understanding and incorporating that feedback into the spec. As I’m not a security or privacy expert, I’d rather not opine as to whether the risks around things like the removal of the on-path requirement have been sufficiently mitigated, but it seems like the right folks have been involved.

In the run up to origin trial, during implementation, we found that the bugs we were filing against the spec and the Chrome implementation were diminishing in both number and severity, to the point where I feel it’s stable. For instance, the last few bugs we filed before OT had mostly to do with improving the debugging experience (e.g. http://crbug.com/890199, http://crbug.com/899364). We have one major feature request to help us monitor the effectiveness of our intermediary (https://github.com/w3c/network-error-logging/issues/99), but is dependent on this feature, not blocking it.

During the origin trial, we launched AMP signed exchanges (SXGs) as a developer preview, meaning that it was only enabled for Google Search users who opted into the experiment. Unfortunately, we didn’t see a lot of SXGs being created as a result of this preview, so we weren’t able to test at scale. I believe the onus is on the AMP project to fix this, by making it much easier for web developers to create SXGs and by making it useful for them to do so (enabling it for all Google Search users on SXG-supporting browsers). We are actively working on both of these, and are happy that Cloudflare is helping with the former as well.

On a personal note, I'm excited about many other use-cases that signed exchanges can add more trust to, such as P2P sharing, caching proxies for unreliable WANs (e.g. on a train), cross-origin subresources, privacy-preserving cross-origin SPA (in combination with Portals), and archival. Obviously more design and engineering will be needed for each of them, but this seems like a necessary first step.

Thanks,

Devin

[Kinuko Yasuda]

Thanks a lot Devin for sharing the feedback!

Kouhei and probably API owners too will be updating this thread again, but we also got some feedback from API owners, and one of them was requesting for sharing more feedback from the outcomes of the origin trials-- I believe this detailed feedback is really helpful in the context as a real voice from the customer's pov.

On Sat, Jan 26, 2019 at 10:47 AM twifkak via blink-dev <blin...@chromium.org> wrote:

Hi Kinuko, I'm happy to provide some feedback.

First off, AMP project is excited to have a solution to a major pain point for users and publishers alike -- proper URL attribution and proper origins for things like cookies, local storage, and CORS -- while maintaining two major pillars of AMP’s ability to provide good UX -- privacy-preserving prefetch and and AMPHTML validation.

In terms of the tradeoffs, I think it’s feasible for content publishers and distributors to generate signed exchanges, and feasible for intermediaries to cache them and serve them to supporting browsers. On the other hand, in regards to cross-cutting concerns such as security and privacy, Jeffrey and Kouhei have been very thorough in soliciting feedback from domain experts, and understanding and incorporating that feedback into the spec. As I’m not a security or privacy expert, I’d rather not opine as to whether the risks around things like the removal of the on-path requirement have been sufficiently mitigated, but it seems like the right folks have been involved.

Thanks. And yeah there is surely some tension and tradeoff, and we care a lot about how the users/developers would feel, while we also want to address any security and privacy issues as they have been so far the biggest concerns.  As you hinted there has been lots of discussions arduously trying to address the concerns, they can be also found on github as well as on many past IETF discussion threads.

In the run up to origin trial, during implementation, we found that the bugs we were filing against the spec and the Chrome implementation were diminishing in both number and severity, to the point where I feel it’s stable. For instance, the last few bugs we filed before OT had mostly to do with improving the debugging experience (e.g. http://crbug.com/890199, http://crbug.com/899364). We have one major feature request to help us monitor the effectiveness of our intermediary (https://github.com/w3c/network-error-logging/issues/99), but is dependent on this feature, not blocking it.

Yes, and thanks for filing and raising these issues. And just to share the status with this thread, the Network Error Logging one is currently being actively worked on by Horo (wip PR here).

 

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/1e691139-0e09-40ee-a4a0-817de9999fa9%40chromium.org.

[Kinuko Yasuda]

On Tue, Jan 29, 2019 at 8:42 PM Kinuko Yasuda <kin...@chromium.org> wrote:

Thanks a lot Devin for sharing the feedback!

Kouhei and probably API owners too will be updating this thread again, but we also got some feedback from API owners, and one of them was requesting for sharing more feedback from the outcomes of the origin trials-- I believe this detailed feedback is really helpful in the context as a real voice from the customer's pov.

Oh, and I just got a quick feedback from Jim Pick from Protocol Lab, who's been experimenting with this feature on IPFS, saying that he's very excited about the feature and potential use cases with IPFS, so let me share. (A little more info about this experiment can be found here)

[Chris Harrelson]

The API owners discussed this Intent for 30 minutes last week, and 30 minutes again this week. Also, several of us (not me though) were involved in this feature, and so are likely recusing themselves from a vote. We all recognized that this Intent introduces a significant change to the way that web content is delivered. I believe we took this recognition seriously and had a useful and open debate about any possible negatives we could think of.

With any such change, there are always risks and unknowns. Examples of such risks/unknowns include whether the new technology has good design, negative security or privacy implications, impacts on the ecosystem of the web, compat risks with browsers that don't yet support the new feature, and legitimate differences of opinion about the value proposition.

The role of the API owners is, however, not to avoid risk, but to make sure that we all have done what we can to think through and handle all of the risks to the best of our ability, in the interests of moving the web forward.

From reading the documentation of this feature, the many data points expressed in this thread, and other discussions, I have not been able to find any issue raised that has not been adequately responded to or mitigated. On the contrary, I think those who worked on this feature have done a very good job in these respects. In addition, I found the customer feedback from the Origin Trial useful and compelling regarding the value proposition and quality of design & implementation. Thank you for a job well done!

LGTM1

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/CAMWgRNZ59rZCiUh7DMUd09QCt8PdUZtBVwNTbj3%3D5WkZD6pNJQ%40mail.gmail.com.

[Alex Russell]

Thanks, Chris.

As one of the OWNERs who has recused (I helped design the progenitor packaging spec at the W3C TAG and have been an advocate for the feature within the Chrome team), I'd like to offer whatever help I can in answering questions.

Obviously, I can't +1, but consider this my amicus support. The team has done an extraordinary job and has crossed every i and dotted every t that have been brought up.

Regards

[oj...@google.com]

LGTM2

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/15eb73b8-3ca0-4e2e-b734-f2bb11a493b7%40chromium.org.

[Mike West]

TL;DR: LGTM3.

I've been impressed with the effort Jeffrey, et al. have put into outreach on the underlying specification over the last ~18 months, and the attention they've paid to critique and concern along the way. I expect them to continue doing so going forward.

The security and privacy properties of signed exchanges are robust, and I expect them to improve over time as we gain experience with this new primitive. I buy the story around privacy-preserving prefetch, I buy the story around offline access, I buy the comparison from a privacy perspective to the status quo, and I look forward to cleaning up the URLs presented to users when loading distributed content (whether via AMP, Bing, IPFS, or future protocols).

I'm happy to see that folks at Microsoft are excited about the feature's potential. At the same time, I think it's important to recognize that Mozilla is not yet on board, and Apple is only beginning to engage publicly. There's a real risk that signed exchanges remain a Chrome-only feature for some period of time. I think that the team has mitigated those risks to a reasonable extent by designing a versioning/fallback mechanism that will enable us to ship breaking changes as we get feedback from developers and other vendors, and by limiting the lifetime of signed exchanges such that bugs we discover only after shipping are limited in scope, and can be quickly ameliorated.

With those mitigations in mind, we should ship some running code, and continue working towards rough consensus with other vendors as we learn together from that implementation experience.

-mike

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CANMdWTsCGDzyWedVF8y4xOM-2amNm7iBDPXaJ3%3DTZTe2tjr0AQ%40mail.gmail.com.

[Anne van Kesteren]

On Fri, Feb 1, 2019 at 11:28 PM Mike West <mk...@chromium.org> wrote:
> With those mitigations in mind, we should ship some running code, and continue working towards rough consensus with other vendors as we learn together from that implementation experience.

To be clear, there's only running code. There's no rough consensus or
an accepted web standard. If what you want is implementation
experience, why not make this an experiment for a while?

[Daniel Bratell]

As Chris wrote, a lot of discussion went into the shipping decision so I
want to document what made it a non-trivial decision from my point of view:

This is changing the delivery model of the web. We can't predict 100% how
it will evolve, but moving away from point-to-point distribution (which
has been further enforced by https, but also weakened by CDN systems) to a
model with distribution centers has the potential to change the power
balance of the Internet. Is that a reason not to ship it? No. At least not
in itself, but it makes it more important to get right.

Security: The team seems to have done an awesome job collecting feedback
and adapting the feature to alleviate any potential known security
problems, but the change in delivery path opens up some new attack
vectors. None that can't be protected against, but as developers lack
experience with this, there is a certain risk they make mistakes.

Cross platform: We want a distributed internet/web with multiple
compatible implementations. As of today, no browser engine beyond Chromium
has committed to implementing this and Mozilla has even labeled the whole
idea as "harmful". I believe that the team has addressed the technical
arguments from other browser vendors and I hope Mozilla would change their
mind if they took a new look, but it remains a fact that this feature will
not initially be cross browser.

For a user, best case, there is no visible difference between a resource
delivered from the original site and a resource delivered from a
SXG-proxy, but worst case a site might decide to only provide SXG
resources. That would be incredibly bad. If Chromium can do something to
make such a decision a non-option, that would be good.

Some support for a feature from other browser vendors is a key factor when
we decide whether to ship a feature, but at some time we have to determine
that the Chromium development team has done everything reasonable to get
others onboard despite nobody else supporting it and that is the case
here. Then the question becomes if this is valuable enough to ship anyway.

User feedback: Will this be used? Is this solving a problem? We did
request feedback from the experiment, and we got some. All in all it seems
to solve an important problem for CDNs and similar parties, a problem that
has really weak work-arounds today. Does it solve a problem for end-users
or web developers? Well, it's supposed to be invisible for end-users, and
the problem it solves for web developers mostly has to do with
distribution. It might unlock better page load performance due to a better
CDN experience and that is something users and web developers usually like.

Given all of the above, I think shipping is the way to go (lgtm4), but
also that the effort to get other vendors onboard needs to continue.

Anne asked about running an experiment instead of shipping. An experiment
has been running for a couple of months and it seems to have produced
positive results but given the investment required to use this feature, I
think the feature has to be backed by a longer term commitment (shipping)
before we can get more feedback.

/Daniel

On Mon, 04 Feb 2019 10:48:39 +0100, Anne van Kesteren <ann...@annevk.nl>
wrote:

--
/* Opera Software, Linköping, Sweden: CET (UTC+1) */

[Rick Byers]

This is a good point. Perhaps we could consider, for example, having a 1% hold-out where some users don't get SXG support. This is problematic mainly because it causes confusion for developers trying to compare performance or diagnose issues. Generally we keep observable platform behavior experiments to dev and beta channels, but that probably would not be a sufficient population to motivate anyone to avoid depending on it.

But fallback URLs are already required for publishers to avoid being impacted by expected format breaking changes (which I'm sure we will have). So even in the worst case that some server is mis-configured to ignore the Accept header and always serve an SXG (eg. perhaps based on User-Agent string), it should be trivial and reliable to pull out the fallback URL and navigate to that.

I propose that we keep our eyes out for any experience getting worse than today in browsers without signed exchange support, and if we see evidence of this happening at scale, pull signed exchange support back from some fraction of Chrome users. Exactly how best to do this will depend on the situation. But it could even include, for example, having a period of a week where 50% of Chrome users have SXG support disabled. Or perhaps we could even disable support for specific origins which a crawler algorithmically identifies as lacking proper fallback support (after attempting to reach out to the owners of those origins of course).

Anyway there are lots of options here. So I'm confident there's no need to be further delayed by fear over what bad things might happen. Instead we can try to agree and publicly commit to the outcome we all want (i.e. the web continues to work as well as it does today in browsers without SXG, works better for users and publishers in browsers that have SXG support, and SXG is on a reasonable path to eventually be supported by multiple engines). Then when (I say "when", because at some scale some amount is inevitable) there is concrete evidence that part of the web ecosystem is moving in a direction against the goals of the web packaging effort, we can deploy mitigations (up to and including disabling support entirely if necessary).

Some support for a feature from other browser vendors is a key factor when 
we decide whether to ship a feature, but at some time we have to determine 
that the Chromium development team has done everything reasonable to get 
others onboard despite nobody else supporting it and that is the case 
here. Then the question becomes if this is valuable enough to ship anyway.

User feedback: Will this be used? Is this solving a problem? We did 
request feedback from the experiment, and we got some. All in all it seems 
to solve an important problem for CDNs and similar parties, a problem that 
has really weak work-arounds today. Does it solve a problem for end-users 
or web developers? Well, it's supposed to be invisible for end-users, and 
the problem it solves for web developers mostly has to do with 
distribution. It might unlock better page load performance due to a better 
CDN experience and that is something users and web developers usually like.

Given all of the above, I think shipping is the way to go (lgtm4), but 
also that the effort to get other vendors onboard needs to continue.

Anne asked about running an experiment instead of shipping. An experiment 
has been running for a couple of months and it seems to have produced 
positive results but given the investment required to use this feature, I 
think the feature has to be backed by a longer term commitment (shipping) 
before we can get more feedback.

+1. Let's not forget that it's been 1.5 years since the W3C Tag issued their finding encouraging the development of web packaging (shortly after which Google started serious investments including driving more active discussion in standards groups and landing code), and 5 years since the TAG first started driving exploration of the space. As for any change of this magnitude to the architecture of the web, I'm sure it'll continue to be somewhat "experimental" for the next 5 years. But any meaningful experiment with aspirations of succeeding in under a decade end-to-end requires making it available by default at some point in the middle (especially in cases like this where we have confidence that we could safely drop support without significant user harm if results indicate the experiment is a failure).

 

/Daniel

On Mon, 04 Feb 2019 10:48:39 +0100, Anne van Kesteren <ann...@annevk.nl> 
wrote:

> On Fri, Feb 1, 2019 at 11:28 PM Mike West <mk...@chromium.org> wrote:
>> With those mitigations in mind, we should ship some running code, and 
>> continue working towards rough consensus with other vendors as we learn 
>> together from that implementation experience.
>
> To be clear, there's only running code. There's no rough consensus or
> an accepted web standard. If what you want is implementation
> experience, why not make this an experiment for a while?
>


--
/* Opera Software, Linköping, Sweden: CET (UTC+1) */

--
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/op.zwouypz0rbppqq%40cicero2.linkoping.osa.

[Kouhei Ueno]

Thank you for your valuable feedback.

We just enabled Signed HTTP Exchange by default on ToT. As Daniel mentioned, we believe this is the best way forward to gather broader feedback from users.

Shipping a feature is not an end of our work by any means. We are fully committed to continue work in the space. Your feedback is highly welcomed at any stage.

We will continue to seek support from other browser vendors. I highly appreciate the fact that other browser vendors are starting to engage in the WICG/webpackage repository.

Especially given the current situation, we believe it is important to maintain the state where Signed HTTP Exchange is not required for any web content. This will not only avoid us subsetting the Web, but also allow us to make breaking changes to Signed HTTP Exchange and evolve. The fallbackUrl is one of our attempts to enforce this from spec.

--

kouhei

[PhistucK]

This is a bit of a specification question/suggestion, but it might help in not being totally against this feature -

What about requiring and reusing the Location HTTP response header? When the Content-Type response header is of a signed exchange type, it will be ignored by browsers that support signed exchange and non-supporting browsers (or format mismatch) will simply redirect to the non-signed-exchange version. Without Location, the signed exchange will be ignored and result in a navigation error.

One more alternative to make sure signed exchanges do not subset the Web is to fetch the fallback URL in parallel certain percents of the signed exchange responses (or once per origin per day) and compare the content. 90% similarity will not trigger the no-fallback histogram.

☆PhistucK

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/CAPVAxLVvXR%2BDXxG2D3-1ORWQBM04R%2BiXxj0J-oa4bb0_AQpaPQ%40mail.gmail.com.

[Claudio DeSouza]

Hello,

I've noticed that the flag for this feature has recently been removed on 107, and now this feature cannot be disabled anymore on chromium.

https://chromium-review.googlesource.com/c/chromium/src/+/3372042

I would like to mention though that this feature seems to be a bit controversial. Both Brave (https://brave.com/web-standards-at-brave/6-privacy-sandbox-concerns/), and Mozilla (https://mozilla.github.io/standards-positions/#http-origin-signed-responses) have indicated objection to SXG. I understand that it is common policy to remove flags that are enabled by default after several releases. Having said that, I would appreciate if anyone could suggest what is the way forward. How do we intend to achieve consensus?

Regards,

Claudio.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Kunihiko Sakamoto]

Hello Claudio,

The flag removed in 107 was for SignedExchangeSubresourcePrefetch (https://chromestatus.com/feature/5126805474246656), which is a sub-feature of SXG. 

There's still a flag that control the overall SXG functionality:
https://source.chromium.org/chromium/chromium/src/+/main:content/public/common/content_features.cc;l=1007;drc=cf35bef762c6f8cd87de849010f803618a4c9ef4
Turning this off disables the SignedExchangeSubresourcePrefetch feature as well.

2022年10月12日(水) 2:17 Claudio DeSouza <cdes...@chromium.org>:

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/CAPVAxLVvXR%2BDXxG2D3-1ORWQBM04R%2BiXxj0J-oa4bb0_AQpaPQ%40mail.gmail.com.

--

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/d5c5cf6b-9466-4de2-88fe-7b1e6ae4376bn%40chromium.org.

[Claudio DeSouza]

Ah,

Thanks for the clarification.

Claudio.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPVAxLVvXR%2BDXxG2D3-1ORWQBM04R%2BiXxj0J-oa4bb0_AQpaPQ%40mail.gmail.com.

--
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+unsubscribe@chromium.org.