Year: 2011

Un-Trusteer-ed

The bank we use for our business account recently mandated the use of a product called Trusteer Rapport while accessing our information online. Although Mac OS X doesn’t have any problems with “increasingly sophisticated malware in the online environment”, I do need to periodically check our accounts and transactions so I proceeded with the installation.

The first warning sign was after starting the Installer: I was prompted for an administrator password indicating that this software wanted to run from protected areas of my system. Being a developer, I immediately dug into the installer scripts and configuration files to see that the app is placing items in the Rapport/bin, PreferencePanes, LaunchDaemons and LaunchAgents folders of the main system Library folder. The launch folders indicate that the software will be run whenever my Mac is restarted and will be able to do things a normal user would not (because of elevated permissions.)

I placed my security concerns aside as I need to access my bank website, so I went ahead with the installation. Afterwards, I was directed to a web page describing the new software.

Again, as a developer, my first thoughts were suspicious ones. From experience, I know that it’s not easy to modify Safari’s user interface in the way that Trusteer was doing. My guess that there would be a new, always active, background process was confirmed by the presence of “rooksd” in my process list.

However what happened next really opened my eyes. Safari crashed.

Of course that, in and of itself, isn’t the end of the world. But I was surprised to see a new library named RapportUtil1 while looking at the Safari crash report. It was pretty clear that the new Trusteer software caused the crash. But how?

As a longtime Objective-C developer, I know a thing or two about “method swizzling“. In a nutshell, this allows a developer to replace the functionality of code they don’t have direct access to (typically in the system or other frameworks.)

Seeing “_nsapplication_sendEvent_override” tells me that Trusteer is using this technique to change the behavior of Safari. The function that is being affected is -sendEvent: — the part of every Cocoa application where mouse, keyboard and other input is routed.

Method swizzling is a dangerous activity. You have to make assumptions about how some other code, that you’ve never seen, is behaving. You also need to think about how that code might change in future versions. There are extreme cases where this technique can be effective: overriding the default behavior of my web browser is not one of them.

It’s clear that the folks taking control of my browser aren’t as clever as they think. Do you see a common theme when you search Apple’s discussion forums for “RapportUtil1“?

Even more troubling is the method being overridden: every key press or mouse movement is first being sent to Rapport and then forwarded onto Safari. Since this happens often, the intruding software can do pretty much whatever it wants, whenever it wants. And remember that part of this package is running with elevated permissions in the background.

After mentioning my findings on Twitter, I got back some very interesting replies. Graham Lee (@iamleeg) pointed out that I’m not the first developer to question the technical merits of this software. But then Peter Hosey (@boredzo) dropped the real bomb. Trusteer tacitly admits to recording my password. That’s easy to do when you take control of -sendEvent:.

Essentially, my bank is asking me to install is a keylogger. Just so they can warn me not to use the same password on suntrust.com and playboy.com.

Hopefully, the engineers behind Rapport are smart enough to be using hashed passwords rather than clear text. And hopefully none of the personal information Safari has access to is being forwarded to the Trusteer servers. And hopefully they’re not recording how many times I visited playboy.com last month. But that’s beside the point, because as a closed source product, no one can audit their activity. That’s not true with Safari.

Oh, and there’s one other thing: the Rapport software isn’t supported on Lion. One of the tenets of method swizzling is to test your software early and often with any new release of the system or framework that it’s modifying. As a developer, you need to be proactive about fixing any problems that pop up in the code you are overriding. Not doing so is irresponsible and puts your users at risk. The last update for Rapport was in 2009.

(One could speculate that the new privilege separation architecture for Safari in Lion is causing Trusteer’s developers a lot of headaches. The other tenet of method swizzling is to remember that it’s not a matter of if your hack will break in the future, but rather when it will break and how painful it will be to fix.)

Needless to say, I have uninstalled this software and will never be installing it again. I would recommend this course of action to any end user.

But that leaves me with a problem: how do I access my bank’s website? I have three options:

1) Find another bank. This is a difficult choice, as there are many systems that are hooked up to this account: ACH transactions for sales via iTunes, bi-weekly payroll, automatic payments for services, etc. I’d also like to give SunTrust a chance to reconsider their position in requiring this software (they will be getting a copy of this report.)

2) Use the telephone. I can call the bank when I need the information. Sure they’ll get tired of hearing from me, and it will cost them more for customer service, but it’s their choice to require Trusteer Rapport.

3) Run the Trusteer Rapport software in locked down environment. Once it’s supported on Lion, it should be possible to create a virtual machine that that will only be used to access the bank website. Needless to say this is inconvenient, a waste of resources, and severely limits my ability take advantage of my bank’s services.

In closing, I’ll leave you with one final irony: I will never be able to access my bank’s website from what is arguably the most secure computing device in existence today. That’s because the iPad is not a supported platform. Apple only allows third-party applications to run in a secure sandbox where they can’t affect other applications or the operating system. What you’ve seen above is exactly the reason they’ve done this.

Written on August 1st, 2011 for Advice, Development, Miscellaneous, Observation

The Rise and Fall of the Independent Developer

I’m old enough to remember a time before the Internet. I know what it’s like to develop software both with and without a worldwide network.

Little has changed with the process of software development since the 1980’s. Of course there have been improvements in our tools and techniques, but the basic act of creating software products is much the same. What has changed dramatically in the past 30 years is how we distribute our creations.

In the days where software was distributed on magnetic media, such as reels of tape, cassettes, or floppy disks, it cost a lot of money to get the product to a customer. As a result, large companies and software publishers were the only ones with the financial resources to get these applications into a retail channel. There were very few independent software developers; and those who did exist were very small operations.

Then along came the Internet and everything changed. Distribution was suddenly cheap.

I remember a conversation with my good friend Cabel Sasser a few years ago. He and I were reminiscing about our first foray into online distribution and were surprised that we had the same initial reaction: “Holy crap! We can put our software on the Internet and people will actually buy it!”

Many other developers had this same experience and began leaving large companies to work on their own. Making a good living while having the freedom to work on their passion was a great life.

Now distribution is going mainstream with the App Store. And it’s already begun changing the lives and businesses of independent software developers. On the surface, it all looks good. There are more customers, increased revenues, and many great new products.

But this expanded distribution is also putting our business at risk: there are people in this new market who claim a right to a part of our hard work. Either by patent or copyright infringement, developers are finding this new cost of litigation to be onerous.

The scary part is that these infringements can happen with any part of our products or websites: things that you’d never imagine being a violation of someone else’s intellectual property. It feels like coding in a mine field.

From our experience, it’s entirely possible that all the revenue for a product can be eaten up by legal fees. After years of pouring your heart and soul into that product, it’s devastating. It makes you question why the hell you’re in the business: when you can’t pay salaries from product sales, there’s no point in building it in the first place.

So, just as in the days of magnetic media, the independent developer now finds him or herself at a point where it is again becoming very expensive to distribute their products to a mass market. This time the retail channel itself is very cheap, but the ancillary costs, both financially and emotionally, are very high.

And, of course, only large companies and publishers can bear these costs. My fear is that It’s only a matter of time before developers find the risks and expenses prohibitive and retreat to the safety of a larger organization. We’ll be going back to square one.

Over the years many of the top selling apps have been created by independent developers, starting with Steve Demeter and Trism at the App Store launch, and continuing to this day with titles like Tiny Wings by Andreas Illiger.

Losing that kind of talent and innovation to a legal system is the real crime.

Written on July 13th, 2011 for Business, Development, Opinion

Predators

Dear Steve,

I’m one of the developers that is affected by the Lodsys patent infringement claim. I’m writing not to beg for your support, but rather to give you a better idea of how this legal action affects the average iOS developer.

We’re a small company. We have 12 employees that have created 14 products for Mac and iOS. We have been incorporated in the state of North Carolina since 1999. We won an Apple Design Award in 2008.

We’ve been doing product development long enough to know that legal expenses are just a part of doing business. But as we both know, the costs of patent litigation can be staggering. As a small company, we don’t have the resources to defend ourselves, so that leaves us with one option: to pay a licensing fee.

And that worries us and every other iOS developer we know.

In and of itself, paying half of a percent of our App Store sales to Lodsys isn’t going to put us out of business. The fear we have is that this is the first step on a very slippery slope.

It’s well known that the top titles in the App Store can earn tens of thousands of dollars per day. There are many predators with dubious patents who see dollar signs when they look at the flock of iOS developers.

What these predators don’t realize is that for every developer who’s earning millions, there are many thousands who are earning much less. This backbone of the iOS ecosystem is doing well with work we love, but that is very much at risk with increased legal costs. We wonder what happens when these predators discover that the earnings from these apps are much lower than they expect. Will the licensing fees increase as a result? Will our next infringement be 5%, 10%, or more?

Of course, this is also a slippery slope for Apple. Taking on a legal burden for an entire platform is not something we would want to do, especially when the root of the problem is a screwed up patent system.

We love developing products for iOS and the Mac, but this legal mess has already started killing that enthusiasm. Apple has revolutionized the distribution of software via the App Store and that has been a great boon for smaller developers. It makes us furious that these greedy predators can put all of that at risk with patents.

Thanks for your time,

Craig Hockenberry

Written on May 23rd, 2011 for Business, Development, Miscellaneous

A disappointment…

When we released Chameleon at the end of last month, we thought we’d try something new to raise funds for the project. Selling T-shirts and stock icons seemed like a pretty good way. Boy, were we wrong.

Since March 22nd, we’ve sold 17 shirts. If you do the math, that will pay for less than a week of our time. And considering that we’ve already spent more than a week getting things rolling on Github and preparing a talk at the VTM conference, we’re already running at a deficit.

In summary, we’re very disappointed with how things have turned out. Not because of the funding, but because there’s some potential here that will never be realized. We’ll continue to add things we need for our own products, but don’t expect to see any documentation or bug fixes that don’t affect our own code. Any changes or fixes will get pushed out to the community on a schedule that suits us best: probably at the end of minor release cycles (every few months.)

To those of you who were so generous to contribute to the project, we appreciate your support. Unfortunately, we’re sorry to say that such a low volume of T-shirts doesn’t warrant the time and energy needed to get them printed up. We’ll make sure that the credit card orders are cancelled.

Damn.

Updated April 19th, 2011: To be clear, we’re not disappointed with the Mac and iOS developer communities. The source of our disappointment is that we can’t afford to spend time working on general improvements to the framework.

Updated April 20th, 2011: We’re hearing a lot of “let the community help”—which is great and has already started happening. We will continue to support this aspect of Chameleon: we’re not giving up on the project.

But the area where the community is not equipped to help is with documentation. We have nine months of experience with porting an iOS app to the Mac: no one else is presently in a position to help other developers achieve the same goal. We also know that writing is a long and difficult task (my book took seven months of full-time work.) A lot of time is going to be wasted without this transfer of information: so be it.

So much of the open source community focuses on the details (code) without looking at the big picture (how people are going to use that code.) And if you try to think beyond the status quo, you get called names.

We’re also painfully aware that we’re new to managing open source projects. It’s likely that 13 years of selling software is tainting our decisions, but our hearts are in the right place: we want to help the iOS and Mac developer communities.

Finally, we’ve added a more traditional Donate button on the Chameleon Project page. Thanks in advance for any contribution you can make.

Written on April 19th, 2011 for Development

Revealing

To date, the Iconfactory’s contributions to open source have been fairly small. That just changed: in a big way.

I’ll be honest here—we’re a bit nervous about this release. We’re not used to revealing our work before we’re completely happy with the results. We’ve spent over nine months getting this far, but there’s so much more to do. We’d like to continue work on this project and get the developer community involved. And that’s going to take time and money.

So please take a moment to check out the Chameleon Project website and buy an exorbitantly priced T-shirt to help us achieve our goal. Thanks!

Written on March 22nd, 2011 for Development
Older