Closed
Bug 565561
Opened 15 years ago
Closed 14 years ago
Include option to delete Flash cookies
Categories
(Firefox :: General, defect)
Firefox
General
Tracking
()
RESOLVED
FIXED
Tracking | Status | |
---|---|---|
blocking2.0 | --- | - |
People
(Reporter: jhill, Unassigned)
References
(Blocks 1 open bug)
Details
(Keywords: privacy)
(Note: this is filed as part of the “Paper Cut” bugs — we assume that there may be multiple existing bugs on this. Please make them block this bug, and we will de-dupe if they are indeed exactly the same. Thanks!)
To reproduce:
1. Go to clear your cookies
2. Flash cookies are not cleared
3.
Recommendation:
We at least need to add a link to the Adobe page that allows you to clear flash cookies (http://www.macromedia.com/support/documentation/en/flashplayer/help/settings_manager07.html). However, it would be better to work with Adobe to create an API to allow us to do this in our own browser settings.
Comment 1•15 years ago
|
||
add to Keywords: privacy
Updated•15 years ago
|
Flags: blocking1.9.0.19?
Updated•15 years ago
|
Updated•15 years ago
|
Flags: blocking1.9.0.19?
Updated•14 years ago
|
blocking1.9.1: ? → ---
blocking1.9.2: ? → ---
Comment 2•14 years ago
|
||
We're working on this, but it's not going to make Firefox 4.
blocking2.0: ? → -
Comment 3•14 years ago
|
||
How is this report different from bug 290456 - Block/clear Flash MX "cookies" as well
Comment 4•14 years ago
|
||
(In reply to comment #3)
> How is this report different from bug 290456 - Block/clear Flash MX "cookies"
> as well
I don't think it is different, but people were asked not to dupe "paper cuts" bugs and leave them to the UX team to consolidate (see comment 1). Maybe that doesn't apply any more, but tidying up will create a lot of bugmail spam...
Comment 5•14 years ago
|
||
I think there is a slight difference between the two, if I'm reading them correctly. This bug seems to be asking for new checkboxes for Flash LSOs in the "Clear Recent History" dialogue (from the Tools menu) and the "Clear history when Firefox closes" dialogue (from the Privacy pane of the Preferences/Options window), to delete all Flash LSOs once (without quitting Fx) and to do so each time Fx quits, respectively. On the other hand, bug 250456 seems to be asking for flash LSOs to be deleted also whenever (regular) cookies are deleted, and for them to be blocked likewise whenever cookies would be blocked (as in "Accept cookies from sites", "Exceptions", "Accept from third-party sites").
As I see them, the intent of the two bugs in regard to LSOs is not different, just the suggested approach; however, the additional checkboxes to control deletion of LSOs (or "Objects stored through plugins"?) would provide the ability to treat these options separately, which I anticipate I would not be the only user to prefer. That said, such checkboxes would not present the options for blocking/rejecting LSOs (or the like?) as are available for cookies, which would also be desirable.
Comment 6•14 years ago
|
||
Oh, I meant bug 290456 up there, of course. Sorry for double-commenting.
Comment 7•14 years ago
|
||
(In reply to comment #5)
> however, the additional checkboxes to control
> deletion of LSOs (or "Objects stored through plugins"?) would provide the
> ability to treat these options separately, which I anticipate I would not be
> the only user to prefer.
Why? I can't imagine a situation in which a user would be willing to let a site store information in cookies but not in plugin objects, or vice versa. I think we would do users a service by applying their existing cookie policies to plugin objects. This will help set an expectation that users' privacy preferences should be honored across the board, rather than making them play whack-a-mole with new technologies.
Comment 8•14 years ago
|
||
> Why? I can't imagine a situation in which a user would be willing to let a
> site store information in cookies but not in plugin objects, or vice versa.
One might, for instance, want to block third-party cookies across the board, but still allow a third-party-hosted Flash object to remember their preferences (say, for video resolution). On second thought, however, this might lead to more complexity than it's worth, especially in light of...
> I think we would do users a service by applying their existing cookie policies
> to plugin objects. This will help set an expectation that users' privacy
> preferences should be honored across the board, rather than making them play
> whack-a-mole with new technologies.
Point taken. This would also avoid cluttering the interface with vestiges of plugin-specific preferences (for those who also use Silverlight, for example), and the need to adapt which preferences are displayed according to which plugins are installed. As long as this is possible for extensions to fine-tune without jumping through too many hoops, for the sake of users who may want to eat their cake and still have it, then maybe the capability to distinguish the treatments of cookies from similar plugin objects would be better left for extensions to deal with if the demand exists.
I suppose it would be helpful if a more general (i.e., not exclusive to Flash) solution could be made available eventually, but then again, in light of the ubiquity of Flash (which probably dwarfs all but a small handful of plugins in popularity), there might not be any need for such a general solution. It might be nice for developers to need not play whack-a-mole with various forms of site-originated client-side state-persistence, but that might be a pipe dream, or more work that it would save, or simply redundant. I guess time will tell.
Comment 9•14 years ago
|
||
I'm not sure this type of discussion is useful at this point - there have already been discussions and a proposed API, so what is needed at this point is implementation.
> I suppose it would be helpful if a more general (i.e., not exclusive to Flash)
> solution could be made available eventually, but then again, in light of the
> ubiquity of Flash (which probably dwarfs all but a small handful of plugins in
> popularity), there might not be any need for such a general solution. It might
> be nice for developers to need not play whack-a-mole with various forms of
> site-originated client-side state-persistence, but that might be a pipe dream,
> or more work that it would save, or simply redundant. I guess time will tell.
That is the direction things are going anyway. This bug (and the similar one) depend on bug 508167, which is about adding to the plugin API. Adobe want to use that to be able to handle the user choosing to delete cookies (or whatever else) in the browser. Any other plugin could (and hopefully will, if appropriate) do the same.
It was noted in the older bug that it would not be appropriate or workable for Firefox to manipulate the files stored by a plugin - that would be more than one mole to whack for each plugin, as there are different versions and different platforms to consider.
Comment 10•14 years ago
|
||
To be fixed by:
Bug 625495 - Clear Adobe Flash Cookies (LSOs) when Clear Cookies is selected in the Privacy > Custom > Clear History When Firefox Closes > Settings... dialog
Bug 625496 - Clear Adobe Flash Cookies (LSOs) when Cookies is selected in Clear Recent History
Bug 625497 - Clear Adobe Flash Cookies (LSOs) when "Forget This Site" is selected
Updated•14 years ago
|
Comment 11•14 years ago
|
||
In the mean time, it would go a long way if there was simply a warning that "Deleting browser cookies does not remove data(cookies) stored by plugins". A similar warning would be helpful when starting private browsing and deleting or disabling browser history.
Comment 12•14 years ago
|
||
Fixed by dependencies.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Comment 13•14 years ago
|
||
(In reply to comment #12)
> Fixed by dependencies.
Are you sure? I just tested this on my Fx 4 install. I always have Fx set to clear cookies on browser exit, but it definitely did not clear my LSOs. I was hoping to do away with the BetterPrivacy extension, but it seems like I will need to keep it for awhile longer.
You need to log in
before you can comment on or make changes to this bug.
Description
•