[
Lists Home |
Date Index |
Thread Index
]
- From: "Jonathan Borden" <jborden@mediaone.net>
- To: "David Galbraith" <david@moreover.com>, <xml-dev@xml.org>
- Date: Sun, 7 May 2000 15:44:23 -0400
David Galbraith wrote:
love
>
>
> It may be entirely desireable that you use mime to create an
> indication that
> a SOAP message is signed, encrypted etc. but it is surely not a necessity.
> You may have a policy that says 'whatever' comes through my firewall must
> have a standard envelope around it to identify itself - but then once
> through the contents are a separate issue.
>
Yes, this of course assumes that intelligent yet effective firewalls will
quickly and uniformly come into use, and that these will be able to
efficiently filter XML traffic.
Yet this isn't just an XML issue and XML isn't likely to solve this problem.
There is nothing preventing a smart firewall from filtering HTML or SMTP
content. On the other hand it is just too difficult a job for a firewall to
know what is good vs. potentially harmful scripting, and if firewalls were
to be given such knowledge e.g. allow individual x with such and such token
to call method y at endpoint z .... application configuration would become
horrendous and most all IS/IT groups would just rather turn all such content
off rather than deal with such issues.
In reality it is the *application framework* which has the ultimate
responsability for sandboxing allowable vs. dangerous operations be that the
JVM, the web or e-mail server and/or clients (e.g. Outlook, Mozilla
whatever).
The problem exists not because firewalls don't have adequate information,
rather because the application frameworks have been implemented in a
braindead fashion: buffer overflows, no sandbox, allowing dangerous
scripting operations etc. These issues are all well known. Lets not allow
people to redirect the problem to blah blah blah protocol issues, or
scripting itself (and remember that scripting has been around for decades!)
This is where the problem lies: braindead implementations.
just my 2p.
Jonathan Borden
***************************************************************************
This is xml-dev, the mailing list for XML developers.
To unsubscribe, mailto:majordomo@xml.org&BODY=unsubscribe%20xml-dev
List archives are available at http://xml.org/archives/xml-dev/
***************************************************************************
|