Lists Home |
Date Index |
From: Paul Prescod [mailto:firstname.lastname@example.org]
Bullard, Claude L (Len) wrote:
>> 1. Why have the scanner vendors taken until now to figure this out?
>> 2. Why single out Microsoft?
>I'm curious what other XML vocabularies you know of that transport
>Turing-complete macros with complete access to every COM object on the
And they are just now waking up to the fact of macros in markup?
Seems sort of a learning curve problem if it took Office betas to
make them realize that. Admittedly, the COM-level integration of
the MS Office framework opens up a lot of wholes, but show me other
vendors with as much integration on the desktop at all. I agree
that MS should be, with the lionshare, a lot more sensitive to the
problem, but I don't know if fixed positions or headers are the
solution for the long term. Office may be the first one with a big
enough desktop mindshare that it rang some alarm bells, but
is isn't a new problem. My sense here is that MS is their market so
that is the only thing they are looking at. It might be better to
face up to the problem at a higher level if they want their solutions
to work in other XML systems.
>The only one I know if is XHTML, and people expect the browser to
>enforce its sandbox, not a virus checker.
Good question because HTML is what I had in mind, but we did it
with the MID, X3D and VRML have scripts in them, and so
does SVG, yes? However, does the browser see the file if the
mailer is getting it? It is the mail system that would worry
There were other markup vocabularies with scripts in them, and
there will probably be more. I don't think a header is the
whole answer here.
>> Tit: Scanning the whole file slows us down.
>> Tat: Viruses take you all the way out.
>Non sequiter. Let me try an analogous argument: "removing the steering
>wheel from the car slows us down." "Theft takes the whole car out."
>Well, why not just put a lock on? Efficiency and security are not
>necessarily at odds.
Agreed, but they are trading performance for a level of consistency
that XML can't guarantee and want one particular vendor to fix it
without addressing the bigger issues. If we want a truly open
network with interoperable solutions, as noted for some time
and many people in many places, interoperability has to start
with the syntax then work on the applications. Syntax doesn't
buy us much for this particular problem. Is there a
general solution for XML application languages besides pulling
the scripts out of the documents as you suggest below?
>> Tit: Microsoft should behave as they ought.
>> Tat: So should scanner software. Just because
>> the header says the macros are "here" doesn't
>> mean another one isn't "there". One might
>> want to validate too.
>A macro that cannot be executed by the software is harmless. It is just
Yep, but one that can and does is dangerous regardless of where
one puts it in the file. The issue is bigger than Office, but
again, failing to scan the whole file is an invitation to danger.
>> Tit: It's Microsoft's fault.
>> Tat: Microsoft didn't invent XML.
>> This is a problem for any XML that
>> can contain a macro and any system
>> that doesn't sandbox it.
>You act as if there is a long list of such systems.
See any XML application language with a script in it. Some now,
more later. We had VRML viewers that weren't inside the browser,
we have PDF viewers, and so forth. I guess the question is one
of how sandboxing works and is it a system-wide capability that
any viewing app with network access can plug in to.
>> Gee. What will Open Office do?
>It doesn't practically matter as a performance issue. The volume of data
>flowing across the firewall in open office format will be a tiny
>fraction of the Office data.
>I would hope that OpenOffice has a macro sandbox (or separates macros
>from documents), but I don't know for sure.
Yes. It's an old debate in markup circles. For SGML, it was mostly
a theoretical worry because few systems had any support for inlined
code except the processing instructions, stylesheet code, etc; and
validation was required, not optional. If one doesn't validate,
it might be a good idea to separate the macros out from documents,
but I can hear the howling from MIT on that one.