202690 - Expire unused cookies

Status: RESOLVED WONTFIX

(Core :: Networking: Cookies, enhancement)

Description

[Dave Warren]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4a) Gecko/20030319
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4a) Gecko/20030319

This feature would expire a cookie once it hasn't been used for 'x' days.

This is different from the current "maximum lifetime" feature in that a cookie
limited with maximum lifetime will expire 30 days after it's created whether it
is being used or not unless the webpage refreshes it.


Reproducible: Always

Steps to Reproduce:

Comment 1

[[e-mail]]

are you sure they're not really the same thing? when you set the max lifetime of
a cookie, if the site doesn't update the cookie within that period it'll be
deleted. if you 'use' the site before then, typically the site will re-set the
cookie (or update it) and its expiry time will be renewed again. so if you have
a fixed cookie lifetime, expiry and last-used times are really just the same
information.

the only case this wouldn't apply, is if a site didn't update/re-set the cookie
when you use the site. can you cite specific examples of this? i wouldn't
imagine it to be very common, but i could be wrong.

Comment 2

[Jo Hermans]

Not very common ? On the contrary : updating cookies is very rare. Most sites
will  set a cookie once and never update it (becuase they want an 'infinite'
lifetime), or when they think they should update it (because it's close to the
expiration-date that they've set themselves). *Not* on every access ! The result
is that you won't see any updates, especially if you have set a 'maximum
lifetime' that is much shorter.

An example: slashdot.org : I have a 'maximum lifetime' set to 7 days, and I have
to login every week again (which will set the cookie).

Comment 3

[[e-mail]]

in that case, i stand corrected. thanks for the example (though to be honest,
it's not a very conducive one... ;)

not sure how we should implement this. do we want to keep adding default prefs
and keep bloating the backend? or should we implement some kind of js (or C...)
'helper function' that takes care of all expiry operations, on a periodic basis?
this way, it's easy to change between browsers (firebird, moz etc), and it's
easy for embeddors to roll their own pref setup.

we already have the framework for this, in nsICookiePermission. it's a wrapper
for the permissions backend, specific to cookies. we could also delegate all the
default prefs to it (which would make a lot of sense); so basically
nsCookieService::CheckPrefs() would shift into this service.

in addition, we could add a helper function IsCookieLive() that simply returns
if a cookie should be kept in the list. we would call this in several places: in
SetCookie() when initially setting a cookie; in GetCookie() when checking if we
can return a cookie; and in RemoveExpiredCookies() when we want to purge the
list of 'non-live' cookies. so now, the concept of an 'expired' cookie is
arbitrary: it doesn't have to relate solely to expiry time; it can be anything
the embeddor desires, e.g. encompassing this last-accessed-greater-than expiry
method.

the only issue i see would be perf. for checking a single cookie it's no
problem; but in RemoveExpiredCookies() we enumerate over the list and would
callback this IsCookieLive() function. this is not done often so it's no really
big deal; but we should make sure the function call is relatively efficient
(i.e. non-virtual?). if cookie core lived in necko, and nsICookiePermission
lived in some xpfe/components/ somewhere, would this still be the case?

comments welcome.

Comment 4

[Darin Fisher]

dwitte:

a callback is by definition "virtual" either via a virtual class method or a
function pointer.  both are really the same thing ;-)

i'd personally punt on this feature unless said refactoring could help with
other bugs.

Comment 5

[Jo Hermans]

I believe that the current cookies are 'expired' when Mozilla starts, and we
also check when we access the cookie. Expiring old cookies isn't something that
has to be done contantly, we can keep it in the application startup, and maybe
in an extra thread that runs every 24 hours or so. There's no need to check it
on every access, because the acces itself is the proof that the cookie is alive.
Just keep a access-timestamp (bug 161000), and we can call the expiration
routines once a day or so.

You would need an extra preference (maximum staleness ?), unless you want to
reuse the maximum expiration preference. But then it would only work for people
who know why they need a maximum expiration. If we have a separate preference,
then we can also provide a reasonable default value (30 days ?).

I always thought that expiring cookies on the access-timestamps was much better
than the expiration timestamp stored in the cookie itself. Most websites uses
stupid expiration times like 1-jan-2010 or 2038 or whatever, but the result is
that we have to process thousands of cookies, most which will be never be seen
again. Limiting the expiration time to 30 days or less is much better, and when
you limit it a very short time (1 day - 1 week), it's also good for your
privacy. But the disadvantage is that most websites are too stupid to update
their cookies on every access (it's not neccessary in IE anyway). When we keep a
access-timestamp, and we purge cookies that haven't been accessed in a month or
so, then we can clean the cookie-database much more intelligently - without the
update-problems that can be seen now.

This is not just an enhancement, this is a sign of an intelligent application.

Comment 6

[[e-mail]]

darin: ok ;)

>I believe that the current cookies are 'expired' when Mozilla starts, and we
>also check when we access the cookie. Expiring old cookies isn't something that
>has to be done contantly, we can keep it in the application startup, and maybe
>in an extra thread that runs every 24 hours or so. There's no need to check it
>on every access, because the acces itself is the proof that the cookie is >alive.
>Just keep a access-timestamp (bug 161000), and we can call the expiration
>routines once a day or so.

re not expiring cookies constantly - that's basically what I said. that's not
really an issue. however, i disagree with your statement about not needing to
check expirytime on every access. we can't send back expired cookies - that's
simply broken. we must check such things before sending a cookie. any other
expiry operations are optional, and we do them only when required for list
maintenance purposes, or when favorable for mem footprint. (well, currently
that's not the case, but it will be when the rest of the rewrite lands)

>You would need an extra preference (maximum staleness ?), unless you want to
>reuse the maximum expiration preference. But then it would only work for people
>who know why they need a maximum expiration. If we have a separate preference,
>then we can also provide a reasonable default value (30 days ?).

right.

>I always thought that expiring cookies on the access-timestamps was much better
>than the expiration timestamp stored in the cookie itself. Most websites uses
>stupid expiration times like 1-jan-2010 or 2038 or whatever, but the result is
>that we have to process thousands of cookies, most which will be never be seen
>again. Limiting the expiration time to 30 days or less is much better, and when
>you limit it a very short time (1 day - 1 week), it's also good for your
>privacy. But the disadvantage is that most websites are too stupid to update
>their cookies on every access (it's not neccessary in IE anyway). When we keep >a
>access-timestamp, and we purge cookies that haven't been accessed in a month or
>so, then we can clean the cookie-database much more intelligently - without the
>update-problems that can be seen now.

what do you mean, it's not necessary in IE? does it automatically update
expirytimes when you access a cookie?

>This is not just an enhancement, this is a sign of an intelligent application.

it's an interesting RFE. i don't like the idea of bloating our backend for every
little pref users may want, so i suggested the idea of making it easily
customizable (so embeddors don't need to pay the price), but that doesn't get
around the bloat/UI for that extra pref. the concensus is that limiting
expirytime is sufficient for now. so, it can stay as an RFE. ;)

Comment 7

[Dave Warren]

FWIW, my personal opinion is that this should be implemented instead of the
"limit expire time" option -- It's designed to accomplish almost the same thing,
but this is somewhat more intuitive to what end users seem to expect.

In my experience advertising tracking cookies tend to reset themselves every
time regardless of whether or not the cookie was already set, but typical
"Rememeber my login" cookies aren't reset automatically, the server only sets
the cookie when the browser doesn't already have the correct cookie set.

My goal with this RFE is to allow "Remember my login" type cookies on sites I
visit on a regular basis to work, but at the same time to clean out cookies from
a site I visited once and never return.

Comment 8

[Gervase Markham [:gerv]]

This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/

Comment 9

[Christian :Biesinger (don't email me, ping me on IRC)]

this being a still applicable RFE, I don't think it should be autoresolved.

Comment 10

[Darin Fisher]

-> default owner

Comment 11

[[e-mail]]

not going to do this in the backend; extension fodder. (this would be easy to do in an extension, now that we're about to have creation time stored for each cookie)