As a security precaution, we have turned on the setting "Require API key authentication for API requests" for everyone. If this has broken something, please contact
Last Comment Bug 204894 - Implement GeckoActiveXObject.supports(clsid)
: Implement GeckoActiveXObject.supports(clsid)
Product: Core
Classification: Components
Component: XPConnect (show other bugs)
: Trunk
: x86 Windows XP
: -- normal (vote)
: mozilla1.5alpha
Assigned To: David Bradley
: Phil Schwartau
: Andrew Overholt [:overholt]
Depends on:
Blocks: 212096 190852
  Show dependency treegraph
Reported: 2003-05-08 10:22 PDT by Adam Lock
Modified: 2005-01-01 17:07 PST (History)
9 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

Sample clientCaps (812 bytes, text/html)
2003-06-10 16:32 PDT, Adam Lock
no flags Details
Addes GeckoActiveXObject.supports (12.25 KB, patch)
2003-06-13 13:03 PDT, David Bradley
adamlock: review+
alecf: superreview+
Details | Diff | Splinter Review

Description User image Adam Lock 2003-05-08 10:22:58 PDT
Implement a method / parameterized property on GeckoActivex that allows JS to
determine whether a control is supported in Mozilla.

For example,

if (GeckoActiveXObject.supports("814ba433-a816-4785-9f95-ad3ba0a43dab")
  document.write("<object> etc.");
  alert("Boo hoo no support for my object!");

Note that making this take a useful form while respecting privacy / security
issues might be problematic.

For example, supports(clsid) should certainly not say whether the control is
installed (otherwise someone could probe every clsid on the system), but just
whether the current policy allows that control to be instantiated assuming it
were installed.

Also, the method should not supports progids, since the impl would have to look
up the progid in the registry to determine the clsid. A clever attacker could
probe for progids and still perhaps figure out what is installed and what is not
based the answers returned.

For example, if "Foo.SomeObject.1" maps to
"814ba433-a816-4785-9f95-ad3ba0a43dab", an attacker could call
GeckoActiveX.supports("Foo.SomeObject.1") and
GeckoActiveX.supports("814ba433-a816-4785-9f95-ad3ba0a43dab"). If the first call
failed but the second succeeded I would know that "Foo.SomeObject.1" is not
installed because the progId lookup failed, but the clsid lookup succeeded,
meaning the current policy allows it so its not because of that.
Comment 1 User image David Bradley 2003-05-08 11:00:39 PDT
Good points Adam, I hadn't thought about the prog id and class id testing trick.
I wonder if that's going to be a problem for anyone? We support instantiating
via a prog id. Only allowing this check via class ID seems a little odd, but
maybe that's the price of security.
Comment 2 User image Phil Schwartau 2003-05-13 17:53:23 PDT
I came across the following syntax at, where
the site determines whether the client supports Windows Media Player 9:

   <span style="behavior:url(#default#clientCaps)" id="cc"></span> 

   <script language=JavaScript> 
   var cv = cc.getComponentVersion("{6BF52A52-394A-11D3-B153-00C04F79FAA6}",  

   if (cv == null || cv == "") 
     top.location.href = ""; 

(The clsid is for Windows Media Player 9). Notice the <span>
element acquired the getComponentVersion() method via CSS !!!


Adam found references for this syntax, which at present 
is IE-only, and is known as "DHTML Default Behaviours":

As this is not currently supported by Mozilla, it's another of
the peripheral changes that Yahoo, for example, would have to make
in order for Mozilla to handle
Comment 3 User image David Bradley 2003-05-16 13:13:06 PDT
Thought I had already targetted this, ->1.5a
Comment 4 User image David Bradley 2003-06-10 10:16:53 PDT
I've been waffling on whether supports should ask the object whether it is safe
for scripting. Initially I really didn't want supports to instantiate the
object, but that would mean that the results for supports and
GeckActiveXObject("xxx") would be different and that didn't seem good either.

So I'm looking for some feed back on what others think is the appropriate approach.
Comment 5 User image Heikki Toivonen (remove -bugzilla when emailing directly) 2003-06-10 14:09:07 PDT
If you instantiate the object, and it is hostile, it could cause havoc at that
point. Of course, if the object was hostile the installation probably would have
caused harm as well.
Comment 6 User image Adam Lock 2003-06-10 14:24:26 PDT
Here is some info about the methods that the clientCaps behaviour exposes on any
element given that style

Importantly, the documentation says that only certain clsids are detectable
using these methods.

This suggests that other clsids are prevented deliberately to prevent 'sniffing'
a big long list to see what might be on the machine.

Perhaps we need to restrict ourselves in the same way, using the whitelist
perhaps, or a hardcoded list in blacklist mode. IE might even store these
'detectable' clsids somewhere in the registry where they can be read.
Comment 7 User image Adam Lock 2003-06-10 16:32:34 PDT
Created attachment 125352 [details]
Sample clientCaps

I grabbed this from the web. Load it in IE.

I'm fairly sure that clientCaps will only report back on CLSIDs that it finds

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Active Setup\Installed Components

and possibly under HKEY_CURRENT_USER too.
Comment 8 User image David Bradley 2003-06-11 07:38:59 PDT
Heikki, yes that was my concern as well. And I was trying to weigh that against
parity between GeckoActiveXObject("xxx") and GeckoActiveXObject.supports("xxx");
But the instantiation is only the last part, and only occurs if all the other
checks succeed. It also makes supports a heavier function to call as well.

Adam, I wonder, will IE instantiate a component if it's not in Installed Components?

By default ActiveX/COM objects create an entry here (at least the ones I built).
But maybe that's a reasonable requirement for controls being used on the web.
So, should an item on the white list that isn't in this list be disallowed?

I found the following link: but
I'm unable to figure out how it works on XP.
Comment 9 User image Adam Lock 2003-06-11 11:09:01 PDT
In DevStudio 6 at least, controls do not create an entry in this list yet they
work fine in IE without warnings when they implement IObjectSafety. So I don't
believe there is a requirement that they appear here. Not being here might mean
they cannot be detected but they can still be instantiated. Other controls, for
example the Shutterfly control also do not appear here but work fine in IE.

The dumb thing about this list is that it contains stuff which should not be
detectable (you would think), such as CLSIDs for various service pack fixes. If
restricting the list of CLSIDs is meant to be a security thing, it would seem
counterproductive to let a page see what service packs I have applied. I
verified that I can see them by modifiying the sample page. But ask it about
Shutterfly and it returns nothing. 

I also tried to figure out what the second sIDType parameter on
isComponentInstalled / getComponentVersion is meant to represent. If you pass
'componentId' the docs hint that my assumption of where it is checking is
correct (Active Setup). If I just pass in 'clsid' instead, it returns version
information but only for the WMP and not the other examples in the test page. I
do not know if 'clsid' is a valid arg since the docs are vague, but perhaps it
falls back on a hardcoded list when the type is a clsid.
Comment 10 User image David Bradley 2003-06-11 12:38:07 PDT
Well, I searched around a bit, unfortunately accidentally shutdown the browser
and lost my original comment here along with the various links. So I'll summarize.

Some nsIDTypes:

Looks like isComponentInstalled takes clsid, ComponentID, progID, mime(not sure
of the exact spelling). Also, apparently there's a VBScript isComponentInstalled
that returns 0, 1, 2, or 3. denoting if it's installed, a newer version, or the
user said don't check. As opposed to true/false of the DHMTL version.

Given there is little documentation on this, I think it would probably be best
to avoid it for now. It's really probably only useful in black list mode anyway.

Given that some embedders might want to use such vendor specific checks or
something completely different. I wonder if it would be better to provide an
interface to allow vendors to replace our current default vendor specific checks
with their own?
Comment 11 User image David Bradley 2003-06-13 13:03:27 PDT
Created attachment 125596 [details] [diff] [review]
Addes GeckoActiveXObject.supports

Ok, this doesn't support the DHTML behaviors. I just don't think that's
documented well enough for us to get it close to right. So I'd rather avoid it
till it's more well known. We could always add a isComponentInstalled to
GeckoActiveXObject if and when that happens.

I also chose not to ask the object if it's safe when using
GeckoActiveXObject.supports. This sacrifices parity between
GeckoActiveXObject() and GeckoActiveXObject.supports(), but makes it a much
lighter weight function that if it had to instantiate, ask, and then throw away
the object.

If anyone can make a strong argument for either of these two issue, I'm open.
Comment 12 User image David Bradley 2003-06-13 13:04:28 PDT
Comment on attachment 125596 [details] [diff] [review]
Addes GeckoActiveXObject.supports

Looking for reviews
Comment 13 User image Adam Lock 2003-06-16 08:39:03 PDT
I'll review in a moment, but first we definitely don't want to create an object
ever just to determine if its safe or not. Creating an Adobe Acrobat, MS Word
document, or even an IE browser object is obviously wasteful.

This functionality has to compare the clsid to *some* list and possibly
additionally say whether its installed or not.

The list could be a combination of:

1. Whitelist / blacklist
2. Hardcoded list of clsids
3. Some part of the registry

And then finally if it passes whatever of these we test, possibly test if the
clsid is even installed. This last step is not acceptable from a
security/privacy standpoint if we only test the whitelist/blacklist and its in
blacklist mode. And saying we support it is provisional on its object safety and
further checks when its actually created.

Perhaps the answer for the moment, is supports() does not say whether the
control is actually installed or not, just whether Moz would support it if it
were (and we're not going to say if it is) and if passes the safe for scripting
checks if they're enabled.

If later we want to add an isComponentInstalled / getComponentVersion, it can
supplement the existing supports behaviour. Personally I think that this would
be sufficient for now. And if we add an isComponentInstalled, it can use the
hardcoded list that MS documents as an additional filter.
Comment 14 User image Adam Lock 2003-06-16 08:45:03 PDT
Comment on attachment 125596 [details] [diff] [review]
Addes GeckoActiveXObject.supports


This implementation seems to make the most sense for now.
Comment 15 User image Alec Flett 2003-06-17 14:02:12 PDT
Comment on attachment 125596 [details] [diff] [review]
Addes GeckoActiveXObject.supports

Comment 16 User image David Bradley 2003-06-19 21:17:10 PDT
Patch checked into trunk. Leaving open for possible consideration of the 1.4
branch later.
Comment 17 User image Henrik Gemal 2003-06-26 04:00:12 PDT
FYI: I've added GeckoActiveX detection to BrowserSpy
Comment 18 User image David Bradley 2003-07-08 14:56:41 PDT
Closing to get off 1.5a radar, though these should still be checked into 1.4 branch.
Comment 19 User image Phil Schwartau 2003-07-08 15:05:52 PDT
Rubber-stamp vrfy

Note You need to log in before you can comment on or make changes to this bug.