LGTM2, same conditions On Wednesday, June 25, 2025 at 11:28:27 AM UTC-4 Mike Taylor wrote:
> LGTM1, but conditioned on the spec work landing before shipping anything. > On 6/25/25 1:00 a.m., Yoav Weiss (@Shopify) 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/5d068f26-f995-4263-b5aa-43bb6fa48065n%40chromium.org.
