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 > > 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 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/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/CAOmohSLCEih3Kf%2B3PE%2B31DEjP2O0CBf0aZmNdh9NXDVMdRz%3DDg%40mail.gmail.com.
