Just to close the loop on this, the rename landed and was back-merged into 140. No flags required. Mozilla similarly renamed their implementation.
On Wed, Aug 20, 2025 at 4:44 PM Mike Taylor <miketa...@chromium.org> wrote: > On 8/20/25 10:42 a.m., Yoav Weiss (@Shopify) wrote: > > > > On Wed, Aug 20, 2025 at 4:35 PM Mike Taylor <miketa...@chromium.org> > wrote: > >> On 8/11/25 5:27 a.m., Yoav Weiss (@Shopify) wrote: >> >> Reviving this thread, as while talking to folks about deploying this I >> realized we should name `__HostHttp-` to be `__Host-Http-`. >> That makes sure that deploying __Host-Http- prefixed cookies maintains >> host semantics in non-supporting browsers and makes for a progressive >> enhancement. (rather than requiring complex server side logic to determine >> the cookie name based on browser and version) >> >> I discussed the rename with WebKit, Mozilla and Chrome engineers on the >> #cookies matrix channel and everyone seemed on board with it. >> I also filed spec <https://github.com/httpwg/http-extensions/pull/3153> >> PRs <https://github.com/whatwg/cookiestore/pull/286> as well as WPT >> <https://github.com/web-platform-tests/wpt/pull/54226>. >> >> Since this never hit stable (it landed in 140, which is still in Beta), I >> suggest to: >> * Turn off the feature flag >> <https://source.chromium.org/chromium/chromium/src/+/main:net/base/features.h;l=184?q=hosthttp%20f:feature&ss=chromium%2Fchromium%2Fsrc> >> in >> 140 (either in code with back-merges or on the server-side if Google folks >> are interested in helping with that). >> * Rename the prefix in 141 and enable the flag there. >> >> That would mean that the __Http- prefix would ship in 140 and __HostHttp- >> ships in 141, but I think that's perfectly fine. >> >> What do y'all think? >> >> Makes sense to me! >> >> >> P.S. Another thing that seems important for ease of deployment is that >> supporting browsers would apply the prefix rules to cookies already in >> their stores when they are upgraded. >> I'm planning to change Chromium's implementation to support that, but >> that doesn't seem extremely web-exposed. Let me know if you think otherwise. >> >> Will you make sure the RFC is updated to reflect this change? >> > > There's an ongoing discussion at > https://github.com/httpwg/http-extensions/pull/3156 > > Perfect, thanks. > > >> On Mon, Jun 30, 2025 at 4:36 PM Yoav Weiss (@Shopify) < >> yoavwe...@chromium.org> wrote: >> >>> 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 Status >>>>>>>> https://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/CAOmohSKsGyqchsfbHrXBLPorj--FaTvtJ4wROsNK2dwgkrUaYg%40mail.gmail.com >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOmohSKsGyqchsfbHrXBLPorj--FaTvtJ4wROsNK2dwgkrUaYg%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/CAOmohSLRDpHAP0HSx1xdz2%2Bt8Odo8DzhnJ9P3nO7%3DZnT_HvOYg%40mail.gmail.com.
