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)
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).
Comment 1•21 years ago
|
||
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
Reporter | ||
Comment 2•21 years ago
|
||
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.
Comment 3•21 years ago
|
||
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?
Reporter | ||
Comment 4•21 years ago
|
||
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.
Comment 5•21 years ago
|
||
>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...
Reporter | ||
Comment 6•21 years ago
|
||
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.
Comment 7•21 years ago
|
||
-> 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 ;) ?
Comment 9•21 years ago
|
||
>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 :)
Comment 10•21 years ago
|
||
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.]
Comment 11•16 years ago
|
||
Filter on "Nobody_NScomTLD_20080620"
QA Contact: ktrina → profile-migration
Blocks: 1243899
Comment 12•8 years ago
|
||
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.
Assignee | ||
Updated•8 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•