One of the big selling points of descriptive markup is that it is safe.
One area where this has been a great concern, of course, has been for office documents. Macros can be an enormous security hole. Microsoft in recent years has been back pedalling hard on the use of VisualBasic macros: indeed they are no longer available on the Mac Office 2008. One of the big innovations in Office 2008 was that files with the standard extensions (.docx, .pptx, .xlsx) are opened in a macro-disabled mode (rather than .docm, .pptm, .xlsm which are macro-enabled.)
In order to cope with the reduction in customizability from not having macros, markup has to step up to the plate and provide the kinds of general functions that otherwise would be done by macros. We can see examples of this in ODF's provision of XForms and OOXML similar provision of XML mapping.
And more has to be done by embedded controls, which can be signed, downloaded and verified, though at the cost of some cumbersomeness.
However, it has to be admitted that it is impossible for even vastly improved descriptive markup (e.g. for menus, completions, etc) to give what a customized script can do. The answer, at least in the near term: we have just live with it and give up macros if we want security.
Thankfully there is another upside: improved descriptive markup does allow extra things that we may not have realized we needed but become indispensable: I think Office's SmartArt (data entry by structured list editor, transformed into various diagrams dynamically) is a good example.
More deeply, we need to move away from the idea of "smart documents" where those smarts include procedural information, unless they use domain-specific notations that have known acceptable security properties (URIs, formulas)
For security we cannot have the "document contains the application" approach that general purpose macro languages support.
The "smart documents" need to be documents with only descriptive information: XML, JSON, whatever. Custom applications need to be distributed out-of-band.
What brings on this? My favourite lurid nutter site, NOOOXML.COM, this week has a surprising post .XLSX files as a security risk.
In a sense, Microsoft has brought this on themselves: their security alert starts with Microsoft is investigating new public reports of a vulnerability in Microsoft Office Excel that could allow remote code execution if a user opens a specially crafted Excel file. And the rest of the alert is rather impenetrable, allowing the kind of hysterical mischief and FUD we have learned to cherish from NOOOXML.COM.
So what is the real story? This is just the old problem: if you use a binary format (or a macro-enabled file) you can have a security problems. The solution: use the MOICE tool to convert the binary to a macro-disabled OOXML file, and/or alter the Registry setting to disallow binary files from opening.
(I contacted MicroSoft to check up whether my understanding was correct, and they confirmed it.)
But I think it shows the technical value of NOOOXML.COM that a security alert that says "Overcome the security problem of the Excel binary formats by converting to .XLSX" gets interpreted as exactly the opposite ".XLSX files as a security risk". Hhrmmmmph
Will we see a retraction from NOOOXML.COM? Not on your life.
These are the people who tried to imply some connection between national standards bodies at ISO from countries low on the corruption index who voted for DIS29500 (OOXML), but who didn't feel it would be consistent to look at the nations on the CONSEGI Declaration through the same lense (Brazil=80, South Africa=54, Venezuela=158, Ecuador=151, Cuba=65 and Paraguay=138, out of 180 by the way.) My point is not to accuse the CONSEGI participants of corruption at all, it is that implying causal connection without evidence is just disguised prejudice, in this case one that plays on racism. (If you are a person who thought the implied connection was reasonable, I think you need to consider whether your prejudice is overriding your rationality, by the way--and fully admitting that I am not immune to this either.) [UPDATE: Please note the comment by Bob Jolliffe below, and my clarification.]
Sensible people: ODF
The issue of macros and security is one that obviously applies to ODF as well as OOXML. Looking at the new committe draft for ODF 1.2, what features does ODF have for macro security?
Err, absolutely none that I could see.
I searched on "macro", "script" and a little of "event" and there was nothing. Indeed, in the draft non-normative Appendix D Core Feature Sets, scripts are listed as a feature that are or would be usually supported by applications.
The ODF TC is currenctly discussing top-level conformance issues. I have written why I think a minimal profile for writers of ODF is good to have, why it is a bad idea for readers of ODF to reject documents with extensions, and why a minimum profile will not actually meet the goal of preventing extensions by unscrupulous hijacking implementers given the other places that extensible information can go.
So add scripting/macros to that list!
I think ODF needs to take a leaf out of OOXML's book here, and at least adopt the convention where the normal extensions must be opened by conforming applications with macro- and script- and event- disabled.
This is not only a security issue: the imagined toxic hijacking developers can already add arbitrary binary files to the ODF, link to them from scripts, embed them in drawings with Bin64, give them as alternative section with text:section-source and so on. Hence my point that a minimal ODF without element extensions is useful to have, but does not in anyway provide anything effective for reducing opportunities to embrace, extend and extinguish. It is not sufficient and (given that many extensions are harmles) not even necessary: OOXML's MCE provides a better basis.
Is it really so unbearable to the ODF people to countenance that some parts of OOXML could be much more advanced in some areas than ODF? If it is, then what hope can we have for convergence, which surely must be based on reducing gratuitous feature gaps of leading applications?
Security is so important, that it should be part of ODF 1.2 rather than a next-generation ODF issue. Governments and users need to take a lead here and get something —anything— pushed through for ODF 1.2 during these top-level conformance discussions. It seems to me to dwarf issues such as vendor-proofing ODF against hijacking vendors, against extension-panic.