317229 - apply cookie exceptions using cookie domain, not originating host

Status: RESOLVED INVALID

(Core :: Networking: Cookies, defect, P3)

Description

[Dan Mellem]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20051029 SeaMonkey/1.1a Mnenhy/0.7.2.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20051029 SeaMonkey/1.1a

If cookies are disabled by default but a host in a "lower" child domain (e.g., host.example.domain.com) permits cookies, they are permitted for the higher domain name (e.g., example.domain.com).


Reproducible: Always

Steps to Reproduce:
1. Start in a new profile, or remove all cookies and sites
2. Select "Block all cookies"
3. Go to URL above. Cookies will be blocked.
4. Enable cookies for this site (ecomm.dell.com)
5. Reload page and view stored cookies
...continuing...
6. Clear all cookies
7. Explicitly block cookies from "dell.com"
8. Reload page and view stored cookies
(same results)
Actual Results:  
Cookies for the parent domain are permitted. This occurs at both steps 5 and 8.

Expected Results:  
There should have only been cookies for the one site that is permitted (and perhaps its child domains [debatable]).

Confirmed in SeaMonkey 1.1a build 2005102909 and Firefox 1.5 build 20051107.

Comment 1

[Ria Klaassen (not reading all bugmail)]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20051120 Firefox/1.6a1 ID:2005112006

WFM. If I first delete the domain in the allowed cookies list and then add it again as a blocked cookie.

Comment 2

[Dan Mellem]

This was in a brand new profile and there were no domains listed in the allowed list initially.

I've confirmed it with Firefox 1.6a1 build 20051120 (and on a different machine).

Comment 3

[Ria Klaassen (not reading all bugmail)]

Did the same steps to reproduce carefully - same result: empty cookies list.

Comment 4

[Dan Mellem]

I can send you an animation of what I'm seeing if that's helpful.

Comment 5

[Dan Mellem]

BTW, this isn't about blocking a particular cookie. It's setting the default to block cookies but then allowing certain sites. The setting is under Edit/Preferences.../Privacy & Security/Cookies/Cookie Acceptance Policy/Block cookies. The window Cookie Manager/Cookie Sites should only have a single "site can set cookies" in it, with no "site cannot set cookies" listed.

Comment 6

[Mike Connor [:mconnor]]

That doesn't make sense.  This bug, as reported, has nothing to do with UI, its a core issue, assuming it exists, but I can't reproduce.

Comment 7

[Darin Fisher]

-> default owner

Comment 8

[Dan Mellem]

Attachment: Dialog boxes showing cookies and settings.

I just tried it again with SeaMonkey build 2006041308 and it's still happening. I'll attach a picture of what I'm seeing. Notice that there's six "dell.com" cookies even though only "ecomm.dell.com" can set cookies for itself. Perhaps it's just checking if the particular hostname is trusted and, if so, all cookies are permitted?

Comment 9

[[e-mail]]

"sites that can set cookies" refers to the site trying to set the cookie, not the domain it actually sets the cookie for. (ecomm.dell.com can set a domain cookie for dell.com, which you're seeing in the cookie manager.) so, this is technically invalid.

Comment 10

[Dan Mellem]

I disagree this is invalid. While it is common to allow host1.domain.com to be able to set .domain.com cookies, it shouldn't allow it if .domain.com is blocked (step 6 above).

Another example is the CNET domain "com.com". They have host1.com.com and host2.com.com that are completely unrelated. I should be able to block "com.com" as if it where a TLD. 

I'm reopening this for now. It sounds like the logic may be a little off it the "sites that can set cookies" only looks at the current hostname. If you can point to something that says this is the expected behavior, feel free to mark it invalid again or change it to an RFE.

Comment 12

[[e-mail]]

updating summary to more closely reflect bug.

Comment 14

[T. Bug Reporter]

So, the way I'm reading this (and the duplicate Bug 389055 that I filed), it boils down to a difference of opinion over exactly what "Blocked" means.  If I follow, you're saying in Comment #9 that Firefox's current interpretation of "Blocked" (or "Allow for session", which in essence means "Blocked from being saved beyond this session") is "Don't allow this site to SET cookies - regardless of which site they're being set FOR"; whereas the common sense end user interpretation of "Blocked" is more like "Don't allow this site to HAVE cookies - regardless of which site they're being set FROM".

Does that sound right?

Comment 15

[[e-mail]]

(In reply to comment #14)
> Does that sound right?

pretty much. note that there's a bug on using the base domain of the host for doing this, which is one way of solving the problem - see bug 407929.

Comment 16

[Firefox Bug Husbandry Bot]

Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258

Comment 17

[Firefox Bug Husbandry Bot]

Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258

Comment 18

[Andrea Marchesini [:baku]]

I mark this bug as invalid because we have changed the cookie policy and how we delete cookies during the data-sanitization project.