Some items to put on the table... Flash Player AVM The only way to ensure that class B is used in lieu of class A... is to make sure that class B gets loaded / instantiated first. I'm specifically referring to underriding (monkey patching - less common?) or dealing with version skew (marshal plan - more common?). Off the top of my head, the only way I can think to get around this is to roll a custom application bootstrap. That might not be too bad... but lets go a little deeper.
SecurityError: Error #3015 Loading and getting the RSL (SWC/SWZ) into storage looks like a clear path. The first obstacle will likely happen when loading in your 'cached' RSL - "Loader.loadBytes() is not permitted to load content with executable code." Easy enough, all you have to do is set the loader context allowLoadBytesCodeExecution=true. Next - but be careful who you give the keys to your house to! Cross Site Scripting Attacks Loading RSLs from a trusted / known location on a server where only person(s) X would have the ability to place file(s) Y at location(s) Z is part of the RSL security model. Bypassing this to place RSLs (or anything for that matter) on the client and loading that content into your application is a little scary... if you have any kind of XSS vunerability - anything in your localStorage is available to an attacker. This is pretty much a show-stopper for most people. Storage Limits As you say, the Flex SDK is big... and simply won't fit in the default 2.5mb - 5mb window. Especially if it's base64 encoded. Your idea of using multiple iFrames + sub-domains is clever - storing the SDK in chunks shouldn't be a problem. I mean... breaking an archive into contigous volumes is something that Zip has been doing for decades. However, this practice is something that the HTML5 spec specficially mentions 'not' to do. http://dev.w3.org/html5/webstorage/#disk-space It's likely that browsers, at some point, will prompt you to increase limits. So... this is really a maturity issue that will have to be addressed over time. Just so you know, I've been experimenting with all kinds of alternative methods (http://quilix.com/node/96) to load, execute, and cache Flash-based content. I totally get your approach, and it is a clever idea ...but... if it's a file caching problem you're trying to solve, wouldn't we want to try and leverage the browsers native ability to cache content? If we did, we inherit security and a first class means to an end. N'est-ce pas? R On Thursday, May 24, 2012 at 11:39 AM, Jeff Conrad wrote: > Hi all, > > I've been lurking on the list for a while now, and I came up with an idea > to fix the 'no signed RSLs' issue. It's a little hackish, but it just > might work. We might be able to use HTML5 storage technologies like > LocalStorage and IndexedDB to cache RSLs in the browser like the Flash > Player asset cache does now. > > I've only done a very small amount of research and no experiments yet to > see if it will work. It's been at least a few weeks since this thought > popped into my head, and I don't want it to stay in my head if someone else > wants to do it, they should be able to do it. > > Here's what I was thinking of doing. Use a storage js library like > lawnchair (http://brian.io/lawnchair/) which abstracts out all the details > of HTML5 storage and then store and retrieve RSLs as a base64-encoded > string which can be converted to a ByteArray and loaded via loadBytes just > like the SDK does now. > > Pros: > > - There's a somewhat large storage cap. LocalStorage has an effective cap > of 2.5-5mb per domain depending on the browser implementation and from what > little investigation I did. IndexedDB, which doesn't a lot of supporting > implementations, has a 50mb limit in Firefox. IndexedDB is capped in > Chrome at 5mb unless you make your webapp into a Chrome Web Store app. > Then, you can request unlimited storage as part of your manifest.json > file. To get more storage, it may be possible to use iframes and > postMessage() to store and retrieve RSLs on a per-domain basis. > > - This would work with any SWF you wanted to be an RSL, and it could be > hosted from any website / cdn. > > Cons: > > - Relies on JavaScript and multiple differing implementations of local > storage APIs. Some of that can be abstracted away with a library, but > underneath all the abstraction, it's still an issue. Ideally, if js / > storage implementations change, you can just upload newer js libraries so > existing apps wouldn't have to be recompiled to be fixed. > > Other thoughts: > > - I have no idea what the performance for something like this is like > because I haven't done any tests. > > - Automated testing of this functionality can be done using selenium. > > What do you guys think? > > Jeff
