Year: 2007

Don’t feed the raccoons

Piracy is a fact of life for software developers. There are always douche-bags who think they should get your hard work for free. Sometimes this takes the form of distributing serial numbers, sometimes it’s kracking the application to eliminate the checks. I’ve come to accept this as part of running a software business.

Recently, however, a certain individual has made a claim that Twitterrific has a security vulnerability that allows it to be modified and not display ads. That is a very serious claim; not just for my application but for all Cocoa applications. And it puts my good name in a bad light.

I am not going to link to the individual in question since it’s likely that these claims are attempts to generate traffic (link baiting.) Instead, I’ll link to a salient tweet by my friend John Gruber.

Without getting too technical, the claim is that a tweet received by Twitterrific causes code to be executed. That code modifies the application and eliminates the ads. If true, this would mean that there is a security vulnerability in the Cocoa frameworks that process XML (NSXMLDocument) or text (NSString). A security vulnerability of this type would have broad implications: applications like Safari, NetNewsWire, and anything else that processes XML or text would be vulnerable to malicious payloads. A vulnerability of this magnitude should be reported directly to Apple, not just posted to some shitty little web log.

Fortunately, I have yet to see this exploit actually do anything. Nor has the person making this claim produced any source code showing how it’s done. (Why does a vulnerability have to be released under the GPL anyway?)

All I can assume at this point is that Marc Fiszman is not only a jackhole, but a very dangerous one: and not for the security exploit, but for the libel.

My partner, Dave Brasgalla, has a phrase for this kind of situation: “Don’t feed the raccoons.” Feeding these individuals only makes them want more food and leads to unnatural behavior, malnutrition and disease. So my best course of action at this point is to clear my name and ignore this jerk.

There is some good to come out of all of this: I’m reminded that for every idiot on the Internet, there are hundreds of individuals that are kind and supportive. The comments and registrations we’ve received in response to this incident are much appreciated. I thank you all.

Written on December 28th, 2007 for Advice, Development

Silence is golden

It’s been rather quiet around here for the past couple of weeks. This is why:

MobileTwitterrific

After I get back from a much needed break, I’ll get an alpha release ready. In the meantime, use the source, Luke.

Update: If you haven’t figured it out by now, we’re holding off on future development until Apple releases the SDK in February 2008.

Written on September 11th, 2007 for Miscellaneous

Put your content in my pocket

Sometimes it takes awhile to fulfill a promise.

One such pledge was made last century to my good friend Jeffrey (he was only a prince at the time.) I said that I’d love to write something for his fledgling mailing list: A List Apart. This past month, I finally got around to writing that piece: Put Your Content in My Pocket.

If you’re visiting this site for the first time, you might be interested in the original article that prompted our collaboration. I’ve also written some articles that explore some of the problems, performance and less than obvious features on the iPhone. For the hard core geeks, there are also some explorations into the specifications.

So enjoy your visit and please make sure to join in the discussion forum at ALA if you have any questions or concerns about my article. Thanks!

Postscript: I mentioned some nonsense in the article: here it is, the Eric Meyer Memorial iPhone Blocker.

Written on August 27th, 2007 for Design, Development, Personal

What the iPhone specs don’t tell you…

The iPhone technical specifications mention nothing about how much RAM is included nor how fast the CPU is running. Now that I have a toolchain, it was a simple task to take some code from iPulse to investigate.

Note: Apple has obviously not documented the system level APIs that I’m using to extract this information, so take these numbers with a grain of salt. Personally, I doubt that they would bother to make these low-level functions report erroneous information just to protect some consumer spec sheet, so it’s likely that they’re close if not exact.

First, let’s start off with memory. Calling host_statistics() with HOST_VM_INFO returns a count of the number of memory pages in use (the “vm_stat” tool at the command line does the same thing.) Totaling these counts shows that there are 19,500 pages of memory with each page being 4096 bytes. That’s 78,000 KB or 76.2 MB.

Another way to determine memory size is by calling sysctl() with CTL_HW and HW_PHYSMEM. This results in 121,634,816 bytes or 117 MB being reported for physical memory. Similarly, user memory is reported as 93,605,888 bytes or 89.3 MB—close to the 76.2 MB reported by host_statistics(). These calls are equivalent to using “sysctl hw.physmem” and “sysctl hw.usermem” from the Mac OS X command line.

None of these numbers are the nice round powers of 2 that we’re so accustomed to. I suspect that there is some kind of memory partitioning: something like a graphics chip could be using 11 MB of memory and that combined with the 117 MB of physical memory would bring the RAM total to 128 MB.

Now let’s take a look at the CPU speed. Again, sysctl() is our friend, this time using CTL_HW with HW_CPU_FREQ and HW_BUS_FREQ. The results of our test show that the CPU is specified at 400 Mhz with a bus frequency of 100 Mhz.

There have been various hardware reports that place the ARM chip’s frequency above 600 Mhz. Maybe sysctl() is lying to us, or maybe the CPU is clocked down to give improved battery life. Only Apple knows that for sure.

For those of you who care, the source code used for the tests is available.

Written on August 21st, 2007 for Observation
Older