July 2008

I've been doing a lot of work over the last few weeks to get my domain portfolio (both my personal one and that used by my employers) all into one place, as they were spread across a mish mash of registrars and pointing at various different name servers and whatnot.

One thing that struck me whilst I was doing this is the scarcity now of three letter domains (and, indeed, "good" domains) under the most well known TLDs (.com, .net and .org) as well as, to some extent, .co.uk. Whilst a quick Google revealed no hard numbers, I'd suspect that the last of the three letter domains under .com were hoovered up some years ago by Domainers (those who purposefully register domains purely to resell them at a profit). Of those remaining, there's obviously a split between business, and personal users.

The only ways in which these domains might come back into circulation are someone forgetting to renew; a business going under; in the case of a domain registered by a person, that person dying.

This is what I'd been thinking about. In the case of the last two, we've been aware for a while now of the value of three letter domains, so, in the future are we likely to see these domains valued by administrators when a company goes under? What about the Government (in the UK) for inheritance tax reasons? Who would decide these values? With a house, it's relatively easy to do. But with a domain, surely the value is much more difficult to calculate.

I found out yesterday that the exam board used in a project I'm involved with will accept the audio recording from an oral test (ie the speaking part of a test) as an mp3 file. This seems somewhat interesting as it's extremely easy to manipulate the files after they've been generated using freeware audio editing tools, such as Audacity. Obviously, though, this problem isn't a new one - certainly, it's possible to manipulate audio on tape or CD with as much ease.

The easiest way to prove that a file has been edited is to generate a hash of the original. If the hash doesn't match this file, then there's obviously been a change to the file. But how does one know that the has generated is that of the original file, and not one of the edited file? What's to stop someone just generating a hash based on the edited file?

Thinking about this a bit further, I hit on an idea. There's open source mp3 players/recorders out there such as the iRiver. This device runs an operating system which can be developed for applications such as this. It would be possible to create a custom operating system for devices such as this which could generate a hash based on the file that's just been recorded, along with the time, date, and a secret cipher. This hash could then be saved to an associated file.

From here, both the audio file and the file containing the hash would need to be sent to the exam board. As usual, if the hash matches the contents, all is good. It wouldn't be easy to create a new hash based on the edited file unless one knew the secret cipher and the other bits associated with the hash (ie method, and the date and time element). There's got to be something I've not considered here, though. What am I missing?

My Macbook Pro has been having some odd problems with the DVD writer for a few weeks now. I use Toast primarily for recording DVD-R and CD-R. Although the machine would read any media quite happily, I was having increasing problems with writing to CD-R and DVD-R. Out of a cake of 100 CD-R, I'd perhaps get a successful write with about 60, gradually decreasing over time to 20 or so. Not good. Googling suggested a dead drive.

Toast would give an error of "Sense Key=Medium Error 0x73, 0x03". Trying to record the disc from Finder would give me an error of "The device failed to calibrate the laser power for this media".

For reference, this is the device information:

MATSHITA DVD-R UJ-857E:

Firmware Revision: ZA0E
Interconnect: ATAPI
Burn Support: Yes (Apple Shipping Drive)
Cache: 2048 KB
Reads DVD: Yes
CD-Write: -R, -RW
DVD-Write: -R, -R DL, -RW, +R, +R DL, +RW
Write Strategies: CD-TAO, CD-SAO, DVD-DAO
Media: Insert media and refresh to show available burn speeds

What concerned me was after the drive failed to write to a disc, the cache line would change to:

Cache: 0kb

After trying the various fixes listed on forums (including Apple's support site) I only had one solution left - a lens cleaner. I've always been somewhat dubious about these things as they seem a little bit snake oil to me. Colour me surprised that it seems to have fixed it.