In response to your last post, to help us get better positioned, I will attempt to layout the overall issue in a way that is generalized for distros like Whonix, Tails, etc…
Need: Custom Local Homepage for Tor Browser
Distributions that include Tor Browser as their primary web browser, for various reasons (project branding, user instruction, special web application, legal trademark, etc), may need/want to implement a custom default local homepage, without the burden of building each new version of Tor Browser from source code on behalf of their users.
Problems: Torbutton State and New Windows
Distributions can currently use a custom Tor Browser launcher script that passes a URL option to “start-tor-browser” for opening a custom webpage upon initial browser launch.
However, there are a couple fundamental shortcomings to this launcher script method:
1) Lack of Torbutton State on Homepage:
It would be beneficial for the local homepage of distributions that use Tor Browser to be able to access the “state” of Torbutton, so they can visually warn users when TBB needs updating or Tor is not connected, just as the original “about:tor” page does.
This Torbutton “state” is passed to the “about:tor” homepage via these CSS classes:
class="hideIfTorOn"
class="hideIfTorOff"
class="hideIfTorIsUpToDate"
class="hideIfTBBNeedsUpdate"
2) Opening New Windows Reverts to Default Homepage:
After a user launches Tor Browser with a distribution’s custom homepage launcher script, if they simply open a new browser window, the default “about:tor” homepage is reverted to.
It would be beneficial if a custom homepage were able to be persistent for distributions that use Tor Browser.
Suggested Solution: Make “kAboutTorURL” Conditional with Environment Variable
A ticket that would be a solution has been submitted by Patrick Schleizer to the Tor Project here:
[b]Sign in · GitLab
[b]Tor Browser's homepage is currently hardcoded in (aboutTor.js).[/b]
kAboutTorURL = "chrome://torbutton/content/aboutTor/aboutTor.xhtml";
It would be nice if there was an TOR_HOMEPAGE environment variable to configure this. Would be useful for (linux) distributions that want to set a divergent default.
This would keep the homepage URL as “about:tor” but allow distributions to use their own custom local webpage as the homepage content. And allow for the 2 mentioned problems to be properly resolved (Problems: Torbutton State and New Windows).
If the Tor Project did not want to allow other distributions to modify or replace the content associated with the “about:tor” homepage URL…
Then an additional “about:” URL could be registered and used by Torbutton if a custom homepage Environment Variable is set by a distribution.
Potentially using another “about:” URL, if “about:tor” is considered taboo, for example:
about:homepage
about:start
about:anon
about:distro
etc
Torbutton would have to register any such additional “about:” URL for this purpose, if using “about:tor” would be a taboo issue.
Non-Ideal Other Solution: Make “browser.startup.homepage” Conditional with Environment Variable
Another non-ideal solution has been discussed and submitted, involving conditionally setting “browser.startup.homepage” to a local homepage “file://” path, when a custom homepage Environment Variable is set by a distribution.
This is non-ideal, compared to the solution of making the “kAboutTorURL” variable be conditional to an Environment Variable.
It does not resolve problem #1) Lack of Torbutton State, because Torbutton is only able to pass its “state” to “about:tor” or another purposefully registered “about:” URL.
Non-Ideal Torbutton State Workaround
If the ideal “kAboutTorURL” solution is not implemented…
A non-ideal workaround for passing similar Tor-related “state” information to a distribution’s custom local homepage would be to:
Develop an extra external program that independently queries Tor Browser versions and Tor connection information, and then dynamically overwrites a JavaScript or DTD file with such “state” information.
Then the custom local homepage could call that file in a standard way to retrieve the “state” info.
However, this is non-ideal, because:
-
It places higher and unnecessary development demands upon distributions for an already built-in feature of Torbutton.
-
It likely means that distributions will have to regularly initiate internet queries to get Tor Browser update information, where such network traffic patterns, different from Torbutton, could lead to additional external fingerprinting of a specific distribution in use.
