Annoyance of the Day: Maps and Intellectual Property

For Christmas 2007, I received a TomTom ONE 3rd Edition GPS Navigation System as a gift from my parents. While I don’t often do a lot of traveling beyond my daily commute to work, I do occasionally, so it’s come in quite handy, particularly as we don’t have a cell phone with which to communicate with someone else en-route if we get lost. However, over the past two and a half years, roads have changed. The only significant change in the local area that I’m aware of is the 146/I-290 intersection, but it’s likely that other roads have changed as well, and the point of a GPS is to navigate me through the places I’m not familiar with.

So, I decided I’d finally get around to hooking it up to my computer and seeing how one goes about updating it. The TomTom software happily offered to update me to the latest version, plus the next 18 months of map updates, for the low low price of somewhere around $75. Since I think that’s around the cost of a new unit, I’m not planning on going that route.

It’s interesting how valuable map data is. It’s an interesting form of intellectual property, in that one would think that most of it would be available from public domain sources. But somehow it’s not, and so the various mapping companies (there’s only one or two, I think, that just license the data to the various GPS manufacturers and online mapping providers) spend a lot of effort collecting the data, by driving around every road they can with their own GPS, and noting the various street signs. I suspect that one of the main driving forces behind Google’s Street View car is actually to collect the mapping data themselves so they can at some point stop buying it from other sources. The Google Maps application for Apple’s iOS doesn’t integrate with the built-in GPS in the later-model iPhones since Google hasn’t paid for that use of the mapping data, or so I’ve been told. It seems that companies that use map data as a business model have found that driving around to collect data is more efficient and/or accurate than trying to use various public domain sources such as government records of roads being constructed.

If there’s a lot of effort that goes into creating accurate maps, it makes some sense for them to be protected by copyright law. But since we’re all so used to going to online mapping services that offer their services for free, it feels like map data ought to be free. There’s one organization I know of that is trying to create a free wiki-like map. I have no idea how accurate or complete they’ve gotten. I’m not aware of anyone working on loading free third-party map data into commodity GPS hardware, although I assume it must be possible.

I think this is just another poorly-constructed rant as I’m annoyed that I can’t get current map data on my GPS. That’s all.

Annoyance of the Day: S/MIME and Mac Mail

S/MIME has what in my opinion is a flaw: There’s no authentication of the time that a message is sent. As far as I can tell, there’s not even any proposed extensions out there trying to fix this. As a result, when one signs an email message with a valid certificate, and then the expiration date of the signing certificate passes, one gets an error when one then later tries to read the email message, as the authenticity of the message can no longer be verified. (Signed code doesn’t have this problem, as the signer can have a third party add a signed timestamp to the code signature, so that the code can still be verified as having been signed by a valid certificate as of the date of the signature, even after the certificate’s expiration date.)

The practical upshot of that is, then when using S/MIME to sign one’s mail, one wants to renew the certificate and start using the new certificate a couple months before the expiration date of an older certificate. You want people that you email to be able to authenticate that your messages are genuine for at least a couple months.

So, for this period of at least a couple months, one would have two valid personal certificates installed on one’s system, the old one that expires in a couple months, and the new one (that would typically expire in a year). When sending email, one would pretty much always want to be signing with the newest certificate that has the latest expiration date. But, one wants to have both installed, in order to be able to decrypt messages sent that were encrypted to either key.

Mac Mail (and/or Mac Keychain Access, which it uses) doesn’t seem to see things that way. In Apple’s characteristic style, signing mail “just works” and there are no options to configure it. In particular, it just uses the first signing certificate that’s installed which is valid for the sending email addresses. And by “first signing certificate”, I mean the one that was installed first, which is going to be the one with the soonest expiration date.

So, whenever I renew my certificate and install the new one, I need to go into Mac Keychain Access, export the old certificate, delete it from the Keychain, and re-import it. That way, the old certificate is no longer the first signing certificate, and Mac Mail signs using the correct newest certificate that has the latest expiration date.

This is a real shame, because in most ways Mac Mail’s handling of S/MIME is just perfect, since it does “just work” without any configuration. I just needed to get this annoyance off my chest. Thank you for reading.