lex Krawarik [MSFT] wrote:
> We agree that using the most secure version of MSXML is desirable

Good. So we have a sound starting point.

As a side note: this is the first time ever I'm conducting a discussion
on one of Microsoft forums. I'm way beyond of "Misro$oft must
die" silliness, just always prefer to ask and discuss on more generic
technical groups. Well, everything has to be tried at least once in
ones life :-)

> however
> you are unfortunately greatly misinformed as to what the capabilities of
> each version of MSXML actually is, or when they can be used.

That's hardly as I was forced to deal with ActiveX/MSXML since 2001.
But OK.

> Without going
> into a large technical discussion, the Xml Core Team (thats me!) guidance is
>
> MSXML3 is more secure than MSXML4 or MSXML5 for most scenarios, today.
> Period.

It is very bad if you really think so. MSXML3 _with all up-to-date
vulnerability fixes_ is rather secure. MSXML3 as it is on older IE6
distribution packages is a big security risk.
Without knowing exactly how a particular MSXML3 was installed and what
updates were made you cannot just blindly state that "MSXML3 is more
secure than X".

> You should never use MSXML5. Period.
> You should avoid MSXML4. Period.

If one has a choice to use either MSXML4 or MSXML3 then choose MSXML4.
Period.
Also with several MSXML libraries installed MSXML3 may get unavailable
after updating MSXML4, so the choice will be eliminated by itself.

> MSXML6 is the best option for new applications, going forward.

That is correct.

> As such, please stop doling out bad advice.
>
> > I respect your freedom to express your point of you, but it is not
> > acceptable for the programming practice - this is the opinion I reserve
> > to hold.
>
> Now THATS funny! :)

It is, but not for the reason you think of. After reading the linked
blog and your advises, I thought first of the famous historical
anecdote about poor Queen Marie-Antoinette:
- You Majesty, your peasants have no bread.
- Poor they are! So let them eat cakes.

In application to the current case that would be something like:
- Dear M$, developers don't know what MSXML to use.
- Poor they are! So let them run the provided .exe file to determine
the current MSXML version.

In the suggested blog I truly enjoyed the expressed vision of the World
Wide Web as one huge ASP-based intranet with developers running around
with admin rights. There is some darling naiveness in that, just like
in Marie-Antoinette with her "so let them eat brioches".

As I went into the discussion any way, let me show how the things are
really being done in WWW. Consider it as a free tour outside of
Versailles (outside of One Microsoft Way ;-)

To eliminate the universal ProgID option, let's us imagine a case with
XPath, contextual fragments and stuff: so "Microsoft.XMLHTTP" doesn't
do the trick.

So say the objective is to write a cross-browser script doing run-time
instantiation of XSLT tools. In case if the needed XSLT tools cannot be
instantiated then warn user and suggest to navigate to an alt page. The
script will be run within the default (narrowed) security settings of
the Internet zone.

So the page is loaded, .js file parsed and started to execute.

Step 1
First check if this is a modern standard-compliant browser, then
explore all other options:

 if (
  (typeof window.XSLTProcessor == 'function') &&
  (typeof document.implementation == 'object') &&
  (typeof document.implementation.createDocument == 'function')) {
 /*
  * Oh... but it is better to be safe now than sorry later.
  * The rest of the instantiation code in this branch is irrelevant
  * to our subject.
  */
 }
 else if (typeof window.ActiveXObject == 'function') {
 /*
  * Hello, softish! :-)
  *
  * Of course ActiveXObject can be spoofed as well by some
  * previous script like say window.ActiveXObject = new Function;
  * But window.ActiveXObject check is so widely used that an
  * absolute hate is guaranteed to anyone breaking it. Thus even
  * the most "famous" spoofers like Safari or Opera did not dare
  * so far to spoof window.ActiveXObject.
  * So this the regular precaution assume that it is a browser
  * supporting ActiveX and potentially able to instantiate MSXML
  *
  * proceed to Step 2
  */
 }
 else {
 /*
  * No needed tools found.
  * Proceed to the fall-back options, whatever
  * you have chosen.
  */
 }

Step 2
On the previous step we successfully branched onto IE-specific block.
Now it's time to try to instantiate MSXML objects. There are two main
obstacles to be ready on this step:

1) current environment prohibits to instantiate _any_ ActiveX objects:
unsigned, signed by Microsoft, by Bill Gates personally, by Lord
himself - doesn't matter. That is an extreme but possible situation, if
say admin was promised to receive pink slip "if sh** like that happens
one more time".
So we have to be ready for a security exception raised on attempt to
instantiate an ActiveX object.

2) We don't know what ProgID to use w/o fail. 6? 4? 3?
On IE situation gets even more complicated because both JScript and
MSXML are not build into browser but they are rather independent DLLs.
It is also spiced up by the facts that during some major pandemics in
the past Microsoft destributed JScript and MSXML "updates" which are
merely previous versions of the relevant DLLs. Say for JScript 5.6
there was "security update" containing JScript 5.1
It could be also occasionally overridden by admin from Windows 2000
setup disk when re-installing scripting host or the whole system.
All that makes possible situations when say IE 6.0 SP1 on Windows 2000
is running JScript 5.1 instead of 5.6 with just-installed MSXML4
security update that made unavailable the default MSXML3. That is not a
mind game: that is just one of practical situations - and not even out
of the most complicated ones - in my support history.

So what shall we do with all these obstacles? Marie-Antoinette would
suggest "to eat cakes if you dont have any bread". So we would display
a message prompting our user to download the needed .exe tool, execute
it and submit the execution results via provided form. Other words
something silly like at <http://support.microsoft.com/kb/q296647/>

But on a commercial web-project one should avoid Marie-Antoinette's
destiny. So our task is to try to activate the needed objects without
any guarantee of a particular library available and even without
guarantee that we are allowed to instantiate any ActiveX objects. And
all this on the background, without asking user to help us and within
the standard Internet zone sandbox.

After some deep thinking :-) it becomes obvious that try-catch block is
our only option. Lucky it is supported in JScript 5.1 as well so we
don't have to worry about IE6 with overridden jscript.dll
The older versions of JScript (1.0 - 5.0) can be rather safely
disregarded as of the year 2007.

As we do agree that MSXML6 is up-to-date the best choice, we'll try
first this library. If no luck then we will try consecutively all other
libraries from top to bottom. Jumping from MSXML6 right onto MSXML3 is
not an option: as it was explained earlier it can be Windows 98
SE/Windows 2000 platform with MSXML4 update so MSXML3 unavailable. Thus
by going from 6 right to 3 you are cutting off without any reason some
part of potential users.

All this effectively brings us to code similar to
<http://groups.google.com/group/microsoft.public.xml/msg/e050e13f6ba7db3f>

The code itself can be further improved of course. Say IE for both
ActiveX disabled and no needed library found situations reports error
439 "Automation server cannot create object". Sometimes it is important
to know the exact reason of the failure so to give appropriate advises
or to redirect to an appropriate page.

In this case one may try to instantiate first some very generic object
and see if success:
 try {
  var XSLT = new ActiveXObject('Microsoft.XMLHTTP');
 }
 catch(e) {
  if (e.number&0xFFFF)==429) {
   // Most probably ActiveX is disabled
  }
 }
 finally {
  // Upon check above either instantiate XSLT
  // with needed object or fall-back.
 }

As I said this is only if you have different fall-back options for
narrowed security and for missing MSXML library. Otherwise do not
complicate your code with no need.

P.S. Here is it, Your Majesty. Our trip to the real world is finished,
I'm leaving you in front of the gates of Versailles :-)