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 <[email protected]>: > 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 > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/d5c5cf6b-9466-4de2-88fe-7b1e6ae4376bn%40chromium.org?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/CAO5vZCj25r-SEqYKnC5bSAbG0Kd0aQGNORruvUJeQQZeCLk%2BzQ%40mail.gmail.com.
