Дополнение для FireFox "HTTP UserAgent cleaner" - справка



 Support(English; do not use Google translate, if do not speak English - write in the language that you know. If needed, my crypto key ( https://www.gpg4win.org/ ) is C64BE61A in keys.gnupg.net [0ADA 369A 692F 515F F4CC 6C2B D30A C753 C64B E61A])
Поддержка(на русском. Если хотите шифровать переписку, мой GnuPG-ключ шифрования ( https://www.gpg4win.org/ ): C64BE61A на keys.gnupg.net [0ADA 369A 692F 515F F4CC 6C2B D30A C753 C64B E61A])






Функции вкладки "Сторонние" (как и всё дополнение) не работают с включённым E10S (multiprocess FireFox / Electrolisys). Отключайте дополнение, если работаете с E10S во избежании неверной работы дополнения.
Также, на момент ноября 2015 года функции дополнения, особенно функции вкладки "Стороние", не совместимы с работой дополнения FoxyProxy. Работа фильтра iCookies не совместима с работой дополнения self-destructing-cookies.
Функции вкладки позволяют блокировать ненужные подзапросы или куки со страницы, такие как запросы к внешним счётчикам посещаемости.

Чтобы получить доступ к настройкам дополнения, щёлкните в панели дополнений на значок дополнения . Наведите мышку на вкладку "Сторонние" (вторая слева). Вы увидите что-то вроде этого


На скриншоте только одно правило. Пока оно ничего не делает.
Вы можете попасть в такую ситуацию, когда все ваши правила отфильтрованы фильтром и не отображается ни одного правила на вкладке "Сторонние". Это означает, что ни один фильтр гарантированно не действует для этого домена. Для решения проблемы с отображением попробуйте закрыть панель и открыть её снова. Если не получается, откройте в FireFox страницу дополнений (меню Инструменты->Дополнения [если меню не видно, нажмите клавишу alt]) и снова попробуйте открыть панель дополнения и зайти на вкладку. Теперь должны отобразиться все имеющиеся правила.

Давайте настроим блокировку CORS-запросов. CORS-запрос генерируется ajax тогда, когда он обращается к адресу на другом домене. Это может быть скрипт, который вас отслеживает, а может быть и полезный скрипт. Будем считать, что CORS подлежит блокированию, если не доказано иное.
Центральный элемент верхней строки - это имя правила. Кликнем по нему.

Отобразится поле ввода. Введём туда слово "CORS" и нажмём клавишу Enter (вместо этого можно кликнуть на сером фоне вкладки). Мы могли бы ввести сюда любое другое слово или не вводить ничего - это просто имя правила. Имена разных правил могут быть одинаковыми, хотя это не удобно.


После этого кликнем по центральному элементу второй строки. Туда тоже введём CORS (и нажмём Enter). Здесь CORS - это имя условия на срабатывание правила.


Пока правило не будет работать, так как имя условия "CORS" нужно вводить в правило с условием типа "obj". Давайте поправим тип условия. Для этого кликнем один раз в левом поле второй строки правила.


Значение "url" сменится на "obj". Теперь это правило будет работать.
Давайте проверим, что правило работает. Я зарегистрирован на сайте vk.com , зайдём туда, там много CORS-запросов. После захода, откроем вкладку "Лог блокировок".


Я вижу, что сайт загрузился, а в логе нет ни одной розовой метки. Что-то не так, наше правило не работает!
Ну конечно, я забыл ввести фильтр. Хотя правило и срабатывает на CORS-запросы, оно с ними ничего не делает :) . Давайте исправим это безобразие. Кликнем в третьей строке по левому полю.


Появится выпадающий список.


Выберем в нём фильтр "Request". (В дальнейшем я предполагаю, что в данном руководстве перед всеми фильтрами стоят значки ). (О том, что значит зелёный кружок около фильтра, появляющийся в новых версиях дополнения, мы поговорим позднее в разделе "Режимы фильтров": сейчас мы предполагаем, что у каждого фильтра именно зелёный куржок, хотя на скриншотах его нет).


Нажмём Enter. Теперь наш фильтр добавился в список фильтров правила.


Надпись "Request:0" означает, что фильтр ничего не делает. Кликнем по этой надписи, и она сменится на "Request:+". Это означает, что запрос, на который сработало правило, будет заблокирован. Теперь наше правило выглядит вот так.


Ну, теперь оно должно работать. Зайдём снова на сайт vk.com.



Как назло, ни одного CORS-запроса. Давайте проверим, может быть у нас фильтруется лог вкладки "Лог блокировок"?
Для этого зайдём в меню "Инструменты->Дополнения" и кликнем на кнопке "Настройки" дополнения.


Проверяем, что в строках logb.displayedLevels и logb.displayedLevelsNoTab стоит, наряду с другими, цифра 9, отделённая пробелом от других цифр.


Ну что ж. Стоит (если не стоит, поставьте). Значит, не удалось нам пока найти CORS-запросов. Но мы будем стараться. Пока оставим это правило, но помним, что все запросы CORS у нас запрещены.

Ещё одно кстати. Рядом с цифрой 9 должно, отделённое от неё пробелом, стоять число 10. Число 10 означает, что в лог будут выводиться ошибки при парсинге введённых правил.

Да, кстати, фильтр CORS с вкладки "HTTP" не имеет никакого отношения к нашему правилу вкладки "Сторонние". Они работают независимо (запрос блокируется, если хотя бы один из них его блокирует). Можно использовать тот фильтр, который удобней. Например, можно отключить фильтр CORS вкладки HTTP.



Раз уж мы всё равно зашли на vk.com, давайте заблокируем на нём счётчики посещаемости. И вообще, все запросы к сторонним сайтам. Счётчики посещаемости и другие запросы к сторонним сайтам могут быть как необходимы для работы сайта, так и использоваться в целях отслеживания, так и то, и другое.

Создадим новое правило. Для этого заметим значок "+" справа первой строки уже созданного нами правила "CORS". Кликнем на него, чтобы появилось новое правило.


Новое правило появилось. В новых версиях дополнения все новые правила добавляются в выключенном состоянии. Поэтому мы должны его включить (при включении правил в дальнейшем учитывайте, что лучше включать полностью настроенное правило, так как иначе на нём могут неожиданно сработать фильтры исполнения на листьях, учитывайте эту возможность, см. Режимы фильтров).

Чтобы включить правило, нужно щёлкнуть вверхнем правом углу правила, на значке "X".


Включённое правило - белое, выключенное - серое.
Введём для него имя, например, "Сторонние". Затем кликнем по центральному элементу (пустому) второй строки правила.


Введём следующее: "td[:]!=rd[:]" (без кавычек). Не забываем нажимать Enter после ввода.


Имя "td" означает, что мы ссылаемся на имя домена адреса нашей вкладки (t - tab, d - domain). "rd" - означает, что мы ссылаемся на имя домена запроса, который посылается с данной вкладки (r - request, d - domain). Запросом может быть, например, картинка, загружающаяся на вкладку в составе документа. "[:]" - означает, что нас интересует полное имя домена (например, для адреса https://www.yandex.ru/someone полное имя домена - www.yandex.ru ).
Знак "!=" говорит о том, что полное имя домена вкладки не должно быть равно полному имени домена запроса. То есть правило будет срабатывать тогда, когда, скажем, счётчик посещаемости с mc.yandex.ru будет запрошен любым документом в домене, кроме как mc.yandex.ru.
Далее, как и для предыдущего правила добавим фильтр "Request" и поставим его во включённое состояние "Request:+".



Давайте зайдём на vk.com и посмотрим, как работает это правило. Возможно, оно работает слишком жёстко, ниже будет приведён другой путь.


На вкладке "Лог блокировок" мы видим большое количество розовых отметок типа "side". А на самой странице мы видим, что аватар и другие изображения не подгрузились. Давайте сделаем так, чтобы сайт работал нормально.
В логе видим следующее: первый заблокированный запрос идёт с домена pp.vk.me . Давайте разблокируем этот домен.
Весь домен vk.me является дружественным домену vk.com, так что надо будет разблокировать сразу весь vk.me, а не только pp.vk.me.
Для этого создадим правило, работающее конкретно для vk.com.
На правиле "Сторонние" кликните на значок ">" (второй справа в верхней строке). Таким образом мы добавим подчинённое к правилу "Сторонние" правило.


Получилось примерно так:


Переименуем правило в "Сторонние.vk.com" и добавим во вторую строку условие "td[0:1] = vk.com" (без кавычек). Это означает, что правило действует для вкладки с доменом второго уровня "vk.com". Так как это правило подчинено правилу "Сторонние", то оно будет действовать только тогда, когда выполнятся условия правила "Сторонние" и домен вкладки будет vk.com.
Далее, снова кликнем на значок ">", но уже на правиле "Сторонние.vk.com", то есть создадим уже ему подчинённое правило. Введём во вновь созданное правило "Сторонние.vk.com.1" условие "rd[0:1] = vk.me" .
Получившийся результат должен быть таким:


Это означает, что правило будет срабатывать тогда, когда сработает родительское правило и домен второго уровня для запроса будет vk.me. То есть домен pp.vk.me тоже будет считаться подходящим под это условие, так как это поддомен pp на домене второго уровня vk.me.
Чтобы лучше понять, что происходит, представим себе следующее. Разобъём домен pp.vk.me на три части: me, vk, pp. Пронумеруем "me" нулём, "vk" - единицей, "pp" - двойкой. rd[0:0] берёт только нулевую составляющую - me. rd[0:1] берёт нулевую и первую составляющую - vk.me, rd[0:2] берёт три составляющие с номерами 0, 1, 2 - то есть pp.vk.me. Соответственно, rd[0:1] от, скажем, dd.vk.me будет vk.me, а rd[1:2] будет dd.vk . Буква L берёт последнюю составляющую массива.
Наше условие говорит, что если rd[0:1] будет равен vk.me, то правило срабатывает.

Теперь введём в это правило, аналогично предыдущим, фильтр Request. Однако поставим его в позицию "Request:-". Для этого нужно сделать два щелчка по фильтру с позиции "Request:0". "Request:-" означает, что мы хотим отменить срабатывание фильтра Request (то есть хотим отменить блокировку запросов к vk.me, установленную родительским правилом).



Зайдём на vk.com снова и посмотрим, что и как.
Теперь картинки снова грузятся, а количество блокировок на вкладке "Лог блокировок" стало небольшим (возможно, в нём остались блокировки с предыдущих запросов: тогда посмотрите на время этих запросов или просто закройте вкладку, а потом загрузите её заново).


Видимо, все оставшиеся запросы являются запросами к счётчикам посещаемости.
Кроме одного. Мы разрешили vk.me, но не разрешили поддомены vk.com, поэтому запрос https://queuev4.vk.com/q_frame.php?7 был заблокирован.
Кликнем на условие правила "Сторонние.vk.com.1" и вместо "rd[0:1] = vk.me" введём "rd[0:1] = vk.me | rd[0:1] = vk.com".
Это условие означает, что либо домен второго уровня нашего запроса должен быть vk.me, либо vk.com. То есть мы разрешили теперь ещё и vk.com.


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




Итак, подведём итог.
Кнопка "+" добавляет новое правило на тот же уровень, что и данное.
Кнопка ">" добавляет новое правило, подчинённое данному.
Подчинённое правило срабатывает, если выполнено условие на его срабатывание и сработало родительское правило.
td - условие на домен вкладки. rd - на домен запроса. tp - на путь вкладки, rp - на путь запроса.
После td, rd, tp, rp ставятся квадратные скобки. [:] означает полное соответствие. [0:1] берёт первые два элемента. [n1:n2] берёт элементы с n1 по n2 включительно, заглавная L берёт последний элемент. Например, если мы загружаем вкладку https://a.b.c.com/someone/d/e, то td[0:1]=c.com, td[0:2]=b.c.com, td[0:3]=td[:]=a.b.c.com, td[2:3]=a.b, td[3]=a, tp[0]=someone, tp[0:1]=someone/d, td[L]=a, rp[L]=e.
Условие CORS является условием типа obj, что должно быть отражено в настройке правила (вторая строка слева).
Условия типа td, rd, tp, rp являются условиями типа url. Этот тип условия (url) ставится в правило по умолчанию.
Однотипные условия (все - url или obj) можно разделять символом "|". Тогда правило срабатывает, если выполнено хотя бы одно условие.

Мы видим, что на сайте vk.com, как минимум, установлены следующие счётчики:
counter.yadro.ru
www.tns-counter.ru
scorecardresearch.com
mail.ru

Давайте заблокируем их так, чтобы их блокировки не отображались в логе (не мешали бы нам смотреть действительно важные вещи).

mail.ru мы блокировать без отображения в логе не будем, так как это крупный портал и можно заблокировать что-нибудь не то и потом не увидеть это в логе. А с отображением в логе он у нас уже заблокирован.

Давайте кликнем на символе ">" правила "Сторонние", чтобы добавить для него новое подчинённое правило.


Назовём это правило "Сторонние.счётчики". Если мы просто введём правило "rd[0:1]=yadro.ru", то мы заблокируем весь домен yadro.ru и никогда не сможем на него зайти. Давайте заблокируем именно домен counter.yadro.ru и только тогда, когда не заходим на домен второго уровня yadro.ru.
Так как это справедливо для всех счётчиков (что нам может потребоваться зайти на их сайты), мы можем сказать, что будем блокировать счётчики только тогда, когда они запрашиваются от сторонних по отношению к этим счётчикам сайтов. То есть td[0:1] != rd[0:1]. Давайте введём это условие в наше только что созданное правило. Теперь добавим к нему подчинённые правила (нажимая ">") для каждого домена-счётчика.


Как видно на скришноше, я создал ещё одно правило, подчинённое правилу "Сторонние.счётчики", и добавил туда условие "rd[0:2] = counter.yadro.ru" и два фильтра: Request и NoLog. Request будет фильтровать наши запросы (если они ещё не отфильтрованы), а NoLog будет определять, что срабатывание правила не нужно логировать.

Аналогично, добавляю правила с условиями "rd[0:2]=www.tns-counter.ru" и "rd[0:1]=scorecardresearch.com".


После добавления этих правил в логе блокировок остался только mail.ru. Остальные запросы к счётчикам были заблокированы, но не загрязнили логов.


Давайте теперь заменим фильтр "Куки" на вкладке "HTTP" фильтром hCookies вкладки "Сторонние" (они работают независимо). Для этого в правило "Сторонние" можно просто добавить фильтр hCookies (в состоянии "+") и отключить фильтр "Куки" на вкладке "HTTP".


Убедитесь, что состояние hCookies действительно "включён" ("+").


Теперь куки будут блокироваться для всех запросов, где полный домен (хост) вкладки не совпадает с хостом запроса. В том числе, с вкладки vk.com будут заблокированы куки запросов, идущих для pp.vk.me, так как хотя мы создали правило, отменяющее блокирование запроса фильтром Request, мы не отменяли действие фильтра hCookies.

Вообще говоря, фильтр hCookies может помешать работе сайтов и, в данном случае, не нужен, так как идёт блокировка всех сторонних запросов. Так что давайте отменим назначение фильтра hCookies. Для этого на фильтре hCookies:+ щёлкните два раза, чтобы он переключился в состояние hCookies:0. Это состояние, когда фильтр нейтрален (правило не задаёт ни условие включения фильтра, ни условие его отключения).







Теперь давайте посмотрим, есть ли для нас что заблокировать или разрешить на сайте http://huac.8vs.ru .


Мы видим несколько блокировок. Наверное, мы не будем их разблокировать (в основном, это блокировки кнопок типа "поделиться в социальных сетях").
Однако, мы видим, также, один счётчик. А именно счётчик яндекс.метрики, который мы могли бы убрать из логов.
Давайте кликнем на значке ">" в правиле "Сторонние.счётчики" и создадим ещё одно правило для стороннего счётчика с условием "rd[0:2] = mc.yandex.ru". Новое правило на скриншоте в самом низу:


Теперь запросы к yandex.метрике не будут загрязнять наши логи на этом и других сайтах.




Давайте посмотрим на работу сайта yandex.ru.
В логе мы увидим кучу блокировок запросов на домены yastatic.net и yabs.yandex.ru, и даже блокировку яндекс.метрики.
Почему мы увидели блокировку яндекс.метрики? Потому что общее правило на счётчики (это правило "Сторонние.счётчики") срабатывает при условии "td[0:1] != rd[0:1]", то есть если домен второго уровня различен для вкладки и запроса. У нас яндекс.метрика на mc.yandex.ru, а зашли мы на https://www.yandex.ru/ . То есть домен второго уровня и у вкладки, и у запроса один и тот же - yandex.ru . Поэтому правило на счётчик яндекс.метрики не сработало (но сработало на другие счётчики).

Давайте разрешим для всех запросов с домена yandex.ru запросы к доменам второго уровня yandex.ru и yastatic.net.
Для этого в правиле "Сторонние" щёлкнем по ">", чтобы создать подчинённое правило. Назовём его "Сторонние.yandex". Введём условие "td[0:1] = yandex.ru". То есть правило будет срабатывать на вкладки с доменом второго уровня yandex.ru.
Добавим подчинённое правило с условием "rd[0:1]=yandex.ru | rd[0:1]=yastatic.net" и фильтром "Request:-". То есть на вкладке, определённой родительским правилом, теперь будут разрешены запросы к хостам с доменом второго уровня yandex.ru или yastatic.net.

Вот что у нас получилось:


Если мы презагрузим страницу www.yandex.ru и посмотрим лог, то мы увидим, что блокированы ещё и запросы к yandex.net и yandex.st. Ранее эти запросы не отображались, так как, видимо, зависят от разрешённых предыдущих запросов. Давайте разрешим ещё и их. Вместо условия на последнее правило "rd[0:1]=yandex.ru | rd[0:1]=yastatic.net" сделаем условие "rd[0:1]=yandex.ru | rd[0:1]=yastatic.net | rd[0:1]=yandex.net | rd[0:1]=yandex.st".




Зайдём на mail.yandex.ru. Кажется, всё работает. Если пощёлкать по интерфейсу, всё подгружается, в логе никаких блокировок нет. Значит, настроив предыдущие правила для домена yandex.ru мы настроили достаточно для функционирования и поддомена mail.yandex.ru.
Однако, бросается в глаза одно неудобство. Правила на счётчики отображаются выше, чем наше правило для домена. Мне бы хотелось наоборот.
Для этой цели у правила есть приоритет отображения. Давайте понизим приоритет отображения правила "Сторонние.счётчики" с 5 до 6 (более высокое значение приоритета означает более низкий приоритет). Для этого кликнем на цифре "5" во второй строке этого правила.


После чего цифра сменится на "6". Мы должны перейти на другую вкладку, а потом вернутся назад на вкладку "Сторонние", чтобы порядок правил изменился при перерисовке.









Давайте воспользуемся ещё одним условием типа obj, а именно - FRAME. Заблокируем все фреймы, кроме нужного домена. Правило строится аналогично правилу CORS, только с заменой слова CORS на слово FRAME и находится на том же уровне, что и правило CORS (то есть создавать его нужно с помощью нажатия на "+" правила CORS).


Теперь правило CORS у нас высоко, а правило FRAME - низко. Давайте опустим правило CORS и, на будущее, и FRAME. Обоим установим приоритеты отображения 6.



Кстати, никогда не создавайте правило с условием FRAME, подчинённое правилу с условием CORS или наоборот: оно никогда не сработает (правда, оно и не нужно). Это связано с тем, что фильтры CORS и FRAME работают на разных стадиях фильтрации. Стадии 4: это content-policy, проходящая перед формированием запроса к web-сайту; это http request, происходящая при формировании запроса, но до его посылки; http response, происходящая после приёма http-заголовков ответа от сервера, и document - происходящая непосредственно в подгруженном документе.
Каждая стадия отрабатывает правила независимо от другой и имеет немного разные служебные данные. Условие FRAME проверяется только на стадии content-policy, в то время как CORS проверяется на стадии http request. На стадии content-policy не сработает условие CORST, а далее не сработает условие FRAME. Поэтому правило FRAME с подчинённым правилом CORS на этапе content-policy не пройдёт по условию CORS, а на следующих этапах - по условию FRAME.

Аналогично, условия ft и ct обрабатываются на разных стадиях: ft на стадии content-policy, ct на стадии http response. Поэтому их подчинение тоже никогда не сработает. То есть бесполезно писать правило с условием ft[:]=IMAGE и подчинять ему правило ct[1]=png. На этапе content-policy никогда не выполнится условие ct[1]=png, а на следующих этапах не будет выполнено условие ft[:]=IMAGE.

Для улучшения возможностей дополнения также имеются условия fta и cta. Правило с условием ft[:]=IMAGE срабатывает только на этапе "Content-policy" (перед формированием запроса к серверу), и только если ожидается получение изображения. Правило с условием fta[:]=IMAGE срабатывает на этапе "Content-policy", если FireFox ожидает получение изображения, но при этом всегда срабатывает на других этапах. То есть условие fta[:] считается всегда выполненным на этапах после "Content-policy" вне зависимости от ожидаемого типа. Аналогично работает и условие cta.


На этой картинке для вкладок домена ya.ru установлены разрешения на загрузку. При этом, фильтр с приоритетом 20 запрещает загрузку любого содержимого, в то время, как остальные правила с большим приоритетом разрешают загрузку. Правило с условием cta[:]=_@_ срабатывает тогда, когда заголовок "Content-Type" в ответе от сервера не установлен. Это бывает по разным причинам, поэтому правило-потомок устанавливает дополнительное условие: hstatus[:]=302. Это условие на то, что ответ от сервера имеет HTTP-статус 302, говорящий о перенаправлении (данное правило разрешает перенаправления на сайте). При этом условие cta[:]=_@_ срабатывает на этапах кроме этапа обработки ответа от сервера абсолютно всегда (вне зависимости от правой части уравнения). То есть условие считается всегда выполненным, пока не получен ответ от сервера. Аналогично, hstatus[:]=302 на любых этапах, кроме этапа обработки ответа, также будет считаться выполненным. В этом отличие cta от ct, который бы заблокировал выполнение запроса на других стадиях. Правило с условием cta[0]=image разрешает подгрузку изображений (работает независимо от фильтра "Изображения" вкладки HTTP). Правила fta[:]=AJAX разрешают отсылку AJAX-запросов. И т.п. Точно такие же правила, но с условиями ft и ct разрешали бы запросы только на стадии срабатывания условий ft и ct ("content-policy" и "http resplonse"), а фильтр по умолчанию блокировал бы условия в остальных случаях.


Здесь мы видим, что каскад правил с уловиями ft сработает ( например, заблокирует http-запрос, если выше установлен фильтр *vRequest:+ ), если ожидается подгрузка чего-либо, кроме страницы, ajax-запроса, фрейма или изображения. То есть этот каскад хорош, если на нём установлен блокирующий фильтр (блокируем всё, кроме заданного). Для упрощения работы с условиями ft/fta и ct/cta включены условия на фазу. Это условие phase[:]. Для фазы обработки 'content-policy' условие выглядит так phase[:]=CP (это фаза на которой принимается решение на то, формировать запрос или нет). 'document created': phase[:]=DOC (фаза обработки созданного документа, например, для блокирования в нём LocalStorage) 'http request (pre)': phase[:]=REQ PRE (фаза предварительной обработки формирующегося http-запроса) 'http request': phase[:]=REQ (повторная обработка http-запроса) 'http response': phase[:]=RESP (обработка http-ответа) Соответственно, ft срабатывает на фазе "phase[:]=CP". А ct и hstatus срабатывает на фазе "phase[:]=RESP".



Если мы зайдём снова на vk.com, то мы увидим, что задали слишком жёсткое правило - оно блокирует все фреймы и заблокировало фрейм https://vk.com на https://vk.com. Давайте удалим правила CORS и FRAME, так как всё равно общее правило "Сторонние" скорее всего заблокирует то, что нам не нужно, в том числе и сторонние фреймы.


Для удаления правила CORS нажмём на символе "X", находящемся справа в верхней строке правила. После нажатия в этой ячейке правило будет выключено и появится символ "!" и, через 2,25 секунды, символ "X?". Если вы хотите удалить правило, то нажмите на символ "X?".




Простое выключение правила доступно по нажатию на кнопку "+", находящуюся слева в первой строке правила. После выключении надпись заменяется на "X", нажатие на который приведёт к включению правила.


Выключение родительского правила исключает подчинённые ему правила из выполнения.




Фильтр Log (в состоянии Log:+) ничего не делает, однако сработавшее с таким фильтром правило попадает в лог. Удобно применять при необходимости убедится, что условие какого-либо правила выполняется. Лучше применять только при отладке фильтров (в остальных случаях пользоваться режимом логирования базового фильтра).




Выше приоритета на отображение, расположен приоритет правила (верхняя строка правила, слева от имени правила). Это цифра от 0 до 9 включительно. Если какие-либо два правила конфликтуют, то применяются приоритеты.



Приоритет подчинённых правил складывается из приоритета родительских правил и приоритета самого подчинённого правила. Например, у правила, помеченного стрелкой на скриншоте (см. выше), приоритет 555.
Если бы у родительского правила "Сторонние.счётчики" был бы приоритет не 5, а 6, то приоритет правила "Сторонние.счётчики.yadro.ru" был бы 565. Если бы у правила "Сторонние" был бы приоритет 4, то приоритет правила "Сторонние.счётчики.yadro.ru" был бы 465. Правило даёт всем фильтрам, описанным в нём, свой приоритет. Например, у правила "Сторонние.счётчики" вообще нет фильтров и оно ни с кем не конфликтует, у правила "Сторонние.счётчики.yadro.ru" есть два фильтра: Request и NoLog, каждый из которых имеет приоритет 555, как и у правила.
Фактически, правила между собой не конфликтуют, конфликтуют только фильтры. Например, если для одного и того же запроса одно правило указало фильтры Request:+ и NoLog:+, а другое Request:-, то фильтр NoLog:+ выполнится в любом случае, а фильтры Request:+ и Request:- будут конфликтовать.
Приоритет 4 выше приоритета 5, то есть будут применяться фильтры, имеющие приоритет 4.
Приоритет из нескольких цифр просматривается слева на право. Применяется тот, у кого первая несовпавшая цифра меньше. Например, применяется приоритет 45, а не 46. То есть первые несовпавшие цифры - 5 и 6, 5 меньше шести, следовательно применяется правило 45. То есть 46 < 45 в плане приоритета.
При совпадении цифр приоритетов в правиле, применяется более длинный приоритет (555 > 55).

Например, правило с приоритетом 565 установило фильтры Request:+ и NoLog:+. Правило с приоритетом 56 установило фильтр Request:-. Фильтр NoLog:+ будет выполнен, так как ни с кем не конфликтует. Фильтр Request:+ будет выполнен, так как его приоритет 565 выше приоритета 56 (приоритет 565 длиннее). То есть 56 < 565.
Ещё примеры. 565 < 560. 555 < 54. 555 > 56. 55 > 56.




Правила вкладки "Сторонние" сохраняются в открытом тексте в директории профиля FireFox. При старте дополнения (старте FireFox) дополнение выдаёт примерно следующее сообщение:
HUAC open settings file C:\Users\userName\AppData\Roaming\Mozilla\Firefox\Profiles\d4u9e1pq.default-4853290104847\HTTPUACleaner\HttpUserAgentCleaner.opt
Это точный путь к настройкам этой вкладки (но не других вкладок). Это сообщение выдаётся только при включённой настройке debug.writeSettingFilePathes.

Сохранение идёт открытым (нешифрованным) текстом в формате JSON. Если вам не хочется, чтобы правило сохранялось, вы можете создавать временное правило. Для этого при нажатии на "+" или ">" при создании правила удерживайте клавишу shift. Аналогично, правило можно превратить во временное, если кликнуть на символ выключения правила "+" (слева первой строки) с нажатым shift. Временное в постоянное - аналогично на временном правиле.
Все правила, подчинённые временному не сохраняются, даже если они не обозначены как временные.
При перезапуске дополнения или FireFox такие правила исчезнут.







Нужно ли нам такое суровое правило "Сторонние"? Например, когда мы заходим на yandex.ru оно блокирует и запросы к mail.yandex.ru (мы уже переопределили его выше подчинёнными правилами так, чтобы не блокировало). Вряд ли нам так уж хочется блокировать на домене a.com поддомены типа mail.a.com, ведь, очевидно, это дружественные друг другу домены. Хотя бы потому, что заходя на a.com мы ожидаем, что b.a.com - также подчинён ему. Вообще говоря, такая логика содержит изъян, так как, скажем, некоторые хостинги дают возможность создавать сайты на поддоменах своего домена. Тогда домен a.hosting.com будет совсем не подчинённым домену hosting.com. Если вы хотите пренебречь этим, то вы можете настроить правило "Сторонние" следующим образом.

Само правило "Сторонние" у нас определено как правило с условием "td[:]!=rd[:]" и фильтром Request:+. Мы можем оставить правило "Сторонние" как есть. Создадим ему подчинённое правило "Сторонние.лёгкий сёрфинг".
Для этого правила создадим подчинённое правило "Сторонние.лёгкий сёрфинг.домен второго уровня".
Сделаем так, чтобы оно не блокировало домены третьего уровня на вкладке с доменом второго уровня. Для начала добавим условие "td[2]=_@_". Это условие на то, что во вкладке отсутствует домен третьего уровня, то есть, скажем, домен yandex.ru, но не www.yandex.ru или mail.yandex.ru. Вы также можете определить условие как "td[2]=_@_ | td[2]=www", чтобы для доменов типа a.ru и www.a.ru правило срабатывало идентично. Далее, мы добавляем правило, подчинённое уже для этого правила, с условием "td[0:1]=rd[0:1]". То есть в запросе должен сохраняться домен второго уровня такой же, как и на вкладке. Уже в этом правиле мы ставим фильтр Request:- (обратите внимание, нужно поставить фильтр Request именно в состояние "-"). При срабатывании, такой фильтр может не попасть в лог, так как он отменяет действие фильтра Request:+ . То есть это будет отсутствие реакции со стороны дополнения и это отсутствие реакции не будет залогировано. Если вы хотите, чтобы такое срабатывание попало в лог, добавьте фильтр Log:+ .

Из-за того, что это правило менее строгое, в частности, проще осуществить идентификацию ваших dns (атака DNS leak). Его можно выключить до поры до времени, а потом включить, если понадобится быстро и временно включить более простые блокировки, например, когда вы читаете новости. А затем, снова выключить его, чтобы вернуть более строгие блокировки.







Бывают ли сайты, которые лучше разблокировать?
Некоторые сайты предоставляют доступ к разделяемому контенту, например, ajax-библиотекам, изображениям. В таком случае, такие сайты, возможно, вы захотите разблокировать. Однако, это означает, что разблокированный сайт сможет сделить за вашей активностью.
Давайте разблокируем для запросов домены googleapis.com и gstatic.com .
Добавим к правилу "Сторонние.лёгкий сёрфинг" ещё одно подчинённое правило с названием "Сторонние.лёгкий сёрфинг.разделяемые". А для него добавим подчинённое правило с названием "Сторонние.лёгкий сёрфинг.разделяемые.google". Добавим в это правило условие "rd[0:1]=googleapis.com | rd[0:1]=gstatic.com". Поставим фильтр Request:- . То есть разрешим запросы с любого домена на googleapis.com и gstatic.com .


Теперь, выключая правило "Сторонние.лёгкий сёрфинг" мы будем выключать все подчинённые ему правила, обеспечивая более строгий уровень блокировок.

Обратите внимание, что, обычно, таким сайтам не нужно получать никаких куков. Поэтому в правило "Сторонние.лёгкий сёрфинг.разделяемые.google" мы можем добавить фильтр hCookies:+ , чтобы препятствовать отслеживанию через куки (однако, всё равно возможности для отслеживания у такого сайта несоизмеримо выше, чем если к нему не направляются запросы вообще).

Если есть желание, также можно создать правило с условием "rd[:]=www.google.com" и подчинённым правилом с условием "rp[0]=jsapi" (разрешает "www.google.com/jsapi/").


Давайте, чтоб не мешало, свернём правило "Сторонние.лёгкий сёрфинг". Для этого кликнем на втором слева элементе первой строки правила.


Получим примерно это.




Если мы зайдём на некоторые сайты, скажем, ria.ru, то увидим, что справа во второй строке показывается последняя дата срабатывания фильтра. Это значит, что фильтр работает. Под датой указано количество правил, подчинённых данному, но не показанных (на каждой вкладке не показываются правила, нерелевантные адресу вкладки).


Допустим, на новостном сайте есть кнопка перепоста или комментирования новости в твиттер или vk.com . Чтобы эта кнопка работала вам нужно будет разрешить доступ этого сайта на vk.com, userapi.com, vk.me (возможно, ещё на ряд сайтов) для использования vk.com, и на ряд доменов твиттера, чтобы пользоваться твиттером. Разрешения делаются аналогично описанным выше, однако такие разрешения позволят этим сайтам очень сильно отслеживать ваши действия на тех сайтах, где есть их кнопки или другие элементы.
Также надо учесть, что на такие сайты фильтр hCookies:+ применять нельзя, так как для корректного выполнения запросов к социальным сетям обычно требуется авторизация.




Для дополнительной защиты вы также можете создать несколько правил. Например, вы зарегистрированы на yandex.ru, vk.com и livejournal.com . Вы можете создать две группы правил с повышенным приоритетом (например, 4), одна из которых будет блокировать всё (Request:+ без условия) и содержать подчинённые правила для разрешения указанных доменов (Request:-). Другая будет, наоборот, блокировать загрузку этих сайтов или отсылку куков на них (Request:+ или hCookies:+).
В таком случае вам обеспечена защита от случайного попадания на эти сайты или попадания на эти сайты, вызванного работой вредоносного скрипта.

Вот так это может выглядеть.
Запрещающие правила:


Разрешающие правила:


При этом будет требоваться переключение между правилами вручную: когда вы заходите на почту или в социальную сеть, вам придётся включать один тип правил (правила "Избранные") и выключать другой ("Избранные/запрет"); когда переходите к интернет-сёрфингу делать наоборот: выключать первый тип правил (правила "Избранные") и включать второй ("Избранные/запрет").

Это не очень удобно настраивать, так как, фактически, требуется дублирование правил, но если хочется немного повысить безопасность, то можно сделать. Если у вас нет паранойи, то это не требуется.

При настройке правил обратите внимание на то, что на картинке правила "Избранные" настроены по вкладке (td), а потом уже по фильтрации запросов, в то время как правила "Избранные/запрет" настроены на запрет любого запроса (rd) к избранным сайтам вне зависимости от вкладки, так как они призваны защитить вас от CSRF-атак на эти сайты с любой вкладки. Также необходимо понимать, что иногда у сайтов есть зеркала (то есть они доступны по двум доменам) или дополнительные служебные домены (например, для vk.com это vk.me). При блокировании сайта нужно убедиться, что остальные домены также заблокированы либо что запросы на них не отсылают куков основного сайта.
Для этого можно выполнить запросы на эти дополнительные домены при блокировке основного и посмотреть:
1. В любом логгере http-запросов: имеются ли куки, которые отсылаются на этот сайт (например, подойдёт дополнение HttpFox).
2. Посмотреть в контекстном меню загруженной страницы информацию по пункту "Информация о странице", вкладка "Защита", кнопка "Просмотреть куки".
Если есть неуверенность, то можно просто запретить все связанные домены (Request:+) или отсылку на них куков (hCookies:+).

Также необходимо понимать, что при блокировании всех доменов, кроме заданных, могут быть заблокированы и домены Mozilla, а также установленных дополнений, что может повлечь за собой невозможность (во время включения этого правила) обновления браузера и нарушение работы дополнений. Например, прокси-дополнения не смогут получить список прокси-серверов и установить с ними связь, а AdBlockPlus не сможет обновить списки блокирования рекламы. Для того, чтобы разрешить такие обновления, настройте панель "Сторонние" так, как описано в настройка разрешения сервисных соединений и перенаправления на https

Более безопасно при работе в интернете выходить из аккаунтов сразу же, как только вы закончили их использование.




Зачем нужен фильтр iCookies?
Фильтр iCookies:+ с условием на url "td[:]!=rd[:]" будет изолировать только сторонние запросы так, что следящим системам будет казаться, что у вас есть куки, но они не смогут вас ослеживать по ним длительно (не более, чем указано в настройке фильтра "Интервал" вкладки "HTTP"). Кроме этого, они не смогут вас отслеживать одновременно на нескольких вкладках с совершенно разными сайтами, так как на запросы с вкладок, открытых с разных хостов, им будут отсылаться разные куки. Последнее справедливо и для iCookies:I . Кроме этого, если установить для всех сайтов без условия на url любой режим фильтра iCookies, то фильтр позволяет просматривать страницы, оставляя куки и содержимое объектов localStorage и sessionStorage изолированным от основного хранилища куков и Storage в FireFox как будто вы работаете в приватном режиме.

Фильтр iCookies в положении "+" позволяет временно принимать куки с сайтов и сбрасывать их в соответствии с настройкой фильтра "Интервал" (каждые n минут или чаще; см. вкладку HTTP). Синхронно меняются и другие настройки, зависящие от фильтра "Интервал" (например, User-Agent). Фильтр "Интервал", к сожалению, не даёт полной иллюзии смены одного браузера на другой, так как в его работе всё-таки есть определённая несинхронность.
Итак, iCookies:+ принимает куки с сайта, а потом, через некоторое время, сбрасывает их. То есть, например, если вы вошли на сайт с логином и паролем с фильтром iCookies:+, то вы некоторое время будете узнаваться этим сайтом. А затем куки сбросятся и сайт перестанет вас узнавать.
iCookies:I не сбрасывает куки раз в n минут. В остальном он работает аналогично iCookies:+ . Он принимает куки, но изолирует их от обычного механизма работы FireFox так, что FireFox не запоминает их дольше, чем на сессию (то есть пока открыт FireFox), и отдаёт только при запросах с вкладок с одним и тем же хостом (или его доменом второго уровня). Таким образом, FireFox не сохранит эти куки, аналогично, как если бы вы работали в приватном режиме браузера. Кроме этого, iCookies:I сбрасывает все куки, установленные на хосте, если вы закрыли все вкладки с этим доменом второго уровня (например, если вы закрыли все вкладки yandex.ru, то есть и mail.yandex.ru, и translate.yandex.ru и т.п.).
Это не заменяет приватный режим браузера, кроме этого, таким образом вы не сможете войти на порталы с большим количеством хостов, которые объединены одной аутентификацией или используют аутентификацию на сторонних сайтах. Например, на yandex.ru, blogspot.ru или google.com . Для них такой фильтр необходимо отключить или переключить в режим I1, I2 или I3 (см. описания ниже).

Настроить фильтр iCookies в режиме I1 (или I2, или I3) для успешного комментирования на сервисе blogspot.ru довольно затруднительно, так как при этом используется целый ряд доменов, причём с используемого для отображения блога blogspot.ru при отсылке коментария идёт перенаправление на blogger.com, поэтому, скорее всего, после первой настройки комментарий послан не будет (потому что мы заранее не знаем, что нужно включить iCookies:I1 ещё и для blogger.com).
Для отсылки придётся установить iCookies:I1 для целого ряда доменов: "td[:2]=accounts.google.com | td[:2]=security.google.com | td[:2]=myaccount.google.com | td[:1]=blogspot.ru | td[:1]=blogger.com". А также разрешить запросы в правилах "Сторонние". Причём устанавливать iCookies:I1 нужно не в правилах, подчинённых правилу "Стороние", так как эти правила срабатывают только если "td[:]!=rd[:]", а iCookies:I1 должны срабатывать в любом случае.







Режимы I1, I2 и I3 изолируют куки только от FireFox и других режимов. Однако, в одном и том же режиме, вкладки видят куки друг друга. Например, если blogspot.ru и accounts.google.com (а также myaccount.google.com и security.google.com) работают в режиме I1, то на blogspot.ru можно будет оставлять комментарии из-под аккаунта google, если вы залогинены в accounts.google.com именно под режимом I1. Если же они работают в разных режимах (например, I1 и I2), то они не будут видеть куки друг друга. Куки режимов I, I1, I2, I3 сбрасываются в случае, если закрыть все приватные окна браузера (если они не открыты - открыть приватное окно и закрыть его).

К сожалению, фильтр iCookies не совместим с работой дополнения self-destructing-cookies (последнее удаляет видоизменённые фильтром куки). Поэтому при обычном сёрфинге, возможно, стоит использовать дополнение self-destructing-cookies, когда же вам нужно перейти в режим периодического сброса куков, дополнение self-destructing-cookies необходимо отключить из панели дополнений и включить фильтр iCookies. В принципе, iCookies заменяет self-destructing-cookies, хотя и значительно менее удобен.

Даже если фильтр LocalStorage отключён, iCookies автоматически включает его. При этом, объекты localStorage и sessionStorage будут хранить запомненные объекты аналогично режиму сохранения куков.
Если включён фильтр document.cookie, то куки из объекта document.cookie по-прежнему не будут доступны. Если он выключен, то, при включённом фильтре iCookies, объект document.cookie будет имитировать свою обычную работу, но работать с подменой куков.



Если вы заходите на какой-то сайт, и после нажатия кнопки или просто так, сайт начинает снова загружать то же самое содержимое, не соответствующее нажатию кнопки, то, возможно, проблема в фильтре iCookies.
Например, сайт m.vk.com при загрузке в цикле постоянно запрашивал некоторые файлы. Всё это выглядело просто как долгая загрузка страницы. После отключения фильтра "document.cookie" на вкладке "HTTP" ситуация разрешилась.
При попытке зайти на http://slonohrom.livejournal.com/1192.html , сайт выдавал запрос на подтверждение о том, что вам 18-ть. Однако после нажатия на кнопку, сайт снова выдавал этот же запрос (проблема была решена перепрограммированием поведения фильтра iCookies, однако в другом случае, могло бы быть так, что пользователь вынужден был бы просто отключить фильтр).




При добавлении правил для текущей вкладки, можно использовать клавиши F1 и F2 (после выделения поля ввода условия). F1 добавляет в условие правила строку вида "td[:]=домен вкладки", а F2 строку вида "td[:1]=домен вкладки второго уровня". В имя правила добавляется домен и домен второго уровня без td[*].
При нажатии клавиши F9 после выделения поля ввода условия правила условие ввода заменяется на условие равенства текущему хосту, а к правилу добавляются подправила. При повторном нажатии, если условия правил не изменялись, будут добавлены только вновь появившиеся правила.




Работа с локальными файлами в расширении не удобна. Для того, чтобы понять, что во вкладку загружен локальный файл, можно использовать правило вида "tprot[:]=file". Чтобы понять, что запросом загружается локальный файл "rprot[:]=file". При этом, для файла "D:/somefile.html", td[:] и rd[:] будет равно "D" (то есть хост выделяется по тем же правилам, как будто это http-запрос). rp[:] и tp[:] будут равны "somefile.html".




Если вы ошиблись при вводе правила, то синтаксический анализатор правила, возможно, укажет вам на ошибку. Анализ на наличие ошибки производится упрощённо, поэтому ошибочное правило не всегда подсвечивается.
Если ошибка найдена, центральная строка правла с ошибкой будет подсвечена красным. А родительские правила будут выделены красным снизу справа.



Для упрощения кода дополнения, подсветка осуществляется не сразу при добавлении или изменении правила, а только при перерисовке всей вкладки "Сторонние" (при наведении на неё мыши).




Мы не рассмотрели здесь Режимы фильтров (о зелёных кружках и красных треугольниках).

Также не рассмотрены условия правил ct и ft. Эти условия работают аналогично условиям типа rp, rd, td, tp, однако определяют условие не на адрес, а на тип содержимого.
ft - это тип ожидаемого FireFox содержимого (работает только на этапе content-policy, см. выше). Перед загрузкой он передаёт ожидаемый тип дополнению. ft игнорирует индексы, то есть ft[:] тоже, что и ft[0]. Типы содержимого для дополнения называются так:

PAGE - запрос для загрузки web-документа (страницы)
FRAME - запрос для загрузки фрейма (страницы в другой странице)
OTHER - запросы, не классифицированные FireFox как запросы другого типа
SCRIPT - скрипт (программа, которая исполняется на странице и обеспечивает её динамическое изменение)
IMAGE - изображение
IMAGESET - изображение, представленное как группа изображений разного размера, одно из которых загружается браузером по собственному усмотрению
CSS - таблица стилей (набор правил отображения страницы: без них страница может быть неверно отображаться, элементы занимать неверные позиции и т.п.)
AJAX - запрос, сгенерированный скриптом со страницы (без перезагрузки страницы) через объект XMLHTTPRequest
BEACON - аналогично AJAX, но через другой программный интерфейс, используется значительно реже
FETCH - аналогично AJAX, но через другой программный интерфейс с большими возможностями для web-программиста
SUBREQUEST - некоторые запросы, делаемые плагинами, в том числе запросы видео, могут быть этого типа, а не типа MEDIA
MEDIA - аудио и видео
CSPR - отчёт о нарушении content security policy (правила на содержимое страницы для повышения безопасности), которая установливается сайтом
XSLT - шаблон для преобразования xml-данных (фактически, web-страница, образующаяся из xml по некоторым правилам)
OBJECT - такие запросы FireFox даёт, когда подгружает объекты типа flash и т.п. Это может быть как реклама, так и полезное содержимое, например, flash-проигрыватель видео.
Другие элементы без расшифровки: 'PING', 'XBL', 'DTD', 'WM' - web manifest

Все названия должны быть написаны заглавными буквами.


Фильтр ct является фильтром по типу содержимого (работает только на этапе http response, см. выше), заявленного web-сервером. Этот тип может использоваться FireFox для принятия решения об обработке конкретного содержимого. Например, html-страница имеет тип text/html, css-правила типа text/css, обычный текстовый файл text/plain, OCSP-ответы тип application/ocsp-response, сведения об обновлении дополнений FireFox - application/rdf+xml или application/rdf, javascript-файлы обычно имеют типы text/javascript, text/js, text/x-javascript, application/x-javascript, application/javascript, application/js и используемые ими для передачи файлы json-формата типы application/json, application/x-json, text/x-json, text/json. Вам также часто могут встретится файлы типов application/xhtml+xml, application/xml, text/xml, application/xml, text/x-cross-domain-policy без которых могут не работать сложные сайты. Изображения имеют формат, начинающийся с image/, например, image/gif или image/png. (Для блокирования изображений лучше использовать фильтр вкладки HTTP)

ct[:] представляет собой полную строку с типом, полученным от сервера. Например, "text/html; charset=utf-8" (без кавычек).
ct[0:1] в таком случае будет text/html. ct[0]=text, ct[1]=html. Тип содержимого можно увидеть на вкладке TLS log. Если тип не указан, на вкладке TLS log он будет обозначен как undefined, но ct в таком случае будет "_@_" (без кавычек).




Сайты, которые, возможно, потребуется разрешить для "лёгкого сёрфинга" (то есть с фильтрами Request:- hCookies:+).
rd[0:1]=yastatic.net | rd[0:1]=yandex.st
    rp[0]=jquery
rd[0:2]=code.jquery.com
rd[0:1]=googleapis.com | rd[0:1]=gstatic.com
rd[:]=www.google.com
    rp[0]=jsapi



Не забудьте определить таже правила для успешного посещения сайтов Mozilla (Request:- NoLog:+ hCookies:+).
td[0:1]=mozilla.org
    rd[0:1]=mozilla.org | rd[0:1]=mozilla.com | rd[0:1]=mozilla.net



Какие ещё сайты отслеживают ваши действия в интернете так или иначе? Перечислим некоторые условия, включая уже перечисленные выше (см. рассказ о правиле "Сторонние.счётчики").

rd[0:2]=counter.yadro.ru
rd[0:2]=www.tns-counter.ru
rd[0:1]=scorecardresearch.com
rd[0:2]=mc.yandex.ru
rd[0:1]=rambler.ru
rd[0:2]=st.top100.ru
rd[0:1]=flagcounter.com
rd[0:1]=hotlog.ru
rd[0:1]=criteo.com
rd[0:1]=adfox.ru
rd[0:1]=adriver.ru
rd[0:1]=google-analytics.com
rd[0:1]=googleadservices.com
rd[0:1]=googlesyndication.com
rd[0:1]=googletagmanager.com
rd[0:1]=googletagservices.com
rd[0:1]=doubleclick.net
rd[0:1]=openstat.net
rd[0:1]=xiti.com
rd[0:1]=utarget.ru
rd[0:1]=tynt.com
rd[0:1]=adwired.mobi | rd[0:1]=adwired.net
rd[0:1]=i-vengo.com
rd[0:1]=index.ru
rd[0:1]=newsinc.com
rd[0:1]=mediametrics.ru
rd[0:1]=admarvel.com
rp[0]=adfox
rd[0:1]=begun.ru
rd[0:1]=zarabotki.ru
Более сложные правила с подчинёнными правилами
rd[0:1]=mail.ru
    rp[0]=counter
rd[0:2]=top.list.ru
    rp[0]=counter

Это лишь немногие из известных рекламных и иных сайтов. Совершенно не обязательно добавлять их всех, если остальные правила работают так, как описано выше, так как тогда все сторонние ресурсы будут заблокированы. Достаточно только добавить правила для тех доменов, которые вы хотите не видеть в логах.



Главная страница
Общие слова
Раздел "Функции вкладок HTTP и FireFox"

Раздел "Функции вкладки 'Сторонние'"
Настройка разрешения сервисных соединений и перенаправления на https
Режимы фильтров

Раздел "Общие настройки дополнения"
Раздел "Управление сертификатами"
Раздел "Контроль изменений сертификатов" (фильтр Certs)
Раздел "Чтение оценки TLS и HPKP" (фильтр CertsHPKP)

Проблемы с фильтрами, часто не отображающиеся в логах

Новости