"ask before accepting" only non-session cookies (silently accept session)

VERIFIED FIXED in mozilla1.7alpha

Status

()

P2
normal
VERIFIED FIXED
18 years ago
13 years ago

People

(Reporter: bugzilla, Assigned: mconnor)

Tracking

Trunk
mozilla1.7alpha
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: checkwin checklinux)

Attachments

(1 attachment)

(Reporter)

Description

18 years ago
It could be nice if you could say that you would accepts all per session cookies 
but be asked about persisten cookies.

So I'm asking about different action for the two types of cookies.

Comment 1

18 years ago
Better yet, be able to accept cookies but force them to expire at the end of a
browser sessien.  

The UI for this could be a check box on the accept cookie dialog box:

	Site so-and-so want to set a cookie.
	Do you wish to allow this?
		[YES]	[NO]
	[x] Expire cookies when browser exits.
	[x] Remember this decision.

I don't care that I'm tracked during a visit to a web site, but I do mind longer
term tracking.  Some sites are coming up with innovative ways to require that
you accept cookies.  For example, Fortunecity.com makes you accept their
cookies.  If you do not accept them, fortunecity will serve an FC ad instead of
any graphics.  This makes many sites on fortunecity unreadable unless you enable
cookies. (Especially if the site uses an image for the background of the page).
 Look at http://skyscraper.fortunecity.com/gates/659/fortune.html
both with and without cookies to see what I mean.  The upshot of this for FC is
that they can track your movement over the web on any of the thousands of sites
that they host.

If there were a way to make the cookie automatically expire at the end of the
session, I would be much happier.  With the UI that I propose, it would be easy
for me to enable long term cookies for places that I want to remember me (my
bank, my webmail, etc.) but not for places I feel are trying to erode my privacy.

Comment 2

18 years ago
see also bug 66207

Comment 3

18 years ago
We already have the ability to limit the lifetime of a cookie.  In other words 
we can specify that we accept cookies that are only for the current browser 
session.  The only thing lacking is the UI for this feature.  And that is the 
topic of bug 53354.

*** This bug has been marked as a duplicate of 53354 ***
Status: NEW → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → DUPLICATE
(Reporter)

Comment 4

18 years ago
verifying bugs...
build 2001013020
Status: RESOLVED → VERIFIED

Comment 5

16 years ago
REOPEN:
There are several bugs asking for this, and I don't think what is proposed by
morse actually works the way the reporter meant it to work.
Status: VERIFIED → REOPENED
QA Contact: tever → cookieqa
Resolution: DUPLICATE → ---
Summary: Differentiate between "real" cookies and per session cookies → Session-only mode
(Assignee)

Comment 6

16 years ago
*** Bug 205793 has been marked as a duplicate of this bug. ***
->dwitte
Assignee: morse → dwitte
Status: REOPENED → NEW

Comment 8

15 years ago
It would be cool if you could say accept all session cookies and cookies that
expire in X days or less.  With longer-lived cookies, you're asked whether you
want to accept, coerce them to X days, or reject.
(Assignee)

Updated

15 years ago
Blocks: 214431

Updated

15 years ago
Summary: Session-only mode → Mode to only "ask before accepting" cookies that are longer than a session

Comment 9

15 years ago
hopefully better summary...
Summary: Mode to only "ask before accepting" cookies that are longer than a session → "ask before accepting" only non-session cookies (silently accept session)

Comment 10

15 years ago
Except for silently accepting cookies, I would like an option to always expire
some cookies at the end of a session. Therefore comment #1 is just what I want:

- I can accept cookies for site X, and have them always (now and in the future)
expire at the end of the session.

In the cookie options there should be some indication that sites are allowed
cookies (including persisting non-session cookies) but that they expire at teh
end of the session.

Comment 11

15 years ago
I agree with <a href="#c1">comment #1</a>, but even better is to add default
handling for all Web sites. So UI should be extended to:

 [x] Enable cookies
     [ ] for the originating Web sites only
     [ ] for the current session only
     [ ] but ask before accepting
     [x] BUT NOT PERSISTENT COOKIES
     [x] BUT EXPIRE THEM AFTER CURRENT SESSION
     

Updated

15 years ago
Blocks: 100573
(Assignee)

Comment 12

15 years ago
I wasn't sure before whether this was a good idea or not.  However, I think it
fits in well with the (as yet unwritten) master plan.  This would make the
cookie prompts far less annoying and intrusive, since a large number of users
don't care about session cookies, just the persistent ones.

-> taking
Assignee: dwitte → mconnor

Comment 13

15 years ago
In the current option list there is one option that is ambiguous: "for the
current session only". Does this option mean to
- only accept session cookies
- expire all cookies at the end of the session
In either case, the text could be changed to one of the these two phrases.

Combining therefore comments #8 and #11, I would propose:

 [x] Enable cookies
     [ ] For the originating Web sites only
     [ ] But ask before accepting

     Persistent cookies (that save date between sessions)
     ( ) Do not accept any persistent cookies
     ( ) Expire them at the end of the session
     ( ) Expire them within [999] days

The ( ) are radio buttons and the user would be able to fill in a number of
days. I believe this would be most generic and will suit all needs that I have
read so far. Comments welcome!

Comment 14

15 years ago
i'd like something like this:

 [x] Enable cookies
     [x] For the originating Web sites only
     [ ] for the current session only
     [x] But ask before accepting
         [x] Accept all session cookies without asking
(Assignee)

Comment 15

15 years ago
the cookies for longer than XXX days thing is a little too arcane, also you 
guys are debating Firebird UI for this, which would be bug 214431

Comment 16

15 years ago
Regarding comment #15: I agree that the "expire after x days" will suit few people.

Being able to "treat persistent cookies as session cookies" (that they expire at
the end of the session) is something that many people will appreciate.
(Assignee)

Comment 17

15 years ago
"for the current session only" already downgrades persistent cookies to session
cookies, with the exception of whitelisted cookies.  This doesn't affect that,
as persistent cookies would prompt you (you can now choose to accept for the
current session only via the prompts though, see bug 230624).

At some point I will be documenting everything/rewriting the seamonkey and
firebird pref panels to reflect the new capabilities of the cookies backend. 
However, I want to finish making things work properly first.
(Assignee)

Updated

15 years ago
Blocks: 222561
(Assignee)

Comment 18

15 years ago
Created attachment 140322 [details] [diff] [review]
backend portion of the patch

dwitte, does this look okay?  I'm actually hacking around with something larger
that you'll see later

Comment 19

15 years ago
Regarding comment #17: I found that this weekend in the help files (I believe
they ship with the latest trunk version and I was using the 0.8 branch one).
Still believe that the current text "for the current session only" does not
indicate clearly what it does (see comment #13) and propose/urge to change the
text. Would you want me to open a different bug for it or do you prefer to take
it along with this one?
(Assignee)

Comment 20

15 years ago
there's already bugs for the seamonkey product, I don't remember if there is one
for Firebird yet, but I won't be touching that until some other issues are finalized

Comment 21

15 years ago
Comment on attachment 140322 [details] [diff] [review]
backend portion of the patch

>Index: mozilla/extensions/cookie/nsCookiePermission.cpp
>===================================================================
>+    // if we're set to not prompt for session cookies, accept it now and return

terminate sentence with a period please :)

>+    // doing this here before the downgrade is needed, otherwise the combination
>+    // of the prefs negates the "ask before accepting" pref

s/needed/done/ ?

>+    if (*aIsSession && mCookiesAlwaysAcceptSessionCookies) {
>+        *aResult = PR_TRUE;
>+        return rv;
>+    }
>     // check cookie lifetime pref, and limit lifetime if required.

hmm, |rv| is actually un-inited at this point... |return NS_OK;| instead
please, and shift the declaration on
http://lxr.mozilla.org/seamonkey/source/extensions/cookie/nsCookiePermission.cp
p#285 to where it's used on #355 for extra points?

also the style in this file is 2-space indents, not 4... and please add a
newline after the |}| in your |if| block.

other than that, welcome to c++ land, again :)
Attachment #140322 - Flags: review+
(Assignee)

Comment 22

15 years ago
this should get fixed with 233339
Status: NEW → ASSIGNED
Priority: -- → P2
Target Milestone: --- → mozilla1.7alpha
(Assignee)

Updated

15 years ago
Depends on: 233339
(Assignee)

Comment 23

15 years ago
fixed as part of bug 233339, fix checked in 03/09/2004 22:47
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago15 years ago
Resolution: --- → FIXED

Comment 24

15 years ago
V: fixed.

Selected "except session cookies" checkbox in prefs.

When session cookies are sent, they appear in cookie manager w/o the accept dialog. 
Non-session cookies continue to behave correctly.

I'm using http://flashtracking.com/es/default.asp?aid=3&pop=n&fla=y&bandwidth=,
which is a bad example, because it might not be around for long, but it sends a
new session cookie everytime you change the music selection, so it is easy to poke.

Status: RESOLVED → VERIFIED
Whiteboard: checkwin checklinux

Comment 25

15 years ago
*** Bug 251321 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 26

15 years ago
*** Bug 251565 has been marked as a duplicate of this bug. ***

Comment 27

13 years ago
see also Bug 301540 for firefox
You need to log in before you can comment on or make changes to this bug.