from __future__ import *

Aral Balkan has recently released SWX, a new data exchange format for Flash.

In his current implementation it's really two standards: A JSON-ish format based on PHP (bad idea) and a particular layout of SWF bytecode on the receiving end (good idea).

Creating another JSON-like format is stupid. I really don't know why he did that. There are plenty of fast parsers for JSON in PHP, which are almost certainly going to be faster and perhaps safer than scanning input with a regex and eval-ing it. Using eval in server-side code with untrusted input, no matter how good you think your input validation is, is just foolish

Generating SWF bytecode for the return value is a good idea. It's fast, compact (zlib compressible even), requires no parsing on the Flash end, and can be used cross-domain (with appropriate instrumentation) since it's just a loadMovie call. We actually do something very similar to SWX for essentially these reasons (that's a lot of what eswf is used for).

I'd like to see him give up on the PHP junk in exchange for JSON and add explicit hooks in the standard for cross-domain help (LocalConnection transport, System.security.allowDomain support). All said, this could be a good thing for Flash developers and I'll be paying close attention to the project over the next few months.

MochiAds is finally out the door! There's a pretty good summary of what we're doing on TechCrunch.

For the technically inclined, the UI for MochiAds is built with Pylons, Genshi and SQLAlchemy. The secret sauce is a combination of Python and Erlang code, and we've got Nginx as the gatekeeper. I've got nothing but good things to say about this whole stack. Erlang's module reloading, concurrency oriented programming model, and pattern matching has really been a dream.

For Flash game developers, we support ActionScript 1, ActionScript 2, and MTASC. Flash movies must be published in Flash 6 or later. Currently we support two ad formats: preloaders and interstitial ads. Either way it's just one line of code to toss in the movie.

The really Big Deal is that Flash game developers can make money off of their work throughout the entire lifespan of the project, especially if it spreads virally. It's no longer a bad thing if a portal "steals" the game without paying a licensing fee, the developer still gets paid!

While the Flash 8 runtime is still in public beta, quite a bit about its new features have already been discovered by reverse engineering. One "feature" I haven't heard much about is the new "security" model.

It's ridiculously broken and stupid (not that this should be a surprise).

Specifically, movies running on the local machine are not allowed to do any network communication whatsoever (even to localhost) without popping up a really obnoxious warning to the user! No other application or content development environments I've seen have any such brainless restrictions. Not HTML, not QuickTime, not anything else. Hell, even most email clients will load images from the internet by default. Give it up Macromedia, you don't know what you're doing. Who are you trying to help here anyway? Certainly not your customers.

With this in place, forget about writing dashboard widgets, network screensavers, locally run network games, etc. Users don't want to see a security warning when they run your content, and explicitly allow every single application (widget, or whatever else) to talk to a server. Especially since it's a couple clicks to do so! I can also imagine this causing Really Bad Things to happen for some uses of Flash (dialog popping up in the context of a screen saver or in dashboard, mostly).

If the user clicks "OK", like they are conditioned to do, the Flash app can't talk on the network and probably won't work. If they click "edit settings" it opens up a browser window pointing somewhere on macromedia.com with a Flash application to manage Flash's preferences. This page doesn't immediately appear to know what you were doing, and doesn't make it at all obvious how to enable a paritcular local movie to talk on the internet. At this point, users will either give up or click "always allow" -- which of course turns this "feature" off for everything everywhere. Why bother having it on by default if everyone is going to either give up on Flash or turn it off anyway?

The actual procedure for enabling a single Flash application to talk on the internet (or LAN, or the loopback interface!) is five steps:

1. Security dialog
2. Macromedia.com security panel
3. Edit locations pulldown
4. Add locations panel
5. Copy and paste URL

What if your content optionally talks over a network (download high scores, report statistics, check for upgrades, etc.), but the user can't currently make a connection to macromedia.com? You guessed it, dialog every time! They can't use the security panel unless they're online. Awesome.

Oh, and this applies to Flash content with any authoring version whatsoever. It's a player feature that's enabled unconditionally for all Flash content.

The workaround of course, is to simply not buy Flash 8 and distribute only Flash 7-built projectors, which are unsigned executable files (that's security!).

P.S. I'm sorry that Macromedia Central was a flop, but you don't have to take that out on everyone else who is trying to use Flash locally.

UPDATE: There is some more information from the horse's mouth in this Flashcoders post. They do plan on having a security model that allows networking with local SWFs; however, they are still planning to break all existing networked content that plays locally. You will have to download and run a command line tool, or buy Flash 8 and republish all of your existing content. WTF? At least I can see a business case for it now; this breakage means more people will buy Flash 8 to ensure that their content will continue to work. I thought they were bought out by Adobe, not Microsoft :)

UPDATE (again): Flash 8 security whitepapers

The (in)security model [1] available to ActionScript at runtime in Macromedia Flash is absolutely worthless. The only capability that off-domain loaded movies don't have is the ability to read variables out of movie clips elsewhere in the hierarchy. This is almost entirely useless, and is really weak default behavior. If you loaded a movie, you damn well better already trust it! It could be a key logger, a denial of service attack (while (true) {}, getURL("somewhere else")), etc. If you don't trust it, DON'T LOAD IT. You have already lost if you're loading untrusted movies.

If you do trust the movie, and you end up needing the movies to communicate, you have to remember to add the System.security.allowDomain call. This means that you're writing more code for the common case, and the uncommon case is broken anyway.