Inka Data Keeping

From a recent University of Texas Press update:

Gary Urton, SIGNS OF THE INKA KHIPU: Binary Coding in the Andean Knotted-String Records. Gary Urton sets forth a pathbreaking theory that the manipulation of fibers in the construction of khipu created physical features that constitute binary-coded sequences which store units of information in a system of binary recordkeeping that was used throughout the Inka empire.

Signs of the Inka Khipu
Excerpts and TOC

Have I blogged about this before? Given the recent lecture on different bases in math, it seemed apropos. The bottom line, with these Inka khipu, that these knotted string doohickeys many people wrote off as decorative may instead have been carriers of great amounts of information, to those trained to 'read' the binary data storage format. Terrribly interesting stuff. A human being, you see cannot read machine code (what computers actually 'run' when you fire up your web browser, or word processor, or what have you). That's OK, computers can't read human languages, either. That's why the role of programmer or software engineer exists at all -- people who know how to speak one or more of the standardized languages that lay 'between' computer and human, and are used to generate machine-readable code in order that the machine achieve human-specified results. Khipu, apparently, may have been used to store data in a binary format, and thus would require some specialized training (a khipu scientist instead of a computer scientist) to get useful information back out.

From the excerpt:

"It is one of the great ironies of the age in which we live that the cacophony of computer-based, electronically produced information that suffuses our every waking moment is carried into our consciousness on patterned waves of just two signs: 1 and 0. This, of course, is no news. We have all been made aware since the dawn of the present Information Age that the ongoing revolution in computing technology rests on a system of binary coding. I discuss the matter at length below, but I would clarify here that by "binary coding," I mean a system of communication based on units of information that take the form of strings of signs or signals, each individual unit of which represents one or the other of a pair of alternative (usually opposite) identities or states; for example, the signal may be on or off (as in a light switch), positive or negative (as in an electrical current), or 1 or 0 (as in computer coding). One can argue that it is the simplicity of binary coding that gives computing technology and its information systems their great flexibility and seemingly inexhaustible expansiveness. In this study, I explore an earlier and potentially equally powerful system of coding information that was at home in pre-Columbian South America and which, like the coding systems used in present-day computer language, was structured primarily as a binary code."

Beach!

Say, did you know when you're unemployed you can just up and go to the beach? Just whenever you feel like it? Woo-hoo!

*splash*splash*frolic*

My goodness, this is fun!

Inside a US Election Vote Counting Program

Inside a US Election Vote Counting Program

As a software developer with a keen interest in such constitutionally-guaranteed rights as the right to vote in this country, this is exactly the kind of information I've wanted to get my hands on for*ever*.

But, I'm having difficulty reading the article because I keep falling down in an epileptic fit and choking to death on my tongue every time I read the words "Microsoft Access".

*thud*choke*choke*die*

Oh, and while I'm dying, someone buy Bev Harris's book for me, wouldja? I'll thumb through it while waiting for my loved ones to gesture me into the light. No, really.

What it looks like, at a glance, is that GEMS security is based on two things: ignorance, and restricted access to the ballot server. Anyone, apparently, with sysadmin skills and access to the machine could do some damage. Most of the people involved in a balloting process, however, do not fit that bill. Still, any programmer will tell you relying on ignorance is not a very robust security scheme.

The first thing that caught my eye is that there was no mention of enforced password changes on the part of the application, meaning it is humanly possible that there are dozens of implementations of this software running that use the default password.

The second is the description of working around user passwords by using Access directly and copying their encrypted password into the GEMS login. Only someone who has access to Access (by having physical and username access to the machine in question, or the Access DB for GEMS being mounted on a network, among others) would be able to do this, because you need to be able to look at the underlying database to pull this off. Ideally, the number of people with that level of access would be very small. In practice, however, that number of people is always higher than you think it is.

The fact that the audit log is editable in any way really worries me. I design and build software systems, frequently web applications using SQL databases, which means I spend a lot of time using tools that include the ability to edit db info at exactly the kind of level this this data is being manipulated at. If I may go off on a tangent for the confused:

This kind of software is multi-layered, just like my funk, baby. The bottommost layer is the information repository, the "database". The next layer up is usually referred to as an API - an established set of functions provided to perform common tasks such as "add record to database", "delete record from database", that kind of thing, which the software developers writing this application use in order to avoid reinventing the wheel constantly and instead focus on the next level up, the User Interface. Where Stuff Actually Happens, from your perspective.

When you register at yahoo, you the user fill out a web form (UI) which, maybe, error-checks your input & comes up with a password (API) and then adds your info into a database (DB).

If you develop software, you may need to test or 'workaround' a known bug or any number of things that require you to edit data in the database by hand. So, varying somewhat from database to database, there are multiple tools to help you do that. In some ways, I think, Microsoft Access blurs the line between UI and DB by making it so easy for a user to touch data directly in the database. MS Access as I understand it targets the development of simple systems, where the user and the developer are frequently the same person, and not terribly technical. That makes it easy to mess up, by virtue of that apparent transparency. It can also make it easy to hack someone else's work. Anyone who wants to screw around with data on a system I develop had better have a password to the db, permission to access the db server from the machine they're on, and a healthy dose of experience programming relational databases and in the use of the relevant db's command-line interface.

So, most of these screenshots and whatnot, they are of the MS equivalent of 'low-level database access', not of the GEMS application itself. Someone who is using GEMS is probably having a very different experience.

Now, back to the audit log. From a design perspective it makes perfect sense to have event tracking or an audit log in the same database as the data itself. I do it that way all the time...when writing using an SQL database. But Access makes it so easy for non-admin personnel to edit info in a database -- makes it seem so much like part of the normal user experience -- that now that I've considered the situation, I would argue strongly against an audit log in the same database as the data. Since, for this app, complete records of the manipulations to the data are so vital.

I would argue for the application requiring a second (thus, obfuscated, yes, not the best approach) db for that info, or store audit information (user X logged on, user X modified record Y, user X ran report ABC....) in a completely different medium -- a flat file, XML streamed to another server, in such a way that no access to the log is permitted. Encrypt it.

"Access encourages those who create audit logs to use auto-numbering, so that every logged entry has an uneditable log number. Then, if one deletes audit entries, a gap in the numbering sequence will appear. However, we found that this feature was disabled, allowing us to write in our own log numbers. We were able to add and delete from the audit without leaving a trace."

This quote makes it sound like the audit trail isn't driven by the GEMS application but by Access itself, in which case, disabling the auto-number sequencing was A Bad Idea™ and was either the GEMS application's responsiblity, or, possibly, that of the installer.

On the whole, it's difficult to assess exactly how endangered specific balloting servers might be -- so much relies on the people restricting access to machines, making sure the ballot server is not on a network, making sure only authorized personnel can sit down in front of the machine, etc., that it's really hard to tell exactly how hackable a balloting process would be that is using this system. That, in itself, is Very Bad News.


Bigger Than Watergate! - How To Rig An Election In The United States
Inside a US Election Vote Counting Program
Bald-Faced Lies About Black Box Voting Machines
Black Box Voting Ballot Tampering in the 21st Century