Open Bug 33469 Opened 24 years ago Updated 2 years ago

Add a 'blacklist website' feature to Mozilla

Categories

(Core :: Graphics: Image Blocking, enhancement)

Product:
Core
Component:
Graphics: Image Blocking
Type:
enhancement

Tracking

()

People

(Reporter: rekle, Unassigned)

References

Details

Add a feature to be able to keep a password-protected blacklist of web sites to 
Mozilla.  It could work in a way similar to the Cookie Manager.  Choose a 
setting in the Preferences that would prompt you on each new site you visit 
asking if you want to blacklist it.  If you say yes, it goes into the blacklist 
and Mozilla won't allow you to access it again.  It should have the ability to 
export this blacklist to a file and reimport a blacklist from a file.  It 
should be intelligent enough to let you block entire domains or just parts of 
them (particular directories, or pages).  Another possiblity is to define some 
kind of filtering protocol and have the user specify a filter server that 
Mozilla could connect to to check blacklisted sites.

This would allow a parent to filter the Web as they see fit and not have to 
rely on third party filtering programs that have hidden blacklists.
Changing component
Assignee: troy → don
Component: Layout → XPApps
QA Contact: petersen → paulmac
spam: moving qa contact on some bugs from paulmac to sairuh@netscape.com
QA Contact: paulmac → sairuh
Reassigning as per Don (Steve, I'm assisting Don w/bug triage)
Assignee: don → morse
Target Milestone: --- → M20
Status: NEW → ASSIGNED
Target Milestone: M20 → M30
Changing fictional "M30" to reality
Target Milestone: M30 → Future
Summary: Add a 'blacklist site' feature to Mozilla → [z]Add a 'blacklist site' feature to Mozilla
Summary: [z]Add a 'blacklist site' feature to Mozilla → Add a 'blacklist site' feature to Mozilla
Whiteboard: [z]
nav triage team:

Not a beta1 stopper, makring nsbeta1-
Keywords: nsbeta1-
Assignee: morse → nobody
Status: ASSIGNED → NEW
Whiteboard: [z]
.
Talking about this on #mozillazine today and wanted to dump a few ideas in here
for discussion:

Potential features:
- As above, per domain or per directory (and below) blocking

- Block all traffic to the blacklisted site - cookies, images, http, https, ftp,
whatever

- Blacklist patching: merge another blacklist w/ your own
	* Maybe patch files should be plaintext, so users know what they are blocking
	* Alternatively, a patch/exported file might be encrypted, but allow for preview
so that unintended viewers don't have a concise list of sites deemed blacklist
worthy (i.e. so kids don't view the mozilla blacklist text file and then open
the sites in another browser).  A preview must be provided to priveledged
user(s) in this case though, so that we aren't blindly blocking based on someone
else's criteria.

- Per profile on/off switch - changeable only by priveledged user(s), and
protected better than a plaintext setting in a world writable file

Concerns:
- How to establish priveledged user status wrt blacklisting?
	* Per profile priveledge or installation wide?
	* Use system security where applicable (*NIX, NT, etc), or mozilla specific?

- Limiting access to the blocklist to proper users
	* This may not be totally possible on non *NIX, NT, other multi-user systems
	* This might be helped by on disk encryption, but we would need to make sure the
blacklist couldn't be simply copied by a non-priveledged user to another mozilla
installation and decrypted. (machine specific encryption?)

- Make sure there aren't easy ways to break this feature:
	* Error/quit on missing/corrupt blacklist
	* Password protect profiles? (is this done already?)
Some users have used .pac files to do the same thing, they send all URL of a 
type (ads or porn are the two most common targets), to a proxy server that 
returns a null file or a generic graphic.

I think this is a good discussion to have, because in the networking component, 
we get a good number of bugs which come from users trying to hack up their 
network configuration so that they do not see or request ads. Most of these 
people want us to "fix" networking to support their hacks, which really is not 
the way to go.
As I explained in Bug 78896, I used hosts file in windows to avoid ads. Having 
your own custom solutions is great but this won't solve my problem, because I 
will still maintain an hosts file (to block ads for IE for example) and even if 
IE creates a new feature like the one you want to do, It will be painful to 
manage 2 lists.

IMHO the right way to go is simply remove the JavaScript error (bugging me on 
every page I visit). I understand this is not cross-platform but there is a 
similar way in Linux to made some domain to resolve to localhost.

In fact my solution is not a *hack* it's the logical step to protect your 
privacy. You decide at the OS level that you disalow some domain to access your 
computer, I just think Mozilla should respect my choice.
You should vote for this bug.

Modifying /etc/hosts is a hack because that is a system file that should not be 
used to control the behavior of a single application. If a system had multiple 
users, then your modification of /etc/hosts would affect all users.

Mozilla runs in many environments, so we do not want to have system-level 
changes involved in its usage (if at all possible).
> Mozilla runs in many environments, so we do not want to have system-level 
> changes involved in its usage (if at all possible).

I really understand this problem. But you'll agree with that keeping two or 
three separated file of blacklisted sites is no-go option too. This is why I 
want to do it at the system level. Best would be at the user level but I don't 
see how we can do that. I won't vote for this bug because It won't solve the 
problem, It will add a feature that's all.

However If Bug 28586 is corrected/accpeted my problem will be solved.
This could be fixed as part of a general mechanism for blocking images, cookies,
and other media types from specific sites (bug 94035).  If you want to blacklist
a site, you could just choose "all" instead of "images" or "cookies".
[Aufbau-P3]: When you're surfing porn, you don't want to bother memorizing each
domain that forces you to click an ads before you can see the thumbnails, and
you don't want to bother looking at the domain of each link you click on.  Using
an external proxy or a "hosts" file to block these domains is not ideal because
Mozilla will still open a window when I middle-click a blocked link unless the
link is blocked at the browser level.
reporter:
you also mentioned "password-protected" in your original description. Can you 
expand on that please?

By password-protected, I mean having a sort of roll-your-own web filtering
system.  For example, if you were a parent, and you didn't want your children
viewing certain web sites, you could add those web sites to the black list
feature, and put a password on the access of the blacklist feature, so the kids
can't go in there and add the sites back in.  

You would need to have an optional password to prevent changes to the blacklist.

Rick
Hmm. The different lists should probably exist as part of different profiles.
The password locking might be something that already works with some of our
features for brower installation and profile management...
Libraries would benefit greatly from something like this.  Like parents, they
also have reason to restrict particular sites and entrust power to an admin
profile.  I  know of a situation where the library wants to only allow web
content from just one server, the card catalog.  The computer does nothing else!
 I'd love to sell them on Mozilla if this is fixed!  It would make sense to turn
this into an allow/deny system to make life easier for this type of
configuration (trusted content).

As a further thought, when untrusted users attempt to "surf" to
untrusted/disallowed sites, these sites could go into an administrative queue
for later consideration.  Administrators or parents could then review the sites,
and decide to blacklist them, or approve them, and the changes would be
auto-applied back to the untrusted profile.
*** Bug 160305 has been marked as a duplicate of this bug. ***
Blocks: 92178
*** Bug 182059 has been marked as a duplicate of this bug. ***
Sorry for the duplicate. I searched but my search came up dry. Anyways, in
addition to blacklisting some sites from dropping cookies and from being
accessible, I also suggest that they be blacklisted from dropping scripts, like
those #(*&^*$ Java scripts that generate popups. 
I am now using Mozilla/5.0 (X11; U; 
Linux i686; en-US; rv:1.3a) Gecko/20021212

I believe this problem has been solved. I have not been able to reduplicate 
it over the last week and I had at least 3 situations where is should have
occured.
Whoops! My last comment was posted under the wrong bug #. Please ignor.
Depends on: 169106
*** Bug 239272 has been marked as a duplicate of this bug. ***
Note that the infrastructure for this is already in place (nsIContentPolicy). 
Writing an extension to do this should be pretty straightforward (and in my
opinion that's what should happen).
Product: Core → Mozilla Application Suite
*** Bug 276197 has been marked as a duplicate of this bug. ***
(In reply to comment #24)
bug 240070 is that extension, and is part of default builds now. So you can add
sites to block to hostperm.1.
host	document	8	site.to.block.com
will block the documents from that site.
(ok, it is not yet password protected, but you can use the accress rights of
your OS)


Could someone please be more specific about adding things to hostperm.1 ?
I looked at it with NotePad and it said it was a generated file that should not
be edited.  Thanks!
some extensions include 
FraudEliminator
(?) Linkification

(In reply to comment #27)
> Could someone please be more specific about adding things to hostperm.1 ?
> I looked at it with NotePad and it said it was a generated file that should not
> be edited.  Thanks!

http://wiki.mozilla.org/Firefox:1.5_Extension_Manager_Blacklist may help - not sure if it applies to suite

bz: would it be appropriate to extend nsIContentPolicy to support a ninth "type" of content to block, or should the permissions extension be what gets extended here?

I'm thinking of the following as hostperm.1 syntax:

host    all     2       example.com

as a possible means of implementing this. "All" would essentially be an alias for "cookie,image,popup,...etc."

cl
*** Bug 352298 has been marked as a duplicate of this bug. ***
A few years back a Linux guru demonstrated a technique that would cause an unwanted sender to immediately receive a return email stating that the intended recipient is unknown. The nice thing about this is that it caused spammers to believe that the address was outdated. I do not know how it was done, but there must be someone on the team who knows. I think that it would be a nice way of solving two problems, 1) not receiving from blacklisted sites and 2) getting the sender to drop your email address from their list.
Summary: Add a 'blacklist site' feature to Mozilla → Add a 'blacklist website' feature to Mozilla
Re. comment #31: When mail is sent to a nonexistent user id, the receiving machine does not send back a mail message.  Instead, its SMTP server (typically "smtpd") immediately returns an error code to the sending machine's SMTP client (typically "sendmail").  "sendmail" is responsible for generating the bounce message, if any, that the sender gets back.  (It can be set not to bother.)

If you want the spammer to actually believe that the receiver's user id doesn't exist, this same behavior needs to occur -- and that can't be done in Mozilla because Mozilla (when it handles incoming mail) is not an SMTP server but a user agent.  It only sees a mail message after the SMTP server on your ISP has already accepted it and returned a success code to "sendmail".
Yes, unix sendmail features in Mozilla and Firefox are what is needed. I have observed unix gurus set up their sendmail to immediately respond to emails from select users and from other users after the email has been read telling the sender that either the email address does not exist or that mailbox is full. Of course this requires that server features be built into Moxilla but this is not impossible. Sendmail is a very some program and its features could easily be put into Mozilla or it might be invoked as an addin. 
Blocking certain websites from showing in a browser does not need sendmail. You are putting your comments in the wrong bug.
It is not a matter of blocking. It is a matter of making the sender believe your email address is no longer valid. 
Please, read the summary (comment 0) of this bug. It's about _websites_. That has nothign to do with email addresses.
Ah, yes. The bug did start out as a quest for a black list feature usable at a personal level. But read the history of this bug. A while back the idea of misleading the blacklisted site was included in the discussion. The problem is that to simply blacklist on a personal basis does not stop the blacklisted site from continuing to send spam. The receiver might no longer see it, but bandwidth is being used. Someone might prevent access to the blacklisted site by a person on the computer blacklisting the site (without a password, for example). However, every sender of spam is using a site (or ip address identifiable server which can be accessed and which can send invitations to what is on it). Most black listing sites block these ip addresses. Assuming such sites are senders as well as browseable sites, Without feedback the sender has no reason to stop sending. Look back to comment 31. So, a site blacklisted only as not browseable can still be quite a pain as an email originator. The idea is to mislead it into believing that it is sending to a dead address. The effectively blacklists it from sending as well as from receiving browser requests. 
Martin: this bug still has absolutely nothing whatsoever to do with e-mail (spam or otherwise), and even when implemented, this bug will not do anything to stop spam, as this bug is fundamentally about http/https traffic, not smtp, pop, or imap traffic.

Please desist from commenting here unless you are working on a means to implement comment 0, comment 15, or comment 29.
Assignee: nobody → jag
Priority: P3 → --
QA Contact: bugzilla
Target Milestone: Future → ---
Wait, is this bug specifically referring to SeaMonkey, in which it is categorized, or is it just referring to Mozilla browsers in general?
My feeling is Mozilla in general. Chances are if this were just a SeaMonkey thing, the summary would have been changed quite some time ago.
Kicking this over to Core:Image Blocking, since that's where the original permissions bug lived and there isn't a Core:Permissions component (yet?).

Individual browsers should have their own bugs for a front-end implementation of this once something gets decided on the back end.
Assignee: jag → nobody
Component: UI Design → Image Blocking
OS: Other → All
Product: SeaMonkey → Core
QA Contact: image-blocking
Hardware: x86 → All
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.