No approvals are needed for an Intent to Prototype! On Wed, Apr 23, 2025 at 7:58 AM Mustafa Emre Acer <mea...@chromium.org> wrote:
> Ping. We would like to start landing code behind a feature flag, thanks. > > On Fri, Apr 4, 2025 at 12:41 PM Mustafa Emre Acer <mea...@chromium.org> > wrote: > >> Contact emailsmea...@chromium.org >> >> Explainerhttps://github.com/explainers-by-googlers/script-src-v2 >> >> SpecificationNone >> Existing CSP spec will be updated as part of development. >> >> Summary >> >> Introduces a new Content Security Policy (CSP) directive tentatively >> called *script-src-v2*. This new directive adds two new hash based >> allowlisting mechanisms: script sources based on hashes of URLs and >> contents of eval() and eval() like functions. 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. script-src-v2 drops >> some features considered unsafe from script-src. In particular, hostname >> based allowlisting functionality that is unsafe and no longer necessary >> given the expanded allowlisting functionality is removed. The new directive >> overrides script-src when provided. >> >> >> Blink componentBlink>SecurityFeature>ContentSecurityPolicy >> <https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3ESecurityFeature%3EContentSecurityPolicy%22> >> >> Motivation >> >> Allowlist script-src URLs with their hashes with a new keyword called >> url-hashes: Sites that want to allowlist scripts for use with script-src >> currently have 2 options: allowlist script contents through subresource >> integrity, which is not practical for scripts that change often (e.g. >> analytics), or use host-source to allowlist entire hostnames (thus >> allowlisting more than may be necessary). This proposal permits >> allowlisting full URLs, which permits precise allowlist targeting while >> still allowing content to change as needed. Using hashes over raw URLs in >> the policy allows for a more succinct representation when allowlisting >> longer URLs. More safely enabling scripts for use with eval(), Function, >> setTimeout, setInterval, and setImmediate: The only existing mechanism to >> use eval() and eval-like functions is by enabling them without restriction >> via unsafe-eval. This means that currently any site that needs to use >> eval() (such as for feature detection) must expose itself to eval-based XSS >> risks. Allowlisting individual scripts mitigates these issues. Introducing >> the script-src-v2 directive: Relying on the functionality above without >> incurring breakage on browsers that do not yet support the updated >> semantics necessitates a new directive that overrides the previous >> directive, allowing older browsers to fall back on a less-safe >> script-src-based policy. >> >> >> Initial public proposalhttps://github.com/WICG/proposals/issues/203 >> >> Search tagscontent security policy >> <https://chromestatus.com/features#tags:content%20security%20policy>, csp >> <https://chromestatus.com/features#tags:csp> >> >> TAG reviewNone >> >> TAG review statusPending >> >> Risks >> >> >> Interoperability and Compatibility >> >> The new script-src-v2 directive (final name TBD) is intended to override >> script-src. This will allow sites to enforce a stricter policy in browsers >> that understand the new directive while still including a weaker policy for >> those that only support script-src. The new url-hashes keyword and support >> for hashes of eval'ed functions are only supported in script-src-v2. We >> decided not to backport these changes to script-src to avoid potential >> breakage: Sites deploying these features without checking browser support >> may cause the user's browser to block loading of scripts allowlisted by >> url-hashes and eval hashes. >> >> >> *Gecko*: No signal >> >> *WebKit*: No signal >> >> *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? >> >> None >> >> >> Debuggability >> >> >> >> Is this feature fully tested by web-platform-tests >> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >> ?No >> >> Web Platform Tests will be written as part of the prototype. >> >> >> Flag name on about://flagsNone >> >> Finch feature nameCSPScriptSrcV2 >> >> Requires code in //chrome?False >> >> Tracking bughttps://crbug.com/392657736 >> >> Estimated milestones >> >> No milestones specified >> >> >> Link to entry on the Chrome Platform Status >> https://chromestatus.com/feature/5196368819519488?gate=5111339338694656 >> >> 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/CANDkT5nUKdicqiy0h6S7JcmDinfZpKF3pEfOKi2iSsz-_9sKxw%40mail.gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CANDkT5nUKdicqiy0h6S7JcmDinfZpKF3pEfOKi2iSsz-_9sKxw%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/CAM0wra8YB1xRGJMP%2BvRMAkqyQ3_aLjvpyzG5cxcLKwsG6rX4NA%40mail.gmail.com.
