[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:
http://www.actionscript.org/resources/articles/118/1/SharedObjects/Page1.html
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.
http://gnashdev.org/wiki/index.php/Security
Eric
- [Gnash-dev] Building extensions, Udo Giacomozzi, 2007/04/24
- Re: [Gnash-dev] Building extensions, Rob Savoye, 2007/04/24
- Re: [Gnash-dev] Building extensions, strk, 2007/04/25
- Message not available
- Re: [Gnash-dev] Building extensions, Rob Savoye, 2007/04/26
- [Gnash-dev] Building in security,
Eric Hughes <=
- Re: [Gnash-dev] Building in security, Rob Savoye, 2007/04/26
- Re: [Gnash-dev] Building in security, Martin Guy, 2007/04/26
- Re: [Gnash-dev] Building in security, Rob Savoye, 2007/04/26
- Re: [Gnash-dev] Building in security, Eric Hughes, 2007/04/26
- Re: [Gnash-dev] Building in security, Eric Hughes, 2007/04/26
- Re: [Gnash-dev] Building extensions, Martin Guy, 2007/04/26
- Re: [Gnash-dev] Building extensions, Rob Savoye, 2007/04/26
- Re: [Gnash-dev] Building extensions, strk, 2007/04/26