Password protect history from being deleted




8 years ago
8 years ago


(Reporter: kwah90, Unassigned)



Firefox Tracking Flags

(Not tracked)




8 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-GB; rv: Gecko/20101210 Ubuntu/10.04 (lucid) Namoroka/3.6.14pre
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv: Gecko/20101210 Ubuntu/10.04 (lucid) Namoroka/3.6.14pre

Following dealing with a SUMO question there appears to be no way to prevent the browser history from being deleted. 

Reproducible: Always

Steps to Reproduce:
1. Populate the browser history
2. Attempt to delete any/all of the browser history
Actual Results:  
Regardless of whether a master password is set, the selected history entries are deleted.

Expected Results:  
With a master password defined, or after a particular setting/option is set, the user should be prompted for a password before the history entries are deleted.
why are you deleting history if you're not willing to remove it?
Adding dialogs interrupting user's tasks is not usually a good way of fixing problems. So maybe you think removing history by error is too easy?
Component: General → Bookmarks & History
Keywords: uiwanted
QA Contact: general → bookmarks

Comment 2

8 years ago
Given bug 536644 and bug 471658 will already provide a mechanism via parent controls this should probably be WONTFIXed.
you're probably right
Whiteboard: wontfix?

Comment 4

8 years ago
Marco, you misunderstand the purpose - it is not to prevent yourself from (accidentally?) deleting the history items, it is more about providing accountability and preventing others from being able to do this albeit in a somewhat rudimentary form. 

In this specific case the question/request was from someone who did not want their family members from being able to delete the browsing history. I assume that schools / workplace environments would benefit from such a feature if it isn't already being done by switches/proxies etc - something options that most home users do not have.

This isn't just a one-off request either - searching for "firefox password protect history" (and similar) turns up quite a few requests for this feature with the only workarounds potentially being a) editing userchrome.css or b) using a tool to backup the history regularly. (a) has caveats with respect to catching every available way of deleting history (keyboard shortcuts etc) and (b) suffers from history not being written to disk until close (afaik) so deletions/changes etc won't get caught if done during the same browser session.

* Though, I am aware that it would not prevent creating extra profiles etc nor would it necessarily manage private browsing mode..
well, comment 2 covers the request pretty well, but clearly, there is no safe way to do these kind of things, it's pretty easy to find ways to circumvent any software based check, so the best thing is always supervising browsing in person.

I'm duping to the bug that most gets near the requested feature.
Last Resolved: 8 years ago
Resolution: --- → DUPLICATE
Whiteboard: wontfix?
Duplicate of bug: 536644

Comment 6

8 years ago
(In reply to comment #2)
> Given bug 536644 and bug 471658 will already provide a mechanism via parent
> controls this should probably be WONTFIXed.

I think that you are correct, those bugs will provide the mechanisms but they rely upon the Vista parental controls - *BUT* what is being asked for here is to set it within Firefox (somehow) and to password protect it. AFAICS those bugs just react to parental controls defined in Vita only and (will eventually..) disable controls accordingly.

I would perhaps refine this request to include password protecting profiles and the option of password protecting history deletions/private browsing during profile setup. Similarly, I suspect that protection against extra profiles being created could also fall within these aims, but these are all perhaps out of the scope of this single bug?
Really, this request would add a layer of complexity we don't want to manage, the OS is serving parental control functionality and the feature, as any other software based check, could be workarounded. There are far better software and hardware filtering solutions to handle children's (or whatever) navigation, but there is no one that will prevent them to find a workaround to do whatever they want. the only safeway is side-by-side browsing. Consider that even if we block any history deletion, external software could still do it and a bunch of other weird things.
You need to log in before you can comment on or make changes to this bug.