From MozillaZine Knowledge Base

David, if you decide to come here, I suggest you add your reponses inline, starting each chunk of text with a colon.

I've copied this from an email exchange between David Hallowell and myself. It starts with me. raiph 03:18, 22 Jul 2004 (PDT)

Might be useful to mention that this discussion is based on bug 71270 - michaell 20040722

I did post a lot of replies to the comments here but ended up in a mid-air collision with michaell, as the points are summed up well I'll only add bits where I feel they still need adding Dave532

The widgets that mozilla use are not native as such, they're still XUL just that Mozilla now draws the widgets with the assistance of the OS using whatever theming method they have in place therefore giving a native look and feel on platforms that support it. Dave532

OK. Am I right in concluding from the bug comments that, in 2001, Seamonkey did *not* support the sort of native widget that rendered it more open to spyware? And what about now? Does either Mozilla 1.x and/or Firefox now support the particular sort of native widget that was being referred to in the bug? raiph 03:18, 22 Jul 2004 (PDT)

AIUI, Mozilla and Firefox both contain that code, yes. So does IE, Opera, and any other native Windows app. - michaell 20040722

The bug you mention above places a hidden native widget in win32 versions of Mozilla for the purpose of a certain legitimate application to record browsing habits. Dave532

Well, it talks about code that does that, and yes, that much was very clear. raiph 03:18, 22 Jul 2004 (PDT)

Unfortunately it also means it's easier for spyware to do the same Dave532

This is a critical point. If true, it is surely at least a concern. (Albeit one that must be weighed alongside other issues.) raiph 03:18, 22 Jul 2004 (PDT)

I don't see this is a concern really. If there's software running on the user's own computer, then without this, it could pick up the same information from the stored files on the disk (cache, cookies, etc), or by monitoring the network traffic, or by monitoring the user's keystrokes, or what's on their screen. The fact is, if you have spyware on your computer, it can spy on you. Aside from the particular MediaMatrix app mentioned, I'm not sure spyware would even bother to use this, as it would only work with Mozilla/Firefox. There many other techniques they could use, and if they used another technique, they could monitor all your programs at once. Short of running each of your apps in its own virtual copy of the operating system and encrypting everything on your hard drive, there's nothing you can do about this. The thing to do is not to run the spyware in the first place. - michaell 20040722

however this is not a disadvantage for mozilla because every other browser that uses native widgets for the URL bar has this 'feature'. Dave532

I agree that it isn't a disadvantage *relative to other browsers that do the same thing*, but I'd hardly dismiss Mozilla code unnecessarily doing something terribly wrong (I'm not saying it is mind -- I just don't know), just because other browsers do something terribly wrong. raiph 03:18, 22 Jul 2004 (PDT)

Should this be removed? Maybe,

Well, should it? At one point in 2001 Brendan clearly wanted it removed. Mitchell Baker pushed back. Then, well, I don't know. The code's still in the source. I don't know if it gets compiled in. I don't know if other changes occured that make this bug a moot point. raiph 03:18, 22 Jul 2004 (PDT)

but in reality what matters is that the browser is not as vulnerable to drive by installs of spyware because in the end a determined spyware author could get this info without the native widget, it just happens that the native widget approach makes things easier. Dave532

Is that "native widget approach" something that's been added to Seamonkey since 2001, or are you talking about the "not native as such" widgets now used in rendering XUL? And, if the latter, is it possible to configure Firefox to not use these "not native as such" widgets on Windows and, in so doing, significantly reduce the risk of spyware vulnerability? raiph 03:18, 22 Jul 2004 (PDT)

By "native widget approach" he means not using XUL. K-meleon, IE, Opera, and pretty much all other Windows software uses the native widgets - it's the normal thing to do. Mozilla XUL apps don't use the native widgets. This code puts in a native widget, so that other apps can "see" Mozilla like they can see a normal app. - michaell 20040722

Further, it sounds like you're just lightly dismissing the general principle of Security by Design. Either overall, which would conflict terribly with my understanding of what I can expect from Mozilla code, or for this particular issue, which would still trouble me. raiph 03:18, 22 Jul 2004 (PDT)

In terms of security, there are probably hundreds of things which are a bigger problem than this. There are (at last) several not-very-high priority actual security bugs which have been known for a while but haven't been fixed yet. Someone was complaining just the other day that two known security problems (which exist in previous and current versions) that had been marked as blockers for the 1.8alpha2 version were pushed out. It sounds like your "understanding" of what you can expect from Mozilla code doesn't quite meet with the reality. Yes, security is a concern, but it's not an overriding priority to fix moderate security flaws above all else. - michaell 20040722

Funnily enough, some of the people who are fighting for this to be removed want things to work better with download managers such as getright. Download managers work by monitoring links clicked which will reveal more than just a hidden native widget text box. Dave532

At least one person made the comment that a download manager only gets to see links that are clicked that are handed off to a download manager. (I may have misunderstood, they may have been wrong. But it sounds plausible to me.) If so, there's a world of difference between software that sees links you click on to downloadable files, and software that sees all links you click on. raiph 03:18, 22 Jul 2004 (PDT)

Comments by the author of GetRight http://bugzilla.mozilla.org/show_bug.cgi?id=58744#c22 As far as I can make out the download manager needs to see all links that are clicked and then decide based on that which ones it can handle. In current web browsers there's nowhere to specify that a download manager should handle a particular link (if you set a download manager as a helper app then Mozilla will download the app first before passing it to a helper app). Never used an external downloader app for ages, so not sure if they still work this way. Dave532

So, revealing extra information to external apps can be useful, you have to deal with the problem of unauthorised software installations and people installing things they're not sure of. Dave532

Of course revealing extra info to external apps can be useful. No argument on that. The issue is whether it's worth the tradeoffs. And then making those tradeoffs, and the decisions made about them, understandable to the average joe, and that starts with me, who is an experienced programmer, including a bunch of Windows system coding, and 'still doesn't get what's going on! :< raiph 03:18, 22 Jul 2004 (PDT)

Tradeoffs get made - Firefox, for example, has switched from a profile folder with 8 random letters to a folder with 3 random letters in the extension, to make things clearer. Firefox has changed the name of the passwords file from a random name to a known name. Firefox is going to introduce (limited) support for ActiveX in order to make Windows Media Player work properly. Firefox 1.0 will probably ship with a bunch of low-impact, but known, security bugs rather than holding up the release to fix them all. The developers make those decisions. There isn't any policy of making things understandable to the average joe - the policy only goes as far as opening up the bug discussion and adding bugs to the known vulnerabilities page, and both of those things tend to take a lot longer than they should - for example, in the recent XUL spoof bug, someone points out that it's a dupe of a bug filed several years ago, and that the last dozen comments in the older bug are debating whether the bug should be opened to the public. (However, I see that the known vulnerabilities page has been updated today, which is good, to cover all the stuff that's happened since last November). This particular issue you've picked up is not something to worry about. - michaell 20040722

Basically, my conclusion is that this isn't really anything to worry about, but if there's no real reason to keep this then we might as well remove it but it's not really going to increase your security. e.g. if spyware gets installed it can log keystrokes so whatever protection an app provides will be gone, it can read arbitary files on your machine including history and cache files. So if you've got spyware on your machine however hard you try there's no privacy (but I've got nothing against making their lives harder as long as it doesn't impact legit developers)