Intent to Implement and Ship: Cookie prefixes and Strict Secure Cookies

Joel Weinberger

unread,

Dec 8, 2015, 5:22:17 PM12/8/15

to blink-dev, Mike West, Emily Stark

Contact emails

j...@chromium.org, est...@chromium.org, mk...@chromium.org

Spec

https://tools.ietf.org/html/draft-west-cookie-prefixes

https://tools.ietf.org/html/draft-west-leave-secure-cookies-alone

Link to a tag review or a description about why the tag review process is being skipped.

Summary

Cookie prefixes place a set of restrictions upon the names which may be used for cookies with specific properties. In a nutshell: `__Secure-*` cookies have to have the `Secure` flag, and `__Host-*` cookies have to have `Path=/`, can't have `Domain`, and might require `Secure` (depending on the setter).

Strict secure cookies adds restrictions on cookies marked with the 'Secure' attribute. Currently, Secure cookies cannot be accessed by insecure (e.g. HTTP) origins. However, insecure origins can still add Secure cookies, delete them, or indirectly evict them. This feature modifies the cookie jar so that insecure origins cannot in any way touch Secure cookies. This does leave a carve out for cookie eviction, which still may cause the deletion of Secure cookies, but only after all non-Secure cookies are evicted.

Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes.

Debuggability

Neither of these features changes anything about how cookies and networking are debuggable today.

Interoperability and Compatibility Risk

Describe the degree of interoperability and compatibility risk you believe this change poses. If this is a brand new feature, please characterize how much we might regret shipping this new feature because we might want to change or remove it in the future. If you don’t have a launch tracking bug or row in the feature dashboard, include in this email links to relevant specs, standards discussions, or documentation about support for the feature in other browsers. Please be thorough here if compatibility risk has changed since your intent to implement.

Prefixes presents very minimal compatibility risk. While technically adding these prefixes could interfere with already existing cookies, our metrics have seen no cookies with these prexfixes in the wild.

Strict secure cookies present a bit more of a risk as they change the behavior of already existing cookies. However, of cookies that are set, fewer than 00.02% are secure cookies set by an insecure scheme. Thus, while we do risk some compatibility issues, they seem likely to be minimal.

OWP launch tracking bug

https://crbug.com/567867

Entry on the feature dashboard

Cookie Prefixes

Strict Secure Cookies

Emily Stark

unread,

Dec 8, 2015, 5:38:18 PM12/8/15

to Joel Weinberger, blink-dev, Mike West, Emily Stark

Joel and I had a minor miscommunication, oops. I actually sent out a separate Intent to Ship for cookie prefixes earlier today: https://groups.google.com/a/chromium.org/d/msg/blink-dev/ueCrrgFX8J4/3C8CN6gEAgAJ

So I suppose we should use this one for Strict Secure cookies and https://groups.google.com/a/chromium.org/d/msg/blink-dev/ueCrrgFX8J4/3C8CN6gEAgAJ for cookie prefixes.

Elliott Sprehn

unread,

Dec 8, 2015, 5:53:52 PM12/8/15

to Emily Stark, Mike West, Joel Weinberger, blink-dev

Why did we switch to __ from $$ ?

Emily Stark

unread,

Dec 8, 2015, 6:26:20 PM12/8/15

to Elliott Sprehn, Emily Stark, Mike West, Joel Weinberger, blink-dev

On Tue, Dec 8, 2015 at 2:53 PM, Elliott Sprehn <esp...@chromium.org> wrote:

Why did we switch to __ from $$ ?

We got reports that some cookie parsers ignore cookies whose names start with $. See https://www.ietf.org/rfc/rfc2109.txt Section 4.4 and https://twitter.com/tbroyer/status/670779401135616000

Joel Weinberger

unread,

Dec 8, 2015, 7:38:33 PM12/8/15

to Emily Stark, Elliott Sprehn, Mike West, blink-dev

Thanks, Emily. Yes, my mistake. This really should be for Strict Secure Cookies only.

--Joel

Philip Jägenstedt

unread,

Dec 9, 2015, 10:28:58 AM12/9/15

to Joel Weinberger, Emily Stark, Elliott Sprehn, Mike West, blink-dev

Strict Secure Cookies LGTM1

--
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+...@chromium.org.

Joel Weinberger

unread,

Dec 9, 2015, 11:08:08 AM12/9/15

to Philip Jägenstedt, Emily Stark, Elliott Sprehn, Mike West, blink-dev

As I just mentioned on the Prefixes thread, we plan a slow rollout of Strict Secure (it's implemented behind a Finch Flag). Although the numbers indicate that it should be safe, we want to make sure there are no surprise breakages, and we also want a kill switch if necessary.

Chris Harrelson

unread,

Dec 10, 2015, 11:53:50 PM12/10/15

to Joel Weinberger, blink-dev, Mike West, Emily Stark

Does this mean that 0.02% of existing cookies currently set by insecure domains will now have changed (and broken I think) semantics? Or 0.002%?

Do you know of examples, or specific sites we could reach out to?

OWP launch tracking bug
https://crbug.com/567867

Entry on the feature dashboard
Cookie Prefixes
Strict Secure Cookies

Joel Weinberger

unread,

Dec 11, 2015, 5:27:38 PM12/11/15

to Chris Harrelson, blink-dev, Mike West, Emily Stark

On Thu, Dec 10, 2015 at 8:53 PM Chris Harrelson <chri...@chromium.org> wrote:

On Tue, Dec 8, 2015 at 2:22 PM Joel Weinberger <j...@chromium.org> wrote:
Contact emails
j...@chromium.org, est...@chromium.org, mk...@chromium.org

Spec
https://tools.ietf.org/html/draft-west-cookie-prefixes
https://tools.ietf.org/html/draft-west-leave-secure-cookies-alone

Link to a tag review or a description about why the tag review process is being skipped.

Summary
Cookie prefixes place a set of restrictions upon the names which may be used for cookies with specific properties. In a nutshell: `__Secure-*` cookies have to have the `Secure` flag, and `__Host-*` cookies have to have `Path=/`, can't have `Domain`, and might require `Secure` (depending on the setter).

Strict secure cookies adds restrictions on cookies marked with the 'Secure' attribute. Currently, Secure cookies cannot be accessed by insecure (e.g. HTTP) origins. However, insecure origins can still add Secure cookies, delete them, or indirectly evict them. This feature modifies the cookie jar so that insecure origins cannot in any way touch Secure cookies. This does leave a carve out for cookie eviction, which still may cause the deletion of Secure cookies, but only after all non-Secure cookies are evicted.

Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
Yes.

Debuggability
Neither of these features changes anything about how cookies and networking are debuggable today.

Interoperability and Compatibility Risk
Describe the degree of interoperability and compatibility risk you believe this change poses. If this is a brand new feature, please characterize how much we might regret shipping this new feature because we might want to change or remove it in the future. If you don’t have a launch tracking bug or row in the feature dashboard, include in this email links to relevant specs, standards discussions, or documentation about support for the feature in other browsers. Please be thorough here if compatibility risk has changed since your intent to implement.

Prefixes presents very minimal compatibility risk. While technically adding these prefixes could interfere with already existing cookies, our metrics have seen no cookies with these prexfixes in the wild.
Strict secure cookies present a bit more of a risk as they change the behavior of already existing cookies. However, of cookies that are set, fewer than 00.02% are secure cookies set by an insecure scheme. Thus, while we do risk some compatibility issues, they seem likely to be minimal.

Does this mean that 0.02% of existing cookies currently set by insecure domains will now have changed (and broken I think) semantics? Or 0.002%?

That's just an extra zero at the start because I copied it from the UMA table. Sorry about that :-/

So, to be explicit, this means that of cookies that are set, 0.02% are cookies marked as Secure but are set by insecure origins. If you compare this only to Secure cookies (and not cookies in general) 0.2% of cookies marked Secure are set by insecure origins.

Yes, the semantics will be broken, but the semantics for these sites are already, at best, very weird because what this means is that 0.02% of cookies being set right now are cookies that cannot be ready by the origin than setting them.

Do you know of examples, or specific sites we could reach out to?

Unfortunately, I don't. We didn't collect RAPPOR stats, and even if we did, this number is low enough that I suspect we wouldn't get a large enough sample anyway.

Rick Byers

unread,

Dec 11, 2015, 5:32:23 PM12/11/15

to Joel Weinberger, Chris Harrelson, blink-dev, Mike West, Emily Stark

Yeah this sounds to me like it's worth trying (in a careful / staged way as you say) and looking for issues / feedback.

LGTM2

Chris Harrelson

unread,

Dec 11, 2015, 5:56:22 PM12/11/15

to Rick Byers, Joel Weinberger, blink-dev, Mike West, Emily Stark

LGTM3!!

Joel Weinberger

unread,

Dec 11, 2015, 5:57:26 PM12/11/15

to Chris Harrelson, Rick Byers, blink-dev, Mike West, Emily Stark

Cool, thanks you all. I'm just waiting on Chrome launch bug approval so that we can get the Finch trial up and running.

j...@google.com

unread,

Jan 25, 2017, 5:23:42 PM1/25/17

to blink-dev, chri...@chromium.org, rby...@chromium.org, mk...@chromium.org, est...@chromium.org

Hi everyone. We wanted to give a heads up that we're planning on rolling out Strict Secure Cookies to all of stable shortly (https://codereview.chromium.org/2633663003/). We've been rolling it out slowly over the last year, and while we've caught a few bugs and a few large users of secure cookies on insecure origins, we haven't seen any new issues crop up recently. The usage numbers have also remained pretty stable, around 0.02% of page loads. Please let me know if y

--Joel

Mike West

unread,

Jan 26, 2017, 2:28:25 AM1/26/17

to Joel Weinberger, blink-dev, Chris Harrelson, Rick Byers, Emily Stark

We're well-aligned with Firefox folks, who are shipping the same behavior in 52 (see https://bugzilla.mozilla.org/show_bug.cgi?id=976073). 58 is on more or less the same schedule, which is a happy coincidence. Shipping this behavior now still LGTM (from a non-OWNER's perspective).

-mike

Joe Medley

unread,

Jan 26, 2017, 3:15:43 PM1/26/17

to Joel Weinberger, blink-dev, Chris Harrelson, Rick Byers, Mike West, Emily Stark

On Wed, Jan 25, 2017 at 2:23 PM, jww via blink-dev <blin...@chromium.org> wrote:

e wanted to give a heads up that we're planning on rolling out Strict Secure Cookies to all of stable shortly

Do you have a version number? That's something DevRel might want to mention in one of its communications channels.

Joe Medley | Technical Writer, Chrome DevRel | jme...@google.com | 816-678-7195

If an API's not documented it doesn't exist.

Reply all

Reply to author

Forward