flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick Winscot <rick.wins...@gmail.com>
Subject Re: [PROPOSAL] Use HTML5 storage technologies as caching for RSLs
Date Thu, 24 May 2012 19:03:33 GMT
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

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

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.


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?


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 

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message