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.
