Freedombone Blog

Freedom in the Cloud

Legacy Issues

In the first month of 2020 I've been having a clearout of anything which is no longer strictly necessary. I still have a bunch of CD-ROMs with various photos and other data on them. Around the turn of the century when people asked me what's the best way to store data for the long term then I'd say "write it to CD and stick it in a drawer where it's not exposed to sunlight".

That kind of policy has worked thus far. But now CDs or DVDs once considered to be "space-age laser technology" are legacy media and only my laptop can still read them. Chances are that whenever I get a new laptop it won't come with a CD/DVD drive.

So I was thinking, what's my data preservation policy now? If I'm being brutally honest then I probably don't have any data which will be of interest to future generations, but it's always good to keep backups for your own purposes or maybe for legal reasons if there's any future dispute over who originally wrote certain software.

How long does a USB stick last? If you're not writing much additional data to them, just using them as an archive then it's probably long enough. I have sticks around which are at least a decade old, and they're still readable. If you're using a reputable brand, like Sandisk, and not the dirt cheap Shanzhai type (been there, made that mistake) then you'll probably be ok.

It's to be expected that USB will eventually be obsolete, but it can also be expected that there will be future serial device formats and adaptors for legacy USB.

Codes of Misconduct

There has been debate about codes of conduct and what they should or should not contain for at least a decade. For Freedombone I took the one that Debian was using at the time and then modified it based on experience. One thing which came to light from discussions was that unless you specifically list the kinds of behavior that constitute a violation then there's enough ambiguity that some people won't be confident about participating.

Recently I accidented upon The FOSS Code of Conduct. It has a few good points such as reciprocity and non-discrimination, but in other regards it's like the antithesis of what most codes of conduct try to do. Also see the video here.

The thing is, the entire history of FOSS is political, so trying to be "apolitical" misunderstands the whole exercise at a very basic level. FOSS emerged from the battle with software owners, who were generally corporations such as IBM and Microsoft. The whole idea that software was something which could be owned was rejected by many early FOSS people, and instead they sought to create a global digital commons in software which was universally accessible without artificial price barriers. The early view was that software was just a type of mathematics, and that nobody should own, or have exclusivity over the use of, particular types of math. This was a very political project from the outset.

The third section of the FOSS Code of Conduct is especially misguided. The original remit of FOSS was precisely to create equality of access to software, regardless of status or ability to pay. Many people have benefited from that principle who otherwise would not have been able to gain IT skills. In the 1980s and 90s software such as compilers, spreadsheets and other kinds of utilitarian things were seriously expensive and in most cases definitely beyond the budget of any average person who wanted to tinker and learn.

On the fifth point, judging things is always required and in the real world you can't escape from that by deploying platitudes. If you're unwilling to make a judgement then probably you shouldn't be writing software in the first place, because myriad decisions derived from your own perspective are required along the way. Imagine if Stallman had not been judgemental about a printer manufacturer, or if FOSS developers in the 2000s had stoically refused to be judgemental about the behavior of the people running Microsoft. Don't be so judgemental! Just let Bill Gates fuck you over! It's easy to see how ridiculous and practically counterproductive that would have been.

The "victim mentality" section which talks about "weaklings" is just bizarre, and doesn't really belong in a code of conduct. This on its own would stop me from participating in any project which adopted this CoC. I guess the author just needed to let off steam.

Section seven posits that human value is a market and that "the market is never wrong". It's an overtly political statement positioning the author as a Thatcherite market fundamentalist (as per her famous saying "you can't buck the market"). It's easy to think of numerous historical examples where "the market" (i.e. popular opinion) was badly wrong about this. Was Van Gough poor for his entire lifetime because he was valueless? If other people are unwilling to give you money then perhaps this isn't because you are inherently without value but that other people are similarly impoverished and have nothing left over to give, or perhaps like the case of Van Gough they are too blinded by a prejudice about someone with a mental illness to see the value of their work.

Beyond this particular code of conduct it's not especially unusual for people in the FOSS world to either claim to be apolitical or try to be that. The desire to transcend the grubby business of making concrete decisions in the real world (i.e. things which may carry non-trivial consequences) comes from the need to both avoid flak and to try to maximize consensus. Often projects can only succeed if significant numbers of users engage with it and are prepared to provide feedback. But there's always a limit to how far consensus building efforts can go. When the rubber meets the road there are always arguments, and some of these differences are over axiomatic points of view. Rather than attempt to avoid that it's better to be realistic about it and have a policy with a standpoint which may not be universal but covers enough ground to facilitate rough consensus among a like-minded developer and user group.

Another aspect which the above CoC and video highlights is that it's really advantageous to know what your own politics is and be fully self-aware of that. Otherwise you can end up looking foolish by claiming to be "apolitical" and then launching into a highly political rant about "the market". It's a common problem, but if you want to up your game when it comes to creating group policies or debating in general then it's really essential.

Mitigating Google Tracking

Epicyon now replaces YouTube links with invidio.us automatically. This doesn't eliminate Google's tracking, but reduces the amount of it such that by watching a video you're sending less data about yourself to Google. invidio.us is just an alternative free software interface to YouTube.

The history of these sorts of workarounds is that eventually the company finds some way to block the alternative interface, but for now at least this is a kind of practical harm reduction. The less data the surveillance companies get, the better.

Tempgraph yearly update

At the beginning of each new year I update the tempgraph data set to get the full data for the previous year. The overall picture of climate change is grim. For a while it was looking like the rate of temperature increase was slowing, but now it's evident that's not the case.

Global temperature anomalies 1960-2019

The slowing of the rate of increase correlates with the beginning of The Great Recession in 2008, then after about 2015 temperatures rise again. In the last 40 years average temperatures have risen by over one degree. If nothing changes then we can expect to be past two degrees by 2060 and at that point it's probably game over for human civilization as we know it. If there are positive feedback effects it could happen sooner. Two degrees might not sound like much, but these are averages and in a system as big as the planet it takes gigantic forces to move the average up or down.

Epicyon and Spam Mitigation

I notice that the Pleroma project (another ActivityPub server) has been having trouble with spam, and there have also been earlier spam problems with Mastodon instances. They've mitigated it by having a captcha by default. Personally, I don't like captchas. I don't like them mainly because I can't solve them (the ones with heavily distorted text). As far as captcha systems are concerned I am a robot. Beep boop.

So how does Epicyon deal with spam?

In its design ActivityPub is quite similar to email, and that means it can potentially suffer from similar problems. There are a few ways that fediverse instances in the last couple of years have dealt with this.

The main one is http signatures. Without getting into the details of http signatures as a cryptographic mechanism this basically gives a reasonable assurance about which account a post is coming from when it gets delivered. But that on its own isn't enough. An adversary can potentially generate arbitrary numbers of separate accounts at electronic speeds.

An additional mitigation commonly used has been registration limits. On a public instance you might open new registrations for a limited time or for a limited number of new accounts and then close it again and allow time for the newcomers to settle. The settling time tends to avoid admins becoming overwhelmed by newbie questions, trolls or spam floods. This seems to have worked quite well, and Epicyon also has this available. You can set registrations to be open and then also specify the maximum number of new registrations. By default new registrations are allowed and the maximum is set to 10. In a Freedombone installation with the Epicyon app installed new registrations are closed and only created via a command in the background when new members are added from the admin screen.

Epicyon also has quotas, with a maximum limit on the number of posts which can be received from an account or a domain per day. So if there's a rogue instance sending out a lot of spam or if one of your friends accounts gets hijacked then the maximum rate at which posts can arrive is contained.

Then there is the infamous DDoS scenario. Suppose that there are a million bad instances out there on different domains and they all send one spam per day. In this case it's down to the firewall, and Freedombone only allows a limited number of simultaneous connections on the https port.

Epicyon also does things in a way which makes life difficult for spammers. As a general rule you only see posts from people that you're following. There is no public or federated timeline. And there is no relaying of posts going on either. To a large extent what you see is what you get, with no additional stuff from random accounts you're not interested in. So unless you are following a spam account they may have difficulty getting into your timeline. An extra feature which is off by default but which can be turned on if you need it is to only receive DMs from people that you are following.

It should also be said that Epicyon isn't designed to run large public instances with thousands of accounts. It's intended to support about ten accounts at the upper limit, for self-hosting or small groups. At large scale Epicyon would probably perform poorly, and this is another reason why it would be unattractive for use by spammers. A Small Tech approach has advantages which would otherwise become headaches for projects fixated upon scaleability.

Epicyon Scheduled Posts

In Epicyon you can now schedule posts to be delivered at some time in the future. This can be useful for creating reminders to yourself to do things (eg. don't forget the milk) by posting a DM to yourself in the future. It could be used to promote an event by scheduling information posts leading up to it. Or it could also be used to handle time zone issues where you'd like a post to be seen but the expected recipients may not be awake if you post it right now.

With this type of feature there is the potential for spam, so the number of posts which can be scheduled at any point in time is quite small. Also spammers would have much easier methods for generating and sending a lot of posts, and the signature checking tends to mitigate against the kinds of spamming which happens with email.