As of Friday morning, over 90% of my spam is either in German, about the T_rk_sh g_n_c_d_ of _rm_n__ns, or both. None of it is getting into my main mailbox, of course; what manages to escape my usual spam filters ends up in my Quarantine folder, due to the unknown senders. After the first few get through to there, the filters learn to recognize it.

[Note that I disemvoweled that phrase to keep it from getting into search engines. I know better than to invite traffic from the folks who can’t even see a recipe for Christmas {large bird} without being compelled to post multi-page screeds about that history. I’m already getting email spam about it, I don’t need to clean out my blog comments as well.]

…I don’t sit twenty feet away from my laptop, and the subject line gives it away as spam anyway:

more...

People familiar with Adobe PostScript will recognize the source of this label misprint.

Everywhere I’ve worked, people believe in them. They’re the ones who clear jams, change toner cartridges, reload the paper trays, and clean up the messy pile of abandoned printouts, and finally they’ve been captured on film. I give you…

more...

I have never been more annoyed at an application’s failure to fail.

We have this service daemon that performs various actions on incoming images. Recently, it’s been crashing at random intervals, leaving behind a core file that tells us precisely what function it segfaulted in, but includes nothing to tell us where the image came from. All we know is that somewhere out on the Internet, there are JPEG images that crash our copy of the IJG JPEG library in jpeg_idct_ifast().

Since this was affecting customer performance, we really wanted to know, so we cranked up the logging on one of the affected thirty-two servers, to capture the incoming request URLs. And it hasn’t crashed since.

Four days of crashes every hour or so, and now nothing. The good news is that our customers are less unhappy. The bad news is that our developers don’t have a test case to code a fix against.

So now I’m trolling the web, looking for corrupt JPEGs. I strongly suspect that the images that caused our problem were intended to exploit holes in a certain other OS, but I can’t be sure until I find some and feed them to our server. Sigh.

Gamer friend Scott just discovered that the reason he was having so much trouble with PCGen under Linux was that the JVM was defaulting to a rather small heap size, effectively thrashing the app into oblivion when he tried to print.

Now, while it’s true that PCGen is as piggy as a perl script when it comes to building complex data structures in memory, it’s still fundamentally a straightforward application, and yet it exceeds the default maximum heap settings. He had plenty of free RAM, gigs of free VM, and here was Sun’s Java, refusing to use any of it unless he relaunched the application with a command-line override. Doing so not only fixed printing, it made the entire application run substantially faster. Feh.

I’d noticed a slowdown with recent versions of PCGen on my Mac as well, but Apple was good enough to compile their JVM with defaults sufficient to at least make it run completely. Sure enough, though, increasing the default heap settings makes it run faster, by eliminating a whole bunch of garbage collection.

In other words, with Java, Sun has managed to replicate the Classic MacOS annoyance of adjusting memory allocation on a per-application basis, and made it cross-platform!

PCGen is still the only major Java app I have any use for on a regular basis, although there’s another one that has recently entered my arsenal of special-purpose tools, Multivalent. I have no use for 99% of its functionality, but it includes robust tools for splitting, merging, imposing, validating, compressing, and uncompressing PDF files, as well as stripping the copy/print/etc limitations from any PDF you can open and read.

There’s another Java application out there that might join the list sometime soon, Dundjinni, but first the manufacturers have to finish porting it from Windows to the Mac…

Last year I posted a reference to Arnold Reinhold’s Diceware page, and included a copy of my favorite passphrase generator, which attempts to generate pronouncable nonsense words.

I’ve always been a big fan of pronounceable nonsense, even in the days when passwords were limited to eight characters, but I think it’s particularly useful for long passphrases. My problem was that it can actually be pretty difficult to get a good nonsense phrase out of the original table. So I made my own.

Now, the instinctive reaction to someone creating their own security tool instead of using one created by an expert is (or ought to be) an anguished cry of “Noooooo, you fooooool!”. This is a special case, though, because the beauty of the Diceware scheme is that the contents of the table don’t actually matter, as long as each cell is unique. You could fill the first column with colors and the rest of the cells with the names of different superheroes, and the resulting passphrases would contain just as much entropy.

So here’s my new favorite method of generating passphrases. Roll three six-sided dice (one to choose a consonant, two more to choose the rest of the syllable), repeat at least ten times, and assemble into a phrase.

Update: Sorry if I didn’t make it clear. Split the results up with spaces to create two- or three-syllable “words”.

Also, a word on the relative strength of passphrases. Each syllable contains ~7.75 bits of entropy (log2(666)), so ten syllables produces a 77.5-bit passphrase, which is likely good enough for data that isn’t kept under lock and key 24x7 (e.g. login password on a laptop). See Reinhold’s FAQ on passphrase length for details. Note that the dictionary-based Diceware system requires longer passphrases to get the same strength (5d6 per word versus 6d6 for nonsense syllables).

I hadn’t seen any good spam for a while, even when I indulged my curiosity and looked inside Mail.app’s Junk folder before wiping it clean. This one, however, stood out in the crowd.

Silly me, I didn’t even know the FDIC had an office in Beijing, much less that it was where they hosted their “ATM/Debit/Check Card Protection Program”.

It was, of course, sent to the email address that’s in my WHOIS records, which is not on file with any banking institution I do business with. Not that I’d have fallen for it anyway…

more...