Sorry if the doc didn't make it clear - the "attesting" that the doc envisions isn't expected to be an API or anything in code - it's expected to be something along the lines of a legal agreement or at least manual verification and confirmation by the owners (process - whatever legal and privacy think would be appropriate for the few dozen companies it would apply to).
On Wed, Apr 30, 2025 at 12:13 PM Mike Taylor <miketa...@chromium.org> wrote: > No developer-facing changes implies no approvals[1], but you will need a > mechanical API OWNER approval in the chromestatus entry to ship this change > (and run the experiment). AIUI, the design doc mentions sites attesting to > benefit from this feature, so there will be a new API involved at some > point. > > I'm happy to be wrong here, and welcome other API OWNERs to correct me. > > [1] See > https://www.chromium.org/blink/launching-features/#change-to-existing-code > On 4/30/25 11:34 AM, Patrick Meenan wrote: > > 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/CAPq58w69gmxRfznmdjfkGcUsbzAjB_59i5RGi7sNZABOMKFfDw%40mail.gmail.com.
