According to Stephan, certain features of Tiger’s new Dashboard feature allow for the automatic installation of potentially evil widgets.
I picked up [Tiger] at launch time from my local Apple store, brought it home, and got inspired to start in on a widget the next day. My flores and coras widgets are taking off like crazy. Over the last few days I’ve figured out quite a lot, including the fact that there are some potentially very annoying things one can do with a widget.
Let’s start with autoinstall. I happen to like it, actually, I think it’s a great thing. But, as I have demonstrated here, it has the side effect of setting up a situation where a user can be given an application without their knowledge.
That’s not such a big deal; by default, widgets can’t do much damage, and they can’t run unless you drop them into your dashboard. The funny thing is that once that widget is there, according to Apple, you CANNOT remove it. Type “remove widget” into Apple Help, and you find out:
You cannot remove widgets from the Widget Bar or change their order
Reportedly, widgets can be installed to the Dashboard automatically from Safari, with no user intervention at all. Also, someone can write a widget that immediately closes the dashboard as soon as it’s opened, preventing it from being uninstalled. No major harm, since it only runs in a JS sandbox. Or does it?
“Using certain resources within your widget may pose a security risk for users. In these circumstances, the widget security model provides a method for Dashboard to be aware that your widget may perform insecure tasks. If your widget is working with resources that pose a security threat to the user, the user must approve before access is granted.”
—Dashboard Programming Guide , p 57
“Dashboard provides you with a method for using command-line utilities and scripts within your widget. With this capability you can use any standard utilities included with the system or any utilities or scripts you include within your widget.”
—ibid., p 61
“So what?” you may say, “The user gets warned.”. Two words: social engineering.
Apple’s “warning” when an app like this is about to be run is laughably tame. I’m no novice, and I wouldn’t see the harm in clicking it had I not read this article.
It’s hard to believe that Apple hasn’t learned from Microsoft on this. This exploit is probably somewhat less likely than something on Windows, due to OSX’s smaller market share, but it seems ridiculous that an OS would release with this sort of problem in 2005.
Apple tried to take their ‘easier, just works’ approach with the Dashboard, but the reality is that you have to treat the Internet like it’s actively trying to put porn on your desktop and steal your credit cards, because about a third of it is doing exactly that at any given time.
When you’re designing security policies, you look at things on a continuum. On one end, everything is open and simple and works without your intervention. No passwords, no firewalls, everything can see and trust everything else. In a perfect world, this makes things easier for everyone. On the other end of the continuum, no portion of the system trusts any other portion, and you encrypt and authenticate every message. This is the most secure approach, but you spend more time entering passwords than you do using software.
A good security policy makes things as easy to use as they can be, without trusting more than it has to. Apple definitely erred too far on the side of ‘easy to use’ with this one.