Have you verified this actually works?  CookieMosnter checks the scheme a cookie is set with (https://cs.chromium.org/chromium/src/net/cookies/cookie_monster.cc?type=cs&sq=package:chromium&g=0&l=723).

A compromised renderer could lie about the URL, but I believe in the normal case, these cookies should be blocked.

I opened cookie.html in Chrome and a short time later (or after closing chrome) a row with name=filescheme and path=/path/to/my/desktop appears in the "Cookies" db in the "cookies" table. 

The call to SetCanonicalCookie doesn't come from SetCookieWithOptions, so the check is not applied: 

#1 0x7fa2f0f5e69c net::CookieMonster::SetCanonicalCookie()
#2 0x7fa2f0f6693c _ZN4base8internal7InvokerINS0_9BindStateIMN3net13CookieMonsterEFvNSt3__110unique_ptrINS3_15CanonicalCookieENS5_14default_deleteIS7_EEEEbbNS_12OnceCallbackIFvbEEEEJNS0_17UnretainedWrapperIS4_EESA_bbSD_EEEFvvEE7RunOnceEPNS0_13BindStateBaseE
#3 0x7fa2f0f5e1c7 net::CookieMonster::DoCookieCallbackForHostOrDomain()
#4 0x7fa2f0f5e00e net::CookieMonster::SetCanonicalCookieAsync()
#5 0x7fa2ef89a975 content::RenderFrameMessageFilter::SetCookie()
#6 0x7fa2ef3795f8 content::mojom::RenderFrameMessageFilterStubDispatch::AcceptWithResponder()

Deleted: cookie.html 132 bytes

cookie.html 132 bytes View Download

So this is likely a regression from switching to the new mojo cookie API.  :(

Upping priority.  Tossing in the security tag, just in case, since file URLs doing weird things has been considered a security issue in the past.

Hmm, do we ever render HTML pages on other schemas, like ftp:// or something? That setting a cookie and having it affect HTTP seems... undesirable.

This feels annoying to fix, too, since doesn't CanonicalCookie basically have its schema dropped?

We for for file, chrome-extension, and chrome, at least.  We used to for FTP, but I don't think we do any more (We do use locally assembled HTML using strings from a remote source, though, and there could be flaws in that logic).

And yes, CanonicalCookie has its origin dropped, in favor of just a host.  We could include the URL in the mojo interface, and at least verify it's sane.  Doesn't help with compromised renderer, but that was the status quo, anyways.

WRT to compromised renderers, can't RestrictedCookieManager enforce that? 
It actually seems to already:
https://cs.chromium.org/chromium/src/services/network/restricted_cookie_manager.cc?rcl=9772c3d2020f85c9eae62ab86d793be661dd5f83&l=188

I don't know the new path - in the old path, we only restricted cookie access from extensions, I believe.

Just to check: this isn't a WebView issue, right? It's just that WebView expects file cookies to work, so just disabling them entirely isn't an option?

Just making sure we aren't needed to do something here :)

Please re-add Mobile>WebView if WebView needs to do anything.

Yes, WebView is only somewhat related because it requires file cookies to work sometimes. The bug affects Chrome when file cookies shouldn't work.

Confirmed on Chrome canary 70.

The cookie does show up in the Cookies DB after getting set via document.cookie. However, it can be deleted by removing cookies from the empty origin using chrome://settings/siteData?search=content. I agree that the behavior is quirky, but I'm not sure why this is a P1.

mmenke@: Why do you think this is a P1?

It fundamentally seems unsafe - it's a sidechannel to allow pages running in file scope to set externally available cookies.  What else can access cookies without hosts?  Extensions do, too, I believe.  They only have access to a separate cookie store, but add in another bug where they have access to the main one somehow, and if you can trick someone into running a file URL, you can effectively extend the permissions of extensions.

While this bug alone doesn't seem to be a major issue, it seems to me like the sort of bug that can potentially be chained into something more concerning.