[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Gnash-dev] Building in security

From: Eric Hughes
Subject: [Gnash-dev] Building in security
Date: Thu, 26 Apr 2007 10:03:39 -0600

At 09:16 AM 4/26/2007, Rob Savoye wrote:
  It is obvious the extension mechanism needs some additional security
that currently it doesn't have.

Not just the extension mechanism needs security. Security is one large problem with lots of interlinked subproblems. For example, AS has SharedObject. Here's a web page on them:
And here's an excerpt:
A SharedObject in the most basic sense is a contraption designed to allow local storage of data pertinent to a user on that user's system. Like a cookie but better.

When I read this, I immediately translated that last sentence to myself as "like a cookie but worse". To get some idea about what we'll need eventually, just look at the Privacy and Security configurations in Firefox. Gnash, when mature, will have the same essential complexity.

Personally, what I'd like to see is a common configuration facility for security and privacy that both Gnash and Firefox could share. That's not, unfortunately, in the immediate future. Since abstractions are only relevant when you have at least two instances, the next step is to create a second instance. Only after that will refactoring for commonality become relevant.

Rather than bitching about this, I'd
rather just see somebody volunteer to fix this now, instead of "when we
get around to it".

I volunteer. Unfortunately, this isn't a "fix" but rather a significant piece of internal infrastructure. While I do believe in building in security from the outset, I don't believe in building it in *before* the outset. I'll let Rob decide overall on schedule, but here's my basic approach:
1. Get the essential functionality you want working, even if imperfectly.
2. Before it gets too large and before others rely on its interface too heavily, get its basic security in place, even if imperfectly. Since this step can require API changes, it's best done soon, but not too soon.

  We *will* be extending Flash, get used to the idea...

We'll have to extend if only to get better security configurability.

So now I have a request. I've seen a lot (I mean a _lot_) of security over-engineering that tries to solve hypothetical problems by-and-for all-too-non-hypothetical and paranoid user-programmers. I have no interest in that. So to start, I would ask that folks contribute to creating a documented consensus on what the security problem actually is. I've set up a page on the wiki to act as a repository for this work.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]