Closed Bug 71270 Opened 24 years ago Closed 16 years ago

Browser stores the current URL in a hidden native widget

Categories

(SeaMonkey :: UI Design, defect)

Product:
SeaMonkey
Component:
UI Design
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME

People

(Reporter: jag+mozbugs, Unassigned)

Details

(Whiteboard: In order for this to be spyware, you have to install a spy. Caveat: You may not know you install it.) 

Or, put differently, shaver and I feel nsIURLWidget, its implementation and
related code should not be in the Mozilla tree.
It's called a "widget", but XPToolkit doesn't own it. -> XPApps vishy/law

In (a feeble?) defense, it is designed as a generic facility that another
application could use to co-operate with the browser.
Assignee: trudelle → pchen
Component: XP Toolkit/Widgets → XP Apps
QA Contact: jrgm → sairuh
Thanks for ccing me.

What does it do so evil?

(FYI: Personally, I prefer to have it in the Mozilla tree, but disabled. That
way, we at least see what evil things Netscape does. But I can also see reasons
for removing it.)
OS: Windows 95 → All
Hardware: PC → All
It's not evil (theoretically).  This enables Media Metrix to monitor use of
Mozilla and thus give us some "browser market share."  mozilla.org allegedly
accepted this when it went in, and "XPApps" (Don and I) explicitly disavowed any
responsibility.

Re-assigning to "Evangelism" since that seems most likely to bring it to the
attention of those who are responsible for dealing with this issue.
Assignee: pchen → evangelism
Component: XP Apps → Evangelism
QA Contact: sairuh → zach
> It's not evil (theoretically).  This enables Media Metrix to monitor use of
> Mozilla and thus give us some "browser market share."

Monitoring *is* evil.

This bug is wrong in evagelism. "this component is used to track  web pages that
must be upgraded to support web standards and Mozilla."

It lives in xpfe/, so back to xpfe. As per law, assigning to brendan. What's
going on here?

Could somebody please open bug 36658? It is quoted as reason for the checkin. It
doesn't seem to contain a security bug.

Guys, do you send *each* URL visited to some MMXI site? If a reporter finds out
that, have fun at court...
I hope, this stuff isn't enabled in Mozilla.
Assignee: evangelism → brendan
Component: Evangelism → XP Apps
QA Contact: zach → shaver
Lets get this out of the tree ASAP. Also, 35568 is secure and I cannot get 
to it.
No one on staff@mozilla.org "accepted" or otherwise ok'd this thing.  Please put
it in the ns tree, where it belongs.

/be
Assignee: brendan → law
This better get fixed soon, or I will just remove the offending code from
cvs.mozilla.org and let the chips fall where they may.

/be
Todd, I requested and received *explicit* assurance that I would not have to
deal with this if mozilla.org objected to this "feature."  I don't want to deal
with it and don't think I should have to.
Assignee: law → tpringle
Phil, bug 36658 details the implementation of this media metrix tracking code -
do you remember what happened when we implemented - did someone discuss with
mozilla staff? 
http://bugzilla.mozilla.org/show_bug.cgi?id=36658 is permission denined. 
Why? Can it be made public?
It may be that bug 36658 predates bugscape, and is Netscape-confidential only
for want of a netscape.com-firewalled bugzilla instance in which to file it.  I
don't care.  This code needs to get out of cvs.mozilla.org, and I'll cvs remove
it if necessary -- but it would be much better if someone who has CVS access
(not tpringle, I think) did the work.

So I don't believe that law can duck and have management or marketing own this.
Bill, you may not feel you should have to deal with moving/removing the file,
but you checked it in.  CVS access means removing some times, as well as adding.
I'd rather you did the deed -- please reconsider.

Todd, no one on staff@mozilla.org was ever consulted, as far as I can tell.  Not
mitchell, not me, not leaf, etc.

/be
So, I can understand the concern here, but I'm wondering (innocently; not 
defending one practice or another) why there's such an urgency to remove this 
code.  I just looked at it, and all it is is us creating a native textfield on 
Windows and placing the url in it.  The situation would seemingly be exactly 
the same if Mozilla used native widgets...

Of course, I'd rather we didn't do this extra (and unnecessary) work in Mozilla 
if we didn't have to (or, if we did, an XP approach to this), but I'm not quite 
going insane over it...after all, there's nothing inherently "evil" about it in 
the Mozilla tree, right?
I agree with blake, but the fact of the matter is that we should not have any 
hooks that are designed for 'spying'. We should remove the relivant line 
from navigator.js, but in the event that this doesn't happen soon, I think 
that navigator.js and the other relivant files should just be deleted and let 
the tree burn until someone fixes it!

This is an example of why r=, a= and sr= are the law now!
Group: netscapeconfidential?
Group: netscapeconfidential?
> Phil, ... did someone discuss with mozilla staff? 

Not that I recall. I understand why folks think this is interesting -- maybe we
could pref it out for people who aren't running MMX's client-side
stats-gathering software? Once you're running native code on the user's machine,
this native edit box is really the least of your spying worries. There must be
1000 ways to spy on web traffic once you can do that. Thus, I don't see a
compelling need to move it into the commercial tree.

Bill, hope I'm not forgetting a deal we made -- let me know if I am.

If this code should stay in the open source, then open the bug that asked for
it.  If you can't open the bug, then move the source to the netscape.com
commercial tree.  Tell me why it isn't as simple as that?  Should we have
similar closed-bugsystem reports for ad-hoc "spying" hacks in the open source
for every company involved in mozilla.org?  That's no way to coordinate open
source development.

This is not a stop-the-world-and-fix-it priority, and I never said otherwise --
from this bug's activity, it's clear that we've been patiently waiting for
someone who was involved in the closed bug to stand up and answer for this code.
 So far, all I hear is "not me" (then who?) and "maybe it's not as XP as it
could be" (hah!), and "it's easy to hack Mozilla to spy" (duh!).  That's not
good enough.

We (staff@mozilla.org) are finally (months after bugscape was set up inside
netscape.com, years after the Netscape commercial tree was created) trying to
take an open-source-means-open-bug approach, and reduce the tolerance for closed
bugs and the mystery-source they spawn.  Don't ignore us.

/be
I see 2 separate issues here.

1.  If the code is in the mozilla tree, then there should be a bugzilla bug
describing what the patch is, etc.  I agree here.

2.  Assuming there was a bugzilla bug with the appropriate info in it, would we
want this code in the Mozilla tree?  I don't see this as quite as clear-cut as
many seem to believe.  

I believe this code is necessary for Media Metrix to tell how many people are
using Mozilla based browsers.  As someone asserted below, maybe this is
completely "evil."  But, if Mozilla distributions don't show up on the generally
accepted rader as having enough market share, then Mozilla will have a very hard
time maintaining its viability as an alternative to those browser(s) that do
show up as having significant market share.    

If we're to discuss whether or not market share is important, let's do it
elsewhere and not in this bug.  Here I only note that if market share is
important, there will need to be some way to demonstrate it.  Currently, Media
Matrix is the indicator in the commercial world, evil or not.

One question is:  might we put this in the Mozilla tree, turn it off by default,
and then let those who are willing to deal with the monitoring potential allowed
by this native code in order to promote Mozilla viability turn it on?  Or find
some other way where those who want to usethis code in order to be counted as
using Mozilla can do so?

Mitchell


> 1.  If the code is in the mozilla tree, then there should be a bugzilla bug
> describing what the patch is, etc.  I agree here.

As I described this morning, I don't agree with that. Making good changes in the
public code for proprietary reasons is necessary for some of the contributions
we (layout, toolkit, embedding, memory/performance) make.

> maybe this [Media Metrix-friendly code] is completely "evil."

I don't agree with that either. Plenty of applications use native Windows
controls, and they're just as vulnerable to spying as we are. Once you can run
native code, you can spy. Mozilla is no more or less monitor-able with this code.

As I said in the meeting this morning, I'm fine with making bug 36658 public,
and marketing is pursuing permission to do that.

Phil, what *exactly* do you not agree with:

> > 1.  If the code is in the mozilla tree, then there should be a bugzilla bug
> > describing what the patch is, etc.  I agree here.
> 
> As I described this morning, I don't agree with that. Making good changes in
> the public code for proprietary reasons is necessary for some of the
> contributions we (layout, toolkit, embedding, memory/performance) make.

If a change is made with no open bug, no rationale, no discussion, no ownership
(where are the owners of this code?  law disowns it), and too few comments in
the code itself, what is it doing in the open source?  You have a commercial
tree.  This is not a case where you need a "hook" for non-MPL/NPL'd code.  Any
hooks can be discussed, designed, doc'd in open bugs and newsgroup threads. 
That's a straw man (I set it up, because otherwise I don't understand what you
mean here).

So what do you mean?  Any random, cryptic change with a closed bug can be made
in the open source?  Only those that help measure market share?  Or what?

I'm glad the bug may be opened, but that doesn't answer my question.

/be
I've noted to Phil in a separate discussion that we don't want confidential info
in Bugzilla.  We don't want the details of who wants a bug fixed and why;
Bugscape is perfect for that.

We do want the technical details of the code itself to be in Bugzilla.  What
it's supposed to do, etc.  

I'll work on this

mitchell
Let me clalrify some of my statements:

> Monitoring *is* evil.

I assumed that "monitoring" = sending each visited url to a central site.

> Could somebody please open bug 36658?

I assumed that Netscape had Bugsplat already, when that bug was filed. I might
well have been wrong.

Mitchell,
> We don't want the details of who wants a bug fixed and why;
> Bugscape is perfect for that.
> We do want the technical details of the code itself to be in Bugzilla.  What
> it's supposed to do, etc.  

In this case, the technical details are "This code copies the content of the
urlbar to a native widget" (or so I understood). That's not too useful. Not
useful enough IMO.
If I remove it, does anything break for me? If I can remove it, why do I run
that code?
I've made contact with MediaMetrix and they are going to take a look at the
content of bug 36658 in order to determine whether or not it contains any
information they would be opposed to sharing.  Will update once I hear back from
them one way or the other.
I don't disown the code.  I just disown this bug.

> 1.  If the code is in the mozilla tree, then there should be a bugzilla bug
> describing what the patch is, etc.

How about bug 71270: "all it is is us creating a native textfield on Windows and
placing the url in it."  And if you wonder why: "This enables Media Metrix to
monitor use of Mozilla and thus give us some 'browser market share.'"

Bug 56122 provides additional background info: "This is a must-fix for RTM to
enable Mozilla and Netscape 6 to have their market share tracked."

Then there's the code itself
(http://lxr.mozilla.org/seamonkey/source/xpfe/browser/resources/content/navigator.js#1211):
// Posts the currently displayed url to a native widget so third-party apps
// can observe it.

Damn, probably nobody would have ever caught us if we hadn't left that in there.

We're talking about all of 6, yes 6, lines of code.  Am I to understand that
Mozilla's code base is subject to a higher description-to-code ratio than this?
 If there were no ill-informed, paranoid, conspiracy-theory rants about this
little bit of trivial code, then there wouldn't be an issue.

The code has no comments because that's the way I got it and since no other
Mozilla code seems to need comments, I didn't feel the need to add any to this.
 The one line of code I added does have a comment (the line cited above) and
that one line of comment documents the whole thing better than most of the rest
of Mozilla is documented.

BTW, bug 36658 doesn't say anything beyond what's already been said here.  It
doesn't say *anything* about the code!

One technical note:  As it stands, this "feature" cannot simply be picked up and
dropped into the Netscape commercial tree.  It requires that a load event
listener be added to the browser content area.  That is done in navigator.js and
that file is in the Mozilla tree.  There likely is now a way to accomplish that
via some commercial tree xul overlay trick, but that requires some work.

> 2.  Assuming there was a bugzilla bug with the appropriate info in it, would
> we want this code in the Mozilla tree?  I don't see this as quite as clear-cut
> as many seem to believe.

I'm certainly not in the clear-cut camp, either.

But I think that discussion should occur before we yank this code back out.  I
had been lead to believe that that discussion took place last year.  While I
perhaps erred in not getting a signed and witnessed affidavit to that effect
back then, there's no way I'm going to make the same mistake again.

I still don't see the use of media matrix. Can't webmasters determine market
share a lot more accurately by looking at their server log files. This can only
show market share on the windows platform and neglects the other platforms in
common use.
Also how does looking at the URL's visited determine market share? Wouldn't
looking to see whether iexplore.exe, mozilla.exe, netscape.exe are running and
for how long be as good a way to determine what browsers people are using.

Actually I don't care if this is left in the code because native widget apps
would have this 'feature' automatically, but I still think the reason for having
it is pointless but as long as there's no slowdown with the code being there
then I see no problem with leaving it in.

If we want any of this 'spyware' functionality I'd have rather seen something to
fix bug 58744 where the URL's clicked on are broadcast to help download managers.

I suppose this just reaffirms windows as the number one platform to be spied on!
SPAM: Enabling a central organization (MediaMatrix) to track every url every
user visits is something we should avoid at all costs (i know we can't prevent
it, but let's not enable it). There must be a better way to report what browser
is being used and enable Download Managers. I (a user) DO care very much if this
is in the code. You should seriously consider the subjective impact on the users
if this becomes public. Imagine the headline: *Mozilla has built-in Spyware*.

Caving-in because "it's possible to spy anyways" is the wrong way. We must swim
against this tide, not with it.

I am even going to sacrifice one of my valuable (10) votes for this !!!
From what I understood, the Media Metrix software is a voluntary thing. You
install it yourself. It is similar to researches into what people watch on
television, where they ask people to write down what they've watched, how long
they watched, etc. etc., except with computers all you have to do is install the
software and it takes care of most of the work (if made possible).

I imagine the data they are gathering is:
- Which browser(s) are you using
- Which sites did you visit
- How long did you stay at a page [0]
- How long did you stay at a site [0]

[0] perhaps based on time between page loads, I'm sure they've come up with
something clever.

And probably data you've filled out on some application form, e.g. age, gender,
the usual demographical stuff.

So, for Netscape to show up in those statistics (a good thing!), they have to
provide a way to be measurable by the Media Metrix software. Apparently, the
easiest way was to create a native textbox and update that.

Mozilla.org will have to decide whether they want Mozilla to be measurable or
not, though it sounds like they weren't really given an option (correct me if
I'm wrong here).

More importantly, it is not trivial for other browsers based on Mozilla to
enable or disable this feature, nor do I think it's clear what impact any
changes they make (or don't make) have on this feature. I could imagine the
Browser being determined from the user agent string, or perhaps from the
executable name, or ..., the point is, I don't know, and thus can't influence it
(hi Beonex).

Another main concern I have is whether this is the best way to implement this
feature. Like Bill Law suspected above, this code can indeed be moved into a
dynamic xul overlay, which could then only be installed on Windows, and put
behind a build-time enable/disable switch. This allows any Mozilla based browser
to make the choice themself. And is communication through a (native) textbox the
best way, as opposed to directly communicating with the software?

Media Metrix (and others?) could for example, upon installation, drop a
component or plugin in the browser directory, though I guess that would mean
that anyone who runs a new nightly daily would need to re-install said
component/plugin, making that option less feasible for them than having it built
into the browser.
George Ziegler of MediaMetrix has reviewed the content of bug 36658 and given
the okay to remove the Netscape Confidential designation.  Can someone go ahead
and do that?
done
A number of comments here imply that Media Metrix measure browser market share.
Looking at their web site I can't find anything about browser market share,
rather they seem to measure web site market share. If they don't measure browser
market share then I don't see any benefit to having this code in the Mozilla tree.
As someone said, it seems that MediaMetrix measure website popularity, not 
browser usage. Therefore, there is no benefit to Mozilla from having this code 
included.

Surely the most sensible thing to do would be for the MediaMetrix client to have 
an XPI with this in (using funky overlay tricks, and stuff.) If they, as a 
commercial company, see a need to interface with Mozilla-based code then we have 
given them the ability to do so. In this way, we can just back it out and leave 
them to sort it out for themselves.

Similarly, if Netscape wish to establish a relationship with MediaMetrix to have 
this ship by default in Netscape 6, again, they are perfectly within their 
rights to do so. In this case, Netscape management have to find engineering 
resource to integrate the code with Netscape's product.

Gerv
To make the *intent* of this bug more clear, please change the subject line to: 

<shaver> "Netscape Spyware should be in commercial tree" (and NOT in Mozilla Tree)
Having the URL in a native field would be useful for other 3rd party apps such 
as download managers.
I find it hilarious that a large proportion of those arguing against this code
are also arguing that we should use native widgets instead of XUL.
See also..

bug 31343 [RFE] Provide current URL and title to ICQ like NC4.x did 
bug 58744 3rd party download managers not supported  (already mentioned)
I for one have no problem with this code if it has other, useful (from users'
points of view) uses. It just seemed that there was a perception that it would
help Mozilla because MediaMetrix used it for browser market share research,
which doesn't seem to be the case.
I find it a little strange that we still do not support download managers (bug
58744)  while we support more or less useless marketing software. Don't we have
our priorities wrong?
We support features because someone spends time to implement them and donate 
the code to us.  If you donate code for download manager support, I or someone 
else CC to this bug will gladly work to get it into mozilla.
> As someone said, it seems that MediaMetrix measure website popularity, not 
> browser usage.

I don't know how important a point this is, but that's a false statement. MMXI
certainly tracks browser usage. Not sure if this particular code is required to
do so. Seems possible that it isn't.

As this isn't spyware because the same feature comes as standard in Netscape,
IE, Opera and any other browser that uses native widgets perhaps we should
change the summary to something less alarmist.

This bug is still very valid because people could argue that because we don't
use native widgets we might as well make use of the extra privacy this brings
and market mozilla as the best privacy browser on the Windows platform.

However if you want to support the likes of download managers, you open up the
browser to spyware immediately. I've heard people suggest that this bug *and*
bug 58744 should be fixed. That is just crazy. Fixing bug 58744 just opens up
the browser to spyware as much (possibly even more so) than this one. If we
decide that fixing bug 58744 is the way to go this must be a WONTFIX and vice
versa. If we decide to make it possible for mozilla to share data with other
apps we might as well make it as simple as possible for the legitimate programs.
Evil spyware will always find a way to spy if one exists (so there's no point
filling one hole then opening another) but some legitimate software companies
may decide they can't afford to support Netscape 6.5/Mozilla if their software
can't interact with the browser how they expect.

Basically I don't care which way this bug goes because leaving it as is doesn't
make the browser worse than any other browser on the windows platform and the
potential to spy has to be increased (but still no more than any other browser)
to support 3rd party download managers using the conventional methods. If you're
really worried about spyware you should be running an open source operating
system and only install open source software that has been checked be reputable
sources. I use Windows 2000 but I'd never do something on such a system which I
regarded as confidential, however I don't consider my daily browsing habits to
have any need to be confidential. So what if someone gathers some stats on how
long I've been at a particular site?
 
So you've gotta choice, you can have the convenience of download managers, but
open your browser upto the same spying capabilities as other windows browsers or
you can have mozilla as the browser of choice for people who value their privacy.

I don't know how easy this would be to make it prefable and how would the pref
be worded? I think the best way maybe to make this a compile time option -
distributors could then choose whether they want these features (including the
click monitoring in bug 58744) enabled which would probably be the default in
Netscape and for more privacy concious distributions (e.g. Beonex) then they
could compile with them disabled.
A user selectable pref is far better that a compile-time option because it
leaves the choice to the users. Distributers can then set the default to what
they feel they prefer.

There must be a way for mozilla to support download managers without enabling
this awful feature (I *DO* value my online privacy - where possible) ;)
Whiteboard: In order for this to be spyware, you have to install a spy
The really bad thing about this issue is not how the technical side
works, but the way it was sneaked in to the code, according to the
discussion above. It is things like this which can really hurt a
company's reputation (I'm counting both Netscape and mozilla.org as
companies here) once the word gets out and most people don't
understand the technical issues in enough depth to assess the risks or
benefits. Every time an issue like this comes up one immediately
starts wondering how many cuckoo eggs may still be hidden in the code
base (which everyone knows is just too big to review properly).
Comments like "probably nobody would have ever caught us if we hadn't
left that in there" don't exactly increase confidence, either.

This must be fixed in some way, not because it's a bad or dangerous
software bug but because it's a bad and dangerous P.R. bug. It
wouldn't be half as much fuss if both Netscape and Media Metrix had
been openly and honestly describing what they do and want from the
very beginning.

As for the technical side, this bug should be marked INVALID because:
- the spy property depends on other software which is installed by the
  user at his own discretion, i.e. this is an opt-in case (at least
  this is how I understand it - the Media Metrix client is _not_
  distributed by Netscape along with the browser, right?)
- an application running under any one user ID can read data from
  other applications under the same user ID anyway, no matter which
  OS. Really malicious code would be stopped by removing the easy way
  for a few days only. (In fact a spy program to report visited URLs
  would be dead easy, just copy over history.dat. We're talking about
  installed applications, not applets or scripts.)

For pure (psychological) damage containment reasons I would also
remove the widget too. If this makes it more difficult for Netscape to
add their stuff it's completely their fault. Whether this affects the
download manager issue too is a question of the hooks/protocols used
for the download manager (not being a Windows guy I don't know these).
Recent comments in bug 58744 indicate this is not that bad at all.

Let's not get all overly "technical" about this being a wontfix because the
"spyware" is not in the code.

In my oppinion, the code is a "part" of a larger "spyware" superprogram, all
acting together to allow spying on a user's browsing habits.

If you really want to be "correct" then rename the subject line slightly, but
definetely do not mark this bug as wontfix, because it contains too much
valuable information to be lost in the pile of ignored and forgotten bugs.

This is a PR nightmare. Remove the code, please.
Changing summary. Is it such a big deal now?
Summary: <shaver> "Netscape spyware should be in commercial tree" → Browser stores the current URL in a hidden native widget
Yes it is a big deal. Summary should at least read:

*Browser stores the current URL in a hidden native widget, which is readable by
non-Mozilla programs (e.g. "spyware")*
Well the status whiteboard says it all really :) Having the word spyware in the
subject is just asking for trouble.

Do we want mozilla getting bad press because people assume this is a bad thing,
despite the fact that almost all windows apps use native widgets and are
vulnerable to spyware. All it takes would be a clueless journalist to search
bugzilla for spyware and blow this out of all proportion.

Not spyware but a good example of clueless journalism:
http://www.jwz.org/gruntle/blowme.html
(this is regarding the about: easter eggs)
yes, please remove that code ! (or add a pref with default setting OFF)
No matter how do you call it !

The User ist already controlled with serveral different things.
(Banner-ad [referer], cookies, ...).
This is already enough !
Mozilla should not active support something like this.
PLEASE don´t let the users loose the trust to mozilla !
Mozilla have an excellent Image/cookie blocking and then you put this in the 
mozilla code.
If NS do this - ok, but not mozilla !


How should we decide on that, considering that there are many opinons which
reach into political areas (is producing weapons evil or just the misuse of
them?)? Continue to discuss? Vote? here? Newsgroups? Let mozilla.org (brendan,
shaver, scc etc.) decide?

I suggest, we set up voting bugs as we had them for the default theme. Someone
with the ability to write unbiased despite his own options then writes a summary
of the facts as we know them by now and posts it to .security.

(Personally, the fact that it is opt-in changed my opinion a lot.)

I am assuming that Netscape can use overlays or similar, so it is not a major
technical problem for it to keep the current functionality in the commercial
tree. If I'm wrong, please say so.
Matti, Peter: How do you want us to support 3rd party download managers and 
programs like ICQ if we remove the hidden native widget?
ALL other possibilities for supporting download managers should be explored
first, while always keeping in mind that a person's privacy and personal freedom
are far more important than a software feature (dload mngr). 

What if Mozilla had its OWN Download Manager that only monitored clicks for THAT
purpose and never revealed URL's to other modules or outside Mozilla itself?

Only if all avenues prove undoable, should we connsider storing the current URL
in a hidden native widget.

Should that be the only (or by FAR the most economical) way, I would strongly
suggest that Mozilla have code that tests the OS or whatever for installed
"spyware" and inform the user ("spyware detected, do you want to activate the
doawnload manager features and potentially expose your browsing habits to the
internet" - YES/NO). If it come this far, I hope that this is possible.
Hixie: Make a pref for that with a security warning.

Please correct me if I'm wrong, but isn't the assertion that this code is
necessary to support download managers false? A download manager only needs the
URL of a link to be downloaded and possibly the URL of the refering page. Surely
an interface can be developed which communicates this info without exposing
every URL visited.

I realise this isn't the bug for this, but personally I'd like to see download
managers supported via the "Helper Applications" preferences item. Have a
setting which allows the user to specify a download manager to use (either
external or Mozilla's built in downloader) and then any MIME type set to "Save
to Disk" would use the download manager. Similarly the context menu item "Save
link as ..." should call the download manager. No more need for any support for
applications to snoop the current URL.
Even a simple right-click - "copy link..." (or "save as", or whatever) could
bring up a dialoge box: Copy link to clipboard or copy link to download manager XYZ.

I am seeing less and less need for this "spyware-enabler" code. Out with it :)
This can/should be done like in Galeon: there is a user pref how to do "save to
disk", either via the internal mechanism or via invoking gtm (a download manager).
gtm does this via CORBA, surely there is a similar mechanism in Windows.
What´s with this bug ?
Please ignore the user wish and close this bug or get this stuff out.
Isn't this bug getting a bit off course?  The main issue from my point of view
is that someone hauled off and checked code into the Mozilla tree without
consulting mozilla.org and without getting r/sr/a from same.
The code is old. Back then, the checkin rules were different.
Did I understand it correctly that this code does nothing but make it somewhat
easier for some strange software from Mediamatrix to do what it does?
Why is it so important for Mozilla to support Mediamatrix? Is Netscape in some
way affiliated with them? I don't think so.

As for ICQ, this code does _not_ allow ICQ to get the current page's URL. It
would, in theory, allow ICQ to do it, but ICQ doesn't use this feature.
In no case would it allow it to get the title of the page.

Download managers are UNAFFECTED by this, as I understand it.
The current URL is of no use to download managers.
They want to get the URL of links you follow, before Mozilla loads it, as the
download manager should load it.
The URL of downloadable files is likely to be never in the location bar, so it
won't be in this widget either, am I wrong here?
IMHO, this code is nothing but bloat and should be removed.
I'll repeat my April 24 comment:

> I find it a little strange that we still do not support download managers 
> (bug 58744)  while we support more or less useless marketing software. 
> Don't we have our priorities wrong?

I believe it is still valid.


Jacek, the priorities are sat by the entities who contribute code to Mozilla. To
great parts, this is Netscape. If MediaMatrix is of larger importance to
Netscape than Download Managers, that's thier thing.

As for the motivation: I think, it is more the website statistics than the
browser statistics, which are interesting about MediaMatrix. A prgram that runs
on a few platforms only and has to hardcode support for each browser is
inadequate to measure browser market share, because it will always miss the
smaller ones (unlike server logs). But it is a far better for measuring the
market share of websites, which cannot be infered from server logs. So, I think
that the real motivation was to "get a market share" for the website
netscape.com, not the browser Netscape. (And of course, it is then important to
make the Netscape browser, which accesses netscape.com over-proportionally, to
support this statistics-gathering.) Consequently, I don't see how MediaMatrix
could help Mozilla (and its deratives, apart from Netscape) "get some market
share" as suggested by Bill Law (and Eric Krock in the other bug).

I agree that this bug is not really scaring, for the reasons Phil Peterson
mentioned 2001-04-10 12:00.

If there were some volunteer (with checkin rights) which wants to remove the
code, would he be allowed to do that?

There is some hookup in navigator.js, which could be a problem for Netscape to
re-add, given they way they build. I would find it acceptable to leave that
little code fragment in and just fail without error, if the spy-XPCOM-component
is not installed.
I still see no reason for this code to sit in the Mozilla trunk. Sorry.
There is *no good reason* to uneccessarily (i.e., unavoidably) let strangers
know where we are browsing and what browser we are using. Period. At a *minimum,
there should be a pref: "Let Mozilla help broadcast every place you browse to to
a company you don't know."

> Mozilla is no more or less monitor-able with this code. (Phil Peterson
2001-04-10 12:00)
Oh really, then why do we have it in the first place? Out with it, or loose my
trust and gain my wrath! I will make sure this becomes public!
I dont think you understand: this code will be effective only if you choose to 
to install the Media Metrix software to measure your usage. You would do this 
only if you chose to participate in a tracking activity (similar to some 
families choose to participate in Nielsen's rating measurements). This code is 
not generally of any consequence in a normal mozilla or netscape installation. 
Hope this helps ... 
I'm not entirely sure why there's all the hoopla over this bug.  It looks to me 
(correct me if I'm wrong) that all this does is makes it somewhat easier for a 
*legitimate* 3rd-party program to send back URLs.  Could an illegitimate 
program make use of this to send back your URLs?  Yes.  Could an illegitimate 
program scoop up your session history, your passwords, and your favorite pr0n 
stash, and send them to sixty random people and the CIA?  Yes.  That's a 
Windows problem, not a Mozilla problem, and if you don't want it happening, 
install Zonealarm and carefully vet any executables you run on your system.  
Will we next demand that the addressbook be forbidden to export data, 
because "spyware" could grab the file and send personal information to someone 
else?  I can appreciate that people would be angry when the relevant bug was 
confidential, etc., but now that we know what's going on, all the melodramatic 
Steve Gibson imitations seem uncalled for.  My $.02...
Wow, what a bug.  Leave the code in.  It can be used for good or evil, but only
"evil" if you choose to do so.  Where's the problem?
Several marketing data collecting programs installed stealthly with shareware
versions of download managers (and probably other software). The user may not be
aware he has spyware installed. 

Changing the status whiteboard accordingly.
Whiteboard: In order for this to be spyware, you have to install a spy → In order for this to be spyware, you have to install a spy. Caveat: You may not know you install it.
What's the status of this bug? After we don't have to care about Netscape
anymore, do we still need this tracking widget?
Product: Core → Mozilla Application Suite
Assignee: tpringle → jag
QA Contact: shaver
No file *nsIURLWidget* exists in mozilla-central or comm-central (SeaMonkey) anymore.
FIXED by unknown person
Assignee: jag → nobody
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
No audit trail for QA. The fix is unknown.
Resolution: FIXED → WORKSFORME
You need to log in before you can comment on or make changes to this bug.