56545 - mozilla allows cookie for the whole .com.br

Status: RESOLVED DUPLICATE of bug 8743

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

Description

[Cesar Eduardo Barros]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.0-test9-pre1 i686; en-US; m18)
Gecko/20001009
BuildID:    2000100908

Mozilla seems to allow a site to set a cookie which applies to the whole .com.br
domain, instead of ignoring the cookie.

Reproducible: Always
Steps to Reproduce:
1. Enable confirmation of cookie requests and set it to allow from the
originating server only
2. Open the page

Actual Results:  Mozilla asked if I wanted to set a cookie for the whole .com.br
domain. If I agree, it sets a RMID cookie for the whole .com.br second level domain.

Expected Results:  Ignored the cookie (not even bringing up the confirmation
dialog), possibly saying in some way (a popup or a funny yellow or red icon)
that the site was using a invalid HTTP header. Crashing before setting the
cookie might be acceptable too =)

Comment 1

[Stephen P. Morse]

Unfortunately there is no way that this bug can ever be fixed.  See discussion 
in bug 8743.

Comment 2

[Cesar Eduardo Barros]

Nope, I disagree.

You can always:

a) Strictly follow the "Enable cookies for originating site only" and disallow
any domain-level cookies
b) Creatively follow the "Enable cookies for originating site only" and allow
all kind of wierd cookied, BUT store the server that sent them in the cookies
database and ONLY send them to the originating site.

I'm not concerned about privacy nonsense. I'm concerned about bandwidth wastage.
If every freaking domain decided to do so for .com.br, a http request would take
minutes.

Besides, I believe legitimate sites seldom (if ever) use a cookie which should
be sent to another server (if I get a cookie from bugzilla.mozilla.org, it'll
probably be used again only in bugzilla.mozilla.org).

Comment 3

[Stephen P. Morse]

a) We can't disallow domain-level cookies.  It's part of the cookie spec and 
many sites utilize it.

b) We can't change the cookie database without losing backwards compatibility.

Comment 4

[Cesar Eduardo Barros]

Aw, of course you can!

Make a cooksite.txt and record THERE which cookie is from which site.

You lost no backwards compatibility (since the other two files are still there,
and in the same format, and with the same information as before).

Comment 5

[Stephen P. Morse]

OK, I stand corrected.  We can modify the cookie database in the manner you 
described and still maintain backwards compatibility (I should have realized 
that since I'm the one who introduced cookperm.txt for that very reason).

But what you are proposing (in b) is a change in cookie semantics and you run 
the risk of breaking legitimate web-sites.  Many well-intentioned websites do 
very strange things with cookies.  Take a look at all the trouble we ran into 
with yahoo mail when we tried to improve upon the situation (gory details given 
in bug 8743).

In fact, from experience I would have to disagree with the following statement 
that you made:

   "I believe legitimate sites seldom (if ever) use a cookie which should
   be sent to another server"

Comment 6

[Cesar Eduardo Barros]

OK, I understand now... At least make this a dupe of 8743 then.

Comment 7

[Stephen P. Morse]

Making dup as requested by reporter.

Comment 8

[Stephen P. Morse]

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