Thanks for clarifying, Carlos. As this will be an effective reset of the OT timeline, LGTM1.
On Thursday, March 12, 2026 at 10:51:04 AM UTC-7 [email protected] wrote: > Hi Alex, > > As far as movement on the spec or TAG feedback, we hoped to use feedback > from real-life use during the origin trial, so that's still stuck. However, > we still plan to move the spec forward once we run a successful trial. > The bugs blocked getting any meaningful use or feedback, so the plan is > indeed to "start for real" on this round. > > Thanks, > Carlos > > On Wed, Mar 11, 2026 at 8:17 AM Alex Russell <[email protected]> > wrote: > >> Thanks, Carlos. >> >> We discussed in the API OWNERS meeting this morning, and a couple of >> questions bubbled up: >> >> - Has there been progress on addressing TAG feedback? >> - Is the spec PR still moving? >> - Are folks using this successfully even though there are some bugs? >> >> On the last point, the main question is basically "are we going to be >> starting for real in 147?" Or is that only useful to a small set of >> potential OT users? >> >> Also, if there has been feedback, are you able to summarize that here? >> >> Best, >> >> Alex >> >> On Tuesday, March 10, 2026 at 3:17:41 PM UTC-7 [email protected] wrote: >> >>> Hi Alex, >>> >>> The request is to extend the OT end (from M144) until M150. The API is >>> identical, just with the bugs fixed. >>> >>> Thanks, >>> -Carlos >>> >>> On Monday, March 9, 2026 at 11:45:50 AM UTC-7 [email protected] >>> wrote: >>> >>>> Thanks for re-filing this, and apologies for perhaps having missed some >>>> detail here: >>>> >>>> >>>> - Are you planning to use the previous timeline (141-150), but >>>> asking for permission to update? >>>> - Is this version API compatible with the "v1" that didn't get use >>>> from a partner? >>>> - Or is this intent asking for an extension to the previous 144 end >>>> date? >>>> >>>> Best, >>>> >>>> Alex >>>> >>>> On Thursday, March 5, 2026 at 11:11:25 AM UTC-8 Chromestatus wrote: >>>> >>> *Contact emails* >>>>> [email protected] >>>> >>>> >>>>> >>>>> *Explainer* >>>>> https://github.com/explainers-by-googlers/script-src-v2 >>>>> >>>>> *Specification* >>>>> https://github.com/w3c/webappsec-csp/pull/784 >>>>> >>>>> *Summary* >>>>> Introduces a new keywords to the script-src Content Security Policy >>>>> (CSP) directive. This adds two new hash based allowlisting mechanisms: >>>>> script sources based on hashes of URLs and contents of eval() and eval() >>>>> like functions. We loosely refer to this as script-src-v2, although it is >>>>> backwards compatible with the existing script-src, and uses the same >>>>> directive. Extending hashes to cover URL and eval() hashes allows >>>>> developers to set reasonably strict security policies by narrowly >>>>> allowlisting scripts by their hashes even when script contents are >>>>> subject >>>>> to frequent changes, and known-safe contents of eval() without permitting >>>>> unchecked use of eval() broadly. The new keywords override host-based >>>>> script-src when provided. This allows a single header to be compatible >>>>> with >>>>> browsers that both do or do not implement the new keywords. >>>>> >>>>> *Blink component* >>>>> Blink>SecurityFeature>ContentSecurityPolicy >>>>> <https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3ESecurityFeature%3EContentSecurityPolicy%22> >>>>> >>>>> *Web Feature ID* >>>>> csp <https://webstatus.dev/features/csp> >>>>> >>>>> *Search tags* >>>>> content security policy >>>>> <http:///features#tags:content%20security%20policy>, csp >>>>> <http:///features#tags:csp> >>>>> >>>>> *TAG review* >>>>> https://github.com/w3ctag/design-reviews/issues/1128 >>>>> >>>>> *TAG review status* >>>>> Pending >>>>> >>>>> *Origin Trial Name* >>>>> URL and eval hashes in CSP script-src >>>>> >>>>> *Chromium Trial Name* >>>>> CSPExtendedScriptSrcHashes >>>>> >>>>> *Origin Trial documentation link* >>>>> https://github.com/explainers-by-googlers/script-src-v2 >>>>> >>>>> *WebFeature UseCounter name* >>>>> kCSPUrlHashes >>>>> >>>>> *Risks* >>>>> >>>>> >>>>> *Interoperability and Compatibility* >>>>> For url hashes, the new url-<hash-algorithm>-<hash-value> keyword >>>>> overrides hosts in source lists so both a host and a hash can be set. >>>>> This >>>>> will allow sites to enforce a stricter policy in browsers that understand >>>>> the new keyword while still including a weaker policy for those that do >>>>> not. This also adds a strict-dynamic-url keyword, which enables >>>>> strict-dynamic like behavior when using URL hashes. This allows sites >>>>> that >>>>> need strict-dynamic with the new policy (but not with the fallback >>>>> policy) >>>>> to set it while still being able to use hostname sources in the fallback. >>>>> Similarly, the new eval-<hash-algorithm>-<hash-value> keyword overrides >>>>> unsafe-eval so both can be set, in order to prevent breakage for users in >>>>> browsers that don't support eval hashes yet. >>>>> >>>>> *Gecko*: No signal ( >>>>> https://github.com/mozilla/standards-positions/issues/1277) >>>>> >>>>> *WebKit*: No signal ( >>>>> https://github.com/WebKit/standards-positions/issues/535) >>>>> >>>>> *Web developers*: No signals >>>>> >>>>> *Other signals*: >>>>> >>>>> *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? >>>>> *No information provided* >>>>> >>>>> >>>>> *Goals for experimentation* >>>>> *No information provided* >>>>> >>>>> *Reason this experiment is being extended* >>>>> Two bugs were discovered (crbug.com/490022555 and crbug.com/490022554) >>>>> that prevented the internal Google team that was going to test the new >>>>> features from using them. Bugs are now in the process of being fixed, >>>>> requesting an extension so this can actually be used. >>>>> >>>>> *Ongoing technical constraints* >>>>> *No information provided* >>>>> >>>>> *Debuggability* >>>>> *No information provided* >>>>> >>>>> *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>?* >>>>> Yes >>>>> Tetntative tests have been added in >>>>> https://github.com/web-platform-tests/wpt/tree/master/content-security-policy/script-src/tentative >>>>> >>>>> *Flag name on about://flags* >>>>> *No information provided* >>>>> >>>>> *Finch feature name* >>>>> ScriptSrcHashesV1 >>>>> >>>>> *Requires code in //chrome?* >>>>> False >>>>> >>>>> *Tracking bug* >>>>> https://crbug.com/392657736 >>>>> >>>>> *Launch bug* >>>>> https://launch.corp.google.com/launch/4394549 >>>>> >>>>> *Estimated milestones* >>>>> Origin trial desktop first 141 >>>>> Origin trial desktop last 144 >>>>> Origin trial extension 1 end milestone 150 >>>>> Origin trial Android first 141 >>>>> Origin trial Android last 144 >>>>> Origin trial WebView first 141 >>>>> Origin trial WebView last 144 >>>>> >>>>> *Link to entry on the Chrome Platform Status* >>>>> https://chromestatus.com/feature/5196368819519488?gate=5078661873139712 >>>>> >>>>> *Links to previous Intent discussions* >>>>> Intent to Prototype: >>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CANDkT5k9roBJptbJvGBCQBt1Lhefrdz3WCqvr35gHGP2aiXXJw%40mail.gmail.com >>>>> Intent to Experiment: >>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAABgKfXm35Eeyx-X8St%2BTAV1uvJk1SOuFL1Rkq%2B7ORhJXyjYmQ%40mail.gmail.com >>>>> >>>>> >>>>> 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 [email protected]. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/0959f555-b89d-4a62-985a-1a47804c36a7n%40chromium.org.
