Apple « Vincent Gable’s Blog

July 21, 2010

Sneaking Malware Into the App Store

Filed under: Announcement,iPhone,Programming,Security | App Store, Apple, iTunes, Malware, Review Process
― Vincent Gable on July 21, 2010

It’s happened. An app that grossly violated Apple’s terms of service (by enabling free tethering) made it through Apple’s review process, onto the App Store, and into the #2 most-popular spot before being taken down. Although this app wasn’t malicious to users, it’s absolutely malicious to Apple’s agreements with AT&T and other phone-companies. It is a real demonstration that Apple can’t keep malware off the App Store.

A Few Sneaky Ideas

It’s not hard to come up with ways to fool App-Store reviewers.

You might just get lucky. With over 230,000 Apps in the store, reviewers are swamped. They’re only human and they might not notice some subtle evil — especially if it’s not on their naughty-behavior list.

Time-Bombs, apps that hide their bad-behavior for a few days, are undetectable without periodic audits, since they act normally during the pre-release review period.

Phoning home to a server that let’s an app know it’s passed review and can begin it’s life of crime, would let an app be even more precise.

With just a few minutes thought, I’m sure you can think of even more clever tricks, or combination of tricks.

Not a Fully Open Vulnerability

That’s not to say your iPhone is in as much danger as your PC. iOS apps don’t have the same free-reign that traditional computer programs have. That limits their usefulness, but it also limits the damage they can cause. An iOS App can’t stop you from killing it, and it can’t mess with other apps, so it can’t “take over” your phone. But it can do anything it likes with your Contacts, and secretly abuse the phone’s always-on network connection, and get up to other sorts of minor mischief.

I don’t have room here to fully analyze the risks of a rogue iPhone’s program. But generally, the danger isn’t too great: a little more than a what website can do, a lot less than what a PC program with administrator access can do.

Ultimately, Apple’s best defense against malware isn’t control of the App Store review process or iTunes payments (although they help), but control over iOS. A well-designed operating system limits what kinds of malware are possible. The review process can screen for egregious mistakes. But it can’t catch everything, and it’s least-able to catch the most clever malware, which ultimately, are the programs we should be most worried about. Apple’s review process doesn’t provide real security against modern malware.

Comments (1)

July 16, 2010

“I Have No Apology”

Filed under: Quotes | Apple, Business, Steve Jobs
― Vincent Gable on July 16, 2010

Q: Will you apologize for investors?
A: Steve: We are apologizing to our customers. We want investors for the long haul. To those investors who bought the stock and are down $5, I have no apology.

–Steve Jobs, taking questions at a press conference on antenna issues with the iPhone 4 design, July 16th, 2010.

That’s a CEO with his priorities straight.

Comments (0)

July 8, 2010

NSDictionary Copies It’s Keys

Filed under: Bug Bite,Cocoa,iPhone,MacOSX,Objective-C,Programming | Apple, copy, Documentation, NSDictionary
― Vincent Gable on July 8, 2010

An NSDictionary will retain it’s objects, and copy it’s keys.

Here are some effects this has had on code I’ve worked on.

Sometimes you get the same object you put in, sometimes not.
Immutable objects are optimized to return themselves as a copy. (But with some exceptions!). So the following code:
```
	NSDictionary *d = [NSDictionary dictionaryWithObject:@"object" forKey:originalKey];
	for(id aKey in d)
		if(aKey == originalKey)
			NSLog(@"Found the original key!");
```
Might print “Found the original key!”, and might not, depending on how [originalKey copy] is implemented. For this reason, never use pointer-equality when comparing keys.

Mutable objects make bad keys. If x is a mutable NSObject, [x copy] is an immutable copy of x, at that point in time. Any changes to x are not reflected in the copy. For example,

	[dict setObject:x forKey:key];
	//...code that changes key, but not dict
	assert([[dict objectForKey:key] isEqual:x]); //fails!

Because the copy is an immutable object, it will blow up if you try to mutate it.

	NSMutableString *key = //something...
	[dict setObject:x forKey:key];
	for(NSMutableString *aKey in dict)
		[aKey appendString:@"2"]; //Error, aKey isn't mutable, even though key is!

View objects make bad keys. Views have state related to the screen: their frame, position in the view hierarchy, animation layers, etc. When you copy a view object, the copy won’t (always) be isEqual: to the original, because it’s not on the screen in exactly the same way.
Your classes must support NSCopying to be used as a key in an NSDictionary, you can’t just implement -hash and -isEqual: in your custom classes.

Of course, this isn’t a complete list of every way key-copying can trip you up. But if you understand what copy means in Cocoa, and remember how NSDictionary works, you’ll be able to avoid or quickly solve any issues.

How to Document Such Behavior Better Than Apple Did

Given what we know about NSDictionary, what’s wrong with the following snippit from NSDictionary.h?

@interface NSMutableDictionary : NSDictionary
- (void)setObject:(id)anObject forKey:(id)aKey;
@end

Answer: aKey needs to implement NSCopying, so it should be of type (id<NSCopying>) instead of type (id). That way, the header is self-documenting, and, if like most smart programmers, you’re using autocomplete to type out Cocoa’s long method names, the auto-completed template will be self-documenting too.

Comments (6)

July 7, 2010

Worthless on an Unimaginable Scale

Filed under: iPhone | App Store, Apple, Crapware
― Vincent Gable on July 7, 2010

There are other App Farms we know of…. One example is Brighthouse Labs with 4568 Apps, all virtually worthless.

—Zee, writing for The Next Web

I have a hard time wrapping my head around that number. Nearly five thousand “apps”. Near as I can tell, it’s a solid 2% of the whole App Store. With an (optimistic) 5-day-per-app approval time, it would take Apple 86 years to approve them serially.

Comments (2)

June 11, 2010

Simulator Advertising?

Filed under: Announcement,iPhone,MacOSX,Programming | Advertising, App Store, Apple, iOS, iPhone Simulator, Simulator
― Vincent Gable on June 11, 2010

I wish I could take credit for this idea, but it’s from someone else, will Apple sell iAds that only show up in the iPhone simulator? Probably not, but it would be a hell of a targeted demographic.

For those of you who aren’t familiar with how building iPhone software works, we developers spend thousands of hours testing and debugging our programs in an iPhone Simulator application that runs on our Macs. The simulator can’t run Apps from the App Store, only programs compiled from source code with Xcode. So the only people using the simulator are programers, or otherwise deeply involved with building iOS apps. Apple could make it so that any iAds in the simulator would show special ads targeted to developers.

Better still, iAds in the simulator could show something useful like rules from the Human Interface Guidelines (that too few read), good tips or even inspiring quotations.

Comments (1)

June 9, 2010

Apple’s Typographic “Perfection” Sucks

Filed under: Design,iPhone,Quotes | Apple, iBooks, iOS, Typesetting, Typography
― Vincent Gable on June 9, 2010

…one particularly outrageous moment stuck out for me. At about three minutes into the video, senior vice president for iPhone software Scott Forstall extolls the virtues of the Retina Display by declaring that “The text… is just perfect!” Meanwhile, the central image in the video at just that moment is this little typographic calamity:

I urge you to fast-forward the time code to 3:02 to hear this for yourself. Forstall is quite literally claiming perfection while a hand model holds up this terrible example of everything that’s wrong with Apple’s commitment to typography. While the letterforms on that virtual page may look gorgeous, it’s apparent to any designer that the text is far from perfectly typeset. It’s hideous, scarred as it is by unsightly “rivers” of bad spacing within the text. No self-respecting typographer would dare call that perfect.

—Khoi Vinh

The unrelenting drive for perfection was a quality I always admired in Apple. I hope this is just bullshit spin, and an unfortunate choice of sample frames.

Comments (0)

October 22, 2009

iPhone Shows the Irrelevance of the Programmer User

Filed under: iPhone,Usability | App Store, Apple, Business, Failure, Freedom
― Vincent Gable on October 22, 2009

There’s a lot of discord over Apple’s draconian “closed” handling of the iPhone and App store. And rightly so. But there are a few interesting lessons in the current situation. The one I want to discuss now is that,

Being able to program your own computer isn’t enough to make it open

As things stand today, Apple can’t stop you from installing any damn iPhone app if you build yourself.

To do that you have to join the iPhone developer program of course. And there’s a $99/year fee. That’s inconvenient, but it’s just using a subscription-based way of selling iPhone OS: Developer Edition.

That’s the kind of dirty money-grabbing scheme I’d expect from Microsoft. It’s a bit shady, because it’s not how most OSes are sold. But it’s not without precedent. And unless you are against ever charging money for software, I don’t think there’s an argument that it’s actually depriving people of freedom.

Yes, it’s an unaffordably high price for many. But the iPhone is a premium good that costs real money to build — it’s inherently beyond many people’s means, even when subsidized.

Observation: Only Binaries Matter

If you have a great iPhone app that Apple won’t allow into the store, you can still give it to me in source code form, and since I have iPhone OS: Developer Edition, I can run it on my iPhone.

But clearly that’s not good enough.

In fact, I’m not aware of any substantive iPhone App that’s distributed as source. By “substantive” I mean an app with a lot of users — say as many as the 100th most downloaded App Store app — or an app that does something that makes people jealous, like tethering (See update!), which we know is possible using the SDK. I realize this is a wishy-washy definition — what I’m trying to say is that distributed-as-source iPhone Apps seem to be totally irrelevant.

“It’s not open until I can put Linux on it”

I believe it’s technically possible to run Linux on an iPhone without jail-breaking it. (Although it’s not terribly practical.) Just build Linux (or an emulator that runs Linux) as an iPhone app, and leave it running all the time to get around the limitations on background processes.

Apple won’t allow such a thing into the App Store of course —but how does that stop you from distributing the source for it? As best I can tell, it doesn’t.

So as things stand today, yes you can distribute source code that lets any iPhone OS: Developer Edition user run Linux. It’s technically challenging, but it’s doable.

Conclusion

It’s possible to build open systems on top of closed systems. We’ve done it before when we built the internet on Ma Bell’s back.

But the iPhone remains a closed device. User-compiled applications have 0 momentum. And I think that clearly shows the irrelevance of the rare “programmer user”, who is comfortable dealing with the source code for the programs he uses.

UPDATE 2010-01-21: iProxy is an open-source project to enable tethering! Maybe the programmer-user will have their day after-all.

Comments (1)

July 19, 2009

For iPhone and or iPod Touch and or Other Things As Well

Filed under: Announcement,iPhone,MacOSX | Apple, Diction, iPhone, iPhone OS, iPod Touch, Names, Writing
― Vincent Gable on July 19, 2009

It’s very clear that a program “for Mac OS X” works with any personal computer Apple sells, because they all have “Mac” in their name. Unfortunately, the flavor of OS X that runs on the iPhone and iPod Touch is officially called “iPhone OS” by Apple, which it implies an incompatibility with the iPod Touch, and any future device that doesn’t have “phone” in the name.

I don’t know a good way to unambiguously say that a program is for any iPhone OS device, without tedious enumeration.

“For iPhone OS” sounds like it excludes the iPod Touch.

“For all models of iPhone and iPod Touch” sounds terrible. It will sound even worse when Apple comes out with other iPhone OS devices (“…for iPhone or iPod Touch or iTablet or iFPGA…”).

Apple could help by renaming “iPhone OS” to “Mobile OS X”, but I don’t see this happening.

I personally lean towards using “for iPhone” in general writing, and clarifying, if necessary, in “systems requirements” fine print. This feels closest to how the press covers iPhone OS applications, and of course it’s how Apple named the OS.

I’d love to hear what you call iPhone OS applications, and why.

Comments (2)

January 15, 2009

Even a Small Child Can Do it

Filed under: Accessibility,Design,Programming,Usability | Alan Kay, Apple, Doing With Images Makes Symbols, Education, Icons, Reading
― Vincent Gable on January 15, 2009

This segment of an Alan Kay presentation (pt 2) really jumped out at me.

She’s never lived in a world that wasn’t densely populated with Macintoshes. …She literally learned to use it by sitting on her mother’s lap while her mother was working. So for this child, the Macintosh is not a piece of technology, but simply more material in the environment to manipulate.

Another interesting point to note is that even though she can’t read, she’s able to recognize standard textual menu items.

And in fact we discovered that she was about 70% literate — that about 70% of the generic window commands that are found in any Macintosh application, she’s able to use. Not just in a visual program like Mac Paint.

One message Alan Kay really drove home is not just that that computers can be simple enough for children, but that designing for children can lead to better designs for adults. But remember that that just because a child can use a computer does not make it a silver bullet for education.

Comments (0)

January 4, 2009

How To Beat Web Apps

Filed under: Cocoa,Design,Quotes,Usability | AJAX, Apple, Web, Web 2.0
― Vincent Gable on January 4, 2009

The way Apple stays ahead of the web app trend is by creating native Cocoa experiences that can’t be duplicated in web apps — both on the Mac and iPhone.

—John Gruber

Comments (2)

Older Posts »