Fair is fair: If we're going to pick on Apple about the iPhone supposedly tracking its users' whereabouts, we should at least share the news that Google apparently does it, too. Says The Wall Street Journal:

In the case of Google, according to new research by security analyst Samy Kamkar, an HTC Android phone collected its location every few seconds and transmitted the data to Google at least several times an hour. It also transmitted the name, location and signal strength of any nearby Wi-Fi networks, as well as a unique phone identifier.

Meantime, some bloggers are making a case that the data collection that brought Apple so much attention yesterday isn't tight enough to constitute personal tracking. Andy Inhatko writes:

• This database isn’t storing GPS data. It’s just making a rough location fix based on nearby cell towers. The database can’t reveal where you were…only that you were in a certain vicinity. Sometimes it’s miles and miles off. This implies that the logfile’s purpose is to track the performance of the phone and the network, and not the movements of the user.
• A third party couldn’t get access to this file without physical access to your computer or your iPhone. Not unless you’ve jailbroken your iPhone and didn’t bother resetting its remote-access password…or there’s an unpatched exploit that would give Random Person On The Internet root access to your phone.
• It’s pretty much a non-issue if you’ve clicked the “Encrypt iPhone Backup” option in iTunes. Even with physical access to your desktop, a no-goodnik wouldn’t be able to access the logfile.

But:

And while the logfile can’t tell someone that you were at a specific house, it can obviously tell your boss that you went to the Cape on the day you called in sick.

Over on Daring Fireball, John Gruber thinks Apple's issue may boil down to a bug:

The big question, of course, is why Apple is storing this information. I don’t have a definitive answer, but the best at least somewhat-informed theory I’ve heard is that consolidated.db acts as a cache for location data, and that historical data should be getting culled but isn’t, either due to a bug or, more likely, an oversight. I.e. someone wrote the code to cache location data but never wrote code to cull non-recent entries from the cache, so that a database that’s meant to serve as a cache of your recent location data is instead a persistent log of your location history. I’d wager this gets fixed in the next iOS update.

There'll be more to come on this, I'm sure. Meantime, expect your specs to carry more language along the lines of "Data must be kept really, really secure. Really." Thanks to MobileBeat for its inspiration.