Re[2]: [Gnash-dev] Gnash whitepaper

[Udo Giacomozzi]

Hello David,

Friday, August 17, 2007, 12:36:20 AM, you wrote:
DR> On memory tests: It may be useful to provide a comparison of the
DR> official standalone flash player running the exact same SWFs.
DR> (Perhaps both version 7 and version 9, so we can compare to how
DR> the official player has evolved, or possibly gotten worse)

As she states, the memory tests are not up to date anyway.

However, I wonder how one can effectively measure the memory
consumption of a process under Linux. Measuring *data* segments is
somewhat feasible but when it comes to *code* size you run into all
sorts of problems (shared memory, shared libs, paged out pages, copy
on write, ...).
For example, add all RSS values of your system's resources and you end
up in odd values. Another example, forking a process virtually doubles
it's code size, but in reality the memory is re-used.

Assuming that it's similarly difficult to really measure a process
memory consumption under Windows I doubt it can be really compared to
each other.

I even wonder that Gnash is so undemanding on memory ;)

Anyway, the probably smallest Gnash version would be using AGG with
only one pixel format (makes much difference) and the FB GUI (and, of
course, without video/sound nor debugging support).


DR> As far as security: 
DR> "Many Flash implementations contain potential security exploits
DR> that could compromise a viewer's system." This is a bit vague,
DR> pretty much all software contains potential security exploits,
DR> even open source software. The more important metrics are the
DR> severity of the exploits, and how quickly they are addressed. 

Agree, probably Gnash similarly has comparable (but different)
security holes we just didn't discover yet.

For instance, AFAIK there's no script lockup protection in Gnash like
the proprietary player has, so DoS attacks would be possible.

But I think this is normal in this stage of development.


DR> "This can be used, for example, to compromise a network device
DR> inside a company firewall via a Flash movie running on an
DR> employee's browser." 
DR> Unless you are talking about the occasional security-related bug
DR> in the official player, this is simply not true.

Maybe you are already referring to this, but there are/were a bugs in
Flash that allowed arbitrary HTTP requests (header injection) and
arbitrary socket(!) connections (there's a port scanning demo around
the net). Of course, these are *implementation* bugs.

So, I wouldn't say that Flash is any worse than any web browser out
there...

Udo