Re: [Owasp-input-api-developers] My thoughts on requirements

[Gabriel L. <ga...@bu...>]

On Thu, 2002-06-27 at 07:08, Chr...@ey... wrote:
> Gabe,
> 
> Hehe, maybe I have an incorrect understanding of what is meant by 
> requirements (a distinct possibility), but what you have below is what 
> imagined the Vision statement would be.  I guess I always imagined 
> requirements as being specific statements of things a program must do, 
> e.g. "the program must core dump and cause the blue screen of death when 
> the user clicks the save button."  Nonetheless, I like what you have 
> below, regardless of whether it is a set of requirements or a vision 
> statement. 

Yes you are totally correct. But after I wrote it and realized it was
off topic, I still decided to send it ;-) Show no fear.


> While I like some of the things you are saying in point #5, I have 
> concerns about some of the wording.  For example, I thought the focus of 
> this project was writing an API for scrubbing user input, not creating "tools and design patterns to help me build a totally secure web 
> application".  No application is totally secure, or ever has been, or ever will be.
Sorry marketing speak. Some folks have actually accused me of being a
marketing person in the past. I still claim I'm an engineer, but every
once in a while things get flubbed up.

What I'm really trying to get at is that using our api should be easy,
but if designed well can also lead the developer to think about security
as part of the development process. Not really a goal of the project,
but I think a side benefit.

 
> If what you are suggesting is that the API be extensible, that sounds like 
> a good idea on the surface, except that it is in direct conflict with 
> "simple".  If we do not trust developers to use the API correctly unless 
> we make it simple, then what makes us think that they will extend the 
> framework without making it insecure in the process?

Ahhh... Yes, I am aware the flexibility/extendability is often in
conflict with simplicity. So I think two things are important. First, I
like to set high goals and get as close as possible. I'm sure some
amount of flexibility will be lost for simplicity and some amount of
simplicity will be lost for flexibility - but lets not give up at the
beginning. Lets shoot for something powerful. Also, if we take a layered
approach to developing this we may be able to set it up so that there is
a simple layer the most folks use and then a flexible layer that people
who need/want to enahnce or extend what we are doing can use as well.
Can we avoid the making it insecure in the process problem? I don't
know. But what if they can make it more secure by doing something? Do we
want to kill the ability to do that on the worry that someone will
bungle things? Good questions that I don't know the answer to. 

I'm going to keep saying this, but I think layers are the secret. Layers
that allow people to interact with what we are doing in different ways.
From totally plug and chug to well integrated and totally
interdependant...

It does sound like this one is a bone of contention and I am willing to
back off on the idea of flexibility/extendability for the first round at
least :-)

-gabe