Closed Bug 86174 Opened 23 years ago Closed 20 years ago

Session-cookies do not expire when closing all windows

Categories

(Core :: Networking: Cookies, enhancement)

Product:
Core
Component:
Networking: Cookies
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WONTFIX
Milestone:
Future

People

(Reporter: peope, Assigned: mconnor)

References

(
URL
)

Details

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.1) Gecko/20010607
BuildID:    2001060703

Session-cookies eg session-id for a php-page. Persists until you have closed the
app completely. If I go to a page, get a session-cookie, open tasks/mail. Close
the browser window. Open a new browser window. The session-cookie is still
there. When I close all Mozilla-windows. It is gone.

Reproducible: Always
Steps to Reproduce:
1. open mozilla -mail
2. open mozilla
3. Goto a site with session-cookies in browser
4. Close browser window(s) (all of them)
5. Open new browser window
6. The session-cookie persists


Actual Results:  The session-cookie persists.

Expected Results:  The session-cookie should have ben removed.
I don't know if this bug is valid. 
But I can confirm this.


-> cookies
Assignee: asa → morse
Status: UNCONFIRMED → NEW
Component: Browser-General → Cookies
Ever confirmed: true
QA Contact: doronr → tever
As long as you haven't closed out the app, you are still in the same session.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → INVALID
Sure. It works like that.
But SHOULD it work like that?

I often have mail-window open. It has a much different role than the browser.

Think that a session-cookie should be deleted at least when there are no more
browser-windows open.

What do you think?
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
Severity: normal → enhancement
Target Milestone: --- → Future
I definitely think the "session" should be the application session, not the
browser-window session. Closing all the open application windows is not a
"special" event. Think of it this way: Why should the session cookies be
"forgotten" when closing a single window (leaving no open windows), but not when
closing 8 out of 9 open windows (leaving 1 open window)?

I suggest marking this bug invalid.
I do not think this should be closed. As I see it Mozilla contains several
applications in one program. You got the Browser, Mail, Composer and IRC-client.

Sure Mail and Composer share html-rendering with he browser but there is where
it ends.

Think of this: From any (almost) browser window you can get back to the page
with the cookie. If you only have a mail, irc or composer - window open you
cannot go back to your old webpage. You would need to open a browser window to
do that. Thus you (at least I) would expect the session-cookie to be forgotten.

Think the session-cookies should be isolated in the following order:
1. Application (Multiple users, using X on the same server eg)
2. Webbrowser-domain of Mozilla

Best regards
Per-Olof Pettersson
I'm not convinced. Let's say I'm working in a browser window and then switch to
mail to read and send some messages. I then go back to Web browsing. Why should
it matter whether I left my browsing window open, or closed the window and
opened a new window?

I can see what you mean, but I think the majority of users (including me) expect
"session" to refer to the application session (between starting and quitting
Mozilla). I still favor marking this bug invalid.
Blocks: 100573
I think this should be kept open and addressed. 

Cookies relate to the browser window, not the application. You dont have cookies
in news or in chat or in composer do you? If I did a browser-only install should
the session end on exit from Mozilla or on exit from the last active window? i
would say they are both the same...



If I open a webpage that uses a session cookie and then close my browser down,
the cookie should be expired. This is how IE, NS4, Opera etc etc etc does it. 



> This is how IE, NS4, Opera etc etc etc does it.

Not true.  Mozilla and NS4 do it exactly the same.
Uummm you are indeed correct. I made an assumption based on a project I was
recently working on. Thinking back the version of Netscape in use was Navigator
4.08 so it was only a browser. 

That project involved a cookie holding session specific information that was
meant to expire once the BROWSER was closed. 

It worked perfectly in IE, Opera, NS4.08 but did not  work in Mozilla unles you
killed the entire application - which is a bit of a bitch as it negates the
benefit of having QuickLaunch. 



Quicklaunch is another issue and the session cookies for it are being addressed 
somewhere else.  If all windows are closed, indeed the session is ended.
I confirme, under Windows with quicklaunch enable, this bug is very annoying
(with v0.9.8)
Just to clarify my comment #10 above.  When all windows are closed, all session 
cookies are released.  That is true whether or not quicklaunch is enabled.  The 
bug that deals with releasing session cookies when quicklaunch is enbabled is 
bug 129819 and the patch for it has been checked in.
OK. QuickLaunch issue is resolved.

Still a bitch though. I worke remotely and use chatZilla. To fully expire a
cookie I need to close it which is damn annoying.

I am working on various e-commerce systems and session expiration on BROWSER
shutdown is crucial. Apart from anything else, just testing functionality that
is meant to occur on browser shutdown is a pain as I have to either kill all
windows, or disable then re-enabl cookies in prefs or do as I am now and use Moz
for chatZilla and NS7 for browsing. 

How difficult would it be to do this? 
If I receive a session cookie while browsing, and then I shut down that window
or tab, I would expect that "session" to have ended.  You have to look at it
from the perspective of websites and how they would track visits and not from
the application's perspective.
Security-wise, many websites tell users to close the browser window to ensure
they are logged off (and that their session is expired).  This can cause
unexpected security issues:  imagine on a machine in a public library, someone
goes to a secure website, logs in, downloads a file, then closes the browser
window.  If any other browser windows (or even the "download manager") are left
open, anyone can walk up to the system, go to the site, and be logged in as the
previous user, providing the session hasn't timed out on its own.  

It is also non-intuitive--why should the user have to close their browser window
viewing google.com just to expire the session in their other browser window
viewing amazon.com?  Even though all the browser windows share the same process,
they should still _appear_ to be several independent instances of the same
application.
I also think, there should be a possibility to start a new session.
I am a web developer and I often need several sessions open concurrently for
testing reasons.
Up to now I used IE, where there was such a possibility. If you open new window
from existing window (right click on hyperlink, Ctrl-N, file->new window menu,
etc.) they share the session. If you open a new instance by clicking on IE
shortcut icon, the new session is started.
I don't insist on havin exactly the same behaviour as in IE, but I definetely
would like to have multi-session functionality. Favourably even without
necessity to close all the browser window.
Perhaps the rule could be: tabs share sessions (session cookies), windows don't.
It shouldn't be that difficult to implement.
Scenario: I browse an online catalogue of products. I right click a product and
open its details in a new window. Then I finish browsing the catalog and close
that window. The session has _not_ ended, because I still have the other window.
And when I go to a completely different website in that other window, the
session _still_ hasn't ended, because I might use the Back button to go back.
However, when I close the window, the session _has_ ended, even if I have other
browser windows open.

If a site is making the user close a window to finish the session, that's just
false sense of security - it doesn't work that way even in IE, as described in
comment 16.

Solution:
1) Session cookies should have a session-ID, so that there can be multiple
cookies with the same name, domain and path but different session-ID.
2) Windows/tabs should have a session-ID property.
3) Session-ID's should use reference counting.
4) New browser windows/tabs (Ctrl+N, Ctrl+T, Ctrl+1, new start of Mozilla...)
should get a new, unique session-ID. They would use this session-ID (with
refcount=1) to identify session cookies that are relevant to them.
5) When one opens a link into a new window/tab, or when a new window gets opened
by JavaScript, that new window/tab should inherit the session-ID from the parent
window/tab, AND increase the reference count of the session-ID.
6) When a window/tab is closed, it should decrease the reference count of its
session-ID. If it is zero, the session can be freed, and all its session cookies
deleted.

How 'bout that?

(And setting hardware/OS to all/all.)
OS: Windows 2000 → All
Hardware: PC → All
profile sharing will probably provide the basic backend functionality for this,
though there'll be much more to do in terms of allowing multiple processes of
mozilla before it'll actually work.
Woah, hold your horses there! Multiple processes is overkill. I don't think it's
necessary to have that in order to implement comment 17. In fact, I'm inclined
to think that it's realizable completely in JS, without touching a line of C++,
though I'm not sure about this.
For my 2 pennies worth, I'd like to see this fixed.
I'm using Firebird with multiple tabs, and do lots of web development.

When I connect to a local application server it gives me a JSESSIONID, but when
I close the tab it doesn't get deleted, even though I have other tabs totally
unrelated to the page the session was for. It's not just other tabs being open
either, viewing the source of a completely different page on a different site,
or using the bookmark manager means the cookie won't get deleted, and that just
seems plain wrong.

I'd like the tabs to be treated as separate mozilla/firebird instances (or
sessions), and if you close the tab, kill any session scoped cookies associated
with that tab.
Forgive me if this is off-topic / incorrect, but isn't this also a possible
security issue?  If different tabs/windows aren't sectioned off from one
another, this isn't there the potential for the session cookie information set
by a sensitive site in one tab (say online banking for instance), assuming that
it uses session cookies, to be read by sites in other tabs/windows?
no. cookies can only be read/altered by the sites that set them.
So the only possible security related issue here would be the case where you
close out a site without actually logging out (but don't exit Mozilla), leave
your desk, and some co-worker or other family member comes in, opens up the site
again, and some of the checks are bypassed because the session cookie is still
active - as per comment 15.

I just confirmed this both with phpBB boards (MozillaZine), which is not that
big a deal, and my own online banking site, which is much more of a big deal.

I would have to agree that if I close my online banking tab I should be forced
to login again if I revisit it (without first exiting Mozilla).  The fact that I
don't explicitly log out is incorrect user action, but any negative results from
that shouldn't be impacting the browser side of the equation.

As already suggested, if said online banking site opens up a 2nd window/tab of
its own, existing session cookies should be duplicated but for the unique id
associated with that new window/tab, so that security credentials are
maintained.  However, this does pose problems in terms of what new windows/tabs
some sites will open up.  You could say that only if the originating domain is
the same should the session cookies be copied, so as to avoid popup/redirect
sites, etc. - but what of sites that use a merchant service where the a totally
different, yet legitimate, domain is used?  Is there any way of determining
legitimate vs. illegitmate use here?  In any case, I would first implement
things so that only new tabs/windows created by the 1st site can make use of
that 1st site's information.  Then (try to) deal with this further aspect of
things in a separate bug.  

Should the "privacy" keyword be added here?
Forget the part of my last comment about addressing the situation where one site
opens up a totally different site (legitimately or not) being a problem.  As I
*had* known before I stupidly asked, and as Dan already replied, "cookies can
only be read/altered by the sites that set them".  I seem to be having some kind
of intellectually challenged day today...
Most ecommerce/banking sites also use timeouts in case the user does not log out
or their connections drops and they can't get back online etc.
Bug 117222 might be a dup.
I can confirm that Firebird 0.6 does not expire session cookies when all
instances of the browser are closed. I guess it is due to the quickstart feature
as firebird is still active as a process under NT4. This is very bad though, as
a user should not be expected to know that once they have closed down all
visible signs of the browser that it will still be hanging onto their session
variables (typically used to confirm security credentials).
I have closed down Firebird and then come back to the machine the next day,
launched Firebird and been horrified to find I was still logged into a PHP
application. (NB: It is on a testserver which has no timeouts set).
But Firebird should NOT rely on people logging out of applications, as it is
pretty reasonable for them to assume that if they close the browser that is the
same thing. Certainly IE6 works this way.
Apologies if this is fixed in version 0.7, but that version doesn't list NT as a
supported platform and I daren't risk stuffing my machine by installing it as I
am well behind with a website as it is. I guess I'd better get back to it.
Andy: That's a different bug. This bug (or RFE, rather) applies to
Mozilla-the-application-suite, and requests that sessions expire when all
browser windows pertaining to the session are closed (i.e., potentially sooner
that all Mozilla windows are closed, or even before all browser windows are
closed, but that's a matter of opinion).
*** Bug 200336 has been marked as a duplicate of this bug. ***
leaving the "when should a session be a session" stuff in bug 117222, we still
have the issue of whether closing all browser windows should purge the session
cookies.

taking to evaluate
Assignee: morse → mconnor
Status: REOPENED → NEW
Depends on: 239759
QA Contact: tever → benc
Summary: Session-cookies do not expire when closing window. → Session-cookies do not expire when closing window
as darin pointed out in a discussion on IRC, to do this properly would require
clearing memory cache and SSL session info, since sites may depend on the two
being related.  Doing that would probably require reworking how memory cache and
SSL sessions are persisted, especially since they don't differentiate between
mail/browser objects.  His opinion, which I share, is that this isn't worth
fixing at this stage of Seamonkey's existence.  If it was good enough for NS 4.x
and every Mozilla version until now, its good enough to keep.  

Since Seamonkey is on a sustained engineering path, and the move is towards
standalone apps that do not share session data, I don't think fixing this is
viable/desirable since it would introduce mostly unnecessary changes to
components that don't need to be changed for anything except Seamonkey.
QA Contact: benc → cookieqa
fair enough, just be aware that mozilla will therefore never
make a decent kiosk substitute until this is fixed due to
security concerns.

mark
mconnor: why makes firefox fixing this easier? you still need to clear out
memory cacha and ssl sessions.
In firefox, cookies are also not bound to a window. So how do you know which
cookies to remove?
mvl, this bug is mostly about clearing session cookies when all navigator 
windows are closed, we can easily dump memory cache/SSL sessions on Firefox 
since we don't have to figure out what belongs to mail and what belongs to 
browser.

Mark, please clarify your comments.  If you use just the browser, this isn't an 
issue assuming you close all windows.  If you have a mail window open, the 
cookies don't get cleared.  If you're using a kiosk setup, Firefox seems the 
better option in any case.
having thought way too much about this, I don't believe this is worth fixing. 
Neither does darin or dwitte, for that matter.  Being that this not only would
have to touch cookies, but SSL and cache, and given that only Seamonkey would
benefit from it, there is no point in fixing this at this stage.  In fact
(although this is theory/speculation) to fix this for Seamonkey would create
baggage for standalone apps like Firefox and Thunderbird.

If you want session cookies gone when closing all of your browser windows, use
Firefox.
Status: NEW → RESOLVED
Closed: 23 years ago → 20 years ago
Resolution: --- → WONTFIX
I can accept that this won't be fixed, although I find the justification for it
to be pretty objectionable - as phrased anyway.  Saying "if you don't like it
then use Firefox" is a little draconian.  The last time I looked, mozilla.org
had not discontinued, nor dropped support for, Seamonkey.  With this attitude,
we shouldn't be developing 1.8a at all - just FF.  Much more reasonable, I
think, would be to simply reassign the bug to "nobody" and just not work on it
yourself...  (The comment isn't meant personally, and I don't mean it to be a
flame, I just find the viewpoint to be a little distressing.)
seamonkey isn't in active developement, its in sustained development, which
means that seamonkey-specific changes that involve large engineering effort
simply aren't being done.  While we will continue to work on improving the base
behind the suite, implementing changes across multiple modules for what is
effectively a seamonkey-only bug just doesn't make sense.  Leaving it for
someone to work on is just an invitation to waste someone else's time.  If
someone has the skills and time to invest in integration work, there's a lot of
bugs out there that need to be fixed.

As for the Firefox comment, perhaps a better phrasing is "if you want browser
and mail sessions kept separate, use standalone apps (i.e. Firefox/Thunderbird)
instead of an integrated one (Seamonkey)"  This bug at its core is about making
the navigator windows act like a separate process from the mail process, and
since as an organization we've gone beyond that in producing standalone apps
instead of the monolithic suite, this bug is nowhere near as relevant/important
as it would have been if we'd fixed it three years ago.
Cleaning up summary to say what comment 0 says. To keep me from wrting useless
comments. (Wait, i just did that, and deleted it again...)
Summary: Session-cookies do not expire when closing window → Session-cookies do not expire when closing all windows
*** Bug 253546 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.