Freedombone Blog

Freedom in the Cloud

New icons

Some new icons and a new logo have been submitted to the Freedombone project. These were created by Rashid Mhar, and give the interface and website a much nicer look.

There are also now light and dark themes for the web interface, and the ability to edit translations. I've added some automated translations by default, and no doubt these will need changing to some extent.

Linux Improved

So the Linux kernel project has been scandalized by some complaints about Linus' behavior on LKML. If you've read earlier blog posts here then you'll know that this is very old news and the problems with the way the project is organized are longstanding.

Just to be clear, I'm not trying to generate FUD about Linux. That has already been done far more extensively by certain companies and mainstream tech journalists. In terms of technology and code quality, the Linux kernel is pretty good and it's something I use and rely upon every day.

Rather than ranting incoherently like a Reddit buffoon, I'll propose some suggestions.

Improve the CoC

Code of Conflict wasn't all that good, and the Contributor Covenant isn't all that much better. In particular it's last rule is so vague that it's meaningless.

I suggest either using the Debian CoC, or better than that, crowdsource the creation of a new CoC in a similar manner to what happened with the creation of GPL3. Give anyone who has a patch in the kernel edit permissions and set a deadline for the final draft. This will ensure that participants in the development of the kernel can all have their say about what they consider a good standard of conduct to be.

Consider manual pre-screening

Assuming that Linus is remaining as the top maintainer I'm not all that confident that him adding some outgoing mail rules will entirely prevent him from tripping over whatever CoC exists. Another way of putting this is that after 25 years of consistent behavior I'm not sure that Linus is going to change all that much, and just blocking curse words might not be enough to stop him from getting into a situation where he's violating his own code of conduct.

To get around this problem one of the other maintainers might want to review whatever Linus posts before sending it to LKML. Yes that creates extra work for someone, but it might be the best way to avoid future scandals. So maybe he can appoint a secretary. If possible, someone who has been critical of his tirades in the past so that there's some degree of real vigilance being deployed.

Rotate maintainers

It's something I suggested in the past, and just one of a few similar possibilities. Instead of Linus always being the top maintainer for multiple decades rotate that position between a few of the established maintainers. This spreads the load of governance and also gives other maintainers on-the-job training for when Linus will no longer be around. It could also bring much needed new blood and new perspectives into the project.

Consider alternative funding

Currently Linus and perhaps a few other maintainers are paid to work full time by the Linux Foundation. I may be going out on a limb here, but being funded by Google, Microsoft and Facebook isn't a good situation for the kernel to be in. It will, and probably already has, created conflicts of interest between the billions of Linux users and narrow self-serving corporate ambitions. If you look at the technical advisory board it's packed with people from companies whose ethics are severely tainted.

Perhaps it's time to break that tie.

I think it's realistic to assume that the top maintainers could be crowdfunded. If Mastodon can do it I'm sure that Linus could. Sure, he might have to take a pay cut, move out of Sillycon Valley and live more modestly like an average human. But that would be a positive step, such that the development is no longer heavily influenced by a few corporations.

Change the voting process for the technical advisory board

Have the technical advisory board be 50% women.

No, before you start throwing chairs at me like Ballmer, hear me out.

When elections take place just get voters to nominate one man and one woman. Whether and to what extent non-binary people should be included isn't something I've thought much about. Maybe it could be 50% women or non-binary.

Since the board is in charge of CoC enforcement this would create a handy counterbalance against the previously hostile environment of LKML.

3.2 release

Commit: d326e580f3cf399fbe965df11a04357fbec12ae0

This is a minor release which continues on the base of Debian 9. The main change in this release is the introduction of a new web based user interface, which aims to make installation and management of the system easier. This is part of the bigger goal to try to push self-hosting into the mainstream and make it more accessible to a wider range of users with a reduced requirement for technical knowhow.

The new user interface was designed for minimum complexity, to operate on screens of any size and without any need to have javascript enabled. Installation may be carried out using only a smartphone running a stock browser. No secure shell logins are required, but that can still be enabled after initial setup if it is needed.

The website and logo have been changed to give it a more appliance-like look, and in future releases the descriptions of individual apps will be moved into the web user interface itself as context sensitive help. More support for languages other than English is also expected in the next version.

Images and source code are now obtainable via dat archives. This should be more scalable than the previous arrangement, because archives can be independently seeded by any number of peers.

On the hardware front there is now experimental support for a few additional single board computers: Beaglebone Green (the non-wifi version), Banana Pro and Beagleboard X15. Running from a SATA drive, rather than microSD card is now also supported, and this can improve system performance dramatically especially if you connect an SSD.

The backup system has been simplified such that there is no longer any need for separate keydrives or special formatting. This means that you can buy a USB drive in a shop, plug it into the server, select backup from the web UI and supply a password to encrypt with and it should then work. If you leave the USB drive attached then it will automatically do a backup once per day.

For installation instructions see the main site. Existing installs should upgrade automatically.

At the present time self-hosting is something only done by people with a high level of technical knowledge, but it doesn't have to remain that way. Version 3.2 is the first version of Freedombone which potentially could be deployable to a mass market - especially if the onion version was used which avoids the need for domain registrations or port forwarding.

On the decentralized web

Decentralization is maybe on the way to being a buzzword. I was reading a Guardian article about it recently, and the article was sufficiently awful that I thought I'd do a deconstruction of it here.

The proponents of the so-called decentralised web...


Isn't the so-called decentralized web really just the web?

With the current web, all that user data concentrated in the hands of a few creates risk that our data will be hacked. It also makes it easier for governments to conduct surveillance and impose censorship. And if any of these centralised entities shuts down, your data and connections are lost. Then there are privacy concerns...

This is all true, but it's not the primary reason why decentralization is desirable. If you're running your own decentralized web server there's also a risk that will be hacked too.

The main reason why we want decentralization is that centralized governance doesn't work. Also silo companies which are practicing governance (badly) but claiming that they were mere neutral carriers of information are hypocrites.

Not only does centralized governance in silo systems not work, it produces bizarre and unjust outcomes. See some of the articles written about Facebook's censorship rules and how they're applied. Also see Twitter's defense of far right thugs. Attempting to do governance by AI will be even worse, and I think we're just at the beginning of seeing the consequences of that.

The services are kind of creepy in how much they know about you

Well, yes, but if it was merely about creepyness I could almost live with that. The problem is that the current situation with silo systems goes far beyond creepyness into the territory of doing actual damage to the lives of their users. Not caring about people getting harrassed or dogpiled is part of that problem. Technology is supposed to be an enabler improving life, not something which disempowers and which you may fear using.

The same tech that can protect users in the DWeb from central surveillance might also offer a shield to criminals

See, there are plenty of criminals on Twitter. Not only are they on Twitter but they're being shielded by it. Occasionally Twitter has purges in which some bad people are kicked out, but most remain and often there's a lot of collateral damage of innocent bystanders. There have been dubious bots creating a murky economy of selling followers for the best part of a decade, and they mostly ignored it.

How will my everyday experience of using the web change? If it is done right, say enthusiasts, either you won’t notice or it will be better

"Enthusiasts" is a curious word to use here. Not "experts" or "people who built the internet"?

Trying to market the "DWeb" are merely "better" also misses the point. What we're trying to find a solution to here is nothing less than how to practice good governance in the 21st century. A dictatorship of Facebook and Twitter isn't working out real well with regard to that question.

For the internet, and therefore the rest of life, to be well governed it needs to be run by and for the people who are using it. People need to have a stake in the game. Not just "Zuckerberg calls the shots and the rest of the world falls into line". This isn't about whether apps are convenient to use or not. It's fundamentally about what kind of life you want to live, and whether you want to be a contender or merely someone being "nudged" by an algorithm.

One thing that is likely to change is that you will pay for more stuff directly – think micropayments based on cryptocurrency

One of the biggest problems at the DWeb summit which this article mentions is the conflation between decentralization and blockchain technology. Cryptocurrencies which currently exist - especially Bitcoin - aren't really decentralized. Yes, anyone can run a node, but who generates the new currency and who is getting the most value out of it? Not just theoretically, but practically, in reality. So far that's always been a very exclusive club of beneficiaries, who are mostly the usual suspects. This isn't true decentralization. It's more like a pyramid scheme with cryptography.

At present I'm not convinced that blockchains have much of a role to play in decentralization, but append-only lists might.

Issues of growth

It now looks like the fediverse is well on the way to becoming something mainstream-ish. I expect that over the next year the degree to which it succeeds will be the extent to which my timeline is able to resist turing into something resembling Twitter.

So far it's mostly been a success story. The last Twitter exodus in August did bring with it new challenges though. There was some kind of dogpiling scandal involving a minor celebrity and the lesson from that is that celebrities can bring with them a lot of toxic baggage from the Twitterverse which isn't necessarily trivial to mitigate against. Even on Mastodon it appears that people are easily enthralled by celebrity, and willing to give them far more benefit of the doubt than J Random Mastodon newbie would get.

Maybe other celebrities will be deterred by that debacle, but with the growing network effect we're likely to see a similar story begin again soon enough. It does raise questions about the extent to which the fediverse can avoid classic Twitterisms, like dogpiling of targeted users.

There was also an anomalously high level of squabbling between instance admins. Fortunately that only lasted for a few days and then things returned more or less to their usual condition. As I've mentioned before, the configuration of instance blocks kind of works itself out over time and settles into a new pattern.

One thing which concerns me is that the larger instances are continuing to grow without any limit on number of users, and that as they do so undesirable Twitter-like social dynamics begin to play out. I think what's needed is renewed emphasis on running your own instance and keeping the size of instances small. When instances get very large they become impossible to moderate even with a dedicated team, whereas with small instances peer pressure alone is usually enough to avoid bad behavior going unchecked. Small instances are a key advantage, since they're something which Twitter and Facebook can't do.

Building for Scale

So far the Freedombone home server project has been aimed at people who know how to use GNU/Linux and are not terrified by the sight of a commandline, but for the next release that's going to change.

The next release will have a simplified web based user interface suitable for the mythological "average user". The previous menu system will still be available, but will be for the more advanced users.

I'm not actually a web developer and my knowledge of front end web technologies is very limited. In a job interview not that long ago one of the interviewers berrated me for never having learned Django, saying something like "I do not find it credible that you have not learned Django yet and have not been making money doing that".

To avoid the mess of dependencies which many contemporary web apps appear to entail, for the Freedombone web user interface I've tried to keep it very basic and follow the principle of do the simplest thing possible. I decided early on to avoid javascript. Although it's popular, Javascript often isn't trusted and many people block it altogether with NoScript. So the software architecture of the new web interface is HTML, CSS, a small amount of php and a daemon in the background made with bash. The daemon does all the important stuff, like installing apps or making backups.

Experienced web developers will probably laugh at the crudeness of this implementation, but it works and should be straightforward to maintain. The design can be simplified because it's only expected to be used by whoever is administering the system, so concurrency of inputs doesn't need to be handled.

As a general principle I've tried to keep only a few objects on each screen of the web interface. This keeps the cognitive workload down and the number of things within the buffer size of biological working memory. If there's too much screen clutter then that will make it hard to use. I've stuck to a simple color theme which is hopefully high contrast enough for low vision, and the amount of wording on each screen is kept as small and as direct as possible.

A tricky part of the new user interface was the backup system. If you're running a server then keeping a backup of data is essential. The previous system required making separate keydrives and backup data drives and also included a LUKS formatting step. For a mass market type of system I thought this was too complex, involving too many steps and with too much chance for someone without scrupulous opsec to make mistakes. So I redesigned how backups happen. They're still encrypted with GPG, but the keys are stored on the backup drive and encrypted with a password. This means that it's possible to buy a USB drive, plug it into the server, select "backup" and it will work without any separate formatting step. If you leave the USB drive plugged in then it will make backups automatically once per day. If you later lose the backup drive then the password still protects the keys and therefore the rest of the data.

Another thing about passwords is that I've followed the existing policy of by default not allowing the user to select their own password. This is different from most other systems, including FreedomBox. Instead on first startup the system gives you a random password and tells you to write it down or store it in a password manager. I'm going on the assumption that if the user chooses their password they will choose the name of their cat, or password123, or something else which is trivial to crack.

I've also been rearranging the website such that it assumes a mass market type of deployment, with a mockup of a boxed product in the admin guide.

Whether Freedombone actually does become a mass market thing remains to be seen, but this is a first attempt at moving it in that direction.