shopping hos

Hvorfor er det så vanskelig å fylle på reisekortet på I en perfekt verden går jeg til, taster inn kortnummeret, trykker på OK knappen, og betaler med bankkort på neste siden. Men slik enkelt kan vi ikke ha det.

Første siden jeg blir presentert med er ruteplanleggeren, og det er jo bra, fordi det er vel det folk bruker mest, spesielt siden ruteinformasjonene ikke finnes i Google Maps. Hvorfor egentlig? Etter noe leting på siden etter “fylle på” finner jeg en knapp som heter Nettbutikk. Kanskje jeg tenker feil, men en nettbutikk er for meg et sted jeg kjøper fysiske ting, som en I ❤ VKT skjorte eller caps.

Men jeg trykker uansett

på knappen, og der kommer det opp en side med forklaringer.Dette er ikke noe god tegn. Må du forklare nettbutikken din med to siders instruks, er den sikkert katastrofal dårlig. Den vider meg bilder av en side jeg ikke har kommet til ennå, og minner meg om å trykke på “full på” vis jeg har tenkt å fylle på, eller “kjøp ny” vis jeg trenger ny kort. Dette klarer vi!

Det er to knapper her, begge to heter “Gå til nettbutikk”, og jeg antar at de gjør akkurat det samme. Jeg trukker på en av dem, og tenker at nå skal jeg komme til den siden som ble forklart. Men nei, det er vel for enkelt tenkt. Nå skal jeg først logge meg inn. Hvorfor trenger vi dette? Dere trenger jo ikke noen andre data enn kortnummeret mitt, og jeg skal helt sikkert ikke gi dere nummeret til en annen fyr, og betale for at han kan reise til Tønsberg, altså. Jeg husker ikke om jeg har brukt denne siden før, så jeg trykker på “glemt brukernavn”, prøver 3-5 forskjellige epost-adresser, og da ingen av dem er registrert forstår jeg at dette har jeg ikke brukt før.

“Lag ny brukerkonto”, da. Velg brukernavn og passord, og… jeg skal bekrefte epost-adressen min. Hvorfor det? Hva har dere egentlig tenkt å gjøre med adressen? Skal dere sende noe til den, og denne bekreftelsen er for å beskytte mot folk som lager kontoer for å få spammet sine ex-kjærester? Venter på epost, trykker på linken i den, og nå fortsetter vi.

“Du må knytte et kort til kontoen din”. Ja, dette har vi ventet på. “Er du sikkert at dette er nummeret ditt?” Joda. Er det mange som taster det feil? Da kan det lønner seg å ha dem gjenta det, som man gjerne gjør med epost-adresser (det gjør denne siden dessuten ikke, takk og pris). Eller ha en sjekksum i kortnummeret.

Og nå skal jeg laste opp kortet. Men det er en nettbutikk her som er litt pussig. Jeg skriver inn hvor mange kroner jeg vil ha, og så dukker det opp i handlevognen min. Handlevogn? Det er noe som vi bruker når vi skal flere ting. “først så skal jeg ha 100 kr på kortet mitt, og så 50 kr til, takk” said nobody, ever. Det er ingen “gå til betaling” knapp her, heller, men jeg er flink, og trykker på handlevognen. Da ser jeg gå til betaling knappen og “jeg aksepterer vilkårene rute, som jeg hadde ventet. Egentlig hadde jeg ventet at den dukker opp når jeg lage brukerkonto, da slipper man å gjøre det hver gang, når man nå må ha et konto, men skuffelsene har vært mange i dag, og det er ikke den verste.

Jeg betaler med VISA kortet gjennom PayEx, som vet hvordan betaling skal fungere, og det er ingen “lagre kortet til neste gang” knapp, som hadde vært en grunn til å ha brukerkontoer og passord. Jeg forstår det fortsatt ikke.

Til slutt blir jeg presentert med meldingen: “Din billett vil være tilgjengelig på billettmaskinen neste dag”

Jeg har aldri sett en billettmaskin til VKT. Skal ikke bruke den heller. Hvorfor er ikke pengene bare på kortet nå? Må jeg gjøre noe? Hvordan er en billett forskjellig fra mitt reisekort? Hva har dette med påfyll å gjøre? Forundring.


The Instant Messenger Balkanization

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.

Cloud Backup

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!

Memory Leaks

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.

Plans Change

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.

Sikkerhet på

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.