Open
Bug 33469
Opened 25 years ago
Updated 2 years ago
Add a 'blacklist website' feature to Mozilla
Categories
(Core :: Graphics: Image Blocking, enhancement)
Core
Graphics: Image Blocking
Tracking
()
NEW
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
Comment 2•25 years ago
|
||
spam: moving qa contact on some bugs from paulmac to sairuh@netscape.com
QA Contact: paulmac → sairuh
Comment 3•24 years ago
|
||
Reassigning as per Don (Steve, I'm assisting Don w/bug triage)
Assignee: don → morse
Updated•24 years ago
|
Target Milestone: --- → M20
Updated•24 years ago
|
Status: NEW → ASSIGNED
Updated•24 years ago
|
Target Milestone: M20 → M30
Updated•24 years ago
|
Summary: Add a 'blacklist site' feature to Mozilla → [z]Add a 'blacklist site' feature to Mozilla
Updated•24 years ago
|
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-
Updated•24 years ago
|
Assignee: morse → nobody
Status: ASSIGNED → NEW
Whiteboard: [z]
Comment 6•24 years ago
|
||
.
Comment 7•24 years ago
|
||
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.
Comment 10•23 years ago
|
||
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).
Comment 11•23 years ago
|
||
> 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.
Comment 12•23 years ago
|
||
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".
Comment 13•23 years ago
|
||
[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.
Comment 14•23 years ago
|
||
reporter:
you also mentioned "password-protected" in your original description. Can you
expand on that please?
Reporter | ||
Comment 15•23 years ago
|
||
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
Comment 16•23 years ago
|
||
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...
Comment 17•23 years ago
|
||
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.
Comment 18•22 years ago
|
||
*** Bug 160305 has been marked as a duplicate of this bug. ***
Comment 19•22 years ago
|
||
*** Bug 182059 has been marked as a duplicate of this bug. ***
Comment 20•22 years ago
|
||
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.
Comment 21•22 years ago
|
||
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.
Comment 22•22 years ago
|
||
Whoops! My last comment was posted under the wrong bug #. Please ignor.
Comment 23•21 years ago
|
||
*** Bug 239272 has been marked as a duplicate of this bug. ***
Comment 24•21 years ago
|
||
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).
Updated•20 years ago
|
Product: Core → Mozilla Application Suite
Comment 25•20 years ago
|
||
*** Bug 276197 has been marked as a duplicate of this bug. ***
Comment 26•20 years ago
|
||
(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)
Comment 27•20 years ago
|
||
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!
Comment 28•19 years ago
|
||
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
Comment 29•19 years ago
|
||
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
Comment 30•18 years ago
|
||
*** Bug 352298 has been marked as a duplicate of this bug. ***
Comment 31•17 years ago
|
||
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.
Updated•17 years ago
|
Summary: Add a 'blacklist site' feature to Mozilla → Add a 'blacklist website' feature to Mozilla
Comment 32•17 years ago
|
||
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".
Comment 33•17 years ago
|
||
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.
Comment 34•17 years ago
|
||
Blocking certain websites from showing in a browser does not need sendmail. You are putting your comments in the wrong bug.
Comment 35•17 years ago
|
||
It is not a matter of blocking. It is a matter of making the sender believe your email address is no longer valid.
Comment 36•17 years ago
|
||
Please, read the summary (comment 0) of this bug. It's about _websites_. That has nothign to do with email addresses.
Comment 37•17 years ago
|
||
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.
Comment 38•17 years ago
|
||
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.
Updated•16 years ago
|
Assignee: nobody → jag
Priority: P3 → --
QA Contact: bugzilla
Target Milestone: Future → ---
Comment 40•15 years ago
|
||
Wait, is this bug specifically referring to SeaMonkey, in which it is categorized, or is it just referring to Mozilla browsers in general?
Comment 41•15 years ago
|
||
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.
Comment 42•15 years 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
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•