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?
 


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?
 



*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/8a1a9a00-a4ef-47b1-a807-332e5022851dn%40chromium.org.

Reply via email to