The latest Flash vulnerability and monoculture

[Jerry Leichter]

On Jul 26, 2009, at 2:27 PM, Perry E. Metzger wrote:
> ...[T]here is an exploitable hole in
> Adobe's "Flash" right now, and there is no fix available yet....
> This highlights an unfortunate instance of monoculture -- nearly
> everyone on the internet uses Flash for nearly all the video they  
> watch,
> so just about everyone in the world is using a binary module from a
> single vendor day in, day out.
>
> This is a bit of a wakeup call -- the use of standards based
> technologies to deliver content to users would likely have led to
> multiple implementations being in wide use, which would at least
> mitigate such problems.
While I agree with the sentiment and the theory, I'm not sure that it  
really works that way.  How many actual implementations of typical  
protocols are there?  With open source, once there's a decent  
implementation, there's little
incentive for anyone to start from scratch on an independent one.  Why  
not just improve the one that's already there?

One way or another, a single implementation usually wins out in the  
OSS community.  Even if along the way a competition - based on code  
size or speed or whatever - breaks out between two implementations, in  
the long one someone usually takes the best from both and produces the  
ultimate "winner".

So while standard, openly defined protocols *make it possible* for  
multiple OSS implementations to thrive, they certainly don't  
*guarantee* it, and in many cases that's just not what we end up with.

In fact, the scenario most likely to produce multiple *usable*  
implementations is probably:  An open protocol, and multiple *closed  
source* competing implementations.  As an example, not of a protocol,  
but of another kind of software - consider C compilers.  There  
continues to be a market for proprietary C compilers, and quite a few  
of them exist.  In the OSS world, gcc dominates.  (Perhaps a new LLVM- 
based compiler will displace it - though more likely gcc will just  
absorb LLVM as an alternate back end.  That hardly leave behind all  
gcc bugs.)

In the hardware world, one is typically very leery of buying from a  
sole-source supplier.  It's common to require that the vendor who  
developed some new chip license someone else to build the thing, too -  
just in case.  (Of course, if you buy a couple of hundred chips a year  
from Intel, you're not going to have much luck getting them to work  
with you.  But the *big* buyers definitely force second sourcing when  
they can.  It would be nice if Flash users told Adobe "find someone to  
do another implementation or we stop using Flash."  But since the  
space of Flash users has two components - those who *produce* Flash,  
who generally won't care about this; and those who use it to get light  
- it's difficult to generate such pressures.  The Flash generators  
don't have any reason to care about this, and the users of Flash files  
- who pay nothing - have little leverage unless they serious follow  
through on a strike plan.
                                                         -- Jerry

>

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com