Closed Bug 188853 Opened 22 years ago Closed 8 years ago

trident profile may overflow current profile's max number of cookies

Categories

(Core Graveyard :: Profile: Migration, defect)

x86
Windows 2000
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED INCOMPLETE

People

(Reporter: jrgmorrison, Unassigned)

Details

mozilla (historically) has only allowed a maximum number of cookies, from any 
source, of 300. However, it doesn't store last access time (see bug 188850).
trident will allow at least 1000 cookies (tested IE6 on win2k) and possibly many
more. So, this sets up a potential of overflowing the existing profiles cookies
and replacing them with trident cookies (most of which are just going to be 
privacy-unfriendly permanent cookies set by ad banners and other such services).
188850 is semi-fixed now, so that the order of last access is known for
mozilla's 300 cookies. we don't actually store the last-access time though (it's
normally not important - when cookies are being set via browsing, you know the
last access time is now). so, when dumping in a thousand cookies with random
last access times, we'll assume they're all current and the existing cookies
will be flushed out.

I would argue that's partly the users' fault for wanting to import legions of
cookies; but the nice thing to do would be a) fix the last access crap we have
(-> change file format) and b) increase our cookie limit. This won't solve the
problem of profile imports potentially displacing existing cookies, but do we
care about that? Isn't that intended behavior? Should we (do we) print a warning
to this effect?

jrgm, you say IE6 has a 1k limit? that's good to know... do we want to go that high?

-> me, I don't see danm complaining. :)
Assignee: danm-moz → dwitte
I tested up to 1000 in IE6, and it is at least that high, but I expect it may be
quite a bit higher. 

> b) increase our cookie limit

I really don't think that is necessary or desired. Have a look at a 
300-cookie cookies.txt file and count the number that you require to 
maintain state with sites that you care about. Then count the number of 
cookies in the same file that are ad-banner/spy-cookies with expiration times in
2038. Basically, half or more of that file is junk that just accumulates.
Increasing the size of the file will just mean that you get to collect more junk.
That sounds reasonable to me... so, what do you suggest? A UI of some sort to
select which cookies to import? Or are you just looking for proper last-accessed
handling, so the older 1000 of the total 1300 cookies get thrown without any
user intervention?
Hmm, well it is a bit of a paradox. You can't tell the last access time for
trident cookies, so you can't decide which ones to keep if there are more than
300. If you decide to accept all of them, you're just moving over a lot of extra
junk to preserve a few useful state cookies. And a UI to "help" the end user to
decide which of possibly thousands of cookies to keep would be, uh, not really
that helpful.

I can imagine that a particular embeddor... oh, I don't know... say one 
who was contemplating switching their multi-million user base over to a
different browser engine would perhaps want to make it a seemless upgrade and
preserve as much of the prior state as possible. Not that any such embeddor
actually exists, mind you. But if one did, they might want to figure out the
right thing to do and configure that in their application build. 

But as a general issue in mozilla, absent the needs of a specific embeddor, I
think it would be better to just not import cookies from a trident profile.
>You can't tell the last access time for trident cookies, so you can't decide
>which ones to keep if there are more than 300.

Hmm, are you sure about this? I thought the last accessed time was available...
http://lxr.mozilla.org/seamonkey/source/extensions/tridentprofile/src/nsTridentPreferencesWin.cpp#548

I haven't really checked, but it appears that it stores expiration date and
creation date in the trident cookie files.
-> danm, since this is really more his ballpark than mine...

any opinion what we should do here?
Assignee: dwitte → danm-moz
Oy. My ballpark, eh?

What's a typical cookie count for an IE user? I'm not a good testcase because I
keep clearing mine out. Rephrased: how much of a problem is this?

Anyone who wants to migrate IE cookies to Mozilla must be either a brand new
Mozilla user or someone who uses both concurrently. The "brand new" case is
easier. We should probably migrate cookies in date order and stop just before we
hit Mozilla's limit.

There are three possible date orders: we have access to individual creation
time, individual expiration time, and last modification time as a group from a
singe host, through the modification date of the file. I like the file
modification date. It's visible one step further away, it's less random than the
expiration date, and more indicative of the user's interest than the creation
date. It also makes it convenient to group migrated cookies by host, since
that's how the individual files are grouped. This helps ensure the cookies that
do make it are part of a consistent group of cookies.

The "concurrent" case is a superset of "brand new." It makes sense to stop at
the same point. But there's a question of whether some extant Mozilla cookies
should be replaced by migrated IE cookies. We do keep modification time for
Mozilla cookies but only during the current session. Since in general we can't
tell which are older we have to pick one. I don't foresee a user study, so I'll
just guess.

I imagine a concurrent user who cares enough about IE cookies to migrate them is
for some reason carrying over some IE session into Mozilla. So it's important
that the IE cookies be migrated. I think we should favour the migrated IE
cookies over extant Mozilla cookies. However we do know which cookies were set
during the current Mozilla session. Those would seem to be the most very
important. However giving them highest priority will require some work and I'm
not sold on the idea.

If you were expecting a cookie overflow after migrating, you wouldn't be
surprised to see a basket stuffed with migrated cookies. So in general favoring
IE cookies has the advantage of being expected behaviour, I'd say. Also, I'm
guessing this will be an operation rare enough, and cookie information is by
nature ephemeral enough, that neither choice will cause any damage.

That leaves the question of whether we should give a lower priority to keeping
cookies from some list of sites likely to be of little interest to the user.
Advertisers, that is. I say no. It sounds like a lot of difficulty for a small
win; it's a less predictable algorithm -- there's more room for user surprise;
and I think there's a reasonable potential for sueage.

Summary. (1) We could simply read IE cookies from oldest to newest and let them
overflow all they like. Or (2a) we could read IE cookies from newest to oldest,
processing one IE cookie file at a time, and stop before processing a file whose
contents, entirely migrated, would have caused the number of migrated cookies to
surpass the total cookie limit. Additionally (2b) we could stop migrating a
little earlier, just before processing a file which would cause us to lose
cookies from the current Mozilla session, unless the file was even more recent.

Sorting files by date is the only real problem with either 1 or 2a. They're
nearly identical, but the latter is cleaner. And it does require exposing
kMaxNumberOfCookies somewhere public (yay unfrozen nsICookieManager2). I don't
know how to implement 2b offhand but it'd certainly require additional exposure.

I say when or if someone, maybe I, takes this task, implement choice 2a, which
leaves the door open for 2b.

You're certain you don't want this bug, Dan ;) ?
>from a singe host

oy! what's going on here :)

so yeah, the reason i assigned to you was because i initially figured the
required changes would be in tridentprofile, not cookies. this may turn out to
be wrong. shrug.

anyway, i'm leaning toward option 1, solely for the reason that it's simple and
doesn't require exposing knowledge of intimate private details of our friendly
cookieservice. i agree with the notion that if the user wants to import cookies,
they had better expect that it's possible and likely all of their mozilla
cookies will be displaced. in which case, i don't see much reward for the effort
involved in implementing the difference between 2a and 2b; if you accept that,
then it logically follows the only difference between 1 and 2a is a little bit
of code efficiency for a non-perf-critical import operation. which, imo, does
not outweigh the downside of poking into the poor, innocent cookieservice privates.

if what i've said is agreeable, then the changes to be made lie solely in
tridentprofile, i believe - in which case, this bug fits you better than it fits
me, danm :)
It's a low-impact, 90% solution for a service I suspect no one has ever, ever
used. Good by me. [danm struggles to leave a simple, short comment.]
Assignee: danm.moz → nobody
Filter on "Nobody_NScomTLD_20080620"
QA Contact: ktrina → profile-migration
This bug is filed in a bugzilla component related to pre-Firefox code which no longer exists. I believe it is no longer relevant and I am therefore closing it INCOMPLETE.

If you believe that this bug is still valid and needs to be fixed, please reopen it and move it to the Toolkit:Startup and Profile System product/component.
No longer blocks: 1243899
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → INCOMPLETE
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.