bunnyhero dev

While playing with the new AVFoundation APIs, it occurred to me that in iOS 4, apps can now easily access the camera with no feedback to the user. Before, apps had to use UIImagePickerController, which shows the iris-opening animation before recording starts, even if you hide the preview image using cameraViewTransform. With AVFoundation’s AVCaptureSession, there is no indication to the user at all that the camera is in use unless the app provides its own. There is no permission alert, nor any LED indicator like a webcam. An app could secretly be recording your face with the iPhone 4’s front-facing camera and sending it to who knows where. I wonder if Apple’s app review team checks for this in some way?

On the other hand, the new APIs make it much easier to integrate non-photo-taking uses of the camera into an app. I could imagine using the iPhone 4’s front camera for non-touch gesture controls or facial expression recognition. Makes me wish I knew something about real time image processing!

So here I was, thinking that the Flash Player 9 security update (version 9.0.124) wasn’t going to affect me. A silly assumption, of course—I should have tested with the beta, regardless—but since I didn’t do anything fancy with sockets or web services, I thought I would be fine.

Ha!

I missed this section: “You have SWFs that are exported for Flash Player 7 (SWF7) or earlier that communicate with the hosting HTML by any means”.

And when they say “any means,” that includes LoadVars.send(), which I am using, in a SWF that is hosted on a different subdomain than the page which contains it (petswf.bunnyherolabs.com vs bunnyherolabs.com).

Luckily, the fix was simple: I just had to add the parameter allowScriptAccess = "always" to the embed tag. Phew!

Next time I see one of these announcements, I promise I will test it, even if I don’t think it applies to me ;)

Up until now, I had been making some incorrect assumptions about Adobe Flash Player’s security model.

I had assumed that a SWF could not access anything outside of the domain from which it had been served, in general, without special allowances made by things like crossdomain.xml or System.security.allowDomain().

What I didn’t realize is that these domain restrictions do not apply to the simple use of, say, loadMovie() to load SWFs or JPGs from other domains! It is true that, in general, one SWF cannot read or alter information from another SWF that is loaded from another domain, but simply loading and displaying is fine.

And all this time I had shelved a number of ideas that I thought weren’t possible because of cross-domain issues. Hmmm…!

For reference, here is Adobe’s white paper on the Flash Player 9 security model (PDF) and a white paper on security-related APIs for ActionScript 1.0 and 2.0 (PDF).