(Or, “In Which Your Narrator Learns a Valuable Lesson About The Perils of Cheap Media and the Proper Use of the Verify Button.”)

A while back I picked up a 50-pack ‘cake box’ of surprisingly low-priced DVD+R Dual Layer discs, possibly at Costco (although it could have been Best Buy or Staples, at this point I’m not sure). The price was good and I’d been thinking that it’d be nice to be able to cram more than an hour’s worth of DVD-Video onto a disc, and I naively had some idea about using them for backup purposes as well.

The discs were TDK branded, and say “DVD+R Double Layer 8x Speed 8.5GB”. Unfortunately, what the label doesn’t say is that, as far as I can tell, the only relationship they have with actual recordable DVDs is that they’re roughly the same size and they have a hole in the middle. But more on that later.

Anyway, I bought the discs, brought them home, and promptly forgot about them. I don’t burn a ton of discs anymore, but it’s good to have media on hand…right? So there they sat, lurking.

A few months ago, I went to burn a fairly big photography project to disc for safekeeping. Of course I had it backed up to a second hard drive (via Aperture’s ‘Vaults’ feature), but I figured an additional copy on optical wouldn’t hurt. And so I clicked away in Toast and burned the files to one of the discs.

Now I generally make a point of always letting Toast verify any disc I burn, but I’d be a liar if I told you that I actually remember doing it. It’s possible that I just mounted the disc immediately after burning, cataloged it, and then ejected it and put it with my other backup discs. Rinse, repeat … about a half a dozen times or so, over the space of a few months. Each time the same process — I burn a disc without problems, mount it, catalogue it, and then put it away in a binder. The process wasn’t flawless — sometimes I’d get failures due to ‘sense key’ errors and have to try a couple of times to get a successful write, and writing 8.5GB at the maximum speed of 2X that my writer supported was slow — but I figured that was par for the course.

Up until earlier this week, when I did something different. I burned a bootable disc image (long story) and attempted to use it on another computer. It failed. In fact, the disc wouldn’t even mount when I put it in the other computer’s drive. Thinking it was a compatibility issue, I brought it back to my desktop where I’d burned it — nope, nothing. Odd, I thought — so I tried it again, and got the same result.

Although the disc had mounted just fine immediately after burning, once ejected from the drive and reinserted, it would never mount again.

Not only was the boot disc bad, but every disc I’d burned on the media turned out to be bad. That’s right: one hundred percent mis-burns.

In the interest of science, I blew through most of the rest of the stack trying different burning programs, data, and writers. I achieved identical results with my desktop’s Pioneer DVR-109 and my laptop’s LG GSA-S10N6, using both Toast and Apple’s Disk Utility. No dice under any combination. (On the LG, the discs seem to fail more reliably during burning; on the Pioneer they sometimes complete and fail silently.) However, the error does seem to be reliably caught if full post-burn verification is run on the resulting disc.

So, lessons learned:

1. Always run a full verification cycle on every disc, every time. I got sloppy, and as a result let a few bad discs slip through into my backups. No harm came of it, and they’re a belt-and-suspenders thing anyway, but it’s not hard to imagine how it could have been a nastier surprise. If it’s worth burning, it’s worth verifying.
2. Brand names on optical media are totally meaningless. I’ve discovered the crummy “RITEKS04” stuff under both the TDK and Memorex names. It seems to be the case that if you’re getting a ‘good deal’ on double layer DVD+R 8X media, what you’re getting is probably the RITEK crap. Avoid it like the plague it is.
3. Allegedly, the only decent DVD+R DL media around is Verbatim. I wasn’t able to find any in any local stores in my area, although it is available mail-order. In general, the whole double layer system seems half-baked and worth avoiding unless you really need it.
4. DVD burning isn’t like CD burning. Or at least not like CD burning in the last ten years. I was cavalier about burning DVDs because I mostly burn CDs, and CD writing technology has been pretty reliable — even with cheap non-mail-order media — for the better part of a decade now. DVD burning, especially double layer, isn’t like that; it’s like 1999 all over again with the weird incompatibilities.

It’s entirely possible that there are burners out there that handle the steaming pile that is RITEKS04 just fine, but both of my drives are common models (both are stock Apple parts) and work fine with better grades of Verbatim media.

So much for a good deal on a box of discs.

According to the powers that be at Flickr, you have until June 1, 2010, 12:00 PM PDT to get your historical referrer-log data, if you are a Pro member and are interested. You can download it as CSVs from the bottom of your stats page.

Apparently it is “not sustainable” to keep the data available forever. I suspect this translates to ‘it’s really expensive and only 0.001% of our users actually care or are even aware of it.’ In the future, they will be providing access to 28 days worth of data via the API, but probably nothing beyond that.

I wasn’t even aware that this feature existed until I saw the notice that it was going away, and although their reasons for terminating it are understandable, it is surprisingly interesting data. My strong recommendation is that, if you’re a Pro member and you have a few megabytes of disk and transfer to spare, you might as well take thirty seconds and download them.

Note to anyone thinking of being clever and using curl or wget to batch-download all the files at once: don’t bother, it’s really not worth your time. (Trust me on this, I looked into it.) You’d have to authenticate using Flickr’s API and it’s guaranteed to take longer than just pointing your browser’s download-destination folder to some appropriate place and Alt-clicking on them.

If you download your logs as CSV files — and really why wouldn’t you? Excel gives you no advantage here — you can use this small Python script I wrote to dump them into a SQLite database. The script requires Python 2.5 or later (or possibly an older version with the appropriate PySQLite add-on package, but I haven’t tested that and probably won’t). Bug reports and enhancements are welcomed although it’s not meant to be pretty, since it won’t be of much use to anyone after June 1. The schema should be obvious just from looking at the script; it’s two tables — one for daily and the other for weekly data — and the columns in the CSVs are all carried over into the DB. There’s no date conversion or other fancy stuff.

What you do with it once you get it there is your business; I haven’t really decided what, if anything, to do with it, but it seemed like having everything in a couple of DB tables was a lot more convenient, whatever I might decide to do with it, than having it in dozens of CSVs. (Do keep the CSVs though. They’re small and there’s no good reason not to.) If you have any suggestions of interesting things to do with or ways to analyze the data, let me know by SDF email or in the comments.

Maybe once they get the API access set up, I’ll write something to grab new stats and shove them into the same SQLite DB on top of the existing records. It would only have to run once a month or so to stay on top of the feed, which isn’t that bad.

I was flipping though the channels on TV earlier and came across a new addition to the local lineup — something called The Research Channel. Apparently it broadcasts recordings of presentations by various notable people on a variety of subjects. The recording that caught my eye was Behind the Code with Jim Gray. Gray, at the time of the interview (2005) of Microsoft Research but formerly of IBM, Tandem, and DEC, had some interesting comments about databases, parallel processing, and the future of hardware.

At one point (about two thirds of the way through the video), he describes future processors as probably being “smoking, hairy golfballs.” The ‘smoking’ part is because they’ll be hot, consuming and dissipating large amounts of power in order to run at high clock speeds; hairy because they’ll need as many I/O pins as possible, on all sides; golfballs, because that’s about the maximum size you can achieve before, at very fast clock speeds, you start to run into the “event horizon” (in his words) of the speed of light and lose the ability to propagate information from one side of the processor to the other in one clock cycle.

He didn’t give a timeline on this prediction so I’m not sure it’s fair to call it either correct or incorrect just yet, but it’s interesting. The ‘smoking’ part actually seems to have gone in the opposite direction since 2005; power dissipation has gone down from the highs of the Pentium IV and IBM G5, but it’s possible it could creep back up again if something stops the current trend. He seems to have been right, at least in a limited sense, about ‘hairy’: a look at new processor sockets shows a definite upward trend, with Intel’s newest at more than 1500 pins — common sockets in 2005 would have had less than half that. They’re still all on the bottom of the package, though. The ‘golf ball’ maximum on size is more theoretical, but I don’t think anything has happened recently that provides cause to dismiss it.

After watching the segment, I pulled up the Wikipedia page on Gray, curious to see what he was up to today. Unfortunately, it was at that point when I remembered why his name seemed so familiar: he disappeared while solo sailing off the coast near San Francisco, and despite a massive crowdsourced search effort, he was never found. An sad and unfortunate end for a very interesting guy.

Related:

• A Tribute to Jim Gray from the ACM Queue
• Interview with Jim Gray by Netcraft, on Gray’s work on the Microsoft TerraServer
• Slashdot on Gray’s disappearance
• Slashdot on the search efforts

I really like Yelp, which is probably why I’ve bothered to spend time typing up reviews for it, despite it being a commercial service that could theoretically pull a CDDB at any time. I’ve found a lot of neat little restaurants that I wouldn’t have otherwise found, particularly while traveling, via Yelp, and in general have found the ratings and reviews there to be of very high quality.

However, I’ve noticed that as Yelp’s userbase has grown and expanded beyond the computer-savvy foodie demographic that seemed to have been some of its first users, the average ratings for a particular business are no longer as useful as they once were. It used to be, if a restaurant had five stars and more than a handful of ratings, it was almost certainly phenomenal. Similarly, if a place was languishing at one or two stars, it was probably best avoided — after all, if a place is bad enough to actually get someone (who isn’t being paid) to spend the time to write a negative review, something must be pretty wrong. And if something was in the middle, chances are it was pretty much just average for whatever cuisine it was trying to represent.

Lately, though, I’ve noticed that many places — and this is especially true of eclectic or “acquired taste” restaurants — are getting pushed towards middling reviews not because anyone is actually rating them that way, but because very good and very bad reviews are being averaged out into two or three stars. This isn’t really surprising: reviewing restaurants is a “matter of taste” practically by definition. But that doesn’t make the result very useful. When I’m looking down the search results in Yelp, I want to know what I am likely to enjoy, not what some hypothetical “average user” is going to like. (I’m not the first to notice this problem, either.)

As more and more users join Yelp and start writing reviews, the average review will naturally start to approach what you’d get from reading the AAA guide, or any other travel or dining guide aimed at a general audience. That’s not necessarily bad, and when you’re writing a travel book or dining guide it’s pretty much exactly what you want: try to give an idea of what most people will think of a particular restaurant.

But that’s certainly not the best that an interactive system can do, not by a long shot. The benefit of a website, as opposed to a book, is that the website doesn’t necessarily have to show the same exact thing to everyone. This is why the front page of Netflix is more useful than the top-ten display down at your local Blockbuster, or why Amazon’s recommendations are typically more interesting than whatever happens to be on the aisle-end display at Borders. It’s not that Blockbuster or Borders aren’t trying — they’re doing the best they can to please everyone. The beauty of a dynamic website is that you don’t have to try to please everyone with the same content; you can produce the content in a way that’s maximally useful to each user.

If Yelp took this approach, ratings from users who tend to like the same things that I do would be weighted more heavily when computing an establishment’s overall score; if you brough up the same restaurant (or if it came up in your search results, more importantly), it might have a different score, if your preferences — as expressed via your reviews — are significantly different than mine. This makes perfect sense, and provided that there’s still some way to see what the overall, unweighted average review was (Netflix shows it in small print below the weighted-average), it’s a no-lose situation from the user’s perspective.

I’m sure that Yelp’s engineers are aware of the Netflix model and how it could be applied to Yelp, so this isn’t a suggestion so much as a hope that it’ll get implemented someday.

Earlier today I read a blog entry by Ben Metcalfe that really hit home. The entry is called “My GMail password scares me with its power,” and I’d like to say that he’s not the only one. Particularly in light of the widespread (and apparently quite successful) phishing attacks going around, it’s a good idea to think about how much of your life and personal information are stored behind that one password, and whether that password is really up to snuff.

Metcalf puts forward what I think is a very modest proposal, which I think boils down to two main points. Neither are trivial, but neither are either one a real stretch on technical grounds:

1. Google ought to allow you to enforce some sort of privilege separation: rather than just having one password for everything, more sensitive services (GMail, Google Checkout, Search History) should be able to be configured to use a separate password. This would ensure that the cached password saved in the chat program you use at work couldn’t be used to log into your mail, or make purchases to the credit card associated with your Google Checkout account.

2. Users who are security-conscious could buy a two-factor authentication token, like an RSA SecureID, to use with some or all Google services. This wouldn’t be mandatory and it wouldn’t be free — so it wouldn’t help the clueless or the broke — but it would let those people who are honestly concerned about security but who lack the ability to replicate Google’s services themselves (and, lets face it, just about nobody can replicate Google’s services at this point) to get that security on top of Google’s offerings.

Perhaps neither are economically feasible right now; too few users may care about security—and be willing to pay for it—to cover the cost that either would mean to Google to implement. But as users put more and more of their data in the hands of managed services like Google’s, and security breaches start having more serious consequences, the demand will come.

In the meantime, what’s a concerned user to do? The best thing you can do is to choose a more secure password. If you don’t mind potentially creating something that you can’t memorize, use a random-password generator and either write the results down, or store it in a ‘password keeper’ program that encrypts its data file with one (good!) master password. I take this latter approach, and use the open-source Password Safe on Windows and Linux, and Password Gorilla (which opens Password Safe database files) on Mac OS X. And, of course, take all the usual precautions against potential phishing attacks.

Until Google sees fit to improve on the one-username/one-password architecture for all its services, that’s about the best you can do.

Earlier today my copy of Quicken 2006 for Mac began refusing to download transaction activity from any of my bank or credit card accounts, complaining about an “OL-249” error. It took a bit of Googling to figure out what was going on, so I thought I’d post the solution here.

Short version: you need to download this fairly obscure patch from the Quicken website and install it. You should do this after updating via the regular File/Check for Updates option, and it is in addition to the updates provided via that route.

Longer explanation: from what I can tell, the certificates included with Quicken 2005, 2006 (which I use), and 2007 had relatively short expiration dates. They expired, and for some reason either weren’t or couldn’t be updated via the built-in update mechanism. Hence the additional patch. Why they couldn’t do this via a regular update push I’m not sure, but at least they made them available somehow — I would have half expected them to just tell everyone to upgrade.

Once I ran the installer against Quicken.app, online transaction downloading worked fine once again.

I discovered earlier today, while trying to load my personal X.509/SSL certificates onto my trusty Nokia E61i, that its personal-certificate support is for all intents and purposes intentionally broken.

When the user certificate is imported to Nokia Eseries devices, e.g to be used for authentication with WLAN connections, the certificate contents are checked and if there’s any issues with the certificate fields, the importing of the certificate will fail and the error message “Private key corrupted” is shown.

One common situation where this problem may occur is if the KeyUsage field in the certificate has the nonRepudiation bit enabled. A certificate with nonRepudiation bit is rejected by E60, E61, E61i, E65 and E70 devices because of the security reasons.

The workaround is to create a new user certificate where the nonRepudation bit is removed. The nonRepudiation bit is not necessary when doing a certificate based authentication e.g. in WLAN environments.

Yes, broken. I don’t care what the Nokia engineers were thinking when they put that “feature” in, it sucks. It basically stops you from using 99.9% of all certificates in the world — ones produced using the default settings from most issuers, and forces you to generate a brand new certificate for the device. That is totally unacceptable. Certificates cost money in many cases, and even if they don’t, they take time to create. Plus, managing multiple per-device (rather than per-user) certificates is a royal pain in the ass.

Nokia’s “solution” to the problem would force me to generate a brand-new certificate for my mobile, and then I’d need to replace the certificates stored on every other device with the new one, in order to make sure I can decrypt S/MIME email. If I didn’t do this — if I used one certificate on the E61 and another on my desktop and laptop, the E61 wouldn’t be able to open encrypted email sent in response to messages originating from the other machines.

(This is all assuming the E61i can even do S/MIME, which I’m not 100% sure of; but since it can’t load my certificate, it’s a bit of a moot point.)

Hardcore failure on Nokia’s part. Security, no matter how well-meaning, is worse than useless if it breaks functionality or makes the user’s life this difficult. All it does is raise the ‘cost’ of security, and make it more tempting to forgo things like certificate-based authentication at all.

Up until recently I’ve been pretty happy with the E61i, but I’m feeling more and more that they just didn’t take core functionality seriously enough. The software is flaky and unreliable, as is the Bluetooth stack (I get lockups about once a week when I’m using it with a BT headset or tethered to a laptop), and I question whether anyone who worked on the built-in email client actually used it. (When you have an entire QWERTY keyboard to work with, why does every action require at least 3 clicks on a miniature D-pad?) It does have its charms — JoikuSpot is amazingly useful, and I love not being locked into an iPhone-style “App Store” — but the warm fuzzies are really wearing off.

It’s starting to become clear to me why BlackBerry, and not Nokia, is so dominant among users who actually care about communication over everything else. (BlackBerry offers both S/MIME and PGP, although it seems like it may need to be deployed to an Enterprise Server rather than to individual handhelds.) It’s just unfortunate that the BlackBerry offloads so much intelligence to the BES/BIS backend; I’m not really comfortable being that tied-in to somebody else’s infrastructure, and I don’t really feel like running my own BES.

Maybe it’s time to take a look at Palm.

According to a post on the Full Disclosure mailing list, history has repeated itself: T-Mobile’s systems have apparently suffered a serious breach, and a lot of customer data has been compromised. Oops.

The last time something like this happened to T-Mobile, it was due to a known vulnerability in BEA’s WebLogic application server that T-Mobile had failed to patch correctly. Although the ‘hacker’ in question ended up in the Federal pen for his trouble (one hopes the celebrity email-reading was worth it), and a lot of attention seems to have been paid to the Secret Service’s identification and capture of him, the real culpability was T-Mobile’s. By failing to patch their servers, they left them wide open to infiltration.

It’s a bit too soon to tell whether the latest break-in was similarly due to technical incompetence at T-Mobile, or if they fell victim to some other method. However, it doesn’t sound like the ‘cybercriminals’ behind it all are the sharpest pieces of cutlery in the drawer. Unless they’re playing an amazingly deep game, I think it’s safe to say they didn’t think their cunning plan all the way through.

From the FD post:

We already contacted with [T-Mobile’s] competitors and they didn’t show interest in buying their data -probably because the mails got to the wrong people- so now we are offering them for the highest bidder.

Sounds almost petulant, doesn’t it? “Probably because the mails got to the wrong people” — really? They seriously think that’s the problem? If only they’d had the contact information for the Espionage Division of AT&T, the whole thing would have gone so smoothly!

They would have done better to read up on the Coke / Pepsi trade-secrets bust from back in 2006. A disgruntled Coke employee stole the secret Coke formula and tried to sell it to Pepsi, but Pepsi — much to her surprise, I’m sure — pretty much fell over itself notifying Coke of the offer, and then worked with the Feds during the ensuing investigation. Although the press coverage tried to make a heart-warming after school special out of the whole thing, Pepsi’s behavior should have been predictable and obvious: the risk of getting caught with stolen trade secrets from their fiercest competitor so greatly outweighed the value of those secrets, there was no way they would ever take the thief up on her offer.

The very same situation now exists for the morons who stole the data from T-Mobile. What competitor would even think of touching it? What could any competitor possibly gain from the data that would be greater than the huge downside risk, and could not be obtained more easily some other way? I can’t think of anything. Even if the files were totally complete, and represented dossiers on every one of T-Mobile’s customers completely documenting their behavior and preferences with regards to cellular telephony, it still wouldn’t be worth the near-certain chance of getting busted down the road, when T-Mobile notices a startlingly high number of their subscribers getting poached.

The smartest thing for AT&T, Verizon, Sprint, et al to do, on receiving an offer to purchase obviously stolen records, would have been to immediately report it to the Feds. That they didn’t makes me guess that they probably didn’t even take the offer seriously. How humiliating!

After failing to sell the goods (which I suspect are database dumps) to T-Mobile’s competitors, the thief or thieves then decided to just post a for-sale ad to the Full Disclosure mailinglist — well known in IT security circles, but not known as a clearinghouse for stolen identities. It’s not as though there aren’t venues on the ‘net where trading and selling identity information is common — supposedly there are whole online communities for this purpose — but the FD list certainly isn’t one of them. The only way they could have been more bush league is if they’d used Craigslist. Or maybe Ebay.

So that brings me to two possible conclusions about the whole breach:

1. It was conducted by someone of questionable technical competence (at this point it’s too early to tell), but dreadful business skills, who couldn’t resist undermining the commercial value of the information they stole in order to claim credit in a high-profile way. They chose the FD list rather than some more appropriate sales channel because the FD list gets read by a fair number of security experts, and this means more geek cred. Of course, what ‘geek cred’ gets you in prison is beyond me. (Maybe Hans Reiser knows.)

2. It was conducted by someone who knows exactly what they’re doing, and what we’re seeing is a carefully-constructed ruse of some sort. There might not be any information to sell, or else selling the information at a maximum profit might not be the real goal. Instead, the purpose would be to embarass and tarnish T-Mobile’s reputation as badly as possible.

Admittedly, option #2 does get a little tinfoil-hatty. To profit from it, someone would need to build up a huge short position in DT stock (or certain futures contracts), and hope that the news of the breach would cause the value to slide. However, I don’t even know if this would be realistic: DT is a huge company, and T-Mobile USA is only a part of it. Even a cataclysmic security breach might not do more than wiggle the needle of DT’s share price, requiring a huge position or lots of leverage to take advantage of it.

Neither theory bodes well for the people behind it; according to option #1 they’re clearly incompetent and far beyond their depth as far as professional criminality is concerned. Not exactly a hard target for law enforcement. According to option #2 they’re less stupid, but still at a huge disadvantage: the position they’d need to have built up to profit from the security breach would be visible in retrospect, possibly even obvious. Even spread between lots of accounts, I suspect it wouldn’t take long for the forensic accountants to catch on.

It will be interesting to see how everything pans out in the next few weeks. There is no scenario where it looks good for T-Mobile; those who, like me, are T-Mobile customers can only hope that this time they’ll learn the lesson a bit better, and put some more effort into security.

Earlier today I got an instant message from a friend I haven’t talked to since 2003. Although normally I’d be pleased to hear from an old friend, the fact that the message contained nothing but a link to a web site in the .ru TLD made me suspicious.

Out of curiosity, I grabbed a copy of the page using curl, and then examined it using a text editor. This is the safest way I know of to investigate potentially-hostile web pages; even if the page exploits a flaw in your browser, chances are it’s not designed to exploit a bug in emacs or vi when it’s just being read locally. To no surprise at all, the page was nothing but a bit of JavaScript. (Which is a good reason to browse with something like NoScript enabled.)

Since I’ve just recently started to play around with JS, I thought it would be interesting to take the program apart and see what it does. For safety reasons and because I don’t want to give the malware authors any additional traffic, I’m not going to link to the original Russian site or actually host their index page, but in the interest of science, I’ve put it up on Pastebin for anyone who wishes to poke at. Just be careful and don’t run the thing outside of a sandbox.

Pastebin link to the page’s raw HTML.

They’ve done some (fairly trivial) obfuscation to hide the actual code by way of the two script elements on the page. The first <SCRIPT> defines a Decode function and includes the actual payload in a long string; the second <SCRIPT> calls the decoding function.

Their decoder:

function Decode()
{
    var temp = "", i, c = 0, out = "";
    var str = "60!33!68!79!67!84!89!...blahblahblah";
    l = str.length; 
    while (c <= str.length - 1) {
       while (str.charAt(c) != '!') {
          temp = temp + str.charAt(c++);
       }
       c++;
       out = out + String.fromCharCode(temp);
       temp = "";
   }
   document.write(out);
}
Decode();

Obviously I’ve truncated the value of str here for brevity; it’s several thousand bytes long. What we’re looking for — the actual, presumably-malicious code — is inside that string. There are a number of ways we could get at the contents, but since the malware authors have so helpfully supplied us with a decoder, why not use it? Of course, we don’t want to run it from within a browser, or using any of the online JS shells (which might — stupidly — run the code that’s being obfuscated), but the js CLI shell is a pretty safe option.

If we weren’t absolutely sure what the code was going to do when we ran it, we might want to take additional precautions, like running it inside a walled-off VM, but in this case the code to be executed is trivial.

In order to make Decode() run inside the js CLI shell instead of inside a browser’s JS environment, one small change is necessary: where the code above has document.write(out), we need to change this to a simple print(out). This writes the results to standard output when we run the decoder via js -f badscript.js > badscript.out or something similar.

What we’re left with after running this is the page that the hapless victim actually arrives at, but which the malware author attempted to hide inside the script.

I haven’t had a chance to step through the resulting page completely yet, but it seems like a mess of advertisements combined with scripts designed to make it impossible to close the page. I assume there’s probably more nastiness buried in it besides the obvious, however: since the link was sent to me automatically, it’s a good bet it has a way of propagating itself.

This is fairly neat:

Continuous Audio Life Logs and the Personal Audio Project

This is similar to the photo-based project done by Gordon Bell, well-covered in the press, except with continuous audio recordings instead of still photos. That makes it a lot more practical, and somewhat less intrusive/creepy.

I haven’t delved too far into the papers, but looking just at the graphic on the linked page above, it looks like one of the things they’re doing is cross-referencing audio logs to PIM scheduling information. That struck me as a fairly simple way to instantly make them a whole lot more useful.

Just a neat example of how linking two pieces of information, both of limited usefulness on their own, can create a much more useful resource; one that’s greater than the literal sum of its parts.