Blacklist

[myrdd]

There have been many issues for a Blacklist. This is a collection of important ones:

Blacklist in general: #6 (and #398)
"Ignore" blacklist-requests (e.g. the flag shouldn't go red): #1 and #368

I'm planning to implement a Blacklist, which will be propably the next feature. If there is anything to be discussed (which has not been discussed in the above issues), then I suggest to do the discussion here.

[stewie]

"neutral state" -- I've not previously seen that phrase but have often thought each domain entry should have a status attribute, so that its rule can be suspended (for testing, etc) vs needing to remove items + keep paper notes of removed entries + manually re-add items later.

More ideally, but not suited to storage within a prefs string, additional attributes would be stored for each entry. This probably begs use of sqlite storage. Some possible attributes:

-- date added
-- rule status (active, neutral, disabled)
-- silent (don't bother with red flag icon)
-- source (item loaded from b/wlist named "foo" or subscription list titled "joyjoy" or)
-- category/tag
-- reason

"Date added" would be useful if, in the future, the GUI will provide a "sort by" column. After adding new rules & discovering "breakage", it's important to be able to identify the most-recently-added rules.

"source" -- If user maintains multiple lists, or imports multiple subscription lists, this would help to identify overlap / redundancy across multiple lists

"Category" -- freeform text input for this attribute value. Most items on a list (izzit a blacklist, a whitelist?) will be related to tracking/privacy... but how to recognize those which are not?

"Reason" -- freeform text, or textarea, input to store the rationale for a given item's presence within a list e.g. "must allow siteX or siteY will break". Some entries within a distributed list might have their default status set to "neutral" (and/or "silent"). That way, user can see that suchandsuch rule is recommended (and why) but not experience breakage/confusion.

When I've read discussions/requests regarding "situational lists" aka "rulesets" aka "profiles", my head swims, unable to visualize a construct which can accommodate "all that". Something like that does exist, though, in the functionality of the chrome-only HTTPSwitchboard addon.

[myrdd]

A user problem with rule precedence (#824) made me think the blacklist should be implemented via rule priorities (#717). Blacklist Rules would have priority="max". – The user will have an option in the menu to “blacklist *.example.com”. Manually adding a rule to the blacklist could be done simply by assigning priority=max.

Implementing the blacklist using the priority feature would be IMO a clean implementation. For example, the blacklist should always have precedence over other rules. Besides that, a special "max" keyword is better than a fixed value—like 255—because it would not limit the priority numbers' range.

The difference between priority=max and priority=9999 will be that the former will have a special handling regarding the user interface: The flag won't go red due to a blacklist request.