Open Bug 1051082 Opened 5 years ago Updated 2 years ago
Store homepage configuration outside of prefs
+++ This bug was initially created as a clone of Bug #1029148 +++ Bug 1029148 addressed external search hijackers by moving the selected search engine preference out of the preferences system. Since these search hijackers also tend to hijack the homepage, along with the search engine, by the same mechanism, we should store that setting in a similar manner.
Summary: store "current search engine" configuration outside of prefs → Store homepage configuration outside of prefs
This should include the new tab page setting as well.
Iteration: 34.2 → ---
Points: 8 → ---
Component: Search → General
Removing any such settings from prefs seems to me like it's 1) anti-power-user changes (no sync, unable to find in about:config), 2) only putting the race with malware/adware to a different level (but they will adapt to a different storage) and 3) pointing out that prefs are a bad storage medium and we should potentially abolish them. I personally think that's the wrong strategy. Is there no way to either improve prefs to a better storage medium for, erm, prefs?
From bug 1029148: (In reply to Gregg Lind (User Research - Test Pilot) from comment #11) > Challenging project, good progress. > > Would it make sense to attempt to enumerate all the downstream user > experiences that currently rely on search's "preffiness", to allow > mitigating impact? > > Among these: > > - about:support, SUMO > - Reset Firefox > - FHR data collection and segmentation > - Test Pilot search related work > - profile migration (automatic and manual) > - Sync (for settings) > > All of these rely in exposing *something*. Some of them rely on having > "settable" things. Seems like we should keep those in mind here, too.
Flags: firefox-backlog? → firefox-backlog+
So will an add-on be able to change the value at all using the preference APIs? Changing the default homepage is a very common thing for enterprise. This seems like it would break setting the homepage via something like AutoConfig (which uses prefs) or an extension (which uses prefs).
Based on the behaviour of the , that would likely be the case. Given the extent to which this pref has been abused, the legit cases appear to be outweighed by about an order of magnitude. We may add an opt-in UI (that's the plan for search already) for add-ons to use. At this rate, most of these changes will align for Fx 39, so we're not under the gun to solve for the enterprise case yet.
(Is there a way we can add "audit trail" to this, so that we know if it was an addon, user click, or other thing. Is that a separate bug? Utility/Reason for asking: self-repair, knowing what addons are doing, around both of these prefs.)
4 years ago
Priority: -- → P2
What about creating a preference safe secured by the user's master password? If Firefox detected a change in a preference stored in the safe, for example, when displaying the home page, it could display an infobar over the (previously verified) home page asking the user whether she wishes to change to the page in insecure preferences, or revert it to the saved setting. Of course, users not interested in setting/entering a master password won't benefit as much, but I think we should encourage users to set them.
You need to log in before you can comment on or make changes to this bug.