Preference 'Disable cookies in Mail & Newsgroups' not honored

VERIFIED DUPLICATE of bug 22994

Status

MailNews Core
Security
VERIFIED DUPLICATE of bug 22994
16 years ago
10 years ago

People

(Reporter: FZiegler, Assigned: Darin Fisher)

Tracking

({testcase})

Trunk
testcase
Bug Flags:
blocking1.4b +

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [adt2], URL)

(Reporter)

Description

16 years ago
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.1b) Gecko/20020722
BuildID:    2002072203



Reproducible: Always
Steps to Reproduce:
1. Have cookies prefs set as follows:
   - Enable cookies from the originating web site only
   - Disable cookies in Mail & Newsgroups: YES
   - Ask me before storing a cookie: YES
2. Put the test mailbox of attachment 93412 [details] (bug 138125) 
   in `Local Folders'
3. View the message `Cassandra Wilson...' from that mailbox


Actual Results:  An alert `The site .bluenote.com wants to set a cookie' comes up.


Expected Results:  We shouldn't even be *talking about* that cookie!
(Reporter)

Updated

16 years ago
Depends on: 138125
(Reporter)

Updated

16 years ago
No longer depends on: 138125
Steve, this is the bug Darin and I found during the cookie review. For
first-party cookies naving checks that pFirstURL isn't one of the mailnews
schemes, but since that URL is gotten from the HTTP channel, and the mail
protocols aren't HTTP channels, the string is always blank and the cookies allowed.
Assignee: mstoltz → morse

Updated

16 years ago
QA Contact: junruh → tever

Comment 2

16 years ago
ok, I'll take a look. Is this just mac ?
I'll be updating my testcase next time I get a chance, sorry for missing this.

http://www.mozilla.org/quality/mailnews/tests/sea-mn-cookies.html
No, all platform.
http://lxr.mozilla.org/mozilla/source/extensions/cookie/nsCookies.cpp#1513

firstURL is only set if there's an nsIHTTPChannel, and that's not set for the
mail message itself, only images and whatnot you load from the mail. Might be as
simple as changing cookie_isFromMailNews(firstURL) to
(cookie_isFromMailNews(curURL) || cookie_isFromMailNews(firstURL)).
OS: MacOS X → All
Hardware: Macintosh → All
nominating for Buffy
Keywords: nsbeta1+
Whiteboard: [adt2]

Comment 6

16 years ago
try this:
1) set Mozilla to "dont accept cookies" in Mozilla Mail.
2) set Mozilla to "dont show remote images" in Mozilla Mail.
3) set Mozilla to show "original HTML"

now send a mail to browserspyhtmlmail@gemal.dk

Comment 7

16 years ago
reassigning
(Reporter)

Updated

16 years ago
Depends on: 22994

Comment 8

16 years ago
I meant to reassign this on 9-19 to naving but somehow I failed to do so. 
Reassigning for real this time.

It's more than just testing for cookie_isFromMailNews(curURL) as dveditz
suggested in comment 4.  When nsCookieService::SetCookieStringFromHttp is
called, firstURL is null and curURL has an http scheme.  Furthermore, on entry
to that routine, firstURL is tested for null and, if so, it is set equal to
curURL.  So by the time the call to cookie_isFromMailNews is called, both curURL
and firstURL are identical and have the http scheme.
Assignee: morse → naving
re-assigning nsbeta1+ bugs
Assignee: naving → sspitzer
[Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.3) Gecko/20030312]

Same case as Description, I think:

I get emails with

[
<script language=3D"JavaScript" type=3D"text/javascript" src=3D"http://uk.a=
dserver.yahoo.com/a?f=3D2123800143:HM&p=3Dfrclubs&l=3DHM&c=3Dfm&site-countr=
y=3Dfr&t=3D1047766564">
</script>
]

which generate

[
+++GET 67+++
GET /a?f=2123800143:HM&p=frclubs&l=HM&c=fm&site-country=fr&t=1047766564 HTTP/1.1
Host: uk.adserver.yahoo.com
User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.3) Gecko/20030312
Accept: */*
Accept-Language: fr-fr,fr;q=0.8,en-gb;q=0.7,en;q=0.5,es-es;q=0.3,es;q=0.2
Accept-Encoding: gzip,deflate,compress;q=0.9
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive

+++RESP 67+++
HTTP/1.1 200 OK
Date: Sun, 16 Mar 2003 17:15:31 GMT
Content-Type: application/x-javascript
Cache-Control: private
Connection: close
P3P: policyref="http://p3p.yahoo.com/w3c/p3p.xml", CP="CAO DSP COR CUR ADM DEV
TAI PSA PSD IVAi IVDi CONi TELo OTPi OUR DELi SAMi OTRi UNRi PUBi IND PHY ONL
UNI PUR FIN COM NAV INT DEM CNT STA POL HEA PRE GOV"
Set-Cookie: B=2d1ll64v79c9j&b=2&f=a; expires=Thu, 15 Apr 2010 20:00:00 GMT;
path=/; domain=.yahoo.com
Via: 1.0 becquerel (NetCache NetApp/5.3.1R2DEBUG12)
+++CLOSE 67+++
]

(I would suggest to change Severity from 'Normal' to 'Major'.)

Updated

15 years ago
QA Contact: tever → junruh
privacy, over to cavin.
Assignee: sspitzer → cavin
Flags: blocking1.4b?

Updated

15 years ago
Flags: blocking1.4b? → blocking1.4b+

Updated

15 years ago
QA Contact: junruh → esther

Comment 12

15 years ago
May be related to bug 22994. Over to Darin as he's looking into the issues. 
Assignee: cavin → darin
Re comment 12:

Right !
The current bug is a duplicate of bug 22994. (unless Darin says it is not.)
(Reporter)

Comment 14

15 years ago
Dependency on bug 22994 has been in the description ever since the latter went
from "verified fixed" to "reopened" (last September). I think it's fine that
way. The test case in comment 0 still works, so once Darin's patch for 22994 is
in, it'll be a breeze to check if it fixes this one as well.
Keywords: testcase
Re comment 14: (to summarize)

(I agree to leave the current bug open.)

Reopening of bug 22994 happened on 2002-09-15: see bug 22994 comment 160.
(see bug 168258 comment 3, for duplicate marking)

Bug 168258 description (= testcase) is duplicated in current bug comment 6.
(see bug 168258 comment 6, for URL update)

My comment 10 is yet another case (of 'Set-Cookie:' in the HTTP response):
SCRIPT use, no IMG SRC, no .CSS.
In comment 15, read "SCRIPT _SRC_ use".

Severity changed from 'normal' to 'major', to match bug 22994.
Severity: normal → major
(Assignee)

Comment 17

15 years ago
my patch for bug 22994 fixes this bug as well.  i'm going to mark this as a
duplicate since it is essentially the same problem just exercised in a slightly
different way.

*** This bug has been marked as a duplicate of 22994 ***
Severity: major → normal
Status: NEW → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → DUPLICATE
Summary: Pref to disable cookies in MailNews not honored → Preference 'Disable cookies in Mail & Newsgroups' not honored
(Reporter)

Comment 18

15 years ago
verified, now wfm in 1.4b; thanks darin
Status: RESOLVED → VERIFIED

Comment 19

15 years ago
did you really confirm this? on what build?

in my 20030512 build it's not working

try sending a mail to browserspy-htmlmail-adv@gemal.dk
and then read the mail that comes back
(Reporter)

Comment 20

15 years ago
Henrik: I tried in 1.4b (release), with same settings as in comment 0; no alert
came up, and according to cookie manager, no cookie was set.

Same when viewing your test mail (no alert, no cookie from gemal.dk), however
your diagnostic mail now says:

> You have recently read the BrowserSpy HTML mail test, and your
> mail client is not as safe as you think!
> 
> It was detected that:
> - you read my BrowserSpy HTML test mail!
> - you read it at Mon May 12 22:55:45 2003
> - your mail client is Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US;
rv:1.4b) Gecko/20030507
> - you were detected by an *stylesheet* (CSS) inside the mail
> 
> A spammer could use this to make sure that email address is a valid one!

Is this what you mean? (I can't test build 20030512, right now the latest for
Mac seems to be 20030509.)
(Reporter)

Comment 21

15 years ago
Note: going to http://gemal.dk/browserspy/htmlmail.cgi, I get

"If you read the HTML test mail this means that your mail client does not
support setting cookies - which is good."

(Meanwhile, a second diagnostic mail came saying "you were detected by an
*image* inside the mail", even though the test mail itself said "Image support
is not active - which is good".)

Comment 22

15 years ago
ahh... cookies are off! the stylesheet is still fecthed which is another bug.
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.