Implement GeckoActiveXObject.supports(clsid)

VERIFIED FIXED in mozilla1.5alpha



14 years ago
13 years ago


(Reporter: Adam Lock, Assigned: David Bradley)


(Blocks: 1 bug)

Windows XP
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)




(2 attachments)



14 years ago
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

14 years ago
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

14 years ago
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

14 years ago
Thought I had already targetted this, ->1.5a
Target Milestone: --- → mozilla1.5alpha

Comment 4

14 years ago
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.
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

14 years ago
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

14 years ago
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

14 years ago
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

14 years ago
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

14 years ago
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

14 years ago
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

14 years ago
Comment on attachment 125596 [details] [diff] [review]
Addes GeckoActiveXObject.supports

Looking for reviews
Attachment #125596 - Flags: superreview?(alecf)
Attachment #125596 - Flags: review?(adamlock)

Comment 13

14 years ago
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

14 years ago
Comment on attachment 125596 [details] [diff] [review]
Addes GeckoActiveXObject.supports


This implementation seems to make the most sense for now.
Attachment #125596 - Flags: review?(adamlock) → review+

Comment 15

14 years ago
Comment on attachment 125596 [details] [diff] [review]
Addes GeckoActiveXObject.supports

Attachment #125596 - Flags: superreview?(alecf) → superreview+

Comment 16

14 years ago
Patch checked into trunk. Leaving open for possible consideration of the 1.4
branch later.

Comment 17

14 years ago
FYI: I've added GeckoActiveX detection to BrowserSpy

Comment 18

14 years ago
Closing to get off 1.5a radar, though these should still be checked into 1.4 branch.
Last Resolved: 14 years ago
Resolution: --- → FIXED


14 years ago
Blocks: 212096

Comment 19

14 years ago
Rubber-stamp vrfy
You need to log in before you can comment on or make changes to this bug.