Designing my app with sanity checks in mind
As I’ve been writing before, I’m currently working on an iPad and I’ve got security in mind. However, I’ve also got sanity checks in mind. What do I mean by that?
I’m not a huge, professional operation; instead, I am a one-man show (who has contracted out the actual programming but not the architecture) who is doing this in his spare time. I don’t have a lot of content to upload, but when I do, it has to be right. The user experience is critical to my app and that means that what I update has to be correct. The heart of my app is an xml config file that specifies how data is supposed to be accessed by the user, and how new data should be organized. When I add new data, I have to update the config file.
But what happens if I put a typo in the config file? This would mean either the user couldn’t access new content or it could corrupt existing content. That’s something I don’t want to happen because I don’t want to look like a clown. What do you think when you get software that doesn’t work after an update?
And frankly, me putting a typo in the config file is a possibility. I am doing the updates by hand and sometimes I do them late at night. Or I get on a roll and get careless (heck, when I write this blog, I am so excited to get a new post up that I commit typos all the time, to my chagrin). And what’s worse, even though I can proof read this stuff, I have a hard time proof reading my own writing. What I read on the screen, if it contains an error, is corrected by the time it gets to my brain because my biased brain has corrected the information and read it back to me the way I meant it, not the way I wrote it.
This is a big risk. How do I protect against myself?
The solution I am using is to write a script that examines my xml config file and does a sanity check on it. If it passes all the sanity checks, it writes the file to a pickup directory and only the contents of that directory ever get uploaded.
This sanity checker does the following:
It checks to ensure that certain tags all exist. If not, generate an error (I’ve already found two errors in my sample config file that I sent to my programmers. Oops; well, at least I caught it).
It checks to ensure that files that are referred to in the config file actually exist in their proper directories.
If files refer to each other, it checks to ensure that the naming convention is correct and that they point to each other properly.
It checks to ensure that matching open and close sets of xml tags exist.
Basically, it ensures that everything that is supposed to be there really is there, and if not, spit out an error. This protects me from myself.
This is the way I protect myself from uploading bad content – by ensuring I have a process in place to prevent it (of course, the question now is who polices the police? How do I know I wrote a valid sanity checker? The answer is that I tested it… what else can I say?).
You may be reading this blog and saying to yourself “Okay, what does this app have to do with the security space?” The answer is that I am modeling the architecture the same way that we do our spam filtering:
Our spam filter is designed to take updates regularly. The difference is that our filter uses a push model wherein we push new rules every so often at regular intervals. Users of my app pull new content when it’s available, and when they choose to update.
Just like my app has a sanity checker, our spam rules have sanity checkers, too. We check the syntax of the rules and profile them to make sure they don’t drag down the filter’s throughput before uploading them to the rest of the network.
The update security model between my app and our filter is different. In my app, the data goes from a trusted boundary (the web server) through an untrusted boundary – over the Internet to users. This is why I have to protect the data using SSL. However, for our spam rules, the data all stays within our network and we have access controls on who can get into the data centers.
The exception to this is when we pass spam rules between our legacy network and our new network. Because those networks are considered untrusted between each other, we have to encrypt the data when sync’ing between them. That uses the same model as my app.
So, as you can see. much of what we do on the job I am reusing on a smaller scale. The software development life cycle is not just about releasing code but thinking about the entire experience end-to-end.
And that’s what I’m trying to do.
Comments
Anonymous
August 06, 2012
So you wrote an article on common sense and perhaps that you haven't heard of these fancy things called XSDs. Congrats!Anonymous
August 07, 2012
Yes, JoeBob, I wrote an article on common sense. I do this because: a) Many people in software development are isolated into their own specialty areas and aren't familiar with this sort of thing. b) My readers have varying levels of technical acumen. c) I enjoy writing about the software development process in plain English. So yes, what is obvious to you is not so obvious to everyone else since we all can't be as sophisticated as you are.