incubator-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
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 


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