Subject: Re: video in gnash - msg#00302

Previous Message by Date:

crossdomain policy (was: default load policy in gnashrc)

To help discussion, I'll try to summarize the problem as I understood it. Consider the following scenario: A: web_server B: intranet_client C: intranet_server Assume that host C *trusts* host B (ie: allow http access from B) Assume that host C does *not* trust host A (ie: not accessible from outside the intranet) The problem, as described to me in the past, is that host A can exploit a denial of service on host C by using the Flash Player on host B as a trojan horse. Basically host B plais a movie found on host A, and that movie request loads from C. Now, the flash player is NOT the only player able to act as a proxy. You can do the same thing with JavaScript, and Java, right ? This means that delegating the security to the software on host B is pretty tricky, and of course it assumes you have control over the software installed on B, and it's integrity. Anyway, let's assume you DO have control over software on B and that you choose what software to use based on its ability to help you in this situation, that is you want the software on B to be able to actually use services on C but only when the request for that service is originated by a "trusted" software (be it a Java, JavaScript, Flash or whatever other downloadable and executable software). So, you want to allow B loading something from C and *that* something able to access a service on C; but you don't want to allow B loading something from A and *that* something access service on C. In a schematic form, your need is: allow: B (using C-provided application) access C deny : B (using A-provided application) access C This could still be implemented by making the C-provided application contain an 'authentication token' that enables access to service on C. But this will again requires that the C-provided application is NOT accessed by A, which would still be possible if accessed tough B. But how would A know the location of the C-provided application ? The crossdomain.xml architecture, on the other hand, does not rely on "security trough obscurity", in that even if A knows exact location of things on C, the player on B won't allow access to it unless explicitly allowed by C configuration (a file on its root). Maybe gnash could implement this after all, but only on a condition: "Gnash user must be able to *disable* it" I mean, we don't want Gnash to forbid access to *anything* unless that is really the Gnash user intention (see blacklist). Other thoughts ? --strk;

Next Message by Date:

Re: Re: video in gnash

Compn wrote: > Rob Savoye <rob <at> welcomehome.org> writes: > i tested your curl tarball, and got a crash, i assume this is a similar bug > you > have. Nope, I have a different problem. For me I don't see the problem with handshakes not matching, but I'm using Red5 and/or "Cygnal". I currently have a problem with setting the bit fields of the AMF object header correctly. The RTMPT (RTMP over HTTP) works flawlessly as far as I can tell, as it doesn't actually use RTMP or AMF, just GET requests. > why is the configure 1mb ? is this a non-autotools-required autotools > configure Which configure ? libCurls ? I have no idea. > anyways, i look forward to rtmp support, thanks! Patches are always welcome. :-) I'm working on the plugin architecture right now, but assume the RTMP support only needs a few hours or days of work to be done. Then the idea was to donate the patch to the libCurl project. - rob -

Previous Message by Thread:

Re: video in gnash

Tomas Groth wrote: > * Let gnash/libcurl fetch the video, not ffmpeg, since ffmpeg doesn't support > RTMP (though neither does vanilla libcurl). Actually this is the right way to do it, because I have a patch to libCurl (http://www.welcomehome.org/gnash/curl-080206.tar.bz2) that's about 90% done to add RTMP support. There is a bug in the AMF header encoding I haven't had time to track down. So we need to use libCurl to handle talking to a Flash server. We may still want to use the background thread and a cache though. > * Implement MovieClip.attachAudio() for audio handling of video (audio should > not be automaticly enabled it seems). Probably correct again. > * Seperate the video/audio decoding from the NetStream AS-object and put it > into a video/media handler. This should hopefully make it easier/cleaner to > support other video decoders (gstreamer). We should make a base class for this just like the networking code is for NetConnection. Supporting multiple decoders is also a good idea. For one thing for better Nokia 770 support, they donated patches to Gstreamer for their hardware based video decoder. Since ffmpeg has FLV and VP6 support, we'll need to potentially use the ffmpeg Gstreamer plugin on some platforms to get better performance. > * Implement video viewing for AGG, and later cairo. Yes, since we'll be wanting to stream video on embedded devices, which is when we'll likely be using AGG. The Cairo backend isn't fully functional, I don't think anybody's been working on it since the AGG backend works. > As a side bonus I also hope make support for video embedded directly in > SWF-animations. You'd think that would be easier, since there is no networking required. - rob -

Next Message by Thread:

Re: Re: video in gnash

Compn wrote: > Rob Savoye <rob <at> welcomehome.org> writes: > i tested your curl tarball, and got a crash, i assume this is a similar bug > you > have. Nope, I have a different problem. For me I don't see the problem with handshakes not matching, but I'm using Red5 and/or "Cygnal". I currently have a problem with setting the bit fields of the AMF object header correctly. The RTMPT (RTMP over HTTP) works flawlessly as far as I can tell, as it doesn't actually use RTMP or AMF, just GET requests. > why is the configure 1mb ? is this a non-autotools-required autotools > configure Which configure ? libCurls ? I have no idea. > anyways, i look forward to rtmp support, thanks! Patches are always welcome. :-) I'm working on the plugin architecture right now, but assume the RTMP support only needs a few hours or days of work to be done. Then the idea was to donate the patch to the libCurl project. - rob -