Should `secure` default to true in CookieStoreSetOptions ?

Question

Should `secure` default to true in CookieStoreSetOptions ?

inexorabletash opened this issue 4 years ago · comments

Joshua Bell commented 4 years ago

Chrome's impl doesn't have secure default to true in CookieStoreSetOptions

The spec has boolean secure = true

What do we want here?

Marijn Kruisselbrink · Answer 1 · Fri Jan 24 2020 05:17:33 GMT+0800 (China Standard Time)

Related, per https://w3ctag.github.io/design-principles/#prefer-dict-to-bool we really shoulnd't have dictionary members that default to true.

Victor Costan · Answer 2 · Thu Feb 06 2020 01:51:26 GMT+0800 (China Standard Time)

Here's the reason for not having secure set to true in Blink, from ToCanonicalCookie in cookie_store.cc

Although the Cookie Store API spec always defaults the "secure" cookie attribute to true, we only default to true on cryptographically secure origins, where only secure cookies may be written, and to false otherwise, where only insecure cookies may be written.

As a result, cookieStore.set("name", "value") sets a cookie and cookieStore.delete("name") deletes a cookie on both http://localhost and secure origins, without having to specify secure: false on http://localhost.

Victor Costan · Answer 3 · Thu Feb 06 2020 02:07:21 GMT+0800 (China Standard Time)

Regarding the point raised by @mkruisselbrink -- there is a tradeoff between diverging from the TAG's guidelines and coming up with a different dictionary member, like insecure: true, to represent the Secure attribute in RFC6265bis.

The current design chooses to diverge from the TAG guidelines. I think this results in slightly more readable code in most cases that have to deal with insecure cookies -- I'd guess that secure: false refers to the Secure attribute, but would have no idea what insecure: true means.

I'd be happy to get more feedback here. The implementation is fairly easy to change in this aspect.

Joshua Bell · Answer 4 · Fri Feb 07 2020 03:24:03 GMT+0800 (China Standard Time)

Thanks for explaining! Specifying the blink behavior (which is effectively a tristate/optional Boolean) is possible, but it's going to be weird that it really only exists for localhost testing.

We may want to highlight this for TAG feedback.

Joshua Bell · Answer 5 · Fri Feb 07 2020 03:28:29 GMT+0800 (China Standard Time)

Also, we treat localhost as a secure context in most cases. I guess cookies are treated differently? Is that consistent across browsers? Is changing that possible? (Changing cookie semantics is trendy at the moment...)

Mike West · Answer 6 · Fri Mar 20 2020 14:19:24 GMT+0800 (China Standard Time)

http://localhost/ is a secure context. https://crbug.com/1056543 aims to teach the network stack about that so that it processes secure in the same way Blink does.
In light of https://github.com/mikewest/scheming-cookies, I'd like y'all to consider dropping the secure boolean entirely, and simply not supporting non-secure cookies. The API is already locked to secure contexts, meaning that the flag shouldn't be a barrier to setting or reading cookies (modulo localhost), and it would significantly improve the security posture of the API while mitigating the risk that introducing a new API leads to an increase in non-secure cookie usage.

Ayu Ishii · Answer 7 · Sat Apr 04 2020 05:52:20 GMT+0800 (China Standard Time)

Regarding the points raised by @mikewest -- Thank you for the input! I agree, doing so seems aligned with the overall goal of promoting security, and this seems like a good opportunity to try and encourage the use of secure context for cookies while discouraging the counter.

However, making this change while this issue (allow secure cookies for localhost) exists will mean that this will not work for the many developers who use http and non-https localhost for development. Is this scenario ok? Do we know when we expect this change to take place?

Mike West · Answer 8 · Mon Apr 06 2020 14:17:35 GMT+0800 (China Standard Time)

Do we know when we expect this change to take place?

No one is currently working on it in Chromium with any priority, so I don't think there's any timeline. If it's something y'all would consider blocking, then we need to figure out how to create one.

That said, this seems like a Chromium implementation detail. From an ivory tower specification perspective, it seems like the right thing to define as correct behavior. Then implementers just need to align their behavior with that ideal. :)

Ayu Ishii · Answer 9 · Wed Apr 15 2020 04:29:24 GMT+0800 (China Standard Time)

Thanks for the feedback!
What are your thoughts on what this would mean for the query APIs?

Allowing get()/getAll() to retrieve secure & non-secure cookies may cause some unintended behavior if one were to cookieStore.get() a non-secure cookie, and update a value through cookieStore.set() which would also automatically set secure to be true without explicitly setting so.

Although the alternative for excluding non-secure cookies from the query APIs may make the API less appealing for developers..

Mike West · Answer 10 · Wed Apr 15 2020 12:17:37 GMT+0800 (China Standard Time)

I'd suggest that this API simply pretend that non-secure cookies don't exist. I agree that it could create some short-term confusion, but it seems like the right direction in which to incentivize developers. It creates behavior similar to that proposed in https://github.com/mikewest/scheming-cookies, which is where I think cookies ought to move, which will ensure that we don't create more usage of cross-scheme cookies in the short term while we roll out that larger change.

Do you have use-cases lined up that require access to non-secure cookies that couldn't be made secure?

Victor Costan · Answer 11 · Thu Apr 23 2020 03:32:22 GMT+0800 (China Standard Time)

I'll summarize the analysis we did back in 2017-2018 when we designed the API. I hope this helps a bit, even though some of the background has changed.

This API brings the following benefits to the ecosystem.

Performance - the API is an async replacement for document.cookies. We hope sites will migrate to it, and access cookies without janking the main thread. Worth noting that the incentives aren't as aligned here as they should be... a slow tab will jank all tabs that happen to share the same event loop (by virtue of being in the same renderer). This is especially important on mobile, where there are fewer resources.
Security - the API eliminates the need for parsing/composing the HTTP header string.
Privacy - the API has good defaults (site-only, secure cookies) when writing cookies.

Turning up the Privacy dial with the proposal above increases the cost of adopting the API (at the very least, the developer must make sure they don't happen to be using non-secure cookies anywhere), which will reduce adoption. This means we'll see less of the other benefits.

At the time we designed the API, we thought that the current adoption cost (having to switch to async logic) was high, and we couldn't get away with piling on more requirements.

Ayu Ishii · Answer 12 · Tue May 12 2020 05:30:18 GMT+0800 (China Standard Time)

Thanks for the discussion everyone! With some additional discussion offline, I think we were able to come to an agreement upon adopting a middle ground of being able to read non-secure cookies but only being able to write secure cookies.

I will close the issue with this conclusion, but feel free to re-open if this seems to misrepresented or anything else comes up. Thanks!

Ayu Ishii · Answer 13 · Tue May 12 2020 06:02:20 GMT+0800 (China Standard Time)

Created an implementation issue for Chromium here.

Victor Costan · Answer 14 · Tue May 12 2020 06:04:01 GMT+0800 (China Standard Time)

I propose that we leave the issue open until we update the explainer and the specification.