[K12OSN] Flash, Youtube and Thin Clients

[Rob Owens]

May I suggest that you approach the Gnash folks with the same request?
I realize that Gnash doesn't work for everything, but perhaps this could
be the first step in Gnash actually becoming better than Adobe's Flash
(if Gnash implemented the boolean option and Adobe didn't).

-Rob

Warren Togami wrote:
> I had a talk with someone from Adobe today about our problem with Adobe
> Flash, Youtube and Thin Clients.
> 
> A video of 320x240 resolution at 30fps uses ~70Mbit/sec bandwidth.  This
> kind of bandwidth is completely unusable for thin clients.  For safety
> reasons many of us are forced to disable Flash plugin on our LTSP
> servers in order to avoid killing our networks with only a few clients
> swamping all available bandwidth.
> 
> This is a shame, because Flash is plenty useful without Youtube and
> similar videos.
> 
> I had an idea, what if there were a boolean option in /etc/adobe/mms.cfg
> that could turn off playing of .flv movies?  Then Flash could remain
> very useful for LTSP thin clients, and we wouldn't have to disable it
> entirely for safety reasons.
> 
> Adobe is hesitant.  They say that this is only a policy problem:
> 
> - We should simply tell users not to use any Youtube-like video.  This
> is simply an unreasonable expectation.  Even if all users knew to avoid
> it, it is simply too easy these days to accidentally load a page with
> embedded Flash video.
> - We should use QoS to throttle bandwidth between the terminal server
> and thin clients to protect the network from this kind of failure.  This
> adds complexity in network configuration, and indiscriminately punishes
> all applications, while being ineffective to solve the problem.
> - We should block all possible video sites at our proxy server.  This is
> problematic because there is an arbitrary number of video sites out
> there growing all the time.  Also the below reasons apply.
> - We should block all .flv URL's at the proxy server.  This sounds
> pretty good and would be the simplest workaround, except this fails for
> several reasons including:
> 1) Not every site has or wants proxy filtering.
> 2) A site may want normal desktops to be able to use .flv video while
> disabling it only on the LTSP server.
> 3) It is impossible to selectively filter .flv on a https server.
> 
> I am suggesting to Adobe in response that these suggestions require us
> to jump through hoops, adding lots of complexity and are ultimately
> ineffective in solving the problem.  Meanwhile a tiny change to their
> plugin to implement a boolean variable for an optional config file would
> enable a complete and simple solution, where Flash remains plenty useful
> for many other non-video uses.
> 
> The alternative that we are forced with if they do not agree to this
> simple request: We must disable the plugin on our terminal servers in
> order to protect the stability of our networks.
> 
> To be fair, Adobe didn't know that we existed as a very sizeable
> deployment base of Linux desktops until this conversation.  Also they
> are very late in the Flash Player 10 development cycle and any change,
> no matter how seemingly simple, can create risk.  I would suggest
> however, that in this case the benefit is very large, while the risks
> are small.
> 
> I am asking for the support of all Linux distributions before I approach
> Adobe with a stern but polite appeal.  May I count on your leadership's
> co-signing in asking for this option?
> 
> Do you run a school or business with LTSP and have been plagued by this
> Flash video bandwidth problem?  Please let the list know your
> organization, location, and # of thin clients affected.  I would like to
> include this as a random incomplete sample of affected users when I
> submit the formal letter.
> 
> Warren Togami
> wtogami at redhat.com
> 
> _______________________________________________
> K12OSN mailing list
> K12OSN at redhat.com
> https://www.redhat.com/mailman/listinfo/k12osn
> For more info see <http://www.k12os.org>
********************************************************

The information transmitted is intended only for the person or entity to
which it is addressed and may contain confidential and/or privileged
material. If you are not the addressee, any disclosure, reproduction,
copying, distribution, or other dissemination or use of this transmission in
error please notify the sender immediately and then delete this e-mail.
E-mail transmission cannot be guaranteed to be secure or error free as
information could be intercepted, corrupted lost, destroyed, arrive late or
incomplete, or contain viruses.
The sender therefore does not accept liability for any errors or omissions
in the contents of this message which arise as a result of e-mail
transmission. If verification is required please request a hard copy
version.

********************************************************