Just wanted to add that if the desired behavior is to remove pre-existing non-secure cookies, my view is that it should be done in step 3 above when the secure cookie is set for a path that would be 'shadowed' by the pre-existing non-secure cookie of the same name, not when a new attempt to set a non-secure cookie is done. Otherwise, attackers could try to exploit this by 'pre-empting' secure cookies by setting non-secure cookies for more specific paths with very long expiration dates before the legitimate secure cookie is set. 

Removing these upon creation of the secure cookie could perhaps mitigate this to some extent, although that assumes the server will always create the new secure cookie (which it may not do if the client already sends a cookie with the specific name, as the server can't see the difference between secure/non-secure cookies unless cookie prefixes are used with compliant browsers). 

I think Firefox's behavior is probably correct here. If we could reliably track that the non-secure cookie was set from a non-secure origin, it might be reasonable to apply the same kinds of restrictions to it when setting the secure cookie that we would if the order of operations was reversed. As is, we don't have that information, and can't distinguish between a non-secure cookie set by a secure origin (which is fine), and a non-secure cookies set by a non-secure origin (which isn't). If we could make that distinction, then clearing the cookie after #3 seems reasonable, but that's a bigger change.

Marking this as available; I'll try to get to it in M59.

True, makes sense if we don't have information whether a non-secure cookie was stored from a secure origin or not. Better to align with Firefox in this case.

Related issue: https://bugs.chromium.org/p/chromium/issues/detail?id=843371

If you have a secure cookie set by an https page, trying to set a non-secure cookie of the same name will fail silently, and you will not know that one exists unless you visit the page from https://localhost.

[mkwst]:  Any plans / actionable ideas here?

Assigning this to myself on behalf of chlily, who is looking into this.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/22707642b7cfdbcf8c8ce021959d8ea4b784bb02

commit 22707642b7cfdbcf8c8ce021959d8ea4b784bb02
Author: Lily Chen <chlily@chromium.org>
Date: Tue Oct 02 17:27:21 2018

Avoid deleting pre-existing cookie if secure cookie was skipped

This change avoids erroneously deleting an equivalent pre-existing
(insecure) cookie when attempting to add a new insecure cookie that
path-matches a pre-existing secure cookie. Previously, the pre-existing
insecure cookie would be deleted because it is equivalent to the new
cookie, even if a matching secure cookie was encountered and skipped.
This change adds a check that no secure cookie was skipped while
attempting to add the new cookie.

Bug:  703627 
Change-Id: I471f5887fecd84afc4b746ae78bb73fbf4449cdf
Reviewed-on: https://chromium-review.googlesource.com/1252866
Commit-Queue: Matt Menke <mmenke@chromium.org>
Reviewed-by: Matt Menke <mmenke@chromium.org>
Cr-Commit-Position: refs/heads/master@{#595890}
[modify] https://crrev.com/22707642b7cfdbcf8c8ce021959d8ea4b784bb02/net/cookies/cookie_monster.cc
[modify] https://crrev.com/22707642b7cfdbcf8c8ce021959d8ea4b784bb02/net/cookies/cookie_monster_netlog_params.cc
[modify] https://crrev.com/22707642b7cfdbcf8c8ce021959d8ea4b784bb02/net/cookies/cookie_monster_netlog_params.h
[modify] https://crrev.com/22707642b7cfdbcf8c8ce021959d8ea4b784bb02/net/cookies/cookie_monster_unittest.cc
[modify] https://crrev.com/22707642b7cfdbcf8c8ce021959d8ea4b784bb02/net/log/net_log_event_type_list.h