Flash 8’s Backwards Security Model
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:
- Security dialog
- Macromedia.com security panel
- Edit locations pulldown
- Add locations panel
- 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
Flash 8 is all about alpha blending and visual effects, it would seem. I really hope that Macromedia do something about the whole security model but I’m not sure where they should start. Personally I love the idea that Flash movies can be decompiled so easily, it makes learning from other Flash developers much like learning HTML from the best web designers (right click, view source, etc..).
Flash games, in particular, could really use some security help. If the Flash player acted a bit more like a HTTP client in respect to some of the headers it sends, that would be a start.
Comment by duncan — 2005-08-07 @ 9:45 am
The only thing you need in order to make Flash games more secure is to have more knowledgable programmers writing them. You can’t buy security.
Macromedia is making life suck more for [networked application] developers, not less. They’re not adding security, just annoyances. In the context of a browser you already have the hooks to skirt around it if you try hard enough. This is just useless garbage, like the cross-domain restriction on XMLHttpRequest (which is Microsoft’s fault, but it’s the same mistake).
Comment by Bob Ippolito — 2005-08-08 @ 3:09 am
It sounds more like corporate paranoia — i.e. if someone writes a popular Flash movie that hoses users, it’s Macromedia that’ll get blamed, not “[less] knowledgable programmers”. Kind of like how Microsoft gets more blame than the spyware authors who exploit MSIE flaws. I would bet it’s a technologically uninformed decision by the suits.
Comment by Joe Grossberg — 2005-08-10 @ 8:24 pm
Yeah I agree with this article. With this new security model, developers can’t even getURL to another domain! That’s rediculous. I understand that security is a major issue, but this isn’t the type of protection we need. They should focus on making their own program more secure instead of making our programs unaccessible.
Comment by Leander Lee — 2006-02-28 @ 3:22 am