As a result of some (mostly) wild goose chases debugging for http://codereview.chromium.org/2898953008 I've realized that cookies created with non-canonical schemes (anything other than file:, filesystem:, http:, https:, mailto:, ftp:, ws:, wss:, http-so:,https-so:; see DoCanonicalize in url/url_util.cc) from URLs without an explicit "domain" field won't have a Domain() field (everything after the // is put in the path), and as a result will all be stored using the same, null, key in the cookie monster.  

This has performance implications for storage and lookup of chrome-extensions: cookies (though I don't think that's particularly important), and *might* have security implications.  I did a nihinihi manual test by inspecting the backing pages of a couple of extensions I have running (no cookies set in document.cookie), and set cookies in one and did not see it in others.  So the obvious pathway for leakage between extensions doesn't seem to work; presumably there's some path based filter on it.  But I don't have the depth of understanding of the "extensions cookies" path to be sure that there isn't a problem here.  

I'm filing this bug to track digging down to the floor on this one, but will not be pursuing it with high priority.  If someone wants to take it from me, feel free.  I'll remove the security permission when I've either decided there's no chance of leakage of cookie values between extensions or gotten a security review :-}.