Yes. It can be found here.

In the old days codes of conduct were controversial. It was considered unthinkable that anyone's behavior might be less than completely stellar and that second order cybernetics was unnecessary in the production of software. But of course this was hopelessly naive, and over a long period of time it became abundantly clear that software licenses are not sufficient to govern a developer community. Bad faith actors often join good communities to disrupt them, and this applies especially to any community whose aims are political and run counter to software industry norms.

It is often said that if you are not the customer you're the product being sold, but these days you're not even a saleable product anymore. You're more like the raw material which goes into the making of an advertising product. Or the bait being dangled to get advertisers to spend money on targeted ads. As far as Big Tech is concerned, your interests or human rights are an irrelevance, so if you drop off of the map due to some arbitrary automated decision they've made then it doesn't make much of a ding in their quarterly profit.

The current dominant business model of the internet - Surveillance Capital - started in the early 2000s but really got going in the late 2000s with the appearance of Cloud Computing. It's why many older techies consider the mid 2000s to be the peak of freedom-respecting internet culture, in which internet related companies were somewhat benign and often supported open protocols and decentralized architectures.

It wasn't that companies prior to the mid 2000s didn't want world domination. It's that the technology before then was too limited to support databases containing billions of users. Decentralization was favored not for political reasons but because a high degree of centralization wasn't technically attainable. As those limitations fell away and cloud computing took over the political benefits which come from decentralization also faded.

It's based upon the stable version of Debian, which is currently Bullseye (version 11)

With LibreServer installed, whether the differences from upstream Debian are sufficient to call it a distro in its own right is really subjective decision.

In security discussions there is often talk about threat models, but they rarely seem to be defined. The threat model for this system is documented here.

Yes. You might want to change the branding and the upstream repo. The only requirement is that you abide by the terms of the AGPL license. Free Software is about freedom, not price, so there's nothing stopping you from charging for it. You may also want to use the libreserver-distro command to create a disk image which can be redistrinuted without needing to initially ssh to the box. For further information see the contact details.

See here for the complete list of apps. In addition to those as part of the base install you get an email server.

No. The internet was once much more decentralized than it is now, but roughly between 2005-2020 it became extensively centralized. What people back in the early version of the internet lacked was an attitude of fierce independence and anti-colonialism. Unless you're educated enough to recognize sometimes deviously subtle centralizing tactics when you see them, and willing enough to resist such tactics, then you will fall back into centralized silos with temporary comfort or convenience in the short term and disposessed servitude in the long term.

Yes. From the administration screen select Settings then Members then the account to send admin notifications to.

Check Receive admin notifications then select the Submit button.

The admin notifications will now be diverted to that account. This can be useful if the administrator is unavailable and you want someone else to keep an eye on the server, or of you want to leave the admin account untouched and do most things on an unprivileged account, which improves security a little.

If you want to financially support this project it has a Patreon and LiberaPay is also available.

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 LibreServer installed.

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

In general, no. But it depends on the details of what the difference is between a standard and business account from your ISP.

There can be big differences in the performance of microSD cards, and the cheaper ones are almost invariably terrible and/or unusable. Sandisk and Samsung currently appear to be the better brands. You can find some performance benchmarks here. However, benchmarks like this only give a very rough idea of performance and they can vary significantly between individual cards even within the same brand.

If you're struggling to get good performance out of your microSD card then you might want to consider running from a SATA drive or SSD instead. Some boards such as Cubieboard and Olinuxino have SATA sockets such that you can connect an SSD. It doesn't have to be high cost and the smallest SSD you can find will probably be enough. It's then possible to build an image with the –sata option or download one of the pre-built ones and copy it both to the microSD and SATA drive. SSD drives can give a 10x performance improvement over just using a microSD card.

Full disk encryption helps with laptop security, but on a server uptime is expected to be close to 100% and full disk encryption only provides protection when the machine is powered off and unused. This means that such encryption provides very little useful security for a server.

There is also the additional problem that electrical power outages may leave you with an unusable server for long periods of time if you don't always have physical access to it (eg. out at work, or on holiday) to enter a disk encryption password. LibreServer typically runs on single board computers where there is not expected to be a screen and therefore it may be difficult to enter a disk password during the boot sequence.

If you do need full disk encryption and the above points are not relevant then you can install Debian stable with LUKS and then do a manual setup of LibreServer after that with libreserver menuconfig.

Yes. Raspberry Pi is the world's most popular single board computer. From a software freedom point of view it's not ideal, because it uses a closed operating system owned by Microsoft called ThreadX, and the Linux based operating system is a secondary one running on top of that. You can think of ThreadX as being the Intel ME equivalent on the Pi, with similar security issues.

Due to its ubiquity, from an operational security point of view it may in some places be possible to anonymously obtain a Raspberry Pi in a shop paying in cash. All other boards are typically bought new in a much more traceable way. Depending upon what kind of regime you're living under, this may be an important consideration.

Years ago Tor was usually depicted in the mainstream media as something scary inhabited by cyberterrorists and other bad cybers, but today to a large extent Tor is accepted as just another way of routing data in a network. Depending upon where you live there may still be some amount of fearmongering about Tor, but it now seems clear that the trajectory is towards general acceptance.

Tor and its onion addresses, previously called hidden addresses, have a few key advantages:

• NAT traversal
• Firewall traversal
• Avoiding the domain name system (DNS), which is mostly centralized and not secure
• Avoiding passive bulk surveillance in which governments try to find out who is communicating with who

On the negative side it's a complex system which is not fully decentralized.

Within this project Tor is used more to provide accessibility than the anonymity factor for which Tor is better known. The onion address system provides a way of being able to access sites even if you don't own a conventional domain name or don't have administrator access to your local internet router to be able to do port forwarding.

Tor is installed by default, but it's not configured as a relay or exit node. From the administrator control panel you can optionally set up a Tor bridge, but this is only for adverse situations and not usually advisable.

When you install an app you will be able to access it from its onion address.

Even if you're running the "onion only" build, this only means that sites are accessible via onion addresses. It doesn't mean that everything gets routed through Tor. If full anonymity is your aim then it's probably a good idea to just stick strictly to using TAILS.

You could if you manually edited the relevant nginx configuration files and installed some dynamic DNS system yourself. If you already have sysadmin knowledge then that's probably not too hard. But the builds created with the onion-addresses-only option aren't really intended to support access via clearnet domains.

Data protection laws such as GDPR in the EU or the Data Protection Act in the UK usually only apply to formal organizations which are recognized as being legal entities. So you have to be running a business or a charity or some other formal organization in order for the storage of what's known as personally identifying information to potentially become a legal issue. Laws like this usually include:

• A right to obtain your information
• A right to be forgotten (i.e. to have your data permanently deleted)
• Ensuring that stored personal data remains accurate

If you're self-hosting then in the language of data protection law the "data controller" and the "data subject" are one and the same, so there isn't any power differential of that sort. Each LibreServer server is only intended to be used by a small numbers of people typically in the same household, so if you are hosting more than one person chances are that you know the others quite well and can arrange to update their data or delete their account if that's needed. Even if data protection laws are later extended to include home server type scenarios it's unlikely that this will become a problem.

This system tries to block port scanners. Any other system trying to scan for open ports will have their IP address added to a temporary block list for 24 hours.

It's not recommended unless there exists some compelling reason for you to be on there. That site asks people to upload the private keys, and even if the keys are client side encrypted with a passphrase there's always the chance that there will be a data leak in future and letter agencies will then have a full time opportunity to crack the passphrases.

Saying something resembling "only noobs will use crackable private key passphrases" isn't good enough. A passphrase should not be considered to be a substitute for a private key.

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.

It can take a while for the onion address to become available within the Tor network. In tests the amount of time between creating a site and being able to access it's onion address seems to vary between a minute or two and half an hour. So don't be too impatient if the address doesn't appear to resolve straight away.

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. LibreServer can support a small number of members, for a "friends and family" type of household installation. This gives them access to an email account, XMPP, VoIP, Nextcloud and possibly other apps which have been installed.

It's simple to add new members via the web interface, which on the local network can be accessed via http://libreserver/admin, or via its onion address remotely.

There are many reasons why using Signal is not always the greatest option for private chat, but ultimately Signal is centralized and this gives whoever is running the server an enormous amount of political power. It's much better to run the server infrastructure yourself, then you can have far greater confidence that nothing dodgy is going on.

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 LibreServer server. That way all of the software infrastructure is controlled by you or your community.

Another possibility is the Briar app, which is peer-to-peer and runs over Tor. This may be more convenient, since it doesn't require Orbot to be installed.

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 and so have no metadata protection. It's also important to remember that closed source chat apps should be assumed to be untrustworthy, since their security cannot be independently verified.

Log into the web interface, select members then the person's nickname. You can then select the remove button.

If you're making profits out of the logs by running large server warehouses and then data mining what people click on - as is the business model of well known internet companies - then logging everything makes total sense. However, if you're running a home server then logging really only makes sense if you're trying to diagnose some specific problem with the system, and outside of that context logging everything becomes more of a liability than an asset.

Logs can potentially become quite large and frequent logging isn't a great idea if you're running on a flash disk since it just increases the wear rate and thus shortens its usable lifetime. Also from a security perspective if a compromise occurs then the attacker gets considerably less social information if there are no logs containing timestamped IP addresses.

On the LibreServer system web logs containing IP addresses are turned off by default. They're not deleted, they're just never created in the first place. If you need to turn logging on in order to fix a problem then go to the Administrator control panel and enable logging. If you don't manually turn it off again then it will turn itself off automatically at the next system update, which is typically a few days away.

Even when using LibreServer 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.

The easy way to do this is to go Domain-User Blocking on the settings screen of the web interface. From there you can block particular email addresses or domains, or if you select Muted words then you can block incoming email containing particular words or phrases. Note that the muted words are case sensitive.

If you prefer the commandline then enable ssh via the web interface by supplying a public key, then log in with:

          ssh admin@libreserver -p 2222

Select Change email filtering/blocking 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 admin@libreserver -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.

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 admin@libreserver -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 admin@libreserver -p 2222

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

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 the people using its systems. 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.

LUKS is one of the best ways to keep data secure on a USB drive, but this isn't how backups on LibreServer are implemented.

The model for doing backups is that you should be able to buy a USB drive from any store, plug it in and then select the backup icon from the web interface. It should be no more complicated than that.

Using LUKS requires you to specially format the USB drive, using a tool like Gparted. Most people are not going to do this, and so if the backup required LUKS then most people would not do backups and the whole system then becomes non-viable because there will always come a time when you need to restore from backup.

Instead of using LUKS, backups are written to the drive already encrypted with a backups GPG key, and the backups key is then symmetrically encrypted with a passphrase and written to the backup drive. This passphrase is what's asked for in the web interface. It provides a similar level of data protection to LUKS, provided that you choose a good passphrase.

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 LibreServer. 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? The only current practical solution for clearnet email is to proxy through another "trusted" SMTP server. Sometimes the ISP will provide this, or you might be able to do it via the email services of other companies. It's a less than ideal situation which makes you dependent upon other parties to send email.

To set up outgoing email proxying you can do that via the LibreServer web interface by selecting Mail and then selecting the LibreServer header icon at the top of the screen. You can then enter the proxy details and select Update.

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. With LibreServer you can also use email via onion addresses, and to communicate with other people who have a similar system this might be the best option.

Obtain some tor bridges then go to Settings within the web interface and select Tor Bridges. You can then paste in your bridges lines and select Continue. It may take a few minutes for the tor daemon to reconnect.

You might have to try a few different bridges before you find one that works.

Sandstorm is based on a container-like approach. It looks quite viable now, although I avoided it initially because it was backed by venture capital and that always results in an "exit" which is unfavorable for the users.

The difference is that LibreServer doesn't use containers or anything similar. It's intended for bare metal servers. Containers are well suited for CI/CD where you want to build something for test and then throw it away, but otherwise they just add complexity without much benefit. That's also why before containers running everything in separate chroots never became a popular practice. Containers using Docker were considered and tried early on in 2014, but found to be unfeasible on a platform like the Beaglebone Black. Also I didn't want to get involved with a company funded by a letter agency and a lot of the practices around that system seemed to have the opposite of a security-oriented mindset.

Yunohost (from the meme "Y U No Host?") is quite similar to LibreServer, being also based on Debian. The main difference is that it's written in python rather than bash and that apps are implemented as separate repos, whereas in LibreServer apps are scripts within a single repo.

No. There are no statistics or metrics or analytics or telemetry. No logs are kept, or written, about who downloads the source code or image files or from what geographical location. There is also no intention to do that in future.

This usually happens because you are restoring to a different domain name. Unfortunately most apps are very tied to their domain name and so backing up to one domain and restoring to another usually doesn't work.