Just to close the loop, the PR has landed, and the feature is now enabled by default <https://chromium-review.googlesource.com/c/chromium/src/+/6683341>. Thanks all!!
On Wed, Jun 25, 2025 at 8:59 PM PhistucK <phist...@gmail.com> wrote: > I asked Copilot there and it went over the results itself and found > nothing, too. Handy (even if not 100% reliable). :) > > > ☆*PhistucK* > > > On Wed, Jun 25, 2025 at 7:57 PM Yoav Weiss (@Shopify) < > yoavwe...@chromium.org> wrote: > >> >> >> On Wed, Jun 25, 2025 at 7:37 PM PhistucK <phist...@gmail.com> wrote: >> >>> Have you tried searching GitHub with a regular expression? Seems not to >>> ignore anything. :) >>> https://github.com/search?q=%2F__Http-%2F&type=code >>> >> >> Thanks!! Going over the results, it seems like there's nothing there >> related to cookies (other than the WPT that testing this very feature). >> >> >>> >>> >>> ☆*PhistucK* >>> >>> >>> On Wed, Jun 25, 2025 at 6:00 AM Yoav Weiss (@Shopify) < >>> yoavwe...@chromium.org> wrote: >>> >>>> >>>> >>>> On Wed, Jun 25, 2025 at 4:18 AM Vladimir Levin <vmp...@chromium.org> >>>> wrote: >>>> >>>>> >>>>> >>>>> On Thursday, June 19, 2025 at 9:48:37 AM UTC-4 Yoav Weiss wrote: >>>>> >>>>> Contact emailsyoavwe...@chromium.org >>>>> >>>>> Explainer >>>>> This will add the cookie name prefix `__Http-`. >>>>> Cookies that would start with that prefix would only be able to be set >>>>> using the `Set-Cookie` HTTP header and will have to have an `httpOnly` >>>>> attribute. >>>>> >>>>> Adding that prefix to the cookie name will give site operators the >>>>> guarantee that any such cookie they see was set by their server, and not >>>>> be >>>>> a malicious/compromised script. >>>>> >>>>> There are still ongoing discussions >>>>> <https://github.com/httpwg/http-extensions/issues/3111#issuecomment-2986560222> >>>>> about the exact spelling of a combination of this prefix with the >>>>> `__Host-` >>>>> prefix. I'd like this intent to cover both, but I'm not planning to ship >>>>> the `__HostHttp` variant until the dust settles on the desired spelling. >>>>> >>>>> Specificationhttps://github.com/httpwg/http-extensions/pull/3110 >>>>> >>>>> Summary >>>>> >>>>> There are cases where it's important to distinguish on the server side >>>>> between cookies that were set by the server and ones that were set by the >>>>> client. One such case is cookies that are normally always set by the >>>>> server, unless some unexpected code (an XSS exploit, a malicious >>>>> extension, >>>>> a commit from a confused developer, etc.) happens to set them on the >>>>> client. This proposal adds a signal that would enable servers to make such >>>>> a distinction. More specifically, it defines the __Http and __HostHttp >>>>> prefixes, that make sure that a cookie is not set on the client side using >>>>> script. >>>>> >>>>> >>>>> What is the behavior if one attempts to set an `__Http`-prefixed >>>>> cookie from script with this feature? Does it silently fail, or is there >>>>> an >>>>> error that is thrown? >>>>> >>>> >>>> Similar to existing prefixes >>>> <https://github.com/web-platform-tests/wpt/blob/master/cookies/resources/cookie-helper.sub.js#L76>, >>>> when setting a cookie using `document.cookie`, the only way to know it >>>> failed is observing (on the server) it is not present in relevant requests. >>>> Setting such a cookie through the CookieStore API results in a Promise >>>> rejection >>>> <https://github.com/web-platform-tests/wpt/blob/master/cookie-store/cookieStore_special_names.https.any.js#L39> >>>> . >>>> >>>> >>>>> >>>>> >>>>> Blink componentInternals>Network>Cookies >>>>> <https://issues.chromium.org/issues?q=customfield1222907:%22Internals%3ENetwork%3ECookies%22> >>>>> >>>>> TAG reviewNone, as the TAG doesn't typically review HTTP features. >>>>> >>>>> TAG review statusNot applicable >>>>> >>>>> Risks >>>>> >>>>> >>>>> Interoperability and Compatibility >>>>> >>>>> No particular compat issues, as we don't expect this prefix to already >>>>> exist in the wild. >>>>> >>>>> In terms of interop, Mozilla and Apple folks are heavily involved in >>>>> the discussions and haven't raised any concerns. >>>>> >>>>> >>>>> I agree that the chance of there being __Http named cookies is very >>>>> low, but I've been wrong about things like this before :) Do you have any >>>>> metrics/code searches/etc to validate that this is safe from compat >>>>> perspective? >>>>> >>>> >>>> I don't have any metrics, and GH search seems to ignore the _ and - >>>> parts when searching for `__Http-`.. >>>> I agree there's a non-zero change that someone added such a prefix to a >>>> cookie (without it being httpOnly), but I think having a Finch flag to be >>>> able to turn the feature off in case that turns out to be the case is >>>> sufficient. >>>> >>>> >>>>> >>>>> >>>>> >>>>> >>>>> *Gecko*: No signal (https://github.com/mozilla/ >>>>> standards-positions/issues/1256) >>>>> >>>>> *WebKit*: No signal (https://github.com/WebKit/ >>>>> standards-positions/issues/518) >>>>> >>>>> *Web developers*: Positive (https://lists.w3.org/ >>>>> Archives/Public/ietf-http-wg/2025JanMar/0146.html) >>>>> >>>>> *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 >>>>> >>>>> None >>>>> >>>>> >>>>> 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 >>>>> https://chromium-review.googlesource.com/c/chromium/ >>>>> src/+/6638647/15/third_party/blink/web_tests/external/wpt/ >>>>> cookies/prefix/__Http.https.html >>>>> https://chromium-review.googlesource.com/c/chromium/ >>>>> src/+/6650996/2/third_party/blink/web_tests/external/wpt/ >>>>> cookies/prefix/__HostHttp.https.html >>>>> >>>>> Flag name on about://flagsNone >>>>> >>>>> Finch feature namePrefixCookieHttp, PrefixCookieHostHttp >>>>> >>>>> Rollout planWill ship enabled for all users >>>>> >>>>> Requires code in //chrome?False >>>>> >>>>> Tracking bughttps://issues.chromium.org/issues/426096760 >>>>> >>>>> Estimated milestonesShipping on desktop140Shipping on Android140Shipping >>>>> on WebView140 >>>>> >>>>> Anticipated spec changes >>>>> >>>>> Open questions about a feature may be a source of future web compat or >>>>> interop issues. Please list open issues (e.g. links to known github issues >>>>> in the project for the feature specification) whose resolution may >>>>> introduce web compat/interop risk (e.g., changing to naming or structure >>>>> of >>>>> the API in a non-backward-compatible way). >>>>> None >>>>> >>>>> Link to entry on the Chrome Platform Statushttps://chromestatus.com/ >>>>> feature/5170139586363392?gate=5174068239925248 >>>>> >>>>> 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/CAOmohS%2BRtDnZ9x5izwv8_4xUBOxZrzBd2L8Eh_Cn58dPvd9Ayw%40mail.gmail.com >>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOmohS%2BRtDnZ9x5izwv8_4xUBOxZrzBd2L8Eh_Cn58dPvd9Ayw%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/CAOmohSLdnJfYn4j0R47m82DZ17Bv3CUbnCqdk_aDtjGYt9veDA%40mail.gmail.com.
