93630 - Remove What's Related? from build until bug 53239 is fixed

Status: VERIFIED WONTFIX

(SeaMonkey :: Build Config, defect, P2)

Description

[Henri Sivonen (:hsivonen)]

The What's Related? panel sends the URL the user visits to a third party--in
some cases in situation where the user doesn't expect it and without his/her conset.

IMO, mozilla.org shouldn't be distributing builds with this defect in place. The
bug for fixing the issue itself (bug 53239) has been futured. I suggest the
offending panel be removed from the build until it is fixed.

Comment 1

[Henri Sivonen (:hsivonen)]

Nominating for Mozilla 0.9.4.

Comment 2

[cls]

After reading thru bug 53239, I'm in complete agreement that "What's Related?"
should be removed from the build if the privacy issue will not be addressed. 
The workaround described in bug 53239 (remove the panel) assumes that you know
there's a reason to reomve the panel.  As it's on by default (I don't remember
adding it as I never use the sidebar), this problem will affect the majority of
the users....the ones who never change their default settings.

Comment 3

[Peter Lairo]

This should be a no-brainer. Mozilla should never allow privacy violation issues
like this to even come up in the first place - turn it off by default ASAP!

It is NOBODIES business where the user surfs. Not telling them that ALL urls
they visit are being reported to a 3rd party is a DISGRACE to this project.

Comment 4

[Viswanath Ramachandran]

Please be sure to get r= from Ben (Nav UI owner) on this bug. 

Comment 5

[Henri Sivonen (:hsivonen)]

How can this depend on bug 53239?

Comment 6

[cls]

Attachment: Remove "What's related?" from win32 & linux builds + chrome

Comment 7

[cls]

Attachment: updated patch that removes more of the chrome references to related

Comment 8

[Ben Goodger (use ben at mozilla dot org for email)]

sr=[e-mail]

Comment 9

[Ben Bucksch (:BenB)]

cls, I suggest you remove it only from the the rdf files. (Doesn't it appear in
profile/defaults/localstore.rdf, too?) This stands a smaller chance for a
regression. People will still be able to get it, if they know what they do and
specify the url of the panel directly.

Comment 10

[Jason Kersey]

This is insane.  This is a popular feature, and the privacy concern can be 
addressed by simply not having what's related in the list of default mozilla 
panels actually in the sidebar.  Removing the whole panel is wrong, and is not 
the way to address this.

Comment 11

[Ben Bucksch (:BenB)]

Attachment: Alternative fix. Removes the panel from all UI, but not the build

Comment 12

[Ben Bucksch (:BenB)]

The patch I attached removed the panle from the default panels and the Add
Panels dialog, so an innocent tester won't add it without knowing the
consequences. You (Asa!) should still be able to readd the panel to your sidebar
by clicking the following link:

<a href="javascript:window.sidebar.addPanel('Whats Related?',
'chrome://communicator/content/related/related-panel.xul', '');">Add What's
Related to your sidebar</a><br>
Note: There is <a href="http://bugzilla.mozilla.org/show_bug.cgi?id=53239">a
privacy bug</a>!

Comment 13

[Henri Sivonen (:hsivonen)]

Ben Bucksch, Wouldn't removing from RDF only mean that anyone who has created
their profile under an old build would still be vulnerable? If so, I don't think
removing from RDF is good enough.

Jason Kersey, Removing the sidebar until the privacy bug is fixed is a perfectly
valid way to address this. The bug about fixing the problem itself has been open
a long time and there is no reason to believe it will be fixed anytime soon.
Until someone really fixes the panel, it is a Bad Thing to distribute builds
with the bug in place.

Comment 14

[Jesse Ruderman]

Bug 53239 would be easier to fix than this bug, and it wouldn't have to be 
backed out in the future like this one would.  Sabotaging a feature just 
because it has a bug that annoys some people is not cool.

There are more constructive ways to get 53239 fixed faster than threatening to 
remove the What's Related feature.  These include:
- voting for 53239.
- providing helpful comments in 53239 (eg "This [does/does not] happen in 
Netscape 6.1, [and/but] I think this is important to fix").
- providing a patch or coding hints (eg lxr links) in 53239.
- attempting to escalate 53239 through the people responsible for privacy in 
Mozilla.

Comment 15

[Henri Sivonen (:hsivonen)]

>Bug 53239 would be easier to fix than this bug, 

So why wasn't it fixed 11 months ago?

>and it wouldn't have to be backed out in the future like this one would.

Why wasn't the What's Related sidebar panel itself backed out? If I had CVS
access and checked in a feature with that kind of bug, would my changes get
backed out immediately and not checked back in until I fixed my code?

> - voting for 53239.

Yeah, right. That's not going to help.

> - providing helpful comments in 53239

It has been pretty clear from the comments that it is important to fix, but it
hasn't been fixed, because it is believed to not affect Netscape's commercial
builds.

> - attempting to escalate 53239 through the people responsible for
> privacy in Mozilla.


What one should do to escalate it?

Comment 16

[cls]

> Bug 53239 would be easier to fix than this bug, and it wouldn't have to be 
> backed out in the future like this one would.  Sabotaging a feature just 
> because it has a bug that annoys some people is not cool.

A privacy issue is not equivalent to an "annoying bug".  It is a serious issue.
 Bug 53239 clearly indicated that the privacy issue was *not* going to be
addressed by the person responsible for that bug.  So I'm addressing it as it
became a build issue.  

Comment 17

[Ben Bucksch (:BenB)]

> Sabotaging a feature just because it has a bug that annoys some people is not
> cool.

If there is a security/privacy bug in a feature, and the person responsible
refuses to address it in a timely manner (and noone else volunteers to fix it),
removing the feature is the only way to go that is left. IMO, that resolution is
employed way too rarely in Mozilla,

> Wouldn't removing from RDF only mean that anyone who has created their
> profile under an old build would still be vulnerable? If so, I don't think
> removing from RDF is good enough.

Right. Any ideas how we can automatically remove the panel from the existing
profiles?

Comment 18

[timeless]

I hope i don't have to point out that automatically removing somethign which a 
user manully configured or selected is an abuse of trust.  If microsoft one day 
decided to remove my recylce bin, i'd be upset.

Comment 19

[cls]

Timeless: If Microsoft's recycling bin was sending info to them without my
knowledge, I wouldn't miss it if they removed it.  Let's keep the proper context
here.

Blake: what's the progress on the "quick fix" that you were proposing?

Comment 20

[matt]

fix is in 53239

Comment 21

[Jon Granrose]

can we move this to 0.9.5 then or close this wontfix?

Comment 22

[cls]

Marking WONTFIX now that matt's fix for 53239 is in.

Comment 23

[Jon Granrose]

verified