W3C home > Mailing lists > Public > www-forms@w3.org > November 2005

Re: AJAX vs. Xforms

From: Erik Bruchez <erik@bruchez.org>
Date: Mon, 07 Nov 2005 18:31:34 +0100
Message-ID: <436F8F76.2070906@bruchez.org>
To: www-forms@w3.org

Eric S. Fisher wrote:
> I'm mostly a lurker on this list and am not an active Xforms developer,  
> but I do know something about the Web and about security issues; 
> therefore  I feel justified in offering an opinion about server versus 
> client side  security.
> I agree with Jason that client side applications have problems keeping  
> secrets.  This is not restricted to Xforms versions of those 
> applications,  however: any "rich client" will share them.  So, it seems 
> to me, that the  real issue is deciding which "secrets" are safe for the 
> client side to  keep.  To pursue Jason's example, an email address might 
> indeed be very  private, and the application designer might want to keep 
> all such  information inside the firewall.  In this case I would suggest 
> that the  rich client send a message to a server applet with some sort 
> of key value  that is meaningless outside the context of the 
> application.  The server  side could look up the email address and send 
> the email.
> Granted, this is more complicated than a "pure" client side solution, 
> and  I would not suggest it for all applications.  As always, security 
> is a  negotiable issue subject to cost-benefit analysis, along with 
> every other  aspect of the environment.  We have already dealt with 
> other rich-client  security issues like cookies, and I don't see this 
> being all that  different.
> Without server support, there are always limitations on what a 
> client-side  application can do.  Where these limitations can be managed 
> or don't  matter, I agree with Adam that rich clients can be very useful.

I believe XForms implementations with a server-side component have at 
least the following benefits that could make them a solution of choice 
even if client-side XForms was ubiquitous:

o Security: only data that ends up into visible controls needs to be 
available on the client. Other data can either be encrypted if state is 
kept on the client, or remain on the server, is state is kept on the server.

o Support for large instances and schemas: if a server-side state 
storage option is selected, you can work with very large XForms 
instances and XML Schemas without having to send them to the client.

o Ease of deployment: as with any piece of server-side software, bugs 
can be fixed, new features can be provided without any need to upgrade 
the client. (Client-side XForms implementation leveraging Javascript, 
Flash, or other client-side interpreters, will share this benefit. 
Native implementations and plugins do not.)

(The Orbeon PresentationServer XForms engine does all of the above today.)

So as Jason and Eric have pointed out, let's not dismis those 
server-side implementations just as stop-gap measures :-)

Received on Monday, 7 November 2005 17:31:37 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:36:16 UTC