480779 - ".foo.com" entry in cookies exceptions list does not have option to expand to all of "foo.com"

Status: VERIFIED WONTFIX

(Camino Graveyard :: Preferences, defect)

Description

[Chris Lawson (gone)]

Core treats ".foo.com" and "foo.com" as different entries for cookies permissions. ".foo.com" is more specific (though I'm not clear exactly what ".foo.com" means).

STR: Control-click on a ".foo.com" entry in your cookies exceptions list.

ER: Have the option to expand that entry to all of "foo.com".

AR: No option to expand to all of "foo.com", only all of "com", which is far too broad to be useful.

Comment 1

[Chris Lawson (gone)]

BTW, I noticed this because I had an entry for ".freep.com" in my Deny list,
but cookies from "freep.com" were still being allowed through. I guess this is
a Core bug if they're not supposed to be treated differently, although I still
think we shouldn't be ignoring that leading dot in expanding exceptions.

STR the freep cookies:

1) Visit http://www.freep.com/article/20090228/SPORTS05/90228038
2) Open cookies list and filter on "freep".
3) Choose one of the ".freep.com" cookies and "Remove and block".

Subsequent visits to the article will still allow all those cookies, despite
the ".freep.com" entry in the Deny list. If the entry in the Deny list is
"freep.com", all freep.com cookies are correctly blocked.

Comment 2

[Chris Lawson (gone)]

Just talked with dwitte and he confirmed what Smokey and I thought:

.foo.com cookies can be read by bar.foo.com, baz.foo.com, or foo.com hosts.

foo.com cookies can *only* be read by the host "foo.com".

So what Core is doing is right, and we shouldn't be ignoring the leading dot when expanding the exceptions.

(Also, according to dwitte, we shouldn't even be writing leading dots to the permissions back-end in the first place. I'm going to file another bug on that here in a minute.)

Comment 3

[Chris Lawson (gone)]

(In reply to comment #2)
> (Also, according to dwitte, we shouldn't even be writing leading dots to the
> permissions back-end in the first place. I'm going to file another bug on that
> here in a minute.)

That would be bug 480892.

Comment 4

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Bug 480892 essentially makes this obsolete, since we'll no longer write invalid ".foo.tld" exceptions.  

Users can get the right exception for a ".foo.tld" cookie right now by selecting it in the cookies list and doing Block (or Add, and changing the value in the Exceptions sheet), and once the patch in bug 480892 lands, users will be able to use "Remove and Block" to get the proper exception, too.

I don't think we should expend any effort to make the Exceptions sheet know how to expand ".foo.tld" to "foo.tld"; any additional effort would be better spent writing code that does a one-time fixup of all ".foo.tld" exceptions (and even that might effort we shouldn't expend).

I think the proper resolution of this bug is "WONTFIX after bug 480892 lands."

Comment 5

[Chris Lawson (gone)]

(In reply to comment #4)
> I think the proper resolution of this bug is "WONTFIX after bug 480892 lands."

I'm OK with that.

I'm not sure cleanup code is really worth it on our own; it might be worth looking into for bug 480891, though.

Comment 6

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Bug 480892 has landed; WONTFIX here per previous comments.