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
<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
<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
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>.
