It is possible an email message to set a cookie which may lead to privacy compromise. The cookie manager catches it but I don't like the idea spammers to share information thru cookies in mailbox. The JS code in an email message is: -------------------------- document.cookie="spam=true; expires=Tuesday, 01-Apr-2004 08:00:00 GMT"; --------------------------- Georgi Guninski
I agree with Georgi on this; if there's no marketing requirement for this feature, then the setting of cookies by mail messages should be disabled by default.
Status: NEW → ASSIGNED
This is a dup of bug 22994 in which the topic was discussed as naseau. Setting the pref to reject third-party cookies will block mail messages from setting cookies. The suggestion of making that setting the default was discussed and vetoed in bug 22994. *** This bug has been marked as a duplicate of 22994 ***
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution: --- → DUPLICATE
I don't think this is a duplicate of 22994. Bug 22994 is about images and iframes in mail messages being able to set cookies for the sites the images and iframes come from; this bug is about messages being able to set cookies that are readable by other messages.
Mitchell, this sounds different than 22994 to me too. Please dupe it if I am wrong. Re-opening
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
There should be a way to enable/disable cookie setting from a top-level window perspective. Then, each mail window that's created could just disable cookies.
Apparently this bug is an embedding requirement. I was holding it open until we resolved whether or not mail should be allowed to set cookies, but it looks like embedding needs to be able to configure it this way. Reassigning to morse who owns the cookie management code.
Assignee: mstoltz → morse
Status: REOPENED → NEW
I still think that this is a dup of bug 22994. But in any case, I'm assigning this to naving since he fixed that other bug.
Assignee: morse → naving
Status: ASSIGNED → NEW
We've implemented this, and a couple (maybe just one, singular) of bugs remain.
QA Contact: tever → stephend
Assignee: naving → sspitzer
-> QA to me. (is stephend still working on mailnews?)
QA Contact: stephend → benc
We have this disabled by default now, and the UI is hidden as of 1.7. When sspitzer gave moa to remove the pref from the UI, he said he felt we should keep the pref. Removing the pref doesn't fit in with the sustained development path for Seamonkey, so I think we should just WONTFIX the remaining bit of this bug and move on. dwitte?
agreed. in addition, for a dedicated mail app like tbird, it can avoid building all the seamonkey-specific features in extensions/cookie, and just put the "disable cookies" pref in all.js - much more sane than the cruft we use in seamonkey's nsCookiePermission impl. ;)
(by "cruft" i of course meant the is-this-cookie-request-originating-from-mailnews detection cruft.)
Uhm.. isn't this bug fixed? BTW: there is talk of allowing cookies in the forumzilla extension (or possibly other extensions), so tbird might actually want cookies support in the future... still disabled by default for mail.
taken in the "Mail should not set cookies" sense this is pretty much as fixed as it will ever be. There's probably some improvements in what we're using to define as "mail" but that's separate from this bug. Marking FIXED.
No longer blocks: 187974
Status: NEW → RESOLVED
Closed: 19 years ago → 15 years ago
Resolution: --- → FIXED
No bug/patch referenced that changed the behaviour. (Comment 11 and comment 15 both point to things that have now changed - but don't say how/why.) ->WORKSFORME
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Status: REOPENED → RESOLVED
Closed: 15 years ago → 15 years ago
Resolution: --- → WORKSFORME
V: 1.7b, all plats. I'll add the cookie mail pref to the networking prefs docs.
Status: RESOLVED → VERIFIED
http://www.mozilla.org/projects/netlib/cookies/cookie-prefs.html already has all of the current cookie prefs documented (that I'm aware of, of course)
Can you look at: http://www.mozilla.org/quality/networking/docs/netprefs.html My inclination (without having the time to look at the two pages right now), would be to delete the cookies section from that document, and link to yours.
yeah, mine doesn't have the UI part, but its more embeddor-friendly that way, and eventually there should be more docs on cookie stuff
You need to log in before you can comment on or make changes to this bug.