Closed Bug 228396 Opened 21 years ago Closed 21 years ago

Whitelisted cookies ignore "current session" preference

Categories

(Core :: Networking: Cookies, defect)

Product:
Core
Component:
Networking: Cookies
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
RESOLVED WONTFIX
Milestone:
mozilla1.7alpha

People

(Reporter: unglorious, Assigned: darin.moz)

References

Details

(Keywords: relnote)

Attachments

(2 files, 1 obsolete file)

Change what rememberDecision does to the whitelist
896 bytes, patch
Details | Diff | Splinter Review
restore whitelisted sites' adherence to cookie lifetime prefs
1.24 KB, patch
Details | Diff | Splinter Review 
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6b) Gecko/20031021
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6b) Gecko/20031021

A change in cookie expiration behavior with the latest CVS update (previous
being unknown time in distant past (a few weeks)).  I have my preference set to
limit all cookies to the session.  Now cookies with expiration dates are saved
against my preference.  Seems like the expiration date used to get clobbered
with end-of-session, this is not happening now, as seen when viewing through the
Cookie Manager.

Reproducible: Always

Steps to Reproduce:
1. Set preference to Limit maximum lifetime...->current session
2. Visit any site that uses persistent cookies.  bugzilla.mozilla.org is as good
as any
3. Bring up Cookie Manager.  Observe expiration dates on persistent cookies
4. Quit.
5. Look at cookies.txt.  There are cookies.  Shouldn't be.

Actual Results:  
Cookies not deleted.

Expected Results:  
Cookies deleted.

I searched for previous reports of this problem and found none.  Closest match
related to those who wanted persistent cookies.
Here's what's in prefs.js related to network.cookie:

user_pref("network.cookie.cookieBehavior", 1);
user_pref("network.cookie.enableForCurrentSessionOnly", true);
user_pref("network.cookie.enableForOriginatingWebsiteOnly", true);
user_pref("network.cookie.lifetime.days", 0);
user_pref("network.cookie.lifetime.enabled", true);
user_pref("network.cookie.p3p", "drdrdrdr");
user_pref("network.cookie.p3plevel", 3);
user_pref("network.cookie.warnAboutCookies", true);

you're missing the network.cookie.lifetime.behavior pref. mozilla uses that to
determine whether to limit lifetime to the current session, or to a set number
of days.

is this seamonkey or firebird?
lifetime.behavior isn't being written to prefs.js
If I add it by hand before starting mozilla it will be removed when mozilla
overwrites the file.
If I uncheck the UI box, the other lifetime entries dissapear from prefs.js as well.

Don't know how to answer question 2.
Cookie preferences are not remembered at all in Mozilla 1.6b (Windows XP)!

Open Preferences / Privacy & Security / Cookies: Only flag set is "Enable all
cookies".

Set "Disable cookies in Mail & Newsgroups",
    "Limit maximum lifetime of cookies to",
        "current session",
Press OK.

Open Preferences / Privacy & Security / Cookies: Only flag set is "Enable all
cookies".
Nominating as blocking1.6, as this is a serious privacy violation: global cookie
restrictions set by the user are cleared behind his back.
Flags: blocking1.6?
Oliver: Not setting cookie preferences is a known, fixed bug. (bug 227612)
dwitte, do you have any idea why this pref is being not written or overwritten
for this user? Is it working for others?
so should this be marked a dup of
http://bugzilla.mozilla.org/show_bug.cgi?id=227612 ?
depends of if the reporter (ungloriuos) can still reproduce this with a current
build.
ok. here is what I see now.

created a new profile
ran http://mecha.mozilla.org/buster/test_url_25.html
to generate some cookies

quit
restarted and see that the cookies did persist across sessions
edit |preferences |privacy &security|cookies -> limit max life to current session
quit

restart
it appears some cookies were removed, but other persist from the last session.

if I edit |preferences |privacy &security|cookies
  manage stored cookies | remove all cookies

then all cookies from the older session are remooved
and none will persist across future sessions...

not completely what might be expected but there is a way to make this work.
the combination of 

edit |preferences |privacy &security|cookies
  manage stored cookies | remove all cookies

and

edit |preferences |privacy &security|cookies -> limit max life to current session

should provide the users to keep all cookies from persisting across sessions.

we should maybe change the "max life to current session" setting to
automatically clear all cookies automatically, but I think we can do that for 1.7...

going to set 1.6- on this one.  renominate if anyone sees different behavior or
thinks we still have serious problems..



will provide the
Flags: blocking1.6? → blocking1.6-
Unglorious, can you test with builds around the time you noticed the regression
to narrow down the window of changes? Older builds can be found in the dated
directories at http://archive.mozilla.org/pub/mozilla/nightly/
just wondering if edit |preferences |privacy &security|cookies -> limit max life
to current session should also clear all the older cookies... or if it ever did
that in the past

if someone has 1.4 or 1.5 builds handy I wonder if they can run the same test
shown in comment 10 and post results
seems like the same problem exists in 1.4 and 1.5.

dwitte: if you have an opportunity to look into this that would be great.  thx!
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Target Milestone: --- → mozilla1.7alpha
The question seems to be:

Should setting the "cookie maximum lifetime" preference also affect (delete or
modify) cookies already stored?

I remember clearly that this has not been the case for at least a year, because
for as long as I can remember, I have used this as a feature(!):  In random
surfing, I do not want persistent cookies, so the "limit lifetime to session"
option is on.  However, for two sites I visit frequently, I like the auto-login
feature that persistent cookies give me, so about once a year I do the
following: disable the "limit lifetime" option, log on to the two sites (so I
get the persistent cookies), enable the "limit lifetime" option again.  So the
only persistent cookies in my cookie store are from these two sites I trust.

If setting the "limit lifetime" preference would clobber cookies already stored,
this neat little trick would not work any more.
The current session lifetime appears to be ignored only when cookies are always
permitted from a site, e.g. by adding a site through cookie manager, or tools |
cookies | allow, or 'use my choice for all ...'

Session persistence _is_ enforced 
1. when the site is not among those approved to set cookies
2. for the first cookie from an site being approved

This is occurring with a 1.6 branch build as well as recent trunk CVS pulls.

1.5 and earlier do enforce session persistence for 'approved sites.'

0. be sure cnn.com isn't approved to set cookies, and "ask me before storing..."
is set (cookie prefs)
1. Visit http://www.cnn.com.  I'm being given adsPopup0 which expires tomorrow.
 Allowing this cookie with "Use my choice for all ..."
2. Cookie Manager indicates two cookies were set by cnn.com: adsPopup0 which
expires end of session, and CNNid, which expires August of 2010.
3. Quit and restart.  CNNid persisted.
4. Get rid of the CNNid cookie through cookie manager, and remove www.cnn.com
from the 'sites that can set cookies.'
5. Go back to cnn.com, and accept each of the two cookies, being sure "Use my
choice ..." is not checked.  In the notification dialog, adsPopup0 is indicated
as expiring tomorrow, and CNNid is August 2010.
6.  Cookie manager says these are both session cookies.
7. Quit and restart.  Neither cookie should be found.

Setting 1.7's "Allow session cookies" (tools | cookie manager) for a site still
issues notification for persistent cookies, and behavior related to checking the
box to 'Use my choice...' is as 1.6.
jon: that is somewhat by design. The cookie manager (and the tools->cookie menu)
override the prefs. But in recent build you can set domains to only allow sesion
cookies, while the pref is to block everything for example. However, you can't
set max life time when you overrule the pref with an entry in the cookie manager.

But back to the bug: The maximum lifetime pref has never changed existing
cookies. I think it shouldn't do that, because there is an exsy workaround: just
delete all you cookies before you exit, after you changed the pref. If that
would happen automaticly, you can't do the reverse: store some long time cookies
(logins for some sites for example) and make all cookies session cookies after that.
We could make the UI clearer, bij adding a dialog (ewww...), a tooltip or some
explanatory text stating that you should manually remove all the current cookies.
There may be two possible issues indicated in the original report.

>> Now cookies with expiration dates are saved

and

>> Expected Results:  
>> Cookies deleted

Might the summary be updated to clarify which of these this PR is applicable to?
The steps to reproduct suggest the former.  (Sorry for the spam.)

unglorious?

Sorry, the flurry of activity took me by surprise.

What I find agrees with the points in comment #15 that cookie persistence
depends upon cookie permissions.  Once permission to set cookies becomes
permanent the site's cookies *also* become persistent if they have an expiration
date.  This was not always the case, which I think is also a point made in
comment #15.  IIRC, all cookies set during a session were session cookies if
that preference was selected.

Using yahoo mail for an example I find 2.5 cookie behaviors with limit-session
preference set.  The ask-me preference is set and yahoo.com has been purged from
cookie permissions.
1.  Accept each cookie with "use my..." not checked.  Cookie Manager will show
all 7 as expiring at the end of session.
2. Accept each cookie with "use my..." checked.  Only asked twice, once for each
host.  The first cookie ("B") has an expiration date +3 months but Cookie
Manager shows expires end of session.  Two other cookies from the same host
(login.yahoo.com) have the same expiration date which is shown in Cookie Manager.
2.5 yahoo.com *not* cleared from permissions.  "B" now retains expiration date
in Cookie Manager.

In any event it's inconsistent behavior that a cookie is session or persistent
depending upon whether the cookie is accepted manually by the user or
automatically by remembered preference.

As I understand remembered cookie permissions it's either accept or block.  Are
there other possibilities?  I see Tools->Cookie Manager->Allow Session Cookies
from...

RE: #17, probably the first.  The problem as I see it are cookies accepted
during the session being saved at the end of session even though limit:session
preference is set.  I am not reporting or expecting that stored cookies be deleted.

My current workaround is replace cookies.txt with a symlink to /dev/null.
To respond to my own question, after selecting "Allow Session Cookies from this
Site" from the Tools->Cookie Manager menu I noticed a change in cookperm.txt:
login.yahoo.com 0T
became
login.yahoo.com 0i
And now the formerly persistent cookies are session.
The cookie manager owerrules the limit-lifetime pref. This was to fix bug
217286, which asked for that. We can't have both, so someone needs to make a
decision :) darin and dwitte, what do you think?

This patch is only intended to restore intuitive behavior with respect to
cookie lifetime and whitelisting.

This behavior may coexist with session whitelisting without being confusing.

An alternative fix would at minimum permit users to specify whether
whitelisting makes cookies ignorant of lifetime prefs or not.
With that patch, how can you make you login cookie for a site not expire, while
expiring all other random cookies?
The point of having a session-only permission and a "allow permanent" permission
is to provide the maximum amount of flexibility.  Users who want to allow
persistent cookies for certain sites while restricting all others to session (or
even denying all others outright) now have the ability to do this.  This patch
regresses that type of functionality.

There's two issues that need to be addressed to move on from this bug.

1. UI for the session-only permission (which behaves like the old behaviour) did
not make it into 1.6.  The localization freeze at 1.6b caught me out on that
regard.  This landed in the beginning of 1.7a, however the cookie dialogs do not
current support this permission (work ongoing for that one).

2. Whether we care about backwards compatibility all that much.  If we do, a
stopgap could be (ugh) a hidden pref that allows this pref to override the Allow
permission.  I don't like this idea, and I personally feel that once the UI
gives the option to set the permission for session or permanent than this bug is
moot.
Summary: Cookies ignore "current session" preference → Whitelisted cookies ignore "current session" preference
Good point mlv.

A persistent cookie can be saved as in the past, but its expiration is going to
be clobbered/sessionized next time it's received.  This might be argued to be
more consistent with the session lifetime pref than the past behavior, and
although this might be undesirable, it probably will not receive as much
negative attention as will ignoring the pref for whitelisted sites.


its certainly undesirable for people who want the whitelist to override that
same pref.  Once people understand the two types of permissions, what you're
talking about won't be an issue.
Not wanting to interfere with the semantics of dominance of the whitelist I
tried cook what gets into the whitelist through my main means of populating
it--the "Ask me..." Confirm dialog.  When remembering "Allow" the
lifetime/session pref is taken into account.  Using three buttons
Allow/Deny/Session in the dialog would be much better, but more than I can do.

With allow-session in the whitelist previously saved cookies get converted to
session cookies *except* the first one listed in cookies.txt which persists
through multiple sessions.  Not sure if this is a feature or a bug.
Sorry, Mike, I collided with your comment #24 and noted just the summary change
before reposting.  (Thanks for updating that.)

1.7's session-only permission does duplicate the old behavior.  This isn't what
was observed yesterday. 
fix missing |break|, explicitly assign *aResult (so I can sleep)
Attachment #138754 - Attachment is obsolete: true
Please stop adding patches until the module owners decided what we really want.
(And as a peer I am still in favour of wontfix)
Before you get me wrong, it isn't that i dont want any patches, it is just that
we need to discuss stuff more before getting patch-frenzy. Otherwise, the
discussion is hard to follow, and within a month we will have yet another bug
requesting to undo those patches.
>In any event it's inconsistent behavior that a cookie is session or persistent
>depending upon whether the cookie is accepted manually by the user or
>automatically by remembered preference.

well, not really... if you want to be prompted for every cookie, and you have
the 'limit lifetime to session' pref enabled, what would you expect? just turn
it off if you want to be able to accept persistent cookies. (in future we may
allow the user to edit the lifetime in the cookie dialog, but that's a different
kettle of fish...)

now, if you have a site permission to accept cookies, we've decided via another
bug that it makes sense to make them persistent. if you want to whitelist a site
session-only, wait for 1.7 as mconnor said. that's the most flexible thing we
can do.

there is a bug here though:
http://lxr.mozilla.org/mozilla/source/extensions/cookie/nsCookiePermission.cpp#393

if you add a site to the whitelist, we probably want to treat it the same as if
it was previously added to the whitelist - i.e. we need to undo any session
downgrade that occured. not sure how to do that in code yet...
Not being aware of the change in whitelist precedence made it look inconsistent.
How are users-at-large expected to migrate?  They too might be caught unawares
that their existing whitelist is now overriding their global pref.  In that case
I'd have to agree with comment #5 that this is a significant privacy issue.

Re: undoing session downgrades
Tools->Cookie Manager->Allow Cookies from Site may lead to another line of code
to fix.

So this bug is done?  Wait until the new whitelist semantics make it into the UI?
at this point, the new UI will make things clear, yes.  The dialog work is in
progress at this moment, after which we should be fine.  Unfortunately, there
really wasn't any way to make everything compatible with the old impl without
creating new layers of permissions (i.e. "new" whitelist vs. "old" whitelist),
and this pref was the one case that the current impl would affect. Its too late
at any rate to put this particular genie back in the bottle for 1.6.  We might
want to nominate this for 1.7 release notes and recommend that concerned users
kill all sites in their current whitelist and use "Session" in
prompts/Tools->Cookie Manager.
>We might
>want to nominate this for 1.7 release notes and recommend that concerned users
>kill all sites in their current whitelist and use "Session" in
>prompts/Tools->Cookie Manager.

I'd have to agree.  The workaround is certainly simple enough, there should be
no need for backwards compat (comment 24 point 2).

It'd be nice to have a heads-up in the 1.6 release notes about the changed
behavior, too (assuming the session-only UI isn't brought in and the behavior
described in this PR stays as it is).
Asa, is it possible to get this added to the 1.6 release notes?

First cut, I'm at work so I'm a little braindead:

"Cookies from sites allowed to set cookies will override the "limit lifetime to 
current session" preference.  This allows for users to allow persistent cookies 
from some sites, while limiting all others to session-only.  Mozilla 1.7 will 
have support for per-site acceptance of session-only cookies."

that's terrible, but that's the gist of the situation, wording tweaks 
appreciated.
Keywords: relnote
few points:

- Usable whitelisting (as in UI to add sites) was added after 1.5. So for most
users 1.5 to 1.6 went from no whitelisting to overriding lifetime prefs. No need
to add something to the release notes about "old whitelisting" and "new
whitelisting"

- session only != limit lifetime. there is a difference, so adding UI for
session won't do anything for the lifetime pref.

- don't promise anything for a specifix release :)
For the release note, I'm not sure I understand what the new feature is (bug
number?) or how it changed users' expectations. 
asa: sites where the user chose Accept and checked "remember my decision" when
prompted are part of the whitelist.  Previously, sites that had this permission
were governed by the "accept for current session only" option.  bug 217286
changed this so that sites in the whitelist can set persistent cookies
regardless of the session preference.  This is the counter-bug to that bug,
arguing that the whitelisted sites should still be subject to lifetime limitations.

In 1.7a, there will be complete UI for the session-only whitelist permission,
but not in 1.6.
*** Bug 231297 has been marked as a duplicate of this bug. ***
*** Bug 232442 has been marked as a duplicate of this bug. ***
now that 230624 has landed, the dialogs should be clear as to what will happen,
so this is WONTFIX
Status: ASSIGNED → RESOLVED
Closed: 21 years ago
Resolution: --- → WONTFIX
*** Bug 235156 has been marked as a duplicate of this bug. ***
*** Bug 237030 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: