Re: AJAX vs. Xforms

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 Monday, 7 November 2005 13:26:08 UTC