Попытался сформулировать запросы к программе от конечного пользователя-неспециалиста (но и не совсем чайника). Получился список вида: хочу чтобы <определенный контент> на <Н-ском сайте> был доступен <следующим образом>. Контент - картинки, видео, звуки, флеш, статический, динамический, большого размера и т.д. и т.п. в различных сочетаниях. <Н-ский сайт> - URL. <Доступ> - глаза бы мои его не видели, возможность чтения без доступа к сети, обновлять раз в <срок>, включая <всегда> и <никогда>, не брать из сети и т.д.
Отсюда получается ровно два списка.
Первый описывает контент по любым (в идеале, конечно) параметрам исходящих и входящих заголовков.
Второй описывает что делать с контентом на том или ином сайте (или группе сайтов, в том числе .*).
Преимущества подхода
1. Первым списком можно легко делиться между пользователями и безболезненно его обновлять, так как он НЕ определяет никаких действий, а уточнение понятия "картинка" принесет пользу ВСЕМ, вне зависимости от того, желают ли их видеть, кешировать и обновлять!
2. Второй список делает редактирование похожим на аналогичные настройки браузеров с возможностью настройки кеширования как в целом, так и для отдельных узлов  (например, настройки кеширования для Оперы) только с намного более широкими возможностями.
3. На нижнем уровне могут оставаться существующие списки - они однозначно формируются из двух описанных. Более того, большинству пользователей хватит перевого списка по умолчанию или скачанного у "гуру".
Например, помните, почему на руборде не хотели делиться черным списком? Да потому, что там был разнородный контент! Со списком же контента можно спокойно вести и распространять отдельно "реклама", "чаты", "порно", "P2P", "развлечения" и т.д. А решать что делать каждый пользователь сможет сам.

Ты слишком расплывчато изложил - не понятно ни что именно тебе видится, ни зачем это нужно.

Попробуй написать алгоритм того, как это должно работать и посмотреть, есть ли гемор с написанием и выполнением такого алгоритма

А разве нельзя всю эту "кучу правил" объединить в 1 универсальное?

Полностью поддерживаю. Чрезвычайно полезная, на мой взгляд, идея. Жаль, что как-то ушла в забвение.

Почему не стыкуется? Те же списки с регулярными выражениями и URL... Кто разбирается в нынешних - легко поймет и новые, а для новичков новые списки проще и легче.

Конкретное воплощение с алгоритмом:
1. При поступлении запроса от браузера просматривется список категорий (по порядку) с проверкой условий по URL и параметрам исходящего заголовка. Составляется упорядоченный (в порядке занесения) список сработавших категорий, включая также те, которые требуют дополнительной проверки входящего заголовка.
2. Просматривается список действий - по порядку ТОЛЬКО по отмеченным категориям с учетом URL. Составляется упорядоченный список подходящих записей.
3. Если для категории в этой записи не требуется уточнение входящего заголовка - запрос обрабатывается в соответсвии с указанными в списке действиями. Если действия в списке противоречат друг другу - приоритет имеет находящееся выше по списку.
4. Если требуется обработка входящего заголовка - то список действий проверяется дальше до первой подходящей записи с учетом данных входящего заголовка.

Списки по виду и настройке очень похожи на нынешние - список категорий на большинство из них, список действий - на белый.
С точки зрения пользователя - в большинстве случаев не надо менять список действий, можно легко настроить особое поведения для конкретного сайта. Освоение новой функциональности при обработке URL куда удобнее - добавляются прежде всего варианты действий, а структура списков не меняется.
С точки зрения реализации - поиск по списку категорий можно распараллелить (по нити для каждой категории), поиск по списку действий - ускорить за счет фильтрации по категориям и индексирования по URL как в Proxomiton'e (ведь все сложные регулярные выражения - в списке категорий, а тут можно вообще оставить адреса в привычном виде).

DenZZZ

Колонки списка действий.
1. URL: лучше всего только в простом виде - для ускорения поиска с помощью индексирования.
2. Категория: одна из категорий, определенных в соответствующем списке.
3. Действие: одно из возможных действий ((Не) блокировать, (Не) загружать из сети, (Не) брать из кеша, (Не) обновлять и т.д.) Наличие двух вариантов каждого действия (с "не" и без) позволит уменьшитиь размер белого списка или вообще без него обойтись.
4. Условие - дополнительное условие исполнения действия. Например, срок хранения для действия Не обновлять.
Несколько не противоречащих друг другу действий задается просто включением нескольких строк в список

Списки "Переадресация" и "Преобразование URL" трогать не нужно - они работают отдельно от остальных. Разве что в них полезно добавить поля "Сайт" и "Исключение".

Входящие заголовки - с них начинается ответ http-сервера. Проверять - в момент получения этого ответа. В большинстве случаев этого можно избежать, например блокирование рекламы условий, зависящих от входящего заголовка, не содержит, а значит сработает без запроса к серверу.

Кирилл
Получается, что список твоих действий можно конверитировать в набор нынешних списков?

Значит для начала это можно попробовать реализовать в виде отдельной программы. Eсли это дело получит положительный резонанс, то я это встрою в НС.

То ничего страшного не произойдет Давно уже пора вводить поиск и фильтрацию (по категории, например) при просмотре списков. А наглядность, наоборот, появится - сейчас порядок срабатывания списков из интерфейса неочевиден (без блоксхемы не разобраться). Со списком действий все будет намного прозрачнее - срабатывает то, что выше в списке.
Это еще почему? Что мешает иметь в контекстном меню команду "Добавить URL с категорией XXX"?
Простота добавится - если раньше один и тот же URL в нескольких вариантах требовалось добавлять в несколько разных списков, то теперь достаточно занести его только в список категорий.

Красиво. Но разве сейчас не так? Классификатор - это правило, политика - это гулька "Разрешить". Или же другая пара - список и "Разрешён". Поясни конкретнее - как именно ты видишь такую схему?

Вот теперь более понятно, о чём речьДля того, чтобы использовать нечто "чужое и вылизанное" оно не обязательно должно называться "классификатором" - в топике про "правила по умолчанию" уже звучали предложения по онлайн-обновлениям списков. А вот одновременное управление группами правил - пожалуй, заслуживает внимания...
P.S. см. ПМ

NothingAnother
Скачивая чужие нынешние списки - ты скачиваешь и чужую политику фильтрации!
И потом вынужден работать ручками, например, в том случае, когда тебе надо НЕ блокировать флеш или развлекательные сайты.
А скачав обновленный классификатор, ты улучшаешь распознавание трафика, а свои предпочтения по фильтрации - не трогаешь.

Давайте переименуем тему как-то так:
"Двусписочная система: классификатор трафика и политика действий".
Или предлагайте свои варианты...

А то "Редактирование настроек пользователем", ИМХО, не точно отражает суть предложения...

Так, и того, и другого! Может, "политика загрузки"?

А как при этом пользователю vasya запретить images но разрешить ему загружать ico?

А черный список по умолчанию уже стал разбиваться по категориям...

три - ещё
(не, ?)писать-в-кэш

А двухуровневую систему организовать можно так:
1) именованый список (имя=имя файла lst) из строк
(активно строка_поиска строка_исключения строка_замены)
не всегда все поля будут задействованы, но для унификации.
2) правила в виде
(активно имя_списка ...)

Ну не беря из сети писать в кеш не получится
А вот когда оба "брать" - ещё и приоритет выставлять надо, оба варианта имеют смысл.
А вообще, не так их и много, можно в один дроплист все варианты загнать

Фактически ты предлагаешь "Односписочную модель", которая должна заменить все существующие списки и часть опций + добавить несколько новых.
Это немного не то, что предлагал Кирилл в "Двусписочной модели" - ты подошел к проблеме более радикально...

Возник ряд сомнений:
- Не уверен, что в твоей модели настройки будут "более понятны пользователю"! Реализация данной модели будет означать полное изменение логики настройки HC, причем не в сторону ее упрощения!
- Не понятен механизм обмена частями списков между пользователями. В двусписочной модели можно хотя бы "Политику" оставить свою, а обмениваться только "Классификатором". У тебя же и типы и конкретные правила RegExp - все в одном списке!
- Наличие макросов в твоей модели отнюдь не делает ее безопаснее и проще скриптов!


P.S. Последние посты будут перенесены в раздел "Новые предложения", т.к. требуют обсуждения и обоснования столь радикальных изменений...

Почитал описание языка регулярных выражений Проксомитрона. Существенную часть можно реализовать через PCRE с помощью макросов.
Например,
. = \.
* = .*?
" " = \s*
"=" = \s*=\s*
? = .
и др., а также популярные команды $AV, $AVQ, $NEST
Если кому-то не захочется переучиваться на PCRE, тот сможет пользоваться почти полным вариантом языка регулярных выражений Проксомитрона и некоторыми его командами.

DenZzz
Речь о PCRE и макросах идет в привязке к проверке условий. Для проверки условия никому не нужна запись в файл. Ты смешиваешь это с действиями, которые надо производить при выполнении условия.

DenZzz
1. То, что предложено - это концепт. Не было цели изложить все тонкости, которые есть и будут. Есть желание создать общий универсальный подход к работе с программой.

2. Что касается записи в файл. Если потребуется, это можно включить в список действий, он не исчерпывающий. Сейчас необходимости не вижу, т.к. не видел ни одного обсуждения, где бы обосновано была признана такая необходимость. Приведенный тобой пример создания специального файла вовсе не исчерпывает возможные варианты решения вопроса и, имхо, не является лучшим вариантом. Очень просто будет автоматически хранить эти данные (например, Content-Encoding) в файле-индексе (в метаданных). При этом отдельных файлов создавать пользователю не нужно. Надо обсуждать каждую такую необходимость. Имхо, без этого преждевременно говорить о "существенных ограничениях функциональности".

3. Есть разница между действительно необходимыми действиями, которые предоставляет программа, и широким кругом действий, куда войдут никогда не востребованные, но затрагивающие безопасность возможности. Нужно ли дать пользователю возможность с помощью НС писать в произвольный файл, запускать внешние программы из шелла, отслеживать системные события, работать с сокетами и пр.? Думаю, нет.