[PROPOSAL] Use HTML5 storage technologies as caching for RSLs

[Jeff Conrad <je...@gmail.com>]

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

Re: [PROPOSAL] Use HTML5 storage technologies as caching for RSLs

[Left Right <ol...@gmail.com>]

That could be a bit discouraging, but this approach is hardly any different
from the regular browser's cache. The "catch" in the Flex RSLs is that they
can be downloaded once from site X and then reused by site Y w/o ever
loading them from site Y. If you use the local storage ability, then it has
its domain policies - you can't access stuff from other sites (and if you
somehow can do it, then it will probably get banned some time later as this
is not desired).

So, if you can't reuse the libraries loaded by another site, you are pretty
much in the same situation as if you were just to serve them yourself
hoping they'll end up in the browser's cache.

Best.

Oleg

Re: [PROPOSAL] Use HTML5 storage technologies as caching for RSLs

[Rick Winscot <ri...@gmail.com>]

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 

Re: [PROPOSAL] Use HTML5 storage technologies as caching for RSLs

[Jeff Conrad <je...@gmail.com>]

We just need someone to make the time and experiment with it and post the
results.

Now that I've put the idea out there, I might do the tests myself, but I'm
just as happy if someone beats me to the punch.

Jeff

On Thu, May 24, 2012 at 11:48 AM, Mr. Rich <mr...@gmail.com> wrote:

> All I can say is thank you Jeff.  That idea can span far beyond RSLs.
>
> The iframe to increase the limit is gold.  I know in AS3 storage is based
> on sub domains also.
>
> To get extra tricky, you can map a few with iframe.
>
> Again, thanks Jeff.
> On May 24, 2012 11:39 AM, "Jeff Conrad" <je...@gmail.com> 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
> >
>

Re: [PROPOSAL] Use HTML5 storage technologies as caching for RSLs

["Mr. Rich" <mr...@gmail.com>]

All I can say is thank you Jeff.  That idea can span far beyond RSLs.

The iframe to increase the limit is gold.  I know in AS3 storage is based
on sub domains also.

To get extra tricky, you can map a few with iframe.

Again, thanks Jeff.
On May 24, 2012 11:39 AM, "Jeff Conrad" <je...@gmail.com> 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
>