Frequently Asked Questions

• Email - Server and Mutt client configured for use with GPG and Emacs or Vim
• DLNA - Play music on your local network devices
• Dokuwiki - Databaseless wiki
• GNU Social - Federated social network and resource sharing system
• Gogs - Host your git projects
• qTox - Chat and VoIP client on mesh networks
• HTMLy - Databaseless blogging system
• Pelican - Static blogging system used on mesh networks
• Hubzilla - Federated social networking and web publishing
• IRC server
• Obnam - Encrypted backups to USB or to other servers
• Mumble - VoIP and text chat
• pi-hole - Block internet ads on your local network
• tt-rss - Accessible via an onion address to give you the right to read from any device
• sipwitch - Telephony system
• Syncthing - File sync
• IPFS - For accessing sites on a mesh network
• Toxcore/Toxic - Bootstrap node and client
• XMPP server - Including XEPs needed to support the Conversations Android app with OMEMO
• Shell based web browser - if all else fails then ssh to your server and browse from there

Yes. The minimum requirements are to have some hardware that you can install Debian onto and also that you have administrator access to your internet router so that you can forward ports to the system which has Freedombone installed.

The lack of a static IP address can be worked around by using a dynamic DNS service. Freedombone uses inadyn , which supports a variety of dynamic DNS providers.

When the project began in late 2013 the FreedomBox project seemed to be going nowhere, and was only designed to work with the DreamPlug hardware. There was some new hardware out - the Beaglebone Black - which could run Debian and was also a free hardware design so seemed more appropriate. Hence the name "Freedombone", being like FreedomBox but on a Beaglebone. There are some similarities and differences between the two projects:

The FreedomBox project supports Raspberry Pi builds, and the image build system for Freedombone is based on the same system. However, although the Raspberry Pi can run a version of Debian it requires a closed proprietary blob in order to boot the hardware. Who knows what that blob might contain or what exploits it could facilitate. From an adversarial point of view if you were trying to deliver "bulk equipment interference" then it doesn't get any better than piggybacking on something which has control of the boot process, and hence all subsequently run processes.

So although the Raspberry Pi is cheap and hugely popular it's not supported by the Freedombone project. Perhaps future versions of the Pi won't have the proprietary blob requirement, or maybe the blob will be open sourced at some stage.

Github is paradoxically a centralized, closed and proprietary system which happens to mostly host free and open source projects. Up until now it has been relatively benign, but at some point in the name of "growth" it will likely start becoming more evil, or just become like SourceForge - which was also once much loved by FOSS developers, but turned into a den of malvertizing.

At present Github is useful just because of the sheer number of eyeballs and the easy discoverability of projects via search.

The source code for this project is experimentally independently hosted, and it is expected that in future the main development will shift over to an independent site, maybe with mirrors on Github if it still exists in a viable form.

Currently many of the repositories used for applications which are not yet packaged for Debian are on Github, and to provide some degree of resilliance against depending too much upon that it's possible to use mirrors stored on another server.

Ordinarily this is good advice. However, the threat model for a device in your home is different from the one for a generic server in a massive warehouse. Compare and contrast:

In the home environment a box with a good firewall and no GUI components installed may be much more secure than the end points, such as laptops and phones.

Probably you need to add the site to the NoScript whitelist. Typically click/press on the noscript icon (or select from the menu on mobile) then select whitelist and add the site URL. You may also need to disable HTTPS Everywhere when using onion addresses, which don't use https.

It was originally designed to run on the Beaglebone Black, but that should be regarded as the most minimal system, because it's single core and has by today's standards a small amount of memory. Obviously the more powerful the hardware is the faster things like web pages (blog, social networking, etc) will be served but the more electricity such a system will require if you're running it 24/7. A good compromise between performance and energy consumption is something like an old netbook. The battery of an old netbook or laptop even gives you UPS capability to keep the system going during brief power outages or cable re-arrangements, and that means using full disk encryption on the server also becomes more practical.

Out of fashion but still working computer hardware tends to be cheap and readily available, yet still good for providing internet services.

Yes. Freedombone can support a small number of users, for a "friends and family" type of home installation. This gives them access to an email account, XMPP, SIP phone and the blog (depending on whether the variant which you installed includes those).

ssh username@mydomainname -p 2222

Select Administrator controls then Manage Users and then Add a user. You will be prompted for a username and you can also optionally provide their ssh public key.

Something to consider when having more than a single user on the system is the security situation. The original administrator user will have access to all of the data for other users (including their encryption keys), so if you do add extra users they need to have complete trust in the administrator.

Another point is that Freedombone installations are not intended to support many users (maybe ten at most). Large numbers of users may make the system unstable, and the more users you have on one system the more it becomes a single point of failure and also perhaps a honeypot from the standpoint of adversaries. Think of what happened with Lavabit and the moral dilemma which an administrator can be faced with (comply with threats and betray the trust of your users or don't comply and suffer other consequences). Ideally, you never want to put yourself into a situation where you can be forced to betray others.

Celebrities recommend Signal. It's Free Software so it must be good, right?

If you are currently using a proprietary chat app, something without any encryption or something really bad such as Telegram, then Signal is definitely a step up in terms of security. But Signal has problems, which can be summarised as:

• It's based on a single server run by Open Whisper Systems. That's a single point of failure and ought to be a big red flag (of the sporting rather than the socialist variety) as a possible locus for concentrated nefariousness.
• It requires the installation of Google Play. If you already have Google Play installed on a stock Android OS then this doesn't increase your security problems, but for other more secure Android variants it's a massive increase in attack surface.
• It depends entirely upon the Google message pushing system. That means that Google at least knows who Signal messages are being sent to and may be able to infer the rest via your (insecure) Android phone contact list or via timing correlation of alternating deliveries. Remember that for an adversary metadata in aggregate is much better than having the content of messages. At any time Google could decide that it doesn't want to support Signal, or in adverse circumstances they could be leaned upon by the usual agencies or government cronies.
• Their privacy policy indicates that they will give whatever server data they have to third parties under some conditions. Of course this is always claimed to be for the very best of reasons - such as combating fraud - but once that sort of disclosure capability exists it may be abused without you ever knowing about it.

To give credit where it's due Signal is good, but it could be a lot better. The real solution for private chat is to run your own XMPP server, as you can with Freedombone, or to have someone within your community do that. There is no substitute for a decentralised solution which is within the control of your community.

On mobile there are various options. The apps which are likely to be most secure are ones which have end-to-end encryption enabled by default and which can also be onion routed via Orbot. End-to-end encryption secures the content of the message and onion routing obscures the metadata, making it hard for a passive adversary to know who is communicating with who.

The current safest way to chat is to use Conversations together with Orbot - both of which can be installed from F-droid. You may need to enable the Guardian Project repository within F-droid in order to be able to install Orbot. Within the settings of the Conversations app you can set it to route via Tor, and also you can use the XMPP service of your Freedombone server. That way all of the software infrastructure is controlled by you or your community.

There are many other fashionable chat apps with end-to-end security, but often they are closed source, have a single central server or can't be onion routed. It's also important to remember that closed source chat apps should be assumed to be untrustworthy, since their security cannot be independently verified.

To remove a user:

ssh username@mydomainname -p 2222

Select Administrator controls then Manage Users and then Delete a user. Note that this will delete all of that user's files and email.

The tripwire will be automatically reset once per week. If you want to reset it earlier then do the following:

ssh username@mydomain -p 2222

Select Administrator controls then "reset tripwire" using cursors and space bar then enter.

"We kill people based on metadata"

– Michael Hayden

Even when using Freedombone metadata analysis by third parties is still possible. This can be mitigated by accessing your blog, or other web services, via their onion addresses, rather than via more conventional domain names. In that case your ISP and any government which they might be compelled to report back to will know when your system is being accessed, but not necessarily which services are being accessed or by whom. So for instance using a Tor browser and the onion address people may be able to safely read your blog or wiki and be reasonably confident that metadata isn't being gathered about what they read (or more concisely the metadata which can be gathered by a third party may just not be very useful or personally identifiable). On the other hand if you access the system via conventional domain names and dynamic DNS then it's safe to assume that metadata can and will be collected by third parties.

ssh username@domainname -p 2222

Select Administrator controls then Email Filtering Rules then you can add rules to be applied to incoming email addresses or mailing lists. If you prefer to do things directly on the command line, without the control panel, then the following commands are available:

Spamassassin is also available and within Mutt you can use the S (shift+s) key to mark an email as spam or the H (shift+h) key to mark an email as not being spam. So by using a combination of email rules and spam filtering you should be able to avoid any spammers or trolls.

If you run the command:

systemctl status inadyn

And see some error related to checking for changes in the IP address then you can try other external IP services. Edit /etc/inadyn.conf and change the domain for the checkip-url parameter. Possible sites are:

https://check.torproject.org/
https://www.whatsmydns.net/whats-my-ip-address.html
https://www.privateinternetaccess.com/pages/whats-my-ip/

Suppose that some new encryption vulnerability has been announced and that you need to change your encryption settings. Maybe an algorithm thought to be secure is now no longer so and you need to remove it. You can change your settings by doing the following:

ssh myusername@mydomain -p 2222

Select Administrator controls then select Security Settings. You will then be able to edit the crypto settings for all of the installed applications. Be very careful when editing, since any mistake could make your system less secure rather than more.

Suppose that you have bought a domain name (rather than using a free subdomain on freedns) and you want to use that instead.

Remove any existing nameservers for your domain (or select "custom" nameservers), then add:

NS1.AFRAID.ORG
NS2.AFRAID.ORG
NS3.AFRAID.ORG
NS4.AFRAID.ORG

It might take a few minutes for the above change to take effect. Within freedns click on "Domains" and add your domains (this might only be available to paid members). Make sure that they're marked as "private".

Select "Subdomains" from the menu on the left then select the MX entry for your domain and change the destination to 10:mydomainname rather than 10:mail.mydomainname.

To route email to one of your freedns domains:

editor /etc/mailname

Add any extra domains which you own, then save and exit.

editor /etc/exim4/update-exim4.conf.conf

Within dc_other_hostnames add your extra domain names, separated by a colon ':' character.

Save and exit, then restart exim.

update-exim4.conf.template -r
update-exim4.conf
service exim4 restart

You should now be able to send an email from postmaster@mynewdomainname and it should arrive in your inbox.

If you did the full install or selected the social variant then the system will have tried to obtain a Let's Encrypt certificate automatically during the install process. If this failed for any reason, or if you have created a new site which you need a certificate for then do the following:

ssh username@mydomainname -p 2222

Select Administrator controls then Security settings then Create a new Let's Encrypt certificate.

One thing to be aware of is that Let's Encrypt doesn't support many dynamic DNS subdomains, such as those from freeDNS, so to run Hubzilla and GNU Social you will need to have your own official domains for those. There are many sites from which you can buy cheap domain names, and while this isn't ideal in terms of making you dependent upon another company it's the only option currently.

Normally certificates will be automatically renewed once per month, so you don't need to be concerned about it. If anything goes wrong with the automatic renewal then you should receive a warning email.

If you need to manually renew a certificate:

ssh username@mydomainname -p 2222

Select Administrator controls then Security settings then Renew Let's Encrypt certificate.

Most likely it's because Let's Encrypt doesn't support your particular domain or subdomain. Currently free subdomains tend not to work. You'll need to buy a domain name, link it to your dynamic DNS account and then do:

ssh username@mydomainname -p 2222

Select Administrator controls then Security settings then Create a new Let's Encrypt certificate.

Almost everywhere on the web you will read that self-signed certificates are worthless. They bring up scary-scary looking browser warnings and gurus will advise you not to use them. Self-signed certificates are quite useful though. What the scary warnings mean - and it would be good if they explained this more clearly - is that you have an encrypted connection established but there is no certainty about who that connection is with. They probably will protect the content of your communications from passive bulk interception - such as the tapping of under-sea cables.

The current strategy on this system is to typically create self-signed certificates during the initial installation but also to have the ability to easily convert those to LetsEncrypt certificates via the security settings on the administrator control panel.

You might say, "but surely LetsEncrypt is a single point of failure!", and you'd be right. Maybe at some point in future LetsEncrypt is no longer a thing, or no longer considered sufficiently secure. That's why building in total dependence upon one organisation is a bad idea, and it's still possible to have self-signed certs as a fallback option.

That pledge is utterly worthless. Years ago people trusted Google in the same sort of way, because they promised not be be evil and because a lot of the engineers working for them seemed like honest types who were "on our side". Post-nymwars and post-PRISM we know exactly how much Google cared about the privacy and security of its users. But Google is only one particular example. In general don't trust pledges made by companies, even if the people running them seem really sincere.

Welcome to the world of email. Email is really the archetypal decentralized service, developed during the early days of the internet. In principle anyone can run an email server, and that's exactly what you're doing with Freedombone. Email is very useful, but it has a big problem, and that's that the protocols are totally insecure. That made it easy for spammers to do their thing, and in response highly elaborate spam filtering and blocking systems were developed. Chances are that your emails are being blocked in this way. Sometimes the blocking is so indisciminate that entire countries are excluded. What can you do about it? Unless you control the block list at the receiving end you may not be able to do much unless you can find an email proxy server which is trusted by the receiving server.

Often ISPs will run their own SMTP mail server which you can use for proxying, typically called mail.ISPdomain. On the administrator control panel there is an option to set the details for outgoing email from the Mutt client.

ssh username@mydomainname -p 2222

Select Administrator controls then Outgoing Email Proxy and enter the details for your ISP SMTP server.

This may work, at least when using Mutt, and admittedly if it does then it's a compromise in which you are using some infrastructure which is not controlled by the community - with all of the usual hazards which go along with that.

The current arrangement with email blocking works well for the big internet companies because it effectively centralises email to a few well-known brand names and keeps any independent servers out, or creates dependencies like the one just described in which you become a second class citizen of the internet.

So the situation with email presently is pretty bad, and there's a clear selection pressure against decentralization and towards only a few companies controlling all email services. Longer term the solution is to have more secure protocols which make spamming hard or expensive.