99806 - Release Notes (1.0 ~ 1.4) - add explanation of server rights (ZoneAlarm)

Status: RESOLVED FIXED

(www.mozilla.org :: General, defect)

Description

[Alfonso Martinez]

Whenever a new user that uses ZoneAlarm (and probably other firewalls as well),
installs Mozilla and run it for the first time s/he is faced with a warning
about Mozilla asking for server rights.

If I've understood it properly, this is due to the way Mozilla communicates with
the PSM, so it would be nice if that info is added to the release notes (and
some other documentation that I'm unaware of)

It can be something as simple as:
"Mozilla needs to act as a local server in order to communicate with the PSM,
and  it can safely be blocked to act as an Internet Server in order to protect
your privacy"

I don't know what happens when the PSM is blocked by ZoneAlarm, someone who
knows should add it in order to make the explanation a little better.

I'm leaving this OS as windows, I don't know what happens in other OS

Comment 1

[timeless]

if you block psm, https and ssl (for imap/pop/smtp) should all break.

Comment 2

[chris hofmann]

this message could be alarmming for some widespread distribution embedding
customers.  we need to get a handle on what happens if the user chooses to
deny server rights,(mdunn can you round someone up?) 
and we need to figure out if there is any way to avoid PSMs requirement 
for server rights.

Comment 3

[chris hofmann]

problem might be specific to some versions of zonealarm.  here is a comment to
check out from one tester...

"Connection refused" from every URL...

I had the same problem with connevtion Refused. I tracked it down to ZoneAlarm
3.x Pro. After i shutdown ZoneAlarm the problem went away. I upgraded ZoneAlrms
and have not had the issue happening to me again.

Comment 4

[Javier Delgadillo]

PSM doesn't open any sockets other than the ones necko requests it to open. 
This is not a PSM issue.  I can't seem to find the bug number, but this is
caused by NSPR opening a socket on loopback and listenting to it for some type
of event handling.

Comment 5

[Jatin Billimoria]

If you feel this is worthy of being release noted, please submit it to Moz 1.0
relnote tracking bug: 

Bug 133795

Include this bug number, a brief explanation of the problem, and any workarounds.

Comment 6

[Judson Valeski]

suspecting that we were opening a server socket somewhere, wtc and I had an
email exchange that yielded:

wtc wrote:
"PR_NewTCPSocketPair opens a temporary listening socket
that is bound to the loopback address (INADDR_LOOPBACK).

Necko is the only Mozilla code that calls PR_NewPollableEvent.

There is no obvious way to implement PR_NewPollableEvent
without opening that temporary listening socket on the
loopback address. "

It turns out that the socket transport service is calling PR_NewPollableEvent
here
http://lxr.mozilla.org/seamonkey/source/netwerk/base/src/nsSocketTransportService.cpp#185
upon initilization.

It's not clear to me how we could implement this in another way.

Comment 7

[Zach Lipton [:zach]]

Why do I own this bug? Kicking over to default.

Comment 8

[rudman]

Changing product to NSPR, per Javier's comment, for further investigation and
comment. Assigned to default.

Changing summary from "Add explanation of server rights in Release notes." We
need more info for the relnotes, and if it is a relnote item, add mention in bug
133795.

Comment 9

[rudman]

-->default owner and QA.

Comment 10

[Wan-Teh Chang]

If this is an NSPR bug, it will be resolved as a duplicate
of bug 100154.  I will wait until April 30 to do that.

If this issue should be mentioned in the release notes,
please follow Steve Rudman's instructions in comment #8.

Comment 11

[Alfonso Martinez]

I filed this bug only to reflect the current behaviour in the release notes. I
never intented to request a change in the program, just read my first comment.

Please, can someone elaborate a correct release note with all the info that is
available here and in bug 100154? (English is not my native tongue and so my
senteces can frighten people instead of helping them to understand that
everything is fine)

Comment 12

[Ellen Evans]

Would something like this serve as a relnote, should one be deemed necessary?

========================

Mozilla uses an internal communication method that some software firewalls, like
ZoneAlarm, may interpret as the browser setting itself up as an "Internet
server".   The communication method does not in fact access the net, nor does it
provide non-local users (ie, users on other machines) access to either Mozilla
or the machine running it.  Users should indicate to the firewall that Mozilla
should be be allowed to act as a server.  

Comment 13

[Alfonso Martinez]

I only wolud like to add that at least in ZoneAlarm it's possible to specify if
a program can act as a "local server" or an "internet server", and that the
functionality of Mozilla only depends on the "local server" rights.

Comment 14

[Jesse Ruderman]

*** This bug has been marked as a duplicate of 100154 ***

Comment 15

[Alfonso Martinez]

This is not a dup of 100154.
Just read comment 11 and 12. This is only a bug to _document_ current behaviour.

Comment 16

[Jesse Ruderman]

Sending back to documentation.  This bug shouldn't have been morphed from a
documentation bug into an NSPR bug, and there's already bug 100154 (wontfixed)
covering the NSPR issue.

Comment 17

[Owen Marshall (Not reading bugmail)]

Owen is taking QA for "repeating relnote" bugs. Sorry for the spam; search for
the previous string to find and delete these messages.

Comment 18

[Daniel Wang]

fixed

Comment 19

[Owen Marshall (Not reading bugmail)]

*bugspam*