[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [vtp-dev] Security Branch Merged
|
Hi Trip,
> I have recently merged the security branch into the trunk now that it
> has proven to be stable enough.
That's great!
> With the security updates, I wanted to provide a set of changes to
> enable the safe use of sensitive data within an application. The
> changes amount to providing a mechanism for the application developer
> to identify the sensitive data used in the application and allow the
> runtime components to recognize this desire and take appropirate
> action when logging or otherwise transmitting the data to other
> agents.
It is good to think about security issues here. Just some of my thought:
- Does this include the use of the HTTPS protocol when submitting forms?
- The application developer should be aware that there is also a runtime
environment (the voice browser) that does not know about these new
security issues and that this will not be reflected there.
>
> This is really only a quick pass to allow the use of OpenVXML for
> applications involving sensitive data, such as credit card
> information, without having to completely disable logging to be
> compliant with security regulations.
I have to admit that I share David Reich's concerns about that name.
> There are quite a few more things I’d like to do along these lines.
> Take a look at what I’ve put together as a starting point. I’d love
> to hear everyone’s thoughts or suggestions on how we can improve this
> aspect of the software. Below is an overview of the additions and
> changes:
>
> UI Changes
> * Variables declared in the begin blocks of applications and
> fragments can be marked as secured. The application developer
> simply clicks the table column labeled with the lock icon to
> indicate the desired security setting.
I think that this is an easy and intuitive way to do that.
> * Variables declared in the variable assignment block can be
> marked as secured. The application developer simply clicks
> the table column labeled with the lock icon to indicate the
> desired security setting.
> * Blocks that produce VXML documents can be marked secure. A
> simple checkbox is provided in the general configuration panel
> to mark the desired security setting.
> * The decision block allows the left and right arguments to be
> marked as secured if they are expressions. A checkbox is
> presented under the expression field.
> * The business object editor allows fields to be marked
> secured. The table has a lock column similar to the begin and
> variable assignment blocks.
>
> Scripting Changes
> * Data objects (those under the Variables object) have a new
> function “isSecured()” that returns a Boolean indicating
> whether the value should be secured.
>
> Runtime (API) Changes
> * The variable registry function createVariable() has been
> overloaded to accept a Boolean as a second argument to
> indicate whether the object should be secured.
> * IDataObject has a new function isSecured() that returns a
> Boolean indicating whether the object is secured.
> * Data objects constructed using a business object template will
> now automatically honor the secured flag of each field.
> * All runtime actions for built-in elements that log variables
> now check to see if the variable is secured and log the text
> “**Secured**” in place of the actual value.
> * VXML documents produced by interaction objects marked as
> secured will no longer be logged regardless of logging level.
> * The decision action will replace the calculated value of
> expressions marked secured with “**Secured**” when logging the
> comparison details and results.
> * Insecure objects placed into a variable that was previously
> marked secure will automatically be marked secure when
> assigned.
The changes in the API reflect the easy way to mark something as secure,
so they are straight forward. Maybe this is comparable to the secret
control in XForms? It is not that level of security that can is meant
when I need some sort of authorization e.g. to protect a method call.
My point is expressed by a something from the XForms 1.1 specification
http://www.w3.org/TR/xforms11 :
"Note that this provides only a casual level of security; truly
sensitive information will require additional security measures outside
the scope of XForms."
Besides I realized that the org.eclipse.vtp.desktop.views.extended
requries the presence of the pshelf library
http://www.eclipse.org/nebula/widgets/pshelf/pshelf.php
This project is still in the incubation phase. I do not have any idea
when it will leave that status. So: Is this library really needed? What
do we gain/loose if we use/remove it?
~dirk
