On Jul 7, 2009, at 9:19 PM, Doug Ewell wrote:
Douglas Otis <dotis at mail dash abuse dot org> wrote:
The concern is about the application accepting document
instructions and text and then generating document output. When
this application is proprietary, it is prone to change where
remedies might become expensive or impossible.
The implication is that open-source software is inherently stable
and commercial software is inherently unstable. That's hardly a
safe across-the-board assumption.
When an application is open and the OS APIs change, recompilation
often provides a remedy. When the application is proprietary, whether
patches become available as a remedy to an OS change depends upon the
vendor, who might also expect some precondition be met. This concern
becomes somewhat more pressing when the same vendor controls both the
application and the OS. :^(
The evolution in hardware tends to force the use of different
operating systems which may no longer support older applications.
"Tends to," "may." Sounds like FUD to me. I haven't had any
trouble using Word 2003 under XP to read documents I created in Word
95 thirteen years ago.
Often application APIs exhibit security vulnerabilities. Unforetold
changes to improve security inevitably will inhibit some
applications. It was your good fortune that the application was
updated and made available at a reasonable price. Backward
compatibility modes to support older applications might lessen
security, or simply not function. After all, due to security
concerns, libraries are continuously updated, sometimes in
incompatible ways.
IIRC, I did work back in the early 90's that contained Russian
written using Word 5. Conversion proved difficult since
proprietary fonts were needed. Document recovery then required a
fair amount of work to rediscover the structure and character
mapping. Trying to get any version of Word to generate plain text
outputs consistently always seemed to be a PITA, that varied from
version to version, and never seemed worth the effort.
All work involving Cyrillic text was hit-and-miss fifteen years ago.
Every word processor or other application had its own custom format.
Many used KOI8-R, some used CP866 (or worse, CP855), a few used ISO
8859-5. PDF files depended entirely on the embedded font to convey
meaning; copy-and-paste from PDF was useless. Compatibility
problems in the era before widespread Unicode adoption were hardly
limited to Word.
Not having source available significantly increased recovery efforts,
nor could this effort be shared per the EULA. :^(
When people are required to input Word Document "instructions" into
their Word application, they might become exposed to system
security issues as well.
"Might be." More FUD over security. Has anyone suggested
*requiring* users to employ mail-merge-type macros as part of I-D
preparation, or is this just a general flame against Word?
The concern about what might be embedded within documents was not in
regard to simple macros, but that of a program language capable of
compromising the operating system. The concern was voiced in
opposition to suggestions for using Word input files as a means to
generate inputs for I-D or RFC generation utilities. Of course,
collaborators are likely to share these input documents as well.
Sharing potentially hazardous input files among often virtual
strangers represents a bad practice with respect to security. This is
not any different than warning users not to click on "greeting-
card.exe" email attachments.
The variability of the Word data structures makes identifying
security threats fairly difficult, where many "missing" features
seem to be an intended imposition as a means to necessitate use of
the vendor's macro language.
Translation: I don't like Microsoft.
IMHO, unnecessary risks are being taken with respect to code having
unknown origins. In other words, this is an argument about ensuring
people are able to recognize the gun before pulling its trigger. As a
result of their iFrame innovation and inevitable clickjacking,
websites now need to inhibit iFrames with X-FRAME-OPTIONS (supported
by IE 8 and NoScipts). Users are also warned to disable this feature
within their browsers.
WMA files with ".mp3" extensions will launch and prompt with a system
pop-up for the installation of OS extensions obtained from unknown
locations hidden within the mislabeled files. Often users mistakenly
trust messages that appear generated by the OS. In view of mistaken
trust, why are document related exploits low on a list of concerns
when discussing the generation of archival formats? Why call this
FUD? There is nothing uncertain about the concern.
Inherent security issues alone should disqualify use of proprietary
applications.
Hey, maybe if I say the word "security" enough times, people will
get scared and not use Word any more!
Detecting the malware contained within exchanged active content is
becoming less effective, since malware from unknown sources evolve
every few minutes into new forms. Knowing what might be malware, and
where it originated, remains a difficult problem made increasingly
difficult by organizations that give security low priority.
It would be sending the wrong message to mandate the use of
proprietary operating systems or applications in order to
participate in IETF efforts.
Who ever proposed to *mandate* the use of Windows or Word to write
an I-D or otherwise participate in IETF efforts? The proposal was
to ALLOW users to prepare I-Ds using Word, and translate the output
of Word into a format the IETF tools and RFC Editor can deal with.
Nobody ever said anything about *mandating* any of these tools.
There are security related reasons for not venturing down this path.
In addition, other options might be allowed to fail with a rationale:
"Since Word generates an input that eventually receives IETF nit
checker approval, other options become nonessential, since 80+% of
desktops run Windows."
After all, lax security often found within proprietary operating
systems and applications threatens the Internet.
Pure and complete FUD, despite the real macro threats of a few years
back. The Internet will not fall apart if someone uses Word, feeds
the output into a Word2RFC tool, and submits that output to IETF.
What fundamental design element has changed the basic security
concerns related to the input files? Simpler structures in XML form?
Open source includes more than just Linux, and the exposure of
requiring proprietary applications or operating systems would
affect nearly all IETF participants that maintain existing
documents or generating new ones.
Nobody, but nobody, has proposed requiring Word or Windows for IETF
use.
Sorry, but it would be wise not to consider this application due to
its lack of security whenever expecting to have shareable process
inputs.
-Doug
_______________________________________________
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf