Things that happen when I’m suffering Insomnia: I squeeze 5% out of the storage space required to store Eressea’s data.

I am sure much has been written about the fact that we all have a dozen IM clients installed on our phones, and every one of our contacts uses a different one. I’ve mostly not bothered to trim that down, installed all of them, and had an account with each, whether it’s Hangouts, Twitter, Facebook, Threema, SMS or IRC. But this last week makes me think that we need to get out of this situation.
I have been in hospitals for the past 6 days. That’s a time when people want to get in touch, get updates on my status, but also a time of bad Internet access. The first hospital had barely any patient WiFi to speak of, and this second one has an unsecured AP. I have an Android phone and no computer. The phone’s storage is nearly full, and I’m going to have to cut down on the number of installed apps, but can’t really kill any one of these messengers yet, except for Skype, because it really doesn’t work well on mobile devices. SMS is overall the most reliable form of communication, because it is the most democratic and widely distributed, and will always stick around as long as we have phones. I also need to keep it for my sister, who still doesn’t have a smart phone, and hardly checks messages on her laptop more than once a week. Facebook chat is the one where all of my friends are, but it lacks encryption. Almost all messengers fail on the encryption, so it’s nice that I can at least use these VPN functions in Orbot to route all of the internet traffic on my phone through Tor! Threema has end-to-end encryption, but literally no adoption. The latest offering in this space is Signal, which bills itself as an SMS client, and sends SMS when necessary, but encrypts messages over the Internet if both parties have it installed, and keeps everything inside a single app. A desktop client is in beta, too, which makes this more attractive than Threema. Given a choice, I would prefer that all of my friends ditch the text messaging clients on their phones for Signal, and ubiquitous encryption just happens eventually, but inertia is a terribly difficult thing to overcome.

I have kept meticulous backups of every turn from the three games I run. Before and after each turn, the data file, orders file and summary are zipped up into a .tar.bz2 file. This is essential for fixing bugs weeks later, because it lets me re-run a turn with the old data and watch what went wrong in my debugger “as it happens”.

The problem with these backups is that they sit on the machine in Germany that hosts the game, and I tend to do my debugging at home. Also, storing the current game data and the backups on the same hard disk is hardly redundancy. A weekly rsync between my home machine and the server would solve this, but my home machine runs Windows for a number of reasons, and so that’s not really an option. I could rsync to another machine in the house (I have a few Raspberry Pi for similar purposes) but then I still have to move the files from there to my desktop PC when I actually want to debug something.

Today I finally solved that problem, with a free Box (previously account. Box supports webdav, so it’s as easy a single curl request to upload my file to a shared folder, and the Box app on Windows will sync it to my desktop. Backup and local debug copies solved!

For future reference: to store the eressea.db sqlite database in a Box folder named Eressea, this is the curl command to do the HTTP PUT request:

    curl -n

-T eressea.db 

Authentication with Box is done through a .netrc file on the host, because I don’t want to check the account password into github along with my backup script. cat ~/.netrc:

    machine login password swordfish

Standards are great, and WebDAV support really makes the decision for which cloud storage service I want to use an easy one. The free account gives me 10 GB storage, enough for approximately 460 turns at today’s size of the game, so if I move them to CD backup frequently enough, I should never have to pay for storage. Nice!

Eressea has a pretty simple memory usage pattern. It allocates a bunch of memory during startup, when it loads the current game data file and creates all the regions, factions, units, etc. and the new orders, then stays pretty much flat while it executes the turn, only allocating more memory for messages and auxiliary structures. Then, after the report is written, it exits and the death of the process cleans everything up nicely.

There shouldn’t be a lot of memory leaks in a situation like that, but the code is written with the intention of being able to load and unload data files from the console, for operations like building statistics over time, repairing one file based on data in another, etc. A recent example was “link every familiar in turn X to the same mage they were familiars of in turn X-1″. So while programmatic cleanup is usually not required, it is in a situation like this (after analyzing turn X-1, we should free it before reading turn X to apply the fix).

Another reason for working cleanup code is testing. Unit tests work best when running from clean state, so anything that gets created in one test should be destroyed at the end of it, so it won’t interfere with the next test. My favorite tool for finding leaks like this is valgrind, and recently it was reporting almost 1,000 leaks when run on the full unit test suite. I started a new feature branch to eliminate them, and after a couple of evenings of hard work, I have pared them down to one final leak in the parser that is really hard to track, and a bunch of static variables that are the bane of this code base. As can be expected when doing work like this, I found a number of small errors that were more than just leaks, and added a lot more test coverage, so this should cause overall code stability to go up. The work ended up in one giant pull request, and will be part of the 3.7 version of the code.

Last time I regularly updated this site,  my plans were to use my copious free time to create a mobile version of Eressea, or at least a game based on the same principles. That’s no longer the plan.

Eressea is less a game than it is a world simulation. In this, the original designers were correct. There isn’t very much good strategy game-play at its core, and many of the game’s elements are not in support of a war game, but for world-building and to give players other, self-defined, goals to strive for.

With that said, I don’t have a lot of existing game to build on. Building a mobile client was fun as long as I did it, but the total time required to build what I had in mind was going to be enormous. I was also having more fun just working on successive new releases of Eressea itself.

So the mobile project is dead. Long live the original game!

Some former players have started new factions this years, eking out a living in the ruins of fallen empires, trying to hold their own against the zombie hordes and finding some resources that they can mine, or older factions they can cooperate with. It’s a different way to play, but it seems to be working for some, and for the original game, it’s a better way to maintain the active player base than new recruits and growing the map.

That means my development work is now defined by bug fixing, new features, and occasionally tools for creating new worlds. When I’m asked, I try to support anybody who wants to run a game of their own. And those are the topics that this site is likely going to cover in the future.

Siden jeg endelig fikk pin-kode til mitt konto, kan jeg nå logge meg inn i, og sjekke resten av stedet.

Jeg klaget jo allerede over mangelfulle sertifikater, og har sendt en epost til 

Webredaktør Stine Lindstad, og fikk som svar idag at det er ikke hun, men Trygve Kikut som er ansvarlig for tekniske ting som dette, men han er på ferie til 17. august. Derfor har jeg ingen andre valg enn å logge meg på over en usikker forbindelse, med pin-kode og brukernavn i klartekst.

Første funksjonen son skal testes er derfor endring av pin kode. Ikke at dette hjelper noe stort, siden den alltid kommer til å bli sendt i klartekst, men det forteller oss kanskje noe mer om systemet. På profilsiden leser jeg: “Vi gjør oppmerksom på at din PIN-kode kan bli oppgitt i brev og e-post du mottar fra biblioteket, f.eks. hentemeldinger- og purrebrev. Dette gjør vi for at det skal være lettere for deg å benytte denne tjenesten”

Hva betyr dette? For å kunne sende pin-koden til meg i brev eller e-post er det nødvendig å lagre den i klartekst på server-siden. Normal standard for passord til et system som dette er å bruke en en-veis hashfunksjion (gjerne scrypt eller bcrypt), noe som betyr at det er umulig å lese passordene selv om det er noen innbrudd eller databasen blir stjålet gjennom en feil i systemet. PIN-koden kan dessuten bare inneholde tall, og må være fire sifre langt, hva betyr at selv om de hadde brukt ordentlig kryptering av passordene ville det vært trivielt å kjøre brute-force attack mot passord-databasen. Det er nesten like enkelt å kjøre det mot selveste nettsiden, og det skulle ikke ta mer en noen minutter å bryte seg inn i et konto når man vet (eller gjetter) et låner-nummer.

Så er det bruk av informasjonskapsler, eller cookies. Innloggingen har en mulighet for å forbli pålogget, noe som gjør at når en setter et kryss på det, så trenger man ikke å logge seg på igjen fra samme nettleseren. Dette blir som vanlig gjort gjennom en unik session-cookie som blir spart i nettleseren, og hver gang en side fra blir etterspørt, sender nettleseren selveste cookie tilbake, og så vet nettstedet at det er meg. Vis noen klarer å stjele dette cookie er det lett for han å få tilgang til min konto, han trenger ikke en gang å logge seg på. Det er derfor det er vanlig at all trafikk til nettsteder med brukerkontoer (som skal sendes over SSL-krypterte forbindelser (HTTPS), og derfor er det så ille at sertifikatene til ikke fungerer. Vis jeg sitter i samme rom med noen som bruker på trådlos-nettverket, er det for eksempel meget enkelt å lese verdien av hans cookie med en verktøy som Wireshark.

Det er derfor også vanlig for et nettsted som bruker session-cookies å gi dem veldig kort levetid, dvs. de fungerer bare i noen timer, og så blir det utvekslet en ny en, i tilfelle det gamle er blitt stjålet. Levetiden på selveste cookie fra er ett år, og da antar jeg at dette

heller ikke ble gjort ordentlig.


I dag har Tønsberg og Nøtterøy Bibliotek svart på min epost fra gårsdagen, som klaget over manglende svar på forespørsel etter ny pin-kode. De sendte meg SMS til min registrert telefonnummer med ny PIN kode, og koden fungerer.

For meg ser dette ut som det ikke finnes noe automatisk behandling av pin-kode forespørsel, men her sitter det en person som får en epost hver gang jeg trykker på “glemt kode” knappen på nettsiden, og sender en SMS. Dette er noe som skulle fungere automatisk, fordi det er ikke noe jobb som krever utdanning til bibliotekar, og da ville det også fungert på en søndag. Tenk om Facebook ville brukt samme metoden, hvor mange kundebehandlere de ville trengt bare for det. Men norske kommuner har sikkert spart mye penger på IKT systemer som de kan sløse bort på jobber som den? Vi har i hvert fall ingenting å frykte fra automatiseringen, den skaper jo flere jobber en den ødelegger.

At hun sendte koden gjennom SMS til mitt registrerte nummer, istedenfor til en epost-adresse som ikke var registrert i min profil, er et bra tegn, fordi det kunne jo vært hvem som helst som hadde funnet låner-nummeret mitt og skulle trenge seg inn i min konto. Med andre ord: det er ikke bra, men det kunne vært enda verre.

Dagens interaksjon med får dermed terningkast 2 av 6. skulle jeg kunne bestille bøker, fornye de som jeg har utlånt, og søke i katalogen. Søket fungerer, kanskje fordi søk er noe som bibliotekarene selv bruker?

De fleste andre funksjonene forutsetter selvfølgelig at jeg logger meg på. Det gjør jeg med låner-nummer plus PIN-kode. Og her blir det skammelig.

For det første så ble ikke følgt noen sikkerhetsstandard her. Istedenfor passord har jeg en firesiffret PIN-kode, og hele nettsiden er ikke kryptert med SSL. Om jeg prøver å logge meg på blir brukernavn og passord overført i klartekst. Prøver jeg å åpne får jeg meldingen fra nettlesern at nettstedet er usikkert, fordi sertifikatet er utstilt til – den ansvarlige utvikleren har kjøpt sertifikat for en subdomene istedenfor en wildcard-sertifikat til hele *, og det forklarer vel hvorfor det ikke er i bruk.

Dette er grovt uansvarlig av en moderne nettside. Men enda verre, selv om jeg logger meg inn med mitt brukernummer og PIN-kode, så blir jeg til en side som sier at jeg har oppgitt “feil i lånernummer eller pin-kode”, og siden jeg har kopiert nummeret fra lånerkortet må det vel være pin-kode som er feil? Jeg trodde helt sikkert at jeg husket den, men jeg skal prøve å få meg en ny en.

For å få ny pin-kode skal jeg altså oppgi låner-nummer og epost-adresse. Så får jeg svar at ny pin-kode skal bli sendt til meg, men ingenting skjer. Er det fordi det er søndag idag, og forespørsel blir svart på manuelt? Jeg håper jo at noe så enkelt blir automatisert. Eller er det fordi det står her: “ Dersom e-postadressen ikke er lik den som er registrert i bibliotekets base så vil det ikke bli laget noen ny PIN-kode”. Har jeg registrert noen epost-adresse? Muligens ikke, jeg har jo aldri brukt dette systemet før.

“Har du ikke registrert din e-post adresse hos oss, kan du kontakte oss på” – det er søndag, men jeg skal prøve, og se om jeg får noen svar. Men for en nettside som skal bli brukt av folk flest er dette veldig trist. Jeg kan umulig være den første som har liknende problemer, og jeg undrer meg om det er noen utviklere som samler på sånne type brukerproblemer og fikser dem. Antageligvis har biblioteket kjøpt dette systemet for noen år siden, og ingen har noen gang brydd seg om hvor bra den fungerer, eller hvor mange brukere som har problemer med den.

Jeg ser en del ting som jeg har jobbet med da jeg utviklet en stor nettside i PHP selv. Som for eksempel problemer med character encoding av norske bokstaver:

Her har noen skrevet innholdet i Windows-1252 codepage, men CMS-systemet kjører på UTF-8, og tilsammen blir dette bare vrøvl.

Jeg finner meg ofte lei av forholdene på norske nettsider, og isteden for å mumle sint i skjegget mitt, har jeg altså bestemt meg for å hyle på en blogg. Jeg trenger litt øving av norsken min uansett, og det å skrive artikler hjelper kanskje med ordforrådet?