Closed
Bug 208237
Opened 22 years ago
Closed 21 years ago
Setting to disallow images from setting cookies
Categories
(Core :: Networking: Cookies, enhancement)
Core
Networking: Cookies
Tracking
()
RESOLVED
WONTFIX
People
(Reporter: preed, Assigned: preed)
Details
A bunch of friends and I thought it would be cool if there was a setting to
disable cookies being set by images.
The only real reason cookies are set from images is so ad-tracking sites can
track you... there's no legitimate reason that images should be allowed to set
cookies (that *we* could think of, anyway).
Why are the current cookie options not enough to handle this case?
Power users probably have "ask me" turned on in their cookie prefs... so when
you get certain pages that like to embed cookies in ads, or embed session
cookies so they can track you (from, say msn.com or something), you have to
click "Deny" a bunch of times for each image, even though you may not want to
disallow cookies from the whole domain.
Adding a feature to disallow images from setting cookies would fix this problem.
Comment 1•22 years ago
|
||
reassigning this to jp, since he's the one looking into it.
for the record, I like the idea of this feature, but I'm not happy to see it go
into cookie code (or exist as a pref) - at least not in the UI. the Firebird
folks will agree with me here. this could be a hidden pref, but I don't really
think that's ideal either.
what would probably be best is if we could work this as an extension instead -
there are lots of cool things you can do with cookies to control them better,
but we just don't want to implement them in the backend because it adds
complexity that most users just won't care about. there are a couple of ways we
could approach it (talk to me on IRC if you want more info) - it's up to you to
either convince us why we should implement this by default, or to write it as an
extension. ;)
Assignee: darin → preed
| Assignee | ||
Comment 2•22 years ago
|
||
Extension would be cool; is there some documentation on extensions that I can read?
I had an initial implementation, and it sorta works. Unfortunately, there are a
couple of problems with it:
-- It seems to be hit or miss on whether you get a content-type with the channel
you get passed to cookie_CheckPrefs in nsCookies.cpp. Only in the simplest of
situations will you get an image that sets a cookie with the proper content-type
not only available, but passed through.
The other complication is that a *lot* of sites do the following:
<img src="foo.cgi?adnumber=234">
Now, all foo.cgi will do is set a cookie and issue a 302 redirect to an image.
So *technically*, the image isn't setting the cookie... but it's still the same
underhanded sort of ad-tracking we're trying to get around.
CNN.com does this, for instance.
Comment 3•22 years ago
|
||
I'm the wrong guy to ask about the details of actually _creating_ the extension,
but mozdev.org would be a good place to start. the actual implementation should
be relatively straightforward, but note that cookies will need a tad of work
before it's actually extendable (never fear, that'll happen soonish ;)
there are always ways to circumvent these kinds of measures, which is half the
reason i'm averse to adding random prefs into cookies - we have enough as it is,
and most of them don't work the way they should. 'block cookies in mailnews' was
quite broken until very recently, and 'block foreign cookies' doesn't and never
will work completely. so, just start simple and build more complexity/features
as required. ;) (there exist extensions, for instance, that filter images based
on server name and image filename, e.g. anything containing "ad" - check out mozdev)
Comment 4•21 years ago
|
||
dwitte, so, all that being said, if it doesn't belong in core code, this should
be WONTFIX, correct?
Comment 5•21 years ago
|
||
sure.
Comment 6•21 years ago
|
||
Geez, you could do this yourself y'know
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → WONTFIX
Comment 7•21 years ago
|
||
yeah, but you have to earn your peership somehow...
You need to log in
before you can comment on or make changes to this bug.
Description
•