Local browser homepage for Tor Browser in Whonix

Currently we’re using about:blank when Tor Browser is started in Whonix. A blank page.

TBB’s default is about:tor, which we should not use in Whonix, because it is too Tor specific, contains the Tor trademark and confusing for Whonix users.

It would be nice to have our own local browser homepage in Tor Browser. (Homepage means start page here, the default page that is shown when the browser starts.)

nanohard (http://nanohard.net) offered to implement it.

“Local” means here, that we will supply the html files together with Whonix. It must only use resources, which are stored on the local hard
disk. None from the internet. Having all users who start Tor Browser in Whonix connecting to an online resource such as whonix.org would be
bad for both, security and privacy reasons.

Whonix’s local homepage would contain similar content as about:tor. But we must use a design that cannot be confused with The Tor Project for trademark reasons.

Do you have any suggestions for the content and design of that local Whonix Tor Browser homepage?

It should either be about:tor, blank, or a really well-designed and simplistic page.

But what is your goal? Do we really need a page that every user must see every time they use Tor Browser?

I would prefer about:tor or blank unless there is a good reason or good example provided.

However, having some local files which is linked from the desktop might be a better way, if you want to provide documentation about Whonix, not the Tor Browser. I mean not for every time browsing the web, but a link on the desktop for interested users.

It should mimic the layout of the TBB start page, except with our own logos of course with a blue theme . It should also have a searchbox that uses Starpage.com and be able to notify if there is a new version of TorBrowser available.

[quote=“z, post:2, topic:347”]But what is your goal? Do we really need a page that every user must see every time they use Tor Browser?

I would prefer about:tor or blank unless there is a good reason or good example provided.[/quote]
about:blank is too confusing.

And about:tor is not an option, because The Tor Project really dislikes if someone confuses The Tor Project with Whonix.

Offline documentation would be nice as well, but it’s quite some effort to implement and maintain.

It must use a completely different design. Once someone did mimic the torproject.org homepage with its own project and they were not amused.

Good idea. I hope this will be technically possible.

A fork of TBB just for this feature would not be justified. That would be too much effort. And I didn’t make good experiences getting patches merged into TBB. ( Document environment variable we support (#7266) · Issues · Legacy / Trac · GitLab ) No review after months for such a simple patch.

How does about:tor know if Tor Browser is up to date or not? TorButton finds that out and somehow provides a variable for about:tor. I hope we can re-use it without using about:tor as link.

[quote=“Patrick, post:4, topic:347”]about:blank is too confusing.

And about:tor is not an option, because The Tor Project really dislikes if someone confuses The Tor Project with Whonix.[/quote]

I don’t know. That’s why I’m asking. Are you sure that Tor Project was unhappy of about:tor on Whonix? Did you ask, any links? If you have other reasons, that’s ok, but this argument sounds weird.

They didn’t specifically mention about:tor yet, but other things, and I’ve learned to become very cautious over time. There wasn’t an easy to find reference to make that point, that they are quite protective about their trademark. I’ve started creating a page for reference where I’ll collect examples, that show that this trademark topic is a really hot one:

I want to act in good faith to make it absolutely impossible for anyone to confuse Tor Project / Whonix Project. Even if it is/was legally okay to reuse their design with different colors and logos, I want to maintain good relationship with TPO - that includes making it impossible for anyone to confuse Tor Project / Whonix Project. They don’t like getting disturbed by receiving Whonix support requests and I can understand that.

I too follow the trademark issues surrounding the Tor Project and in this context it just doesn’t make any sense to me. Maybe I just don’t get it but I don’t believe about:tor would ever cause a problem with Tor Project. Maybe we should ask, I think they would be happy to see Tor Browser being used in the original way

The documentation claims that Whonix uses Torbrowser without alterations and that it has the same fingerprint. If you have your own homepage won’t this make it obvious (to exit nodes or traffic analysts) that we are using Whonix? This would drastically lower our crowd size.

We already have whonixcheck for update alerts.

Using about:blank also seems like it would be best for stream isolation. Seems like it wouldn’t leak the fact that you just opened a browser window.

The problem is, I am not allowed to publish the mails we exchanged a while ago. And without transparency, I can’t make my point. In my experience, they are unable to make any clear statements to such kind of questions. Either because no one feels responsible or wants to be responsible or due to being overworked. In any case, the only really safe stand would be a written permission, which they are very unlikely to issue.

The other point is, that they really dislike people contacting torproject support with Whonix questions. Understandable. If I learned anything during Whonix development, it is that Murphy’s law “Anything that can go wrong will go wrong.” is absolutely true. From 1000 users, X users clicks the link to The Tor Project homepage, then clicks support and asks a question about Whonix. No big issue there. But as the number of Whonix users increases, support requests to the wrong place increase as well. At some point they get annoyed. And that’s something I want to prevent.

We still wouldn’t alter it, just start it with a parameter, that tells it what start page to open - a local file on the hard drive. No resources will be fetched from the internet.

No, because the local homepage won’t make any connections to any internet resources. All design/text will be stored on the hard drive.

I don’t see how exit relays could possibly find out, that local homepage has been /usr/share/whonix/local_homepage/index.html instead of about:tor - because no resources from the internet are load.

A homepage set as whonix.org/wiki/welcome_whonix_user [even worse without https] would indeed be a very bad idea. The circuit would go dirty, could be marked as “Whonix user”. But that is not going to happen!

Edit:
typo, recourses → resources

How does about:tor know if Tor Browser is up to date or not? TorButton finds that out and somehow provides a variable for about:tor. I hope we can re-use it without using about:tor as link.

it seems to work in a simialr way to whonixcheck where it communicates with the check.torproject.org and checks the listed versions against the one installed locally. How this affects our threat model where we don’t want all Tor users to auto-connect to the same location is hard to figure.

check.torproject.org does not test the version of your TBB (Tor Browser Bundle). The test is performed by the TBB itself and the information is explicitly passed to the server.

In the Firefox preferences check the Home Page setting. When TBB is up to date you will see:

https://check.torproject.org/?lang=en-US&small=1&uptodate=1

when TBB is out of date, you will see:

https://check.torproject.org/?lang=en-US&small=1&uptodate=0

So TBB itself (precisely said Torbutton) downloads list of recommended TBB versions, compares the installed version to it and tells the check.torproject.org server if it is up to date by the uptodate parameter in the URL. The check is performed by the Torbutton Firefox extension and then the Home Page is updated accordingly. See torbutton.js.

If check.torproject.org was able to directly see your TBB version then it would be a very serious security flaw.

An older post on the tor blogs from Roger:

On May 25th, 2012 arma said:

First, TBB 2.2.35-13 is out, so it is right that you should upgrade.

As for the bug, Torbutton in TBB loads https://check.torproject.org/RecommendedTBBVersions and checks if its version is in the list. It then sends you to the “you need to update” page if needed. So Torbutton in TBB is the one checking if you’re up to date, not some magic run on the check.torproject.org side.

If its a small and audited piece of code that can fetch and read this info from check.torproject then its a safe mechanism to do things.

If you don’t feel like fiddling with torbutton.js, why not rely on whonixcheck for reporting the TorBrowser version?

I hope we don’t have to write our own code for this. It will probably get more complicated than that. Tor Button doesn’t check on each start, it has an interval on which it checks. And it also doesn’t just check when the browser starts. Also during a session, Tor Button may start notifying about and update.

Because if we’re lucky, we don’t have to fiddle with torbutton.js - because it already does its job by setting variables, which we can re-use in our local file. Apart from this, nanohard states on his homepage, that he also knowns javascript. So for a clean solution, if all cords break, we can also consider submitting Tor Button javascript patch to upstream.

Sure, I know enough JS to get by; I could add an alert to about:whonix or a sub-page that informs the user there’s an update to Whonix and anything else.

Does anyone know the about:config setting(s) which deal with the local ‘about:’ pages? How would I set up a new right-side word, like “about:slimy_pancakes”?

I guess it is best to go to /home/user/tor-browser_en-US/Data/Browser/profile.default/extensions/torbutton@torproject.org (after extracting the xpi) and to search that folder for “about:tor”. Seems to be implemented here:

/home/user/tor-browser_en-US/Data/Browser/profile.default/extensions/torbutton@torproject.org/components/aboutTor.js /home/user/tor-browser_en-US/Data/Browser/profile.default/extensions/torbutton@torproject.org/chrome/content/torbutton.js

Adding a about:whonix probably requires either a separate Firefox extension or a Tor Button patch. A separate add-on would be problematic, because we don’t modify Tor Browser for reasons of simplicity and robustness - we just set environment variables that Tor Browser honors.

A Tor Button patch that adds support for configuring arbitrary browser home pages or skinning support for about:tor would be nice, be questionable how fast it gets review and merge.

Can we implement this local homepage using a location on the disk such as /usr/share/whonix/local_homepage/index.html ?

If we were to use /usr/share/whonix/local_homepage/index.html - would we have same access to a few variables Tor Buttons sets (such as up to date yes/no) as about:tor?

If that works out…

Usually Tor Buttons sets…

browser.startup.homepage=about:tor

Maybe we could propose a much simpler, smaller patch. That adds this feature:
If environment variable TOR_BUTTON_HOMEPAGE exists, browser.startup.homepage=$TOR_BUTTON_HOMEPAGE, else set browser.startup.homepage=about:tor.

This would be nice. I’ll check out the source code, but not sure if I can help with that. I don’t see digging up that block of code to be an easy task, since I don’t know where to look, but I’ll look anyway.

That’s what I’m trying to figure out. I’m not sure how the browser sets the location for these files. I could just edit the default files, but would like to avoid doing that and just set an “about:whonix” that points to a new disk location- this would be easier to add things to the local Whonix pages and would allow users to also still view “about:tor”.

It depends on what variables and how they’re accessed, but usually, yes. I say “depends” because I’m not sure how much I can change without affecting other things; a workaround may be to copy some original Tor JavaScript files that are used and link/change the variables from the new file.
I have t o play around with it.
As for “is Tor Browser up-to-date?”, that shouldn’t be too difficult for me- just need to view the Tor Button JavaScript and see how it works.

What you could also do is join irc.oftc.net #tor-dev and try to talk to mikeperry. He could say where that’s implemented and how a patch could be accepted. And if he’s not available, I could post a feature request on trac.torproject.org. Then you could ask where it is currently implemented and roughly on how to implement the new feature.

a workaround may be to copy some original Tor JavaScript files that are used and link/change the variables from the new file.
I could just edit the default files, but would like to avoid doing that
Yes. Because then we would maintain a fork of Tor Button in the long run, which seems wrong, since Tor Button is regularly updated.

The problem is, Tor Browser can not be installed from Debian using apt-get. Maintaining a fork with changes would be very difficult. It gets downloaded by tb-updater and started by tb-starter. In past the updater broke a few times, because The Tor Project (tpo) changed download locations, signing method. We now have a robust implementation. Should tb-updater break, users can manually download and extract Tor Browser from tpo. No modifications required by the user.

So for a robust and easily maintainable solution in long term our options are:

  • Influence Tor Button"from the outside" without modifying it by using a start parameter such as: /home/user/tor-browser_en-US/Browser/firefox --profile Data/Browser/profile.default --new-tab /usr/share/whonix/local_homepage/index.html

  • Submit a patch to Tor Button, that is mergable from tpo’s perspective, that reads some environment variable and/or somehow else enables distributions to use different browser home pages and or skins.

[Such we could submit a patch to Tor Button that includes html files, and when WHONIX=1 environment variable is set, open about:whonix, otherwise open about:tor. - But I guess they are less likely to be happily merge such a thing.]

I guess smaller patches without saying “Whonix” are most likely to get merged.

components/aboutTor.js uses:

const kAboutTorURL = "chrome://torbutton/content/aboutTor/aboutTor.xhtml";

Maybe we could do something like this:

if environment variable WHONIX=1
components/aboutTor.js:const kAboutTorURL = “/usr/share/whonix/local_homepage/index.html”;
else
components/aboutTor.js:const kAboutTorURL = “chrome://torbutton/content/aboutTor/aboutTor.xhtml”;

and just set an "about:whonix" that points to a new disk location- this would be easier to add things to the local Whonix pages and would allow users to also still view "about:tor".
Yes.

nanohard isn’t working on this anymore. Looking for contributor!

Submitted a git branch that implements the TOR_HOMEPAGE environment variable, so we could point to Whonix’s local homepage:

Still looking for a contributor to create a local Whonix homepage!

I’d be happy to contribute this work.

What is needed at this point?

  • Design/Layout?
  • HTML/CSS Code?
  • JavaScript Features?

I’ve got a bit of extra spare time at this point to get a task like this done.

I'd be happy to contribute this work.

Great!

What is needed at this point?
I'll take time now, reread this thread what we already discussed. Maybe we need a new one, because this wasn't really a content/design discussion. It was more of if we should/should not go for it and javascript and such. Will get back to that question.

[hr]

WhonixQubes, you are speaking JavaScript? :slight_smile:

I don’t. Just hacked together two patches. Please have a look: