Category: Advice

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

iPhone multitasking

It’s no secret that “multitasking” is one of the great new features of iOS 4. Unfortunately, many people have a misconception about what Apple has implemented. Hopefully this short essay will help you understand the restrictions and the good reasons for having these limits.

On your desktop, multitasking means that any application or process can run at the same time as another. Technically, there’s no reason why the same can’t be done on a mobile device. However, from a more practical point-of-view, there is one good reason why you don’t want this: a running app uses energy that decreases your battery life. Running fewer apps means you can listen to music longer, make more phone calls, or call up Maps at the end of the day to find a place for dinner.

At the same time, there are certain types of app that must run in the background in order to be useful. Apple has identified three categories of apps:

  • Audio – Apps that plays audible content while in the background. The poster child for this type of application is Pandora.
  • VOIP – When you’re making or receiving phone calls over an Internet connection, you’re using a “Voice Over Internet Protocol” app that runs in the background. Skype is a good example.
  • Location – Some applications need to run in the background so they can keep track of your current location. An app that logs GPS coordinates while you take a walk or run would need to do this.

Additionally, apps can tell iOS 4 that they need additional time to complete a task or want the user to be notified at a specific time. This lets apps finish a long download or pop up the little blue window like an incoming SMS message.

These simple rules cover a wide variety of situations, but there are still some cases that aren’t covered. The main shortcoming is with apps that need to periodically refresh data. Social networking apps, chat programs, news readers, and other utilities that check the Internet for changing data don’t fit into any of the above categories. Developers have proposed solutions to these problems, but there’s no solution for today’s software.

Part of the confusion with multitasking comes from Apple’s excellent implementation of “task switching”. When you double-tap on the home button and start another application, the previous application is “frozen” and put into a state where it’s not running but can be restarted quickly. A part of the freezing process also reduces the amount of memory being used: allowing more applications to fit in freezer.

The next time you tap on the app’s icon, it is “thawed out” and put back on your iPhone’s screen while the previous app is frozen. This process is repeated each time you launch an app.

This sleight of hand makes it feel like you’re running many more applications than you actually are. It also explains how your iPhone can continue to have great battery life while you interact with many different apps. Most of your apps will be frozen and not using power: only the app on your screen is active. And even with audio, phone or GPS apps that are running in the background, you won’t be using more than one of those at a time (go ahead and try to listen to Pandora and the iPod apps at the same time!)

Hopefully this short explanation helps you understand that the developer of your favorite app isn’t being lazy about doing refreshing in the background! If you feel strongly about this situation, the best thing you can do is give Apple some feedback.

Updated July 1st, 2010: Matt Neuburg has written an in-depth explanation of fast app switching at TidBITS.

Written on June 21st, 2010 for Advice, Development, Miscellaneous

Don’t design for early adopters

If you’re like me, the iPad has changed how you look at computers in just a matter of weeks. The possibilities for this device seem endless. It’s natural at this point to start thinking about the future, and to do that thinking in terms of the past.

As an example, we’ve been getting plenty of feature requests for Twitterrific that ask for features and capabilities that exist in other mobile and desktop software. That’s not surprising, since one of our early decisions with the iPad app was to trim the app down to its bare essentials.

Part of this had to do with schedule constraints. Sixty days was not a lot of time to build a product from scratch.

But a more important reason for paring back the design was to simplify the user interface. A new kind of user is about to be introduced to a computer that they can actually use: less interface is more as far as they’re concerned. We designed our iPad app with our families in mind, not the Twitter power user.

It turns out that our design intuition was pretty good:

The non-tech-savvy users want something simple, to push an icon and get your e-mail and go online. With the iPad, people don’t feel intimidated by it.

Mary Elizabeth O’Conner

To this technical-ninny it’s clear
In my compromised 100th year,
    That to read and to write
    Are again within sight

Of this Apple iPad pioneer.

Virginia

Even folks that have access to the latest and greatest technology are preferring the iPad over more complex devices. Initial statistics also show that the iPad has an older demographic.

Of course, 300,000 geeks like you and me don’t fall into that category. We’re the first ones standing in line at the Apple store, and the first ones to use all this cool new software. And we know all the things that apps “used to do”. And we want all sorts of other bells and whistles. And we’re wrong.

As a developer, you should be very careful about this early feedback for your app. Simplicity is the name of the game in this new world order. You don’t maintain simplicity by adding tons of features.

Two of the most requested features after the 1.0 release of Twitterrific for iPad were Instapaper support and photo uploading. If you think about these things, both have a high cognitive load. To use Instapaper, you need to know that:

  • The service exists, and that you can signup for an account.
  • That you can install a bookmark and use it to save pages from your browser.
  • That these saved pages can be synced to your iPad using another application.

For photo uploading, you have to know how to do one of these things in order to “get a picture”:

  • Use the camera connection kit to transfer photos, or
  • Take a screenshot with a non-intuitive gesture (the power and home buttons), or
  • Tap and hold on a picture in a web page and save it to an album, or
  • Create events in iPhoto and sync them with iTunes

Ask yourself if you could explain any one of these things to your mother in less than 25 words. I know I can’t and I’m pretty good with this kind of stuff.

Of course, these are both useful features and we added both of them in subsequent releases. In the case of Instapaper, the feature doesn’t even show up in the UI until you go into the Settings app and add your account information. My mom will never see it.

Photo uploading is a simple button on the compose screen that lets you choose a photo from your library. Eventually, our mothers will figure out how to add things to the photo library and use that feature. But they’ll be happiest when a future device let’s us put a “Take Picture Now” button on that screen.

It’s very easy to get caught up in the excitement this new device has generated in the last month and a half, but the real thrill will be in a year’s time when people who’ve never used a computer will be telling you how much they love your app. And there will be a lot more than 300,000 of them…

Updated: Check out similar thoughts from my colleages: David Lanham and Gedeon Maheux.

Written on May 20th, 2010 for Advice, Design, Development

Waving a red flag

As a result of my last essay, it has come to my attention that there is a simple and effective way to get Apple’s attention for critical bug fixes. An email to appreview@apple.com that explains the critical problem and which product is affected will help speed your update through the system.

Use this email address only for issues with application reviews. If you have a problem with iTunes, getting paid or any other part of the App Store business, use the Contact Us section of iTunes Connect.

Don’t abuse this important communication channel, or we’ll lose it.

Written on July 23rd, 2009 for Advice, Business, Development

Trendy

If you’re reading my essays, it’s likely that you’re selling some kind of software on the Internet. (Or soon will be.)

To be successful at this endeavor, you need to monitor your sales and plan development around the revenue. Ask anyone who’s had success with a software product, and I can guarantee you that they have some kind of metric that tells them how well they are doing.

What I’d like to do today is share one of my favorite methods. But before I do, let me share some advice that will help you understand why this tracking scheme is so effective.

If you’ve released a product, you no doubt have witnessed the “first day spike.” It’s one of the great things about doing a release: you find that people really do love your work.

But there can be a problem. Typically, that initial spike is followed by an exponential curve: every month you’re making half as much money. And even though your income is less and less each month, the support load from existing and new customers stays fairly constant. You’re working just as hard, but earning less.

So how do you work around this? As you would in any other business: by planning ahead.

As software developers we often fall into the “just one more feature” trap. We want a 1.0 release to be awesome, and that one more thing will only take a day or two, and people will love it, so why not?

Because that awesome feature could be a very good thing to generate buzz and sales for a 1.1 or a 1.2 release. And by not “doing it all” in the first release, you get your product to market faster. You’ll be making money while you implement that cool new feature.

And holding back can have another advantage: you might find that your users want something different than what you had planned. Their input can often change your idea, so don’t waste time doing something without feedback.

So when do you know that it’s a good time to do a 1.1 release? A general rule of thumb is 30-90 days after your 1.0 release. On the day you release your 1.0, you should have some code already in the works for the 1.1 release. Give yourself a head start on the next release, because you’ll find those first 30-90 days are consumed by customer support and go by very quickly.

(I can also guarantee that you’ll have a 1.0.1 release because of some stupid little bug you overlooked. So make sure you plan ahead for that, too.)

With all this in mind, I present a simple way to visualize your release cycles by graphing trends of averaged daily sales:

The graph shows four hypothetical products and their sales. The Y axis shows how much the product earned. The X axis shows increasingly short time intervals. To plot each Y value, you just take the total amount sold in that period and divide it by the number of days. The intervals were chosen because they’re nice approximations of monthly, bi-monthly, quarterly, bi-yearly and yearly cycles.

Let’s say the Y grid lines are at $10, $20, $30 and $40 earned per day. The red product has sold about $2.50 per day over the past month, and about $10 per day over the past year. It’s a product that’s definitely in need of a version bump. An update should push it over $10 per day in the 30 day interval.

The gray product shows how a new release looks. Instead of seeing a spike, you’ll see the averages for all intervals go up (with the most change at the most recent intervals, of course.) You’ll also see the most recent averages go up as a result of ads, reviews and other good PR. As time goes on, the 30 day average will eventually drop. When it gets below the 60 or 90 day average, that’s a good time to do a release.

The goal is to end up with a product like the green one. For the most part, it trends upwards. You’re doing things right.

Finally, this graph also shows products that you shouldn’t spend time on. The lavender product isn’t performing as well as the others. Your time is better spent on things that are going to generate more revenue.

In case you’re wondering how I generated these graphs, it’s proprietary Ruby on Rails code that reads our financials and feeds them to XML/SWF Charts. The information in these graphs will change frequently: you’ll want to find a way to automate the collection and processing of your own sales data.

I’ve been talking with Dylan Bruzenak about incorporating this trend graph into AppViz. Hopefully we’ll see it in a future release—make sure to let him know if you’d find it helpful. (And if you’re not already using AppViz to track your iTunes sales, pull your fricken’ head out and start using the trial version.)

Who knew that accounting could be so trendy?

Written on March 2nd, 2009 for Advice, Business, Observation
Newer
Older