W3C home > Mailing lists > Public > xml-dist-app@w3.org > May 2000

Re: Web RPCs Considered Harmful

From: Dave Winer <dave@userland.com>
Date: Sat, 13 May 2000 10:31:02 -0700
Message-ID: <23f101bfbd01$02c36500$1918ccce@murphy>
To: <xml-dist-app@w3.org>, "Ken MacLeod" <ken@bitsko.slc.ut.us>
OK, if that's what this is about, we've already crossed this line. We
operate in a restricted sandbox server-side. I think Wes outlined the way to
approach this. I'm looking for help, not brakes. I see xml-rpc and soap as
mere formalizations of what we're already doing, all over the Web, through
cgis, asps, jsps, etc. To try to put the genie back in the bottle is a big,
undoable task, imho, and also not worthwhile. Users want web apps, so they
will have them (they already do). Dave


----- Original Message -----
From: "Ken MacLeod" <ken@bitsko.slc.ut.us>
To: <xml-dist-app@w3.org>
Sent: Saturday, May 13, 2000 10:02 AM
Subject: Re: Web RPCs Considered Harmful


> "Dave Winer" <dave@userland.com> writes:
>
> > What would be the most practical, easy and low-tech way to add a
> > layer of security, using current best-practices of the Internet?
> >
> > Rather than seeing this a time to put the brakes on, could we get
> > into problem solving mode and have an answer that can easily be
> > implemented in conjunction with the RPC work?
>
> Since the problem is not one of active security (access control), but
> of passive security (unintended faults), the solution isn't really
> something one puts into a specification.
>
> The current best-practice of the Internet for solving the passive
> security problem is "sandboxing", highly restricting the environment
> and access to resources from where code runs so that when that code
> fails it is still confined to the sandbox.
>
> Java and JavaScript, as examples, are designed with sandboxing as a
> core feature.
>
>   -- Ken
>
Received on Saturday, 13 May 2000 13:30:39 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:58:56 GMT