Monday, December 03, 2007

Flash Lite 3 security

Since the Flash Lite 3 player was made available recently I have noticed developers aren't aware of the new security measures. So heres an attempt at summing them up.

The biggest change apart from FLV support is the new security model. Flash Lite 3 now has crossdomain security AND playback security which makes it the same as Flash Players 8+. There are several confusing aspects to this though because Flash Lite doesn't operate in the same context as a desktop computer.

If you are accessing anything remote from a local file then you will have to do the following:

Put a crossdomain.xml file on any server you are accessing. Or have a proxy script on one server and use that as a gateway to anything you want.

Publish your swf as having 'Network Access Only'. So File > Publish Settings > Local Playback security > change 'Access local files only' to 'Network Access Only'. If you don't do this then your swf won't even trigger the network connection dialog on the device, it will just die silently. Its important to note here that the default is local files only so ANY old content that uses a network connection will not work in Flash Lite 3 until you re-publish it with the correct settings.

Be aware that neither Device Central or the Flash IDE enforce the new security measures, so you won't realise any issues until you test on the device.

So now that the basic rules are there heres my take on how the desktop player settings transform themselves into a very different mobile context.

1. On the desktop you can launch a local swf in the browser and a user is given a warning so that they can 'trust' the file to connect remotely. In Flash Lite 3 the user will never get this prompt it will just die silently. This is probably a good thing.

2. On the desktop you can open a projector to playback a swf and this will automatically be 'trusted' and therefore have no local playback security restrictions, you can load local and remote data at the same time. On mobile its a bit different.

The Flash Lite standalone player on s60 is actually treated like a 'local' web browser on the desktop. On s60 the nearest equivalent to a desktop projector file is actually a Symbian application that launches a swf. So, you ask, how can a developer make an application that accesses local and remote data?

We don't know at the moment. But the OEM's should implement the ability to have swf files marked as 'trusted' in someway, maybe during an installation process. This would be similar to the way desktop Flash works in that if they are opened via a projector they are automatically trusted.

3. Shared Objects are not classed as local access. So you can at least save small amounts of data locally and access remote services (same as desktop I think).

4. If you really have to have local and remote access you could easily just have a local proxy program that dealt with all your network requests through it's local connection. This would be easy for data but perhaps a little more tricky media assets.


So there you have it. The new security settings are there to make the Flash Lite player as close as possible security wise to the desktop versions of Flash. The net result of the new security measures will mean more hoops to jump through for mobile developers. How much depends on how well the OEMs implement the Flash Lite 3 player.

My opinion here is that mobile is a controlled enough platform to not need the same security measures as desktop. The issue here is not with crossdomain but local playback security. Bringing Flash Lite closer to the desktop player is in itself pointless. There has to be some recognition of a 'projector' style application for Flash Lite 3 applications for this to work. The new local playback security settings make this now even more of a need.

I suppose one other scenario is that OEMs could also completely ignore the Flash Lite 3 security measures...... now there's an idea :)