Tested the issue on chrome reported version 66.0.3359.139 using Mac 10.12.6 with steps mentioned below:
1)Launched chrome reported version and navigated to URL: HTTPS://http://fiddlerbook.com/test/cookie/LeaveSecureAlone.aspx and clicked on 'Add Secure Cookie'
2) Again navigated to HTTP://fiddlerbook.com/test/cookie/LeaveSecureAlone.aspx and clicked on 'Add Insecure Cookie'
3) Navigated to Developer Tools > Application tab > Cookies, able to see 'SetBy' cookie in the list

@Reporter: Please find the attached screencast for your reference and let us know if we missed anything in reproducing the issue, provide your feedback on it which help in further triaging it, if possible could you please provide screencast of the issue which help in better understanding.

Thanks!

Deleted: 843371.mp4 2.0 MB

	843371.mp4 2.0 MB View Download

The screencast is incorrect. I have attached a new one.

It shows that it is not possible to set an insecure cookie from the http page, and there is no message indicating why it fails.

Deleted: Kapture 2018-05-16 at 23.05.05.mp4 333 KB

	Kapture 2018-05-16 at 23.05.05.mp4 333 KB View Download

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

I think we actually record all "set" cookies in ChromeNetworkDelegate, before we've even sent them to the cookie store (Which is what detects and handles the conflicts).

I believe this issue is in all versions of Chrome from sometime since version 58.  This is major issues for enterprise customers that have sessions states shares across web apps of http and https.  Below are some links to RFCs that google is proposed.  If the intention is to not let chrome share cookies across sub domains of different https and http domains then this will be a major issue for enterprise customer.  A policy will need to be created (maybe a whitelist).  Many enterprise customer want to comply with https standard but enterprise applications and vendor may take years to migrate applications.

https://tools.ietf.org/html/rfc6265
 
https://tools.ietf.org/html/draft-ietf-httpbis-cookie-alone-01

Below is a description of the customer issue 

We've encountered issues with several internal applications because of how Chrome is handling a secure cookie set for a different subdomain.

Flow:
1. Navigate to https://wiki.enterprisecustomer.com/display * This is the root page for a vendor application called Confluence that contains wiki pages

2. The page will set a cookie with the following settings* Set-Cookie: JSESSIONID=AFB46649DF6903DE701DE0A1C0882B5D; Path=/; Secure; HttpOnly

3. The cookie has a domain of wiki.enterprisecustomer.com since no domain was specified

4. Open a new tab and navigate http://remp.enterprisecustomer.com/portal/ODocs* This is an internally developed member contact application

5. The page will set a cookie with the following settings* Set-Cookie: JSESSIONID=0001CZGBZwJkUopJYJ4_iGCwRD0:1camdvid9; Path=/; Domain=.usaa.com

6. Chrome will NOT set the cookie from step 5 which causes the application to break* The cookie set in step 2 will NOT be sent in the request since it was set for a different subdomain

Is this expected? If so then what should be changed to prevent the cookie conflict? This is going to be an ongoing problem for us since many applications require that cookie.

jeffej:  I assume both cookies are being sent using the same top-level domain.  We no longer allow insecure cookies to be set when their domain+path overlaps with a secure cookie.  See https://cs.chromium.org/chromium/src/net/cookies/cookie_monster.cc?q=cookie_monster&sq=package:chromium&g=0&l=1142

As per comment #8 this issue seems to be a Enterprise Applications.Hence forwarding this issue to In house Team to have a look on this issue and CCing jmukthavaram@chromium.org, kkaluri@chromium.org. 

Thanks.!

Able to reproduce the issue on Windows 10, Mac 10.13.4 and Debian Rodete with chrome Stable #66.0.3359.181, Canary #68.0.3438.3 and also on earlier version M60-#60.0.3073.0

This is a non-regression issue, hence marking it as Untriaged

Attaching the screen-cast for reference.

Deleted: 843371.mp4 2.6 MB

	843371.mp4 2.6 MB View Download

The breaking change has been implemented [1] in M-58. Off to enterprise triage to determine whether this needs a policy.

[1] https://chromium.googlesource.com/chromium/src/+/a26e439d02baa9514b09c637bf5fa9f6790c4c3e

Mike, do you know who could take a look at this?

Please keep me updated on this bug.  I have a few Enterprise browser customers that have this issue and is preventing there users from using internal http and https sites as session info does not pass because of this secure cookie setting.  Could an enterprise policy be define so that the secure flag can be overlooked for enterprise customers.  Customers effected USAA - 35K seats, Verizon 100K+ seats, I believe other customer experience this issue, but have their users just suffer with it.

I completely agree that we should have an error message here. I thought we landed one before the relevant engineer left the company, but that apparently didn't happen.

I'm less enthusiastic about adding an enterprise exception, as there are real security implications to allowing non-secure pages to overwrite the cookies of secure pages. Closing that hole was the entire point of the changes underway in https://tools.ietf.org/html/draft-ietf-httpbis-rfc6265bis. Happy to chat offline.

Mike, while the original post does highlight the issue it doesn't explain the way it impacts enterprises.

Here is a quick walkthrough of the problem:
1. Multiple applications are running under the test.com domain (internally developed and vendor applications).
2. Each major application is scoped to its own subdomain (ex: here.test.com and there.test.com).
3. An HTTPS vendor application running on here.test.com sets a secure cookie that is scoped specifically to that subdomain.
4. An HTTP application running on there.test.com attempts to set a non-secure cookie with a domain of .test.com.
5. The secure cookie set by the here.test.com application will prevent the unrelated non-secure cookie of the same name from being set.
6. This causes the second application to encounter issues until the secure cookie is removed from the cookie store.

Within the enterprise environment there are many applications that can step on each other in this way. Especially when dealing with legacy and vendor applications. It makes sense that this is a bug as it allows completely unrelated applications to step on each other's cookie stores just because they run under the same domain. Feel free to contact me to discuss further.

The workaround for me in the meantime is to vary the cookie name by the application name, and whether it is https or http.

E.g. `foo-app-https`, `foo-app-http`, `bar-app-https`.

Most devs will leave their framework-specific cookie names intact though, which causes the problem.

The silent-nature of the bug is a killer though. An error would help a lot.

vrouesnel:  I agree completely with you on that.  Was just having a conversation with another dev about exposing this information in DevTools, and filed a bug for it last week (https://crbug.com/856777).  Unfortunately, no timeline for it, but I think it should be pretty high priority.

This bug has an owner, thus, it's been triaged. Changing status to "assigned".

(Unassigning myself, marking untriaged in preparation to retriage with folks who will do a better job taking care of cookies than I've been able to)

**UI mass Triage**

Still able to reproduce the issue on all OS using latest canary-72.0.3617.0 as per C#0.As it is non reg issue , adding respective labels.
Thanks..!