199883 - Cookie Manager does not respect blocked cookie sites

Status: RESOLVED FIXED

(Core :: Networking: Cookies, defect)

Description

[Navid]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4a) Gecko/20030329
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4a) Gecko/20030329

After the Cookie P3P code was checked in, I tried the "Enable Cookies Based on
Privacy Settings Option."  I did then went back to my old method of restricting
cookies of having the radio button on "Enable all cookies" and having a large
list of sites on the Blocked Cookie list.

However now, if I open Cookie Manager, there are cookies that come from a server
which is on my blocked cookie list.  If I remove them, and select "Don't allow
sites that set removed cookies to set future cookies" and revisit the site, the
cookies are still reset.

Reproducible: Always

Steps to Reproduce:
Not sure if this will work for everyone, but it does for me.

1.  Select Enable Cookies Based on Privacy Settings Option in Prefences
2.  Go to cnn.com
3.  Select Enable all cookies in Preferences
4.  Go to cnn.com
5.  Open cookie manager
6.  Select all cookies from cnn.com
7.  Check the "Don't allow sites that set removed cookies to set future cookies"
options
8.  Remove the Cookies
9.  Close the cookie manager
10.  Revisit cnn.com
11.  Open the cookie manager
Actual Results:  
cnn.com has set cookies

Expected Results:  
cnn.com should not have set cookies

Comment 1

[Michiel van Leeuwen (email: mvl+moz@)]

> 3.  Select Enable all cookies in Preferences

So you tell mozilla to accept all cookies. After that, it doesn't use the
permission list anymore. Bug 184059 requests that to change. I am marking this
as a duplicate for now. Please reopen if you think I am wrong. Thanks.

*** This bug has been marked as a duplicate of 184059 ***

Comment 2

[Michiel van Leeuwen (email: mvl+moz@)]

Sorry, this is not a dup.
When testing for blocked cookies, we check the url where the cookie comes from
(www.cnn.com). But when deleting cookies, with the checkbox to block them
checked, the domain attribute of the cookie is added to the list (cnn.com). So
cookies from www.cnn.com are not blocked.
The old situation was to check for the domain attribute when testing for blocking.

Comment 3

[[e-mail]]

confirming, reassigning

Comment 4

[[e-mail]]

yup, this is a "problem" with the new permissions code - I'm not going to call
it a regression, because I think our new behavior makes more sense.

so previously, we used the cookie host to both check the permissions list, and
add the blocking entry - so there was no problem looking them up; they matched.
our new behavior, as mvl says, is to check against the host URI that set the
cookie, which is often not the same as the cookie host.

i think the change to using the URI instead of cookie host makes sense; when a
user wants to block a cookie from a site, they would probably expect all cookies
from that _site_ to be blocked, not all cookies from the host field in the
cookie itself. the entity that sets the cookie and the sites that cookie is
available to are not the same, and the former should be the one we use for
blocking purposes.

so we have two ways to fix this:

1) change our behavior back. this is actually messy to do now, after the
rewrite, because of the way we do the lookups; and i don't think it's a "good
thing" for the reasons above.

2) implement domain-walking for cookies (bug 176950). i think this is the most
sensible option. currently we domain-walk when checking permissions for popups;
e.g. www.cnn.com results in two lookups: www.cnn.com and cnn.com. we do not do
this for cookies and images, just to stay consistent with old behavior;
hopefully we'll fix this soon.

bug 176950 already has 'major' severity; that seems fitting given the current
breakage we're seeing in this bug.

Comment 5

[[e-mail]]

ah, a couple extra notes:

2) actually it's three lookups, www.cnn.com, cnn.com and com

note that, if we go with option 2, the "Don't allow removed cookies to be
reaccepted later" feature label in the cookie manager won't be entirely
descriptive anymore - using that feature will add a permission entry for e.g.
cnn.com, which will now block all cookies from cnn.com _and_ its subdomains.
however, it wasn't descriptive of the old behavior either - we'd block all
cookies from cnn.com, not just _that_ cookie. so perhaps we should rename this
feature at some point, but it's not urgent right now.

Once we decide what to do here, we can open a separate bug for the name change.

Comment 6

[Jerry Baker]

My problem is that I have "Enable cookies from the originating Web site only"
ticked, and I still get cookies accepted from doubleclick.net, etc. without
visiting their site. In addition to that doubleclick.net is in my list of banned
cookie sites. Something is awry.

Comment 7

[[e-mail]]

*** Bug 199903 has been marked as a duplicate of this bug. ***

Comment 8

[OstGote!]

For me it's the same as in comment 6. I would call it a big regression, because
now the Cookie Manager and the pref "Enable cookies from the originating Web
site only" are both useless for me. I got all the ad cookies. I was very
surprised when I noticed that today and looked for a bug. 

Although I set network.cookie.cookieBehavior to 1 (= dontAcceptForeign), it
seems to me that Moz uses the value 3 (= P3P) with the default 'medium' setting
for level of privacy (network.cookie.p3plevel = 1). I never used the P3P option.

Comment 9

[[e-mail]]

yes; we're aware it's a big regression, and we have a bug open to fix it.

with regard to your second comment: if you're seeing strange behavior with
'reject foreign cookies', please file a separate bug on that, with details on
the symptoms that make it appear to be using P3P settings. there's been a lot of
work on cookies, permissions, and p3p recently, so any info you can provide on
possible regressions would be helpful.

Comment 10

[[e-mail]]

fixed-on-trunk @ 0524 per bug 176950.

Comment 11

[[e-mail]]

*** Bug 204792 has been marked as a duplicate of this bug. ***