Rob,
When you listed the evils of unbridled extension, I thought it was
over-reaching to attach all of those prospects to the presence of foreign
elements-attributes-values. That is for two reasons:
1. If I wanted to attack a consumer and the assets of its user, I would not
do so with foreign e-a-v. Since a consumer is likely to reduce those away,
it doesn't seem like the most-plausible choice for an exploit. Of course,
if there is a prominent, widely-deployed consumer that has some supported
foreign e-a-v that is exploitable, that's perhaps more promising.
2. If I wanted to construct an exploit, I would do it the same way it was
done in the past with Word, via the open and unprotected scripting, plug-in,
and macro capabilities. Promising targets in ODF are fully available as
part of strictly conforming documents and I would go that route once an
implementation was widely-deployed enough to provide a profitable target.
3. Likewise, if I wanted to connive a covert channel for smuggling
information or planting scurrilous information in a document, I would do it
using the available provisions of strictly conforming documents.
4. My sense of your objection is that poorly-designed foreign e-a-v and
their defective support by one or more consumers would expose those
consumers to additional prospects for such difficulties. I can't argue
against that, as much as I hope that we are now much smarter about such
things than we were in the past.
5. I do think that perhaps our efforts might be well-spent giving the same
careful scrutiny to existing exposures in strictly conforming documents that
you identify as important before considering any sort of host-language
profile:
If we want to create a host language profile at some point,
then that would also be fine with me, but we would need to
address the kinds of issues I raised in my previous note
regarding identification of executable code, personal content in
documents, document assembly, referential integrity, etc.
- Dennis
PS: I just had a lot of fun searching through the uses of "script" and
"plugin" in the ODF 1.1 specification and in ODF 1.2 Part 1 draft 8.
-----Original Message-----
From: [mailto:]
http://lists.oasis-open.org/archives/office/200902/msg00061.html
Sent: Thursday, February 05, 2009 13:49
To:
Subject: RE: [office] Conformance Clause proposal, Version 8
[ ... ]
In any case my preference remains to stick with a single conformance
class, not permitting namespace extensions. If we want to create a host
language profile at some point, then that would also be fine with me, but
we would need to address the kinds of issues I raised in my previous note
regarding identification of executable code, personal content in
documents, document assembly, referential integrity, etc.
[ ... ]
