1452144 - Reinstate a Custom URL setting for New Tab

Status: NEW

(Firefox :: New Tab Page, enhancement, P3)

Description

[Aaron Benson]

Some needed context in 1417155 and 1118285.

Within the new Home section in Preferences (spec details: https://mozilla.invisionapp.com/share/65FPNL9RH4V), there is the ability to set a New Window / Home page to a custom URL but you cannot set your New Tab to a custom URL (see above issues as to why).

The concerns raised above are understandable however the resulting user experience suffers as a result. A person would understandably be confused about why one surface can have a custom URL applied to it while the other cannot. 

We should investigate a way to securely and safely save custom URL preferences and reinstate this functionality as part of the new preferences page. I'm pinging some folks in the related issues to start a conversation. Please pass along to others that might need to know or that can help.

Comment 1

[Ed Lee :Mardak]

It looks like part of the reason it was more dangerous before was that the user would get "stuck" and not know how to fix things as the easiest way was via about:config. If there was this about:preferences UI, that would maybe help users realize their new tab page is set to something else and have a way to change it.

Although even with a UI, keeping it as a pref (or any plain storage ?) still means another application can just constantly overwrite any user value. Although storing the data slightly differently could make it a little bit harder to reduce some abuse. ?

Comment 2

[Florian Quèze [:florian]]

about:config used to not be enough to de-hijack the new tab page. The pref was abused in at least 2 ways:
- overwriting the prefs.js file in the profile when Firefox was not running
- injecting a DLL into our Firefox process and using the XPCOM binary APIs to register a pref observer, which was used to set the value of the pref again to the hijacked value whenever the user changed the value from about:config.

At this point I think our binary XPCOM APIs are gone, so the main concern that remains is third party software writing directly to the preferences file. I think a reasonable way to mitigate this would be to save a verification hash along with the pref containing the url, to ensure the pref value has been written by Firefox. This is what the search service does when saving search settings (that are very tempting to hijack). See https://searchfox.org/mozilla-central/rev/7ccb618f45a1398e31a086a009f87c8fd3a790b6/toolkit/components/search/nsSearchService.js#770-775

Such a measure should also be applied to storing the homepage URL, see bug 1051082.

Comment 3

[Mike Conca [:mconca]]

We constantly get requests to add a WebExtensions API to override the new tab page with a custom URL. To date, we have chosen not to implement it for all of the reasons listed here and indirectly in comment 0. This has led to extensions using ugly, not-user-friendly workaround that trap new tab creation. Nothing malicious, but it leads to a bad user experience.

It feels like if the product supports it in a native and secure manner, then exposing that via WebExtensions makes more sense. Native Firefox users are happier, and developers don't have to resort to hacks, so extension users are also happier (which makes me happier).

Tim, I'm not sure where this falls in your list of priorities, but I can safely say that there would be huge demand from an extension developer point-of-view.

Comment 4

[Tim Spurway [:tspurway]]

I don't know that I can add much to the existing discussion, other than to say that if UX (and end-users) want this feature, and Engineering can enable safely and sanely without opening new doors to hijackers, then, by all means, let's do this.

Another thing to consider is bug 1401194, which enables an API so that developers can add a new section to Activity Stream as a Web Extension.  The idea here is to give a more integrated mode of customization.  We suspect that many use cases that replace the newtab page entirely will be better served by a finer grained mechanism like this.

Comment 6

[Andy Bajka]

It's possible to achieve this function using this add-on:

https://addons.mozilla.org/en-GB/firefox/addon/new-tab-homepage/

However it would be best to have this as a default function and not require an add-on to achieve.

Comment 8

[r.alex.hall]

This nuisance (that there's no programmatic way to select/clear/set the text in the URL bar) stands in the way of usability of this featured extension: https://github.com/cadeyrn/newtaboverride/issues/24#issuecomment-436997741

Comment 9

[jsherk]

So as I am not a developer and only an end user, all I can say is that it is a very annoying experience for me when I open a new tab and it is either the Firefox Home page or a Blank page ...

I just want to set it to a Custom URL just like my Home Page and New Windows.

I used to use the extension New Tab Override (which had over 100,000 users) but has now been disabled by Firefox and won't work anymore.

Seems to me that at least 100,000 people are interested in this feature.

Comment 10

[Sören Hentzschel]

(In reply to jsherk from comment #9)

I used to use the extension New Tab Override (which had over 100,000 users) but has now been disabled by Firefox and won't work anymore.

Seems to me that at least 100,000 people are interested in this feature.

Please read https://blog.mozilla.org/addons/2019/05/04/update-regarding-add-ons-in-firefox/

Comment 13

[Andy Bajka]

I agree this feature is very much needed. Here's another very similar feature request:

https://bugzilla.mozilla.org/show_bug.cgi?id=1266837

Either this feature or the one I linked would be a very much needed in Firefox. Both do basically the same thing.

Comment 14

[arbitrarytrajectory]

A question regarding security concerns: I currently use this autoconfig method to set a local file as my new tab page. If an attacker could theoretically modify the newtab URL via prefs.js, can't they theoretically modify it via this method as well? Why is a preference considered too insecure while this method is not? I would think having a clearly-visible preference is preferable to such obscure options; at minimum a hijacked user could see their preference was modified.

I hope that this feature is reimplemented, or if it truly must be relegated to an extension, that Mozilla publishes an official extension for the purpose. Users shouldn't need to rely on third-party extensions for core features.

Comment 15

[Andy Bajka]

I finally wrote a an add-on for this enhancement.

https://addons.mozilla.org/en-US/firefox/addon/newtabplus/

Comment 16

[Sören Hentzschel]

I finally wrote a an add-on for this enhancement.

There are already several add-ons for this purpose, for example https://addons.mozilla.org/en-US/firefox/addon/new-tab-override/. It was the first add-on with this functionality after the feature was removed in Firefox 41, it has more options, it is easier to set-up, it is available in more languages and it is "recommended" by Mozilla. Disclaimer: I am the developer of that add-on.

By the way: Your add-on has a bug. If you save an empty value as new tab URL you will get an infinity loop where tabs open and immediately close forever, making Firefox unsuable until you fix the setting via about:addons.

Comment 17

[duncan.ben]

This (unfortunately closed) enhancement request is blocking having a better UX for new tab extensions, but the ones mentioned above are better than nothing.

Comment 18

[arbitrarytrajectory]

Reading through the related bugs again, I'm struck by how few obstacles remain in the way of this change. This proposal has waited long enough that many of the concerns raised simply no longer apply, so we should get the ball rolling before new obstacles appear.

To summarize the other threads, the malware concerns around the old pref fell into two categories: specific vulnerabilities and user knowledge. The vulnerabilities have already been discussed in this thread. The user concerns focused on (lack of) awareness of homepage vs new tabs and the distinct pre-Activity Stream default pages. With the pref absent from about:preferences, users might be less likely to notice malicious changes, especially users who rarely used new tabs.

At present the default home and new tab pages have been unified, the associated prefs are now in about:preferences, and per comment 2 XPCOM pref hijacking is no longer possible. The only remaining obstacle is the prefs.js vulnerability... which is shared by not-removed browser.startup.homepage! And given that's gone unaddressed for eleven years I can only assume it's not a significant security issue.

So, possible solutions. A few come to mind:

1. Reinstate the new tab URL pref more or less as it was, just visible in about:preferences this time.
2. Add a "same as homepage" option to the new tab setting, allowing use of the same custom URL for both homepage and new tab.
3. Allow setting a new tab URL via policies, as can be done for the homepage.
4. Reinstate the new tab URL pref and finally secure both it and the homepage pref.

I'm inclined towards #2. Avoids re-adding the original vulnerability, relatively minor change, should satisfy most power users. If someone more official approves it I'd be happy to implement this.

Comment 19

[arbitrarytrajectory]

Florian, as the one here involved in removing the original pref, do you know who would be appropriate to make this decision?