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?
On Mon, Jun 30, 2025 at 4:36 PM Yoav Weiss (@Shopify)
<[email protected]> 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 <[email protected]> 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)
<[email protected]> wrote:
On Wed, Jun 25, 2025 at 7:37 PM PhistucK
<[email protected]> 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
<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)
<[email protected]> wrote:
On Wed, Jun 25, 2025 at 4:18 AM Vladimir Levin
<[email protected]> wrote:
On Thursday, June 19, 2025 at 9:48:37 AM UTC-4
Yoav Weiss wrote:
Contact [email protected]
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
<https://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
<https://github.com/mozilla/standards-positions/issues/1256>)
/WebKit/: No signal
(https://github.com/WebKit/standards-positions/issues/518
<https://github.com/WebKit/standards-positions/issues/518>)
/Web developers/: Positive
(https://lists.w3.org/Archives/Public/ietf-http-wg/2025JanMar/0146.html
<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/+/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
<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
<https://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
<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
[email protected].
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 [email protected].
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 [email protected].
To view this discussion visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/1aa89611-d798-4785-a22d-518aa997c25a%40chromium.org.
