Among all apps tested, the most widely shared detail was the unique ID number assigned to every phone. It is effectively a "supercookie," says Vishal Gurbuxani, co-founder of Mobclix Inc., an exchange for mobile advertisers.

On iPhones, this number is the "UDID," or Unique Device Identifier. Android IDs go by other names. These IDs are set by phone makers, carriers or makers of the operating system, and typically can't be blocked or deleted.

"The great thing about mobile is you can't clear a UDID like you can a cookie," says Meghan O'Holleran of Traffic Marketplace, an Internet ad network that is expanding into mobile apps. "That's how we track everything."

Anybody else remember twelve years ago, when Intel started putting serial numbers in CPUs? There was widespread outrage, and they dropped the idea.

Today, Google and Apple have (effectively) put serial numbers in (handheld) computers, and software is rabidly exploiting that.

We didn't tolerate it then, we shouldn't tolerate it now.

This entire analysis is spot on, but the reason blacklists are so popular is that they tend to work - you use one, the spam goes down, your users are happy. (Right up to the point where they discover a false positive that the RBL is blocking them from getting, anyway.)

In light of that, "do not use DNS-RBLs" is kind of throwing the baby out with the bathwater. The obvious middle ground, of course, is "don't use DNS-RBLs to make a binary accept/reject decision." Instead, use them as a weighted input to an overall spam score, such as is done by SpamAssassin or policyd-weight.

But then, that's generally more work. :-)

We've been down this road before. In 2003, Intuit's Turbo Tax (for tax year 2002) pulled the same stunt, indiscriminately overwriting sectors at the beginning of the disk (outside any partition) and trashing people's bootloaders.

All in the futile pursuit of DRM. That's reason enough for me to use Tax Cut, instead, every year since.

Clearly, you're not an emacs user.

...just to get my sig into the thread. :-)