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.
spam: moving qa contact on some bugs from paulmac to email@example.com
Reassigning as per Don (Steve, I'm assisting Don w/bug triage)
Changing fictional "M30" to reality
nav triage team: Not a beta1 stopper, makring nsbeta1-
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.
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. ***
*** 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.
*** 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).
*** 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.
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.
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.