Google blocking paid apps for Developer Phones

Apparently, if you paid the $425 to purchase an Android Developer Phone (ADP1), you are now a second class citizen. Google decided that you can't have paid applications.

Article here.

It's pretty surprising that they'd do this, since we're basically talking about alienating the most hardcore fans and the developers that make your platform worthwhile. There were a lot of areas where Google either just didn't think things through or rushed to market before things were ready (the Email app!).

Here is the rub, as far as I'm concerned:

Google depends on file permissions to control applications.
The developer phone has the ability to copy paid applications.
*All* rooted phones have the ability to copy paid applications (since using file permissions isn't very secure).

So, Google has decided to punish all users that have the ADP1 version of the operating system (all phones can currently be switched between all the different versions of the OS: US/UK/Europe/ADP). Note that this isn't the same set of users that have the ADP1 hardware; at least one person I know has an ADP1, but has a rooted version of RC33 (the US version).

If you took the time to put a rooted version of one of the consumer versions, then you are unaffected by this. And, since clearly all the people who spent $425 on the ADP1 are merely agents of software piracy, they will all be doing this so they can pirate all the paid applications in the Android Market.

Pirates! Arr.
Read more...

Duplicate message ids in the sendmail log

Here's a quick little perl script that can help you find duplicate message ids in your sendmail log. Script and explanation after the break.

#!perl

while (<>) {
        ($_ =~ /msgid=\<(.*?)\>?,/) && ($msgid = $1);
        $ids{$msgid}++;
        print $msgid . "\n" if ($ids{$msgid} == 2);
}

Where to use this script? Let's say, hypothetically, that you have email coming in that is causing the mail server to tempfail a message (over and over). Or you have a server that is sending a mail message over and over. This script can help you find those messages quickly.
Read more...

Stem Cell Research (what hill do you want to die on?)

I think that stem cell research is an important avenue of medical research.

Embryonic stem cell research (as opposed to adult stem cell) has ethical issues related to it. Read on, and I'll tell you why embryonic stem cell research might not be such a great idea, and maybe some insight into the organizational management issues related to it.

This post was triggered by an article on the Examiner.

Yet another breakthrough for stem cell research. Make sure you understand, though: that's adult stem cell research. All of the innovation in stem cell research (including actual medical treatments that are available today) is in adult stem cell research.

It makes no sense to me to spend money on embryonic stem cell research, when over ten years of research, and tens or (more likely) hundreds of millions of dollars have been poured into it, to the net result: zero innovation, zero breakthroughs, zero treatments based on it. What a waste of money and time.

Here's the thing though: once it became a political issue, there was a certain camp that demanded that it be pursued, simply because "the other guys" said that they didn't like it. This isn't a discussion of the politics of the issue, but the idea that people will do things that make no sense just because someone else tells them not to. Those of you with children understand what I'm saying.

Now, I've been a victim of this thinking. I even saw it coming, and it still happened.

I worked for someone who could always get me to take action just by saying, "well, if you think you can't do it...". I knew his strategy, but was still susceptible.

In life (and work) we have to be able to take an objective step back, and ask ourselves: is this the hill I want to die on? Is this actually productive, or am I just pursuing it for emotional reasons?
Read more...

Thinking about reputation services

One of the most popular methods of blocking spam these days is to use a device which implements a reputation service. Unfortunately, there is a significant issue with these types of services. With a little research, a spammer could effectively bypass this protection or pollute the reputations of so-called "good" hosts.

A short description of how reputation services work, and then a breakdown of the failure spot after the break.

Reputation services work on a simple principal: they keep a list of hosts and their respective reputations, and they perform actions based on the reputation of the connecting host. This system "trains" like a bayesian filter does--hosts can improve or decline in status over time. Typically this is augmented with a service which updates this host list.

The two important points to keep in mind here are that a) they track IP addresses, and b) they use training.

A brief sidebar to talk about the Internet Protocol (IP). IP packets can become fragmented for various reasons, including intentionally. The IP specification has a method to re-assemble these fragmented packets:

To assemble the fragments of an internet datagram, an internet
protocol module (for example at a destination host) combines
internet datagrams that all have the same value for the four fields:
identification, source, destination, and protocol. The combination
is done by placing the data portion of each fragment in the relative
position indicated by the fragment offset in that fragment's
internet header. The first fragment will have the fragment offset
zero, and the last fragment will have the more-fragments flag reset
to zero.

The important section there is "placing the data portion of each fragment in the relative position indicated by the fragment offset". In other words, each fragment gets to determine where it starts. By specially crafting packets, it is possible to forge the source and destination ip addresses, but this is only evident if the packets are re-assembled. If you are running at high volume, packet re-assembly is expensive.

Here's the potential problem: if you have a reputation service (which, by definition, needs to handle high volume), it could easily fall prey to clever spammers using IP fragmentation to bypass or pollute the reputation data. If they were truly evil, they would deliberately ruin the reputation of valid, non-spamming organizations.

Worse still, most of these reputation devices communicate back to a central reputation store, so it would be possible to create a denial of service against certain organizations: the ruined reputation now propagates out to other subscribers of the service.

Defense in depth is the only strategy that truly works long term.
Read more...