Mail should not set cookies

VERIFIED WORKSFORME

Status

()

Core
Networking: Cookies
VERIFIED WORKSFORME
18 years ago
14 years ago

People

(Reporter: Mitchell Stoltz (not reading bugmail), Assigned: (not reading, please use seth@sspitzer.org instead))

Tracking

Trunk
mozilla1.2alpha
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

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
(Reporter)

Comment 1

18 years ago
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

Comment 2

18 years ago
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
Last Resolved: 18 years ago
Resolution: --- → DUPLICATE

Comment 3

18 years ago
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.

Comment 4

18 years ago
Mitchell, this sounds different than 22994 to me too.  Please dupe it if I am 
wrong.  Re-opening
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---

Comment 5

18 years ago
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.
Blocks: 64833
(Reporter)

Comment 6

18 years ago
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

Updated

18 years ago
Target Milestone: --- → mozilla1.2

Updated

18 years ago
Keywords: mozilla0.9, mozilla1.0

Updated

18 years ago
Status: NEW → ASSIGNED

Updated

17 years ago
No longer blocks: 64833

Comment 7

16 years ago
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
mass re-assign.
Assignee: naving → sspitzer

Comment 10

15 years ago
-> 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?

Updated

14 years ago
Blocks: 187974

Comment 12

14 years ago
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. ;)

Comment 13

14 years ago
(by "cruft" i of course meant the
is-this-cookie-request-originating-from-mailnews detection cruft.)

Comment 14

14 years ago
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.

Comment 15

14 years ago
So, for the 1.7x milestones, the Pref UI is being removed, but default value
will still be:

network.cookie.disableCookieForMailNews == true.

And if I understand this correctly, this means ALL cookie access (Javascript
Cookies and HTTP cookies) will not work (receive and transmit).
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
Last Resolved: 18 years ago14 years ago
Resolution: --- → FIXED

Comment 17

14 years ago
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 → ---

Updated

14 years ago
Status: REOPENED → RESOLVED
Last Resolved: 14 years ago14 years ago
Resolution: --- → WORKSFORME

Comment 18

14 years ago
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)

Comment 20

14 years ago
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.