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/CABc02_KPZOgq%3D9bUHi%3DnTpNg%3Dz%2B9MsD%3Dtsap6s%2B0RmoJJeR0pg%40mail.gmail.com.
