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/CAOmohSKM94hSe54YUP3rR8KWLQs-4zmJ9OOSDT2zmmSoOCWX3w%40mail.gmail.com.
