Flash Lite 3 Security Sandbox – A Reminder

This isn’t anything new but it’s an easy one to forget and something that caught me out the other day. So to be perfectly honest I’m writing this as more of a reminder to myself rather than anything else.

Firstly the problem. I was helping someone with their Flash Lite app that let the user send SMS messages to friends, but for some strange reason the device refused to launch the SMS application. Of course it was a silent failure so there were no error messages explaining why.

Now I’d simply put it down to the dude’s Nokia E90 not supporting SMS within Flash Lite but Alessandro Pace thankfully chipped in with the reason and a solution. It was of course all down to the fact that the SWF was running on a device shipped with Flash Lite 3 which, rather infuriatingly, has the exact same security sandbox as the Flash 8 player.

So why’s that such a bad thing? Well this security model effectively means that apps can either have local access or remote access but not both, which doesn’t really make much sense when dealing with mobile. If you want to make a getUrl()call, which is required to send an SMS, then you’ll need to publish your SWF with network access enabled and also copy it to a special Trusted folder on your Nokia.

Unfortunately this security model and the work-around both have a whole series of implications ranging from backwards compatibility with SWFs published for older Flash Lite players, to issues getting your applications Symbian Signed.

Adobe have addressed this with Flash Lite 3.1 but it’s something that isn’t going to go away in the short term due to Flash Lite fragmentation across the range of Nokia handsets that are already out there.

If you want to know more then I strongly suggest you read Ugur’s excellent blog entry that he posted way back when Flash Lite 3 was launched. This issue was also raised by Faisal Iqbal at the time who wrote a great follow up with additional issues and nags.