Ah, Thanks for the clarification.
Claudio. On Wednesday, October 12, 2022 at 1:55:34 AM UTC+1 Kunihiko Sakamoto wrote: > 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/4daee388-d26d-481b-abe3-e0a1632769a9n%40chromium.org.
