Shumway is implementing APIs as needed, not targeting a specific SWF version.
Shumway does not currently support click-to-play because it is not a real browser plugin. It hooks into Firefox's click-to-play mechanism to conditionally override the Flash plugin. This is a hack and will soon be replaced with "jsplugins", a Firefox feature that will allow browser plugins to be written in JS and run in an out-of-process sandbox:
Since it won't be native code, they'll only be able to abuse a FF bug exposed by the JS plugin API, but should be in a very bad position to exploit a kernel bug...
Same process isolation, but the JS plugin got a vastly reduced surface to attack.
Exactly. We did a survey of Flash exploits from the last few years and almost all of them would simply have been impossible in Shumway. That doesn't mean that Shumway will automatically free of all security bugs, but the whole class of bugs that in some way is caused by memory corruption is only possible through bugs in Firefox's JS engine SpiderMonkey. Of course it's much easier to just exploit them in JS directly then, so Shumway doesn't increase the surface attackable through bugs like that.
Shumway does not currently support click-to-play because it is not a real browser plugin. It hooks into Firefox's click-to-play mechanism to conditionally override the Flash plugin. This is a hack and will soon be replaced with "jsplugins", a Firefox feature that will allow browser plugins to be written in JS and run in an out-of-process sandbox:
https://bugzil.la/jsplugins