44845 - [meta] No network communication without explicit user request

Status: RESOLVED FIXED

(Core :: Security, defect, P3)

Description

[Ben Bucksch (:BenB)]

We must not transfer any data in any direction without the user having requested
that explicitly, or at least have an option for that. The browser is the user's
tool, not the content provider's. The user must have control over what is going
on (which can happen at different levels of detail, up to a general "protect my
security and privacy by all means").

I do not want Netscape to know whenever I open my browser, customize my sidebar
or whatever. Even less, I want data about me to be sent without me having
requested that or even knowing.

Examples for valid depandant bugs:
- Disable XML-RPC
- Don't download available panels list from a server

Maybe, on a more broad scope (not sure, if this is too broad):
- Access only mail server when reading mail

Comment 1

[Ben Bucksch (:BenB)]

/

Comment 2

[Mitchell Stoltz (not reading bugmail)]

We're already actively considering yout third point. It raises some problems (for 
example, it would break "send page), but it's worth considering. This is a good 
list of concerns for us to keep in mind. Generating third-party server hits 
without the user's request is a "covert channel" for data about the user, but 
addressing this issue is tricky.

Comment 3

[Ben Bucksch (:BenB)]

> Generating third-party server hits 
> without the user's request is a "covert channel" for data about the user,

Even channels back to the main server can be a problem.

> but addressing this issue is tricky.

Agreed, but this is no reason not to do so. In fact, it is very important to do
so. It has social consequences!


---


vidur, I am very concerned about your XML-extras package. It can be a very cool
thing from a technology perspective, but also a reason for lots of new problems
in this bug. Please be very careful while designing this stuff and keep the
consequences in mind. It will propably need a lot of discussion :-/. Don't
create a new security headache like JS or cookies.

Comment 4

[vidur (gone)]

XMLExtras isn't part of the Netscape 6 package. I suspect that a fairly detailed
security review will precede including it in a Netscape-branded release.

I do understand your concern, but am not sure how to address it given the
direction the industry is moving in vis-a-vis web applications. Maybe a pref
related to this kind of "out of band" network activity is a start?

Comment 5

[Ben Bucksch (:BenB)]

vidur, I posted <news://news.mozilla.org/[e-mail]> my reply
to .xml.

Comment 6

[John Unruh]

QA > [e-mail]

Comment 7

[Ben Bucksch (:BenB)]

.

Comment 8

[Greg White]

I am not convinced that the xmlextras package is adding any new security 
problems.  It is quite possible for a page to contain a hidden frame or iframe 
and for some javascript to use that to post data to a server.

Comment 9

[Ben Bucksch (:BenB)]

Greg, please see the thread spawning from the post referenced above.

Comment 10

[Ben Bucksch (:BenB)]

.

Comment 11

[Daniel B.]

> It raises some problems (for example, it would break "send page)

No it wouldn't.  Send Page should not re-retrieve pages in the first
page.  See bug 288462.

Comment 12

[Serge Gautherie (:sgautherie)]

Filter on "Nobody_NScomTLD_20080620"

Comment 13

[Sylvestre Ledru [:Sylvestre]]

11 years without any activity on this meta bug, closing.