Ross Anderson’s book Security Engineering (the second edition of which is now available online for free) is generally quite good; but it’s still possible to tell, from the varying quality of the chapters, which subjects he personally has a lot of experience with. One of these is banking; his chapter on banking security is extraordinarily good. It even explains the reason for double-entry bookkeeping.
Double-entry bookkeeping is basically the standard in the financial world. (The phrase is not to be confused with “keeping two sets of books”, which means having a second set of books with fake entries — the second set likely also in double-entry form, for a total of four entries for most transactions.) But though I’d seen the mechanics of double-entry bookkeeping described many times before, I’d never seen the point of it. Okay, each transaction is registered in two places — as a debit to one ledger and a credit to the other ledger. (The convention they use seems backwards: for example, if you have $100 in cash, the “cash” ledger gets assigned negative 100 dollars. But that’s just a sign convention: you can just imagine negating all the numbers, and then it makes sense. Or you can be an accountant for long enough that your brain gets wired backwards, and then it will make sense even as it is.) And okay, the system has the feature that all the ledgers have to add up to zero, which serves as a way of checking it. (To establish this feature, things like “profit” and “debt” ledgers are introduced for what otherwise would be money sources and sinks.) But what does this buy you? Well, obviously it buys you compliance with laws and regulations, which often demand that you use double-entry bookkeeping. But what is the point of those regulations? Why is this particular check likely to catch errors or fraud?
Anderson explains: where it makes sense is when you have a large company where each ledger is kept by a different person. (The system was invented in medieval Italy; one imagines a large merchant house with a room filled with scribes, each taking care of his own ledger as other people stream in and out telling them what has been bought and sold.) Then, with double-entry bookkeeping, one person can’t fudge the books on his own; two or more people have to collude.
When the whole system gets put onto a computer, that advantage usually goes away, since the computer (or whoever subverts it) can fudge two ledgers as easily as it can fudge one. Another advantage of the system, back in the pre-computer era, was that the supervisory effort was minimal: just the boss going around at the end of the day, adding up all the ledgers and raising hell if the total wasn’t zero. With a computer there is no point in minimizing the supervisory effort, at least not the part of it that the computer does: even elaborate schemes involving lots of cryptographic signatures would scarcely strain a modern computer.
Still, there’s something that actually used to make sense, there. Anderson writes as if it still can make sense, but it’s hard to see how: your software would somehow have to be organized so that different ledgers lived in different trust domains — say, on different computers administered by different people. For a large multinational company, that might even be a natural thing to do; but for others it would take a lot of extra effort — much more than just buying a “double-entry bookkeeping” software package in order to computer-whip the regulations.
In any case, as traditions go, this is not a particularly harmful one: the multiple ledgers can be useful for categorizing expenses and revenues; and in the process of eliminating the ancient security advantages of the system, modern accounting software also eliminates the inconvenience of having to enter everything twice.
It almost seems to be a rule: any time anyone talks about “cyber-“anything, it’s bullshit. I have little idea why. Maybe the word “cyber” appeals to people who read too much bad 1970s science fiction? But whatever the reason, from the heady dotcom bubble era talk of “cyberspace”, to today’s paranoid talk of “cybersecurity”, it’s bunk when looked at in detail. There are serious things to discuss, but somehow serious people use different words: “computer security”, for instance, or “network security”. The “cyber-“people are not all wrong — being 100% wrong is almost as hard as being 100% right — but there’s enough wrong to make them not worth taking seriously.
Of course this feature of the language is just a transitory thing; charlatans, once unmasked, shift to a different cover. After they abandon “cyber” it may even become respectable, eventually. In any case, no offense is intended to people who use the word in the context of debunking the prevailing “cyber”-nonsense, such as Bruce Schneier or Ralph Langner.
An RSS reader
A couple of years ago, I went looking for an RSS reader. For those not familiar with the concept, an RSS reader is a piece of software that maintains a list of blogs, pulls their RSS feeds, and displays a list of articles in them. And, if the blog maintainer puts the full text of his articles in the feed, it lets you read them. A decent RSS reader also remembers which articles you’ve read, and either marks them accordingly or only shows you the new ones. For subscribing to blogs that are only occasionally updated (like this one), an RSS reader is almost a necessity: it does the boring work of repeatedly checking for new articles when there seldom are any.
My criteria were:
Good integration with the web browser. I don’t want to flip back and forth between two different programs, one to read the RSS feed, and another to read the things on the web that it points to. I also want hyperlinks in the RSS feed to have the usual color indicators of whether or not that I’ve already read them, which probably won’t work if the RSS reader is a separate program, unless someone makes extraordinary effort at browser integration. Thus the RSS readers I’d tried previously were Firefox extensions. But I didn’t particularly like any of them, because I wanted:
Something better than the usual three-panel view (one panel for a list of blogs, another for a list of articles in a blog, and a third for the article itself). For one thing, that layout requires a lot of clicking: you typically have to click on each blog, then on each article. I can go through blogs faster than that just using the normal browser features: middle-click on each blog in a list to open it in a new tab, then hit Control-W to close each tab when I’m done with it. Also, the three-panel layout wastes a lot of screen real estate: I’m going to spend 99% of my time reading the articles, yet those appear in only one of the three panels. That’s annoying even on a desktop-sized screen, let alone tablets or phones.
No web-based services. I prefer to be in control.
What I fairly quickly landed on was mtve‘s program RSSaggressor. This is a Perl script that takes a list of blogs (a plaintext file, one URL per line, containing the URL of an RSS or Atom feed), checks each, and spits out a long HTML file containing everything new in every blog. The user then views that HTML file in a web browser. This way, instead of all the mouse clicking one does with a three-panel reader, reading the updates is just a matter of scrolling. (Well, except if the blog chooses not to put the full text in the RSS feed; then it’s back to the ‘middle-click to open each article in a new tab’ procedure.) This way there are no browser integration issues, aside from running the program in the first place and then opening its output HTML file in the browser. The original author runs the program as a cron job; I run it whenever I feel like checking what people have to say.
I’ve also made several changes, the notable ones of which are:
1. It displays the author of each article, which is useful for multiple-author blogs.
2. It allows you to specify a condition which has to be met for each article to be added to the output HTML file. To use this, after each URL in the list you add a condition, which is distinguished from the URLs by being indented. For instance, to subscribe to the Volokh Conspiracy weblog, but only to posts by Orin Kerr or Eugene Volokh, not the twenty or so other “co-conspirators”, you can write:
http://volokh.com/feed/ $author eq "Eugene Volokh" or $author eq "Orin Kerr"
The syntax for the condition is Perl syntax; the code uses Perl’s
eval() function to evaluate it. The accessible variables are
$link (a hyperlink to the web version of the
$text (its full text, if you’re lucky). And since the
condition can be arbitrary Perl code, you can also do other things
with it, including changing any or all of those variables. For
has an RSS API,
but in it they didn’t publish
hyperlinks as hyperlinks, just as plain text. To enable such
hyperlinks (or at least nine tenths of them), you can write, for
instance (fill in the blank with the screen name of the person to
http://api.twitter.com/1/statuses/user_timeline.rss?screen_name=___ $text =~ s((https?://[a-zA-Z0-9_/.+]*[a-zA-Z0-9])) (<a href="$1">$1</a>)g ; 1
(If those last two lines look like gobbledygook, welcome to the world of regular expressions.)
This version of RSSaggressor, like the original, can be found on Github. If all my modifications seem to date from the last few days, that’s because I was using an older version of the program previously, and ported my changes to this newer version.
One odd thing about RSSaggressor is that it remembers whether you’ve read articles by storing their MD5 checksum. Thus if the author goes back and edits the article, you get to see it again in its entirety. This has good aspects (you get to see updates to articles you’ve already read) and bad ones (you get to see the whole article again just because the author corrected a typo). I’d prefer to see some sort of diff between the old and new articles, but haven’t found a good diff library that operates on HTML and plays well with Perl. (Suggestions are welcome; patches or pull requests are even more welcome.)
This program hasn’t been packaged up for the casual user who doesn’t know to pull programs from github or install Perl modules (or, on some systems, install Perl itself). Those are not complicated things to do, but instructions would vary depending on the system. (As regards Perl modules, this version of the program might not need any extra ones: the ones it uses are pretty basic, and might already be there.)