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

Re: AJAX vs. Xforms

From: Jason Eacott <jeacott@hardlight.com.au>
Date: Tue, 8 Nov 2005 11:06:02 +1030
To: "Eric S. Fisher" <efisher@fsystems.com>
Cc: www-forms@w3.org
Message-ID: <4370869A.9032.1725BF8D@localhost>

Thanks Eric,
	I wasn't arguing that securing an email address wasn't possible at all,
just that its not possible with Pure client Xform. After all, you have all those 
nice Xforms tools available to send emails etc, its a shame not to be able to 
use them. If you  are creating such functionality on the server then for many 
basic forms you might as well use a plain old html form. seems a waste to 
me.



To:             	"Flinton Adam" <Adam.Flinton@cfh.nhs.uk>, 
jeacott@hardlight.com.au
Copies to:      	www-forms@w3.org
Subject:        	Re: AJAX vs. Xforms
Date sent:      	Mon, 07 Nov 2005 08:26:36 -0500
From:           	"Eric S. Fisher" <efisher@fsystems.com>
Organization:   	WorldSyncPlus, Inc.

> 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.
> 
> Eric
> 
> On Mon, 07 Nov 2005 07:41:55 -0500, Flinton Adam <Adam.Flinton@cfh.nhs.uk>  
> wrote:
> 
> >
> > Xforms on the client side does make for a very useful low cost, easy to
> > implement (assuming the problems I have detailed are dealt with) way of
> > rendering a piece of XML into a human readable/editable form. I accept
> > that there are limitations vs. running it against a server where you can
> > add in all sorts of nice stuff e.g. database/datastore access,
> > authentication etc.etc.
> >
> > Adam
> >
> >> -----Original Message-----
> >> From: Jason Eacott [mailto:jeacott@hardlight.com.au]
> >> Sent: 07 November 2005 11:00
> >> To: Flinton Adam
> >> Cc: www-forms@w3.org
> >> Subject: RE: AJAX vs. Xforms
> >>
> >> > For what it's worth, I don't include Chiba and Orbeon in
> >> this class.
> >> > Those I haven't used. I think those projects have problems too, but
> >> > they're of a different nature. I'm not convinced of the
> >> feasibility,
> >> > usability, or maintainability of a primarily server-side
> >> solution; but
> >> > that's an argument for another thread.
> >> >
> >>
> >> I've said this before,
> >> 	I'm not convinced of the feasibility, useability,
> >> maintainability or security of clientside solutions.
> >>
> >> I think clientside Xforms has a serious problem with keeping secrets.
> >> HTML forms are incapable of sending emails by themselves (and
> >> many other functions), and where they require secrets to be
> >> kept from the client they need lots of help, usually by means
> >> of serverside function.
> >> If I want my Xform Submission to send an email then I have to
> >> include that/those email address(es) in the Xform!, If I dont
> >> then I'd have to code it as a completely separate serverside
> >> function and thats not what Xforms is about. What about a
> >> case where I need to send a username and/or password to
> >> retreive data from a 3rd party? (perhaps the isp for example
> >> holds a subscription to some content service and it can only
> >> be accessed by supplying user/pass - but that information
> >> should NOT be revealed to the user of the form.) With a 100%
> >> clientside implementation I think this is impossible.
> >> With a serverside Xform implementation at least I can use
> >> Xforms as it was intended with all its functionality in tact
> >> without the huge security issues potentially associated with
> >> sending too much data to the client.
> >> This is the reason I think that the current serverside
> >> implementations that people are describing as a stop gap
> >> measure until Xforms becomes ubiquitous amongst the big
> >> browsers will be around a lot longer than that.
> >>
> >> its just my opinion, but I think these are big problems with
> >> using a 100% clientside solution in many cases. I can however
> >> also see cases where having the option to run clientside
> >> would be helpful - when the server isnt available for example.
> >> It would be helpful sometimes to be able to pick and choose
> >> which parts of a forms models and views were suitable for
> >> 100% client only processing and those which should never be
> >> used by the client directly.
> >>
> >> my 2 cents
> >> Jason.
> >>
> >>
> >>
> >> 	
> >>
> >
> > This e-mail is confidential and privileged. If you are not the intended  
> > recipient please accept our apologies; please do not disclose, copy or  
> > distribute information in this e-mail or take any action in reliance on  
> > its contents: to do so is strictly prohibited and may be unlawful.  
> > Please inform us that this message has gone astray before deleting it.  
> > Thank you for your co-operation.
> >
> >
> >
> 
> 
> 
> -- 
> Important Note:  This e-mail may contain trade secrets or privileged,  
> undisclosed or otherwise confidential information.  If you have received  
> this e-mail in error, you are hereby notified that any review, copying, or  
> distribution of it is strictly prohibited.  Please inform me immediately  
> and destroy the original transmittal.  Thank you for your cooperation.
Received on Tuesday, 8 November 2005 00:36:34 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 10 March 2012 06:22:02 GMT