As I mentioned in my “Blue Hat Report,” I want to expand on one of my answers I gave to a question there. My answer involved better separation of code and data. I’ve since found, in talking to a variety of folks, that the concept is not so obvious as it seems to me.

The basic idea is that when opening a document, a program has to make a decision on how to treat various bits of it. When the bits are jumbled together, its harder to make the right decisions. It’s also harder to write security wrappers that will parse for things like Javascript or Office document macros, when those can be scattered throughout the document. The parser needs to understand the whole document, in the way that the receiver will, rather than just the code parts.
So if we were to separate code and data the way we’ve separated presentation and data into CSS and HTML, we should give serious thought to breaking out an HTML ‘script’ section. Yes, this would be hard, involving standardization and there’s a huge back-compatability issue to be dealt with. But it seems to me that a separate script section would mostly or completely break cross site scripting attacks.
Similarly, with MS Office moving to an XML data format, it would be great to have an explicit “macros” setting at the top of the document. (I haven’t checked to see where macros can occur in the current definition, but my belief is they can be scattered through the file.) [Update: See Kevin Boske's comment, apparently Microsoft is doing this.]
Several years back, I had a conversation with the person responsible for macro security in Office. I really wanted “tell me more” to link, not to the help, but to either a static analysis of the macros, or their content. Through the conversation, I was convinced that that was a great idea for a few hundred, or maybe even a few thousand people, but I was unable to suggest a dialog box that would give a typical user useful decision-making context and data.
If macros were at the top of the XML, then I could do what I really wanted to do: Read the macro myself before opening the document. (I don’t trust that “disable macros” is fool-proof.) If I were writing a document firewall, I could make it faster and more effective.
One final point: Separating code and data allows the parsers to be smaller and more modular, which means faster and more reliable.
By separating code and data, not only do you gain security, but you gain performance and reliability. The sooner we start dealing with the back-compatability issues, the better off we’ll be.