Is there a reason to change the chromestatus type? Presumably we'd want to be able to experiment with things that are internal and not developer-facing (and developers won't directly see any change from this). A lot of the Networking internals tend to fall into that bucket and it'd be nice (at least on some of them) to still go through the intent process for a heads-up.
On Wed, Apr 30, 2025 at 11:29 AM Mike Taylor <miketa...@chromium.org> wrote: > Yeah, probably. Jason, are you able to do some backend magic to convert > the chromestatus type? > On 4/30/25 10:33 AM, Patrick Meenan wrote: > > I'm hoping for 138 (code is in-flight now). I added 138 to the "dev trials > section" but there doesn't appear to be any way to "experiment". The only > stages that come after (or can be added) are shipping. Maybe because it's > "No developer-facing change" for the feature type? > > > > On Wed, Apr 30, 2025 at 7:01 AM Mike Taylor <miketa...@chromium.org> > wrote: > >> Thanks Patrick. It will be interesting to learn how the experiment goes, >> and any possible improvements, especially if resources are changing hourly. >> >> I look forward to learning more about how sites will attest to always >> return the same payload, if the experiment proves successful. >> >> One last question: which milestones are you requesting to run the >> experiment for? Your chromestatus entry doesn't indicate that - I think you >> need to add an experiment milestone (which is probably why this intent >> didn't show up in our review queue). >> On 4/29/25 2:20 PM, Patrick Meenan wrote: >> >> The previous experiment required an exact match of a full URL and payload >> hash (on a path to automate allow-listing responses). Unfortunately, most >> of the interesting third-party resources are updated quite regularly >> (usually at least daily if not every few hours) so the URL list and payload >> hashes were both very stale by the time the experiment was run. >> >> This experiment learned from those results and is targeting a MUCH >> smaller list of manually curated resources that are much more popular and >> uses a URLPattern to allow for versioned variants of the URLs (for things >> like the YT player JS or pubads_impl which include versions in the path) >> and removes the hash-matching requirement for the payload (for things like >> analytics.js which update in-place). >> >> It won't impact as many third-party resources, by design, but the >> resources that it does impact are going to be MUCH more likely to be seen >> by most users multiple times within a browsing session (and within the >> update window for any of them). >> >> On Tue, Apr 29, 2025 at 10:52 AM Mike Taylor <miketa...@chromium.org> >> wrote: >> >>> Hey Patrick, >>> >>> This sounds related to a previous experiment ( >>> https://groups.google.com/a/chromium.org/g/blink-dev/c/9xWJK3IgJb4/m/SYLfUccOBgAJ) >>> - could you describe how this experiment is similar or different (or >>> perhaps builds upon the results from the previous experiment)? >>> >>> thanks, >>> Mike >>> On 4/23/25 10:46 AM, Patrick Meenan wrote: >>> >>> Contact emails pmee...@chromium.org >>> >>> Specification None >>> >>> Design docs >>> >>> https://docs.google.com/document/d/1xaoF9iSOojrlPrHZaKIJMK4iRZKA3AD6pQvbSy4ueUQ/edit?usp=sharing >>> >>> Summary >>> >>> For a small number (hundreds) of hand-curated static third-party scripts >>> that are used on a large portion of the web, Chrome will use a single-keyed >>> HTTP cache to store those resources. This helps users and site owners with >>> faster performance for those scripts that are very widely used while >>> maintaining the privacy protections of the partitioned disk cache. This >>> feature targets the scripts that most users are likely to see multiple >>> times across multiple sites in any given browsing session. They are usually >>> not in the critical path of the page loading and may not impact the common >>> performance metrics but they are still important for the healthy operation >>> of the web. The list of candidate scripts is curated from the HTTP Archive >>> dataset. This includes site-independent things like common analytics >>> scripts, social media embeds, video player embeds, captcha providers and >>> ads libraries. It allows for code that uses versioned URLs as long as the >>> versioning is not a manual process by embedders and that the same version >>> is sent to everybody at a given point in time with the same contents. This >>> does not include things like common Javascript libraries where they are >>> commonly self-hosted or where the URL references a specific version of the >>> library and it is up to site owners to manually select a version. >>> >>> Blink component Blink>Network >>> <https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3ENetwork%22> >>> >>> TAG review None >>> >>> TAG review status Not applicable >>> >>> Risks >>> >>> >>> Interoperability and Compatibility >>> >>> This change is internal to Chrome and should be completely transparent >>> to the web platform with no interoperability risks. >>> >>> >>> *Gecko*: N/A >>> >>> *WebKit*: N/A >>> >>> *Web developers*: No signals >>> >>> *Other signals*: >>> >>> Ergonomics >>> >>> N/A >>> >>> >>> Activation >>> >>> N/A >>> >>> >>> Security >>> >>> Cache partitioning added a level of privacy protection that is being >>> disabled for a small number of resources where it is deemed safe to do so. >>> The linked document and issue provide the details on the protections that >>> are in place to minimize the privacy exposure. >>> >>> >>> WebView application risks >>> >>> Does this intent deprecate or change behavior of existing APIs, such >>> that it has potentially high risk for Android WebView-based applications? >>> >>> None >>> >>> >>> Goals for experimentation For the purposes of the experiment, we will >>> target around a dozen of the most-impactful scripts (mostly ads and >>> analytics) and work with the script owners to measure the resulting impact >>> (on performance, reliability and business metrics). >>> >>> If these scripts show minimal impact from using a shared cache then >>> there is no value in the added complexity for the feature and it can be >>> documented and closed. >>> >>> If there is significant impact then it is likely worth pursuing further >>> (and will also be documented for other similar efforts). >>> >>> Ongoing technical constraints >>> >>> None >>> >>> >>> Debuggability >>> >>> The cache key used for any given resource is exposed in the netlog >>> <https://www.chromium.org/for-testers/providing-network-details/> which >>> can be used to verify if a given resource used the shared cache or not. >>> >>> >>> Will this feature be supported on all six Blink platforms (Windows, Mac, >>> Linux, ChromeOS, Android, and Android WebView)? Yes >>> >>> Is this feature fully tested by web-platform-tests >>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >>> ? No >>> >>> Flag name on about://flags None >>> >>> Finch feature name CacheSharingForPervasiveScripts >>> >>> Non-finch justification None >>> >>> Requires code in //chrome? False >>> >>> Tracking bug https://issues.chromium.org/u/1/issues/404196743 >>> >>> Measurement The success of this feature will be measured directly with >>> the owners of a small number of targeted scripts with a web-exposed >>> experiment. >>> >>> Estimated milestones >>> >>> No milestones specified >>> >>> >>> Link to entry on the Chrome Platform Status >>> https://chromestatus.com/feature/5202380930678784 >>> >>> This intent message was generated by Chrome Platform Status >>> <https://chromestatus.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+unsubscr...@chromium.org. >>> To view this discussion visit >>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPq58w50QC8Vj9qUT_eyAdz2nFx2jEW0033KFeDeM6v%3D4J-mKw%40mail.gmail.com >>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPq58w50QC8Vj9qUT_eyAdz2nFx2jEW0033KFeDeM6v%3D4J-mKw%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 blink-dev+unsubscr...@chromium.org. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPq58w7oJEc10sKHJJ-26BGLo%3D8rDxWaA_4620vvSH5SuLAujQ%40mail.gmail.com.
