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. On Monday, February 4, 2019 at 5:24:20 PM UTC PhistucK wrote: > 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* > > > On Mon, Feb 4, 2019 at 5:40 PM 'Kouhei Ueno' via blink-dev < > [email protected]> wrote: > >> Thank you for your valuable feedback. >> >> We just enabled >> <https://crrev.com/a91c1c2e859a783fcfb448883d758b6c5c823bbe> 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 <https://github.com/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 >> >> >> On Tue, Feb 5, 2019 at 12:31 AM Rick Byers <[email protected]> wrote: >> >>> On Mon, Feb 4, 2019 at 8:12 AM Daniel Bratell <[email protected]> wrote: >>> >>>> 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. >>>> >>> >>> 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 <https://github.com/WICG/webpackage/issues/242> 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 >>> <https://www.w3.org/2001/tag/doc/distributed-content/#recommendations> >>> 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 >>> <https://github.com/w3ctag/packaging-on-the-web>. 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 <[email protected]> >>>> >>>> wrote: >>>> >>>> > On Fri, Feb 1, 2019 at 11:28 PM Mike West <[email protected]> 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 >>>> . >>>> >>> -- >> 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 [email protected]. >> 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 >> >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPVAxLVvXR%2BDXxG2D3-1ORWQBM04R%2BiXxj0J-oa4bb0_AQpaPQ%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> > -- 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 [email protected]. 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.
