53239 - What's Related surfing when it is collapsed - privacy issue

Status: VERIFIED FIXED

(SeaMonkey :: Sidebar, defect, P1)

Description

[Kathleen :Brade]

with a build today (on Mac), I see the dialog for xslt.alexa.com not being found 
as I surf (many times).  This really affects my ability to use the product since 
the dialog pops up right on top of the current front window (which might be 
mail).

My sidebar is closed so why is my browser trying to contact alexa.com?

Comment 1

[Axel Hecht]

Hi Kathleen,
this is unrelated to xslt, despite the host name, the page is referenced in 
xpfe/components/related/ressources/related-panel.js.
Moving to component sidebar, reassigning to owner sidebar.

Axel

Comment 2

[johng]

nav triage team:
Under no circumstances should the What's Related tab (or any other sidebar tab) 
make server requests when closed.  In the What's Related case, this is a privacy 
issue.

nsbeta3+, P1, recommend dogfood-, adding keyword regression

reassigning to pchen per don.  See other related bug 46736, might be a 
regression of that bug.

Comment 3

[Jim Roskind]

johng: You say this absoultely should not be allowed to happen... but don't 
explain why this is not dogfood.  Please give a reason to mark this minus, as it 
sure seems painful to surf if this dialog popped up endlessly :-(.
Marking dogfood-plus for now... but please remove if this is easy to avoid.

Comment 4

[Phil Peterson]

PDT agrees P1

Comment 5

[Jacob Kjome]

I completely agree.  This can't happen.  Actually, there seem to be 2 issues 
here:

1. The sidebar tab should not be making queries when closed

2. No error in the sidebar should interupt normal browser usage (especially not 
poping up dialogue windows constantly).  There is no reason to bother a user 
about something that they haven't actually initiated themselves.

BTW, someone might want to change the platform to "all", since this is 
happening to me on Win2k on a PC and the only platform listed currently is  
Macintosh.

Jake

Comment 6

[Ari Pollak]

*** Bug 53955 has been marked as a duplicate of this bug. ***

Comment 7

[Paul Chen]

My mac ns6 build from this morning isn't popping up a dialog, thank goodness. I
will try nightly build.

Comment 8

[Ben Bucksch (:BenB)]

platform -> all per previous comments.

what a luck that this annoying dialog popped up, or we might have missed this
privacy invasion.

Comment 9

[don]

This is bad, but let's deal with it in the RTM timeframe.

Comment 10

[don]

Even though this is a P1, I'm making this "RTM NEED INFO" because so far
engineering can't reproduce the bug.

Comment 11

[johng]

it is a legal requirement that the What's Related tab does *not* ping the server
when it is closed or when the Sidebar is closed.

QA - please verify.

Comment 12

[shrirang khanzode]

Tried to reproduce this problem on all branch builds for today but am unable to 
do so.:(

Comment 13

[shrirang khanzode]

ok..finally got this message( the one kathy has mentioned) to appear on windows 
(god knows how)...but I see it on windows build 2000092908.

Comment 14

[don]

Crap!  OK ... Paul, have you been able to reproduce this?

Comment 15

[Paul Chen]

I'm still waiting for a reproducible case

Comment 16

[Ben Bucksch (:BenB)]

qawanted

Comment 17

[johng]

nav triage team:
Does this problem still occur (but with a different URL) after Matt checks in
his fix in bugscape 2792?  Reassigning to Matt.  If the problem no longer
exists, can close this bug.

Changing subject from:
constantly see dialog for xslt.alexa.com not found as I surf

to:
What's Related surfing when it is closed - privacy issue

Comment 18

[Kathleen :Brade]

ok, here's how developers can reproduce the problem I have seen:
 * go into related-panel.js and change the alexa url to be something like:
      xslt.alexafoobar.com
   [our goal is to simulate when the server is down; a bad url should be 
sufficient for that]
 * rebuild your jar files if you need to
 * open your browser window to a url
 * make sure that your sidebar is not completely hidden (collapsed or open is 
needed to reproduce).
 * as you go from site to site, page to page, surfing, you'll get dialogs telling 
you some strange url could not be found.  

cc johng:  to me, this seems like a privacy thing but maybe this is actually 
desirable? (I hope not!)  My parents certainly won't recognize the alexa url that 
appears in the dialog.  Also, the dialog says to "try again" uh.... trying to 
load the url in the urlbar again (of course) will reproduce the same dialog.  
Sounds like a frustrating time for anyone who has the misfortune to be surfing 
when the server is down.

Is there any way to suppress this dialog for this url?

Comment 19

[Mitchell Stoltz (not reading bugmail)]

Since we're including their sidebar by default, has anyone verified that Alexa's
privacy policy is compatible with ours? Do we even have a privacy policy? I
wouldn't be surprised if Alexa is gathering more user data than we at Netscape
would find acceptable.

Comment 20

[Ben Bucksch (:BenB)]

For the case somebody doesn't know: ALexa is owned by Amazon (so somebody said
in another bug), and Amazon is known to sell even data about its very own customers.

Comment 21

[johng]

Note that the commercial build is not shipping with Alexa but with the old
What's Realted service hosted by Netscape (see bugscape 2792).  We put it into
the builds to see if we could make it work, but there were privacy and other
issues (some mentioned above) that we could not quite resolve in time for rtm.
We may (and hope to) bring back the Alexa hosted tab after rtm.

The question is if this bug still exists after we back out the recent code and
use the old What's Related we had in PR1 and PR2.  Keeping this bug open since
it is essential that we verify that this is not a problem.

Comment 22

[Kathleen :Brade]

johng (and any others)-- this bug is *NOT* about alexa or a particular host.
This bug is that the user gets dialogs when the host (be it alexa or netscape or
?) is unreachable.  These dialogs are not helpful but instead are confusing and
would lead a user to wonder what their product (be it NS6, mozilla, or an
embedded app) is doing behind their backs.  I wouldn't trust/use the software
(except I know the mesages refer to the sidebar).

I would envision a safe fix to be something along the lines of not displaying
the dialog if the url is exactly the url used by the sidebar.

A better fix would be to not do any queries when the sidebar is collapsed or
hidden but I'm guessing this is too difficult for this stage or we'd already
have made that not happen.

One last note, I see this bug when I'm in the Search tab or other tabs in the
sidebar.  I wasn't expecting to be doing related links when I wasn't in that tab.

Comment 23

[Ben Bucksch (:BenB)]

brade, I disagree. The bug here are the queries, not the dialog. People *will*
find out what you are doing (at least via tcpdump). If you hide the dialog (the
source is open), you will only look more guilty.

Comment 24

[Kathleen :Brade]

BenB--sorry I wasn't clearer.  I don't think we should be making the queries; 
that is the ideal.  However, if that fix isn't acceptable to PDT, at least we 
should disable the bogus dialogs for that url (and release note that the queries 
are being made).  As for hiding the dialog vs tcpdump, only advanced users will 
be doing tcpdump; average/novice users will see the dialog.  The problem reported 
here came about because the sidebar was collapsed when the server happened to be 
down.  tcpdump will show that the requests are being made whether or not the 
server is down (but the dialogs only appear when the server is down).  I hope 
that makes my position a little clearer (with regards to NS6 branch and mozilla 
trunk).

Comment 25

[johng]

Kathy- the bug you are talking about should be opened as a different bug -
please do so.  The issue that we need to take care of for privacy reasons is the
issue described in the title "What's Related surfing when it is closed - privacy
issue".  This privacy issue is what triaging approved by saying "rtm need info"
and we changed the title to make that clear.

I agree Kathy that the problem you describe is real, but *please* deal with that
in a separate bug because we (Nav triage team) decided to deal with that after
rtm and we need to stay focused on the major issue in this bug (privacy concern).

cc'ing claudius since he is knows something about this issue and might be able
to help shrir QA this - this is an important issue to test.  I think Matt is
checking in the What's Related changes now (so you will see the old UI for
What's Related) - as soon as that happens, we should test this.

Comment 26

[Jason Eager]

This bug should no longer be rtm, since NS6 has gone back to the PR2 "What's
Related" tab.

Comment 27

[Ben Bucksch (:BenB)]

Do we still have the new panel in Mozilla? If so, please fix either bug 50763 or
(frist part of) bug 53571 (I prefer the latter).

Comment 28

[Kathleen :Brade]

for the record, I again saw this dialog on a build yesterday on Linux...

Comment 29

[don]

Matt, is this fixed with your checkin to revert what's related?

Comment 30

[Jaime Rodriguez, Jr.]

John - This needs to get a FIX ASAP, we are running low on QA cycles and time.

Question? - Why is this still marked as "New"? Shouldn't it be Assigned to Matt?

Comment 31

[matt]

Reverting back to the old related panel this should be fixed.

Comment 32

[matt]

Looks like reverting back actually still has this problem.
Once you close that panel you still have what's related firing.
This was the default setting in 4.7 but i'm working on it.

Comment 33

[selmer (gone)]

rtm-, removing the panel from the sidebar is the 6.x way to turn off what's 
related.  As in 4.x, what's related does its thing all the time once it's turned 
on.  If you don't like that, turn it off by removing it from the sidebar.

Despite the fact that some people will complain about this, the feature is 
totally above-board and can easily be disabled.

Comment 34

[Jaime Rodriguez, Jr.]

Adding msanz, danielmc and mcarlson to cc: list.

Linda - How does this affect L10N builds?

Comment 35

[Linda Baliman]

International shares exactly the same privacy issues.  We do exactly as the US 
does with respect to What's Related as a tab vs What's Related being served from 
Netcenter.

Just discovered that the What's Related tab is dead in the latest FR build.

Will file bugscape bug.

Comment 36

[verah (gone)]

This is tagged "relnote-user," and I was about to put it in the release notes.
However, in the online Help I advise people to turn this tab off or remove it if
they don't want the feature to be active. It seems to me that the online help
covers this, then.

Comment 37

[R.K.Aa.]

*** Bug 59987 has been marked as a duplicate of this bug. ***

Comment 38

[Kathleen :Brade]

I still see this bug in NS6 commercial builds from last week.
Since this bug isn't being fixed for NS6 RTM and other bugs are being marked as
a duplicate of this here is how I'd summarize the current state of this bug:

(from [e-mail] 2000-09-21 21:46 entry)
Actually, there seem to be 2 issues here:

1. The sidebar tab should not be making queries when closed

2. No error in the sidebar should interupt normal browser usage (especially not
poping up dialogue windows constantly).  There is no reason to bother a user
about something that they haven't actually initiated themselves.

Comment 39

[Michael Witbrock]

Probably this has occurred to someone else already, but a dandy way of
demonstrating this bug is to simply unplug your network connection and then
browse a server running on localhost (proably browsing local files would work
fine too). That's what I was doing when I filed a duplicate of this bug.

Comment 40

[Matt Behrens]

I did a few things with Moz (2000112020, WinNT) and Ethereal
<http://ethereal.zing.org/> to determine precisely when What's Related is
shuffling off data to Alexa.

1.  If What's Related is unchecked in the Tabs list, Alexa doesn't hear where
I'm going.

2.  If Mozilla is started and the What's Related tab is never selected, Alexa
doesn't hear where I'm going.

3.  If the What's Related tab is selected, Alexa hears where I'm going (expected
-- and correct -- behavior.)

4.  If the What's Related tab is then deselected, Alexa contirnues to hear where
I'm going (bad behavior, should be corrected.)

If there's any other cases folks want me to check out let me know.

Comment 41

[bobj]

Someone should clean up the Status Whiteboard and Keywords to reflect post-6.0
status.  Just to get this on the radar, I changed nsbeta3 to nsbeta1.

Comment 42

[Viswanath Ramachandran]

until what's related is completely spec'ed out for the next release, we will not
implement this. todd shd be working on the what's related specification and
server issues. descheduling from mozilla0.8. 

Comment 43

[shrirang khanzode]

spam : changing qa to sujay (New Sidebar QA)

Comment 44

[Paul Chen]

Marking nsbeta1- to get off the radar. Need to figure out what to do after we
figure out what's going on with What's Related.

Comment 45

[matt]

This bug is specific to mozilla.
Any help would be good.

Comment 46

[matt]

*** Bug 53571 has been marked as a duplicate of this bug. ***

Comment 47

[Paul Chen]

Marking nsbeta1- bugs as future to get off the radar

Comment 48

[selmer (gone)]

Matt, is your comment of 3/13 that this doesn't affect Netscape builds supported
by recent QA efforts?  It directly contradicts your prior statement on 10/25/00
and seems improbable given Matt Behrens comment unless some other checkin has
fixed this.  Please enlighten us :-) 

converting nomination from dogfood to catfood since we already shipped like this
once and removing the panel from the sidebar (as we suggest in our help) fixes
this problem.

Was the bug for the dialog problem ever filed?  This bug is NOT about that problem.

Comment 49

[Viswanath Ramachandran]

nav triage: severity of the problem does not warrant a nsCatFood, suitable 
workaround exists to remove the panel from your list. 

Comment 50

[R.K.Aa.]

*** Bug 78764 has been marked as a duplicate of this bug. ***

Comment 51

[Ben Bucksch (:BenB)]

> suitable workaround exists to remove the panel from your list.

The workaround is non-obvious. Most users won't even notice that something is
wrong (yet their privacy is violated).

Adding relnote, although I don't hink that is sufficient. If you don't fix this
bug in the soon, I'd say 'remove the panel altogether'. (That's what I did in
Beonex Communicator.)

Comment 52

[Boris Zbarsky [:bzbarsky]]

*** Bug 86149 has been marked as a duplicate of this bug. ***

Comment 53

[Peter Lairo]

Why is this bug not fixed yet. Privacy issues should have absolute top priority
(even over crashers).

All that needs to be fixed is Matt Behrens comment #4 from 2000-11-21 07:06: 

"4.  If the What's Related tab is then deselected, Alexa continues to hear where
I'm going (bad behavior, should be corrected.)"

Just fix #4 and we're all out of here. Don't fix #4 and Mozilla is seriously
violating EVERY users right to privacy (tab is ON by default!).

The fact that this is nsbeta1- and nsCatFood- (minus!!!) is a disgrace to
Netscape. The fact that this is TM: "Future" is a disgrace to Mozilla.

Comment 54

[Niko Pavlicek]

could there be other problems with other (hypothetical) sidebar tabs caused by
this issue?

Comment 55

[Jesse Ruderman]

See also bug 91168, Search sidebar compiles result list (eating CPU time) even 
when panel is not visible.

Comment 56

[timeless]

Attachment: do nothing.

Comment 57

[matt]

what is happening is that xul sidebar panels after being open don't get closed 
when you collapse the window.  Only when you hide the sidebar

Comment 58

[Kathleen :Brade]

Can we get rid of the "if"?  The "isSandboxed" call will never be executed.

Comment 59

[matt]

Attachment: patch to sideOverlay.js

Comment 60

[matt]

patch posted so that chrome urls don't say open.
Need r and sr and some one to check this sucker in since i'm not going to be
able to.  Oh ya need a A= also.

Comment 61

[cls]

Ok, I verified with tcpdump that attachment 46945 [details] [diff] [review] mostly fixes the problem.  
With the sidebar open and the What's Related tab on the sidebar (default
setting) but with a different tab selected, I no longer see screenfuls of
alexa.com traffic.  However, I do see 1 request/response pair within a minute or
so after I've either selected another tab or closed the sidebar.   
Occassionally, I see the pair several minutes after the WR panel has been
deselected.  Still not sure how that is happening. r=cls

Comment 62

[Gervase Markham [:gerv]]

matt's patch is OK, but we should just remove the if from around the
setAttribute call further down instead. 

However, won't doing this increase startup time when you reopen the sidebar,
because content has to be reloaded?

Gerv

Comment 63

[Henri Sivonen (:hsivonen)]

Does this *really* fix the following cases:
* If the user slides the sidebar edge next to the window edge, the panel should
make no requests even if it was left as the topmost panel.
* If another panel is selected, the what's related panel should make no requests.
?

Last time I checked, the What's related panel prefs were deceptive, too, because
they had no effect.

(BTW, did you notice that Alexa has been the defendant in a class action lawsuit
recently... The complaint described their software as "trojan horse". I still
don't see why mozilla.org wants a partner like that.)

Comment 64

[cls]

Ick. Bad choice of words.  How does reopening the sidebar "increase startup
time"? :-)  Yes, it looks like the content will be reloaded whenever the panel
is reactivated.

No, the proposed fix does not work in the 0-width sidebar case.  I'm not sure if
I'd agree that a 0-width sidebar == inactive sidebar.

Outside of the 1 or 2 pair of stray packets after selecting another panel
(possibly a timers issue?), tcpdump verifies that no requests are being made. 
This is after running tcpdump and using the sidebar for most of the weekend.

Comment 65

[cls]

Considering that most of our panels are fetching data from a remote site
anyways, how bad, realistically, is it to reload the panel from its src url
whenver it is selected?  Especially, when the trade off is to have it disabled
whenever it's not selected?

I'm still looking to get this into 0.9.4.

Comment 66

[jag (Peter Annema)]

So why can't we do something like:

var search =
        Components.classes["@mozilla.org/rdf/datasource;1?name=internetsearch"]
                  .getService(Components.interfaces.nsIInternetSearchService);

var autoOpenSearchPanel =
        pref.GetBoolPref("browser.search.opensidebarsearchpanel");

if (!sidebar_is_hidden() || autoOpenSearchPanel) {
  var searchInProgressFlag = search.FindInternetSearchResults(url);

  if (searchInProgressFlag)
    RevealSearchPanel();
}

I'm sure there's a good reason we can't just not post the url to the internet
search service if the sidebar is hidden and we don't want it to auto-open on us,
and I'm just not seeing that reason.

Comment 67

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

Comment on attachment 46945 [details] [diff] [review]
patch to sideOverlay.js

Oigh. Well this seems harmless enough. 

sr=[e-mail]

Comment 68

[Asa Dotzler [:asa]]

Comment on attachment 46945 [details] [diff] [review]
patch to sideOverlay.js

a=asa for checkin to 0.9.4

Comment 69

[cls]

Attachment 46945 [details] [diff] has been checked into the trunk and the 0.9.4 branch.

Comment 70

[Henri Sivonen (:hsivonen)]

Replying to my own 2001-08-23 23:14 comment:

The case with another panel has been selected appears to be fixed.

When "What's Related?" is the previously used panel but the sidebar has been
minimized, Mozilla sends requests to xstl.alexa.com, which is both a privacy and
performance problem.

Should I reopen this bug or file another one?

Comment 71

[Jaime Rodriguez, Jr.]

Removing ME.

Comment 72

[Ben Bucksch (:BenB)]

Henri, define "minimized".

Comment 73

[Henri Sivonen (:hsivonen)]

With "minimized" I mean the state the sidebar goes into when the grippy of the 
open sidebar is single-clicked (with no dragging).

Comment 74

[Kathleen :Brade]

As the author of this bug, I don't consider it fixed if my sidebar is trying to 
contact alexa.com while it is collapsed/minimized.

Reopening bug based on Henri's comments.

Comment 75

[cls]

Now to play the other side of the coin....I disagree with the entire minimized
== inactive premise.  When you minimize, iconize or shade an application window,
it does not become inactive.  I don't see why the sidebar should be any
different.  If I have a panel that actively streams data and I want to free up
some screen space, I should be able to minimize it (via the grippy) and not lose
the data.  If I want to turn it off, then clicking another tab or disabling the
sidebar (via F9) should be the way to do it.  I think this entire conversation
would be moot if there was a non-menuitem/hotkey way to disable the sidebar like
there is to minimize it.

(Wrt WR, we know that's a privacy issue by itself, minimized or not.  So if you
have it selected, then you know what you're in for.  )

Comment 76

[Michael Marxmeier]

Cristopher: From a user point of view i strongly disagree with your 
view. If i hide (or otherwise) disable a sidebar applet i assume 
it is no longer active ("out of view") and certainly i would not expect 
it to send out information -- independendly if i previously selected it 
or not.

Comment 77

[cls]

Reassigning to default owner & QA.

Comment 78

[Ben Bucksch (:BenB)]

cls, if you disable the sidebar completely (View | Sidebar), would you expect
the panel to continue to fetch? I certainly wouldn't. The average user doesn't
notice the difference between collapsed and disabled (and it is arguable, if
there should be any at all). Besides, rereading the inital description and the
summary, the collapsed state is what this bug was all about, not?

Comment 79

[Peter Lairo]

The behaviour should orient itself according to what the user expects. If
something is closed, minimized or another item is selected, he usually doesnt
want stuff to be happening. Therefore:

- When the sidebar tab is closed (i.e., another tab is selected), there should
be no updating.

- When the sidebar itself is minimized, collapsed, closed or whatever, there
should be no updating.

Comment 80

[cls]

BenB: Obviously, I did see fetching when the sidebar was disabled as a big
problem as I pushed quite a bit to get Matt's fix in.  

However, I do not see an active sidebar (ignoring WR) as a problem.   "Disabled"
and "collapsed/hiding" are distinct states.  By combining those states into a
single state, you lose potential flexibility with the sidebar (think internet
radio).

There are two distinct states for a reason.

Even in these "minimized" state, there is still the presence of the sidebar. 
That should be the first clue that it's not *disabled*.

If the "average user" thinks that something is "disabled" merely because it's
"hidden" or "minimized" or "collapsed", they are fooling themselves and I have
no intent of harboring their misconceptions and I don't think the project should
either.

Does our browser stop loading a page when you minimize the window?  Of course
not, because you didn't *disable* the application.  You merely hid it. If the
"average user" can understand that simple idea, then they should be able to
understand this sidebar issue.  We should not "dumb down" a potentially useful
feature because the "average user" has logistically incorrect expectations.

Comment 81

[Peter Lairo]

What about the fact that users will want to have the "what's related" sidebar
available in the sidebar, but have another sidebar (e.g., bookmarks) open *most*
of the time. Would the rarely used but *available* "what's related" sidebar
still be sending signals?

Thi seems to be something different than a minimized window - which therefore
seems to need a new and different solution. Or am I misunderstanding something here?

Comment 82

[cls]

As of Matt's patch (which has been checked in for 0.9.4 & the trunk), only the
currently selected sidebar panel is active.  And it is only active when the
sidebar is enabled (regardless of the minimized/collapsed state).

So for your example, only the bookmarks panel will be fetching new data. 

Comment 83

[Samir Gehani]

The tab persistence featuer will address this.  Taking for 0.9.5.

Comment 84

[Samir Gehani]

-> Matt fixed this.

Comment 85

[Samir Gehani]

Resolving.

Comment 86

[sujay]

marking VERIFIED per brade.

Comment 87

[Ben Bucksch (:BenB)]

Seems like this bug has never been fixed correctly or it regressed. Filed a new,
clean bug 133073.