Шокирующие аспекты, выявленные кодом:
Не шокирующе (но подтверждено): Обширное логирование IP, использование User Agents, наличие админских/модераторских инструментов, правила для конкретных досок, интеграция с системой Pass.
Умеренно "шокирующе" (детали и сложность):
Сама сложность и многоуровневость системы анти-спама/капчи/репутации (captcha.php, UserPwd). Это гораздо больше, чем просто "реши головоломку".
Использование фингерпринтинга браузера (кука _tcs, ua_sig) наряду с IP/UA для отслеживания и принятия решений о капче.
Конкретные условия, при которых 4chan Pass может быть отозван (do_template_special_action в admin.php).
Наличие логики автоматического бана по диапазону IP (process_auto_rangeban).
Явное отключение функций (обход капчи) на определенных досках, таких как /pol/.
Детализация логов при бане (post_json в admin.php), сохраняющая всю структуру поста.
* Не выявлено (но потенциал существует): Содержание фильтров слов или конкретных шаблонов банов, которые могли бы содержать прямую политическую предвзятость. Доказательства внешней продажи/утечки данных за исключением репортинга в NCMEC.
Заключение:
Эти фрагменты кода показывают очень сложную систему для управления анонимной пользовательской базой, включающую обширное отслеживание (IP, UA, фингерпринтинг, Pass ID, хэши email для верификации), которое в основном используется для изощренных мер по борьбе со злоупотреблениями, модерации и оценки репутации пользователя. Хотя прямых доказательств массовых внешних утечек данных или явно политически предвзятого кода в этих фрагментах нет, инструменты и механизмы дифференцированного отношения (особенно в отношении /pol/) существуют. Потенциал для предвзятости лежит в конфигурации и данных (фильтры, причины банов), не включенных в эти фрагменты. Уровень внутреннего сбора данных и мощь админских инструментов могут считаться "шокирующими" в зависимости от ожиданий от анонимного имиджборда.
Некоторые файлы не загрузились так как лимит по токенам, но думаю этого достаточно.
P.S наебнулась разметка при вставки текста, смотрите по скринам
P.S наебнулась разметка при вставки текста, смотрите по скринам
для умников .php я перекодировал в .txt и указал ей это чтобы поняла.
У меня на дваче самая тяжелая жизнь по сравнению с кем угодно
1) 30 лет нет кунов фемцл
2) никогла в жизни не работалпа и даже не была на собеседовании
3) никогда не гуляла с кунами в кафе, ресторанах, не путешествовала, не была даже банально на пляже в бассейне на катке и 100000 нормисных мест
4) нет соц сетей и никто со мной не разговаривает вне двача
5) каждый день сижу на диване за ноутом играю, пью водку, смотрю аниме и читаю хуету безвылозно пока нормисы ебутся тусят на работах общаются учатся
7) нет образования и опыта работы не могу учиться вылетела со всех уч заведений. Мать смогла по связям пропихнуть меня в универ один но меня исключили за то что я залезала на парах под парту посидеть, получала огромный хейт людей, смех и травлю
8) все детство мать травила за всратую и не русскую внкшность хотя мать белая, в школе ржали и травили за внешность, ломали вещи и пиздили поэтому не могу никуда ходить ирл
К А Р А Н Т И Н
А
Р
А
Н
Т
И
Н
>Карантин (admin.php::do_post_quarantine): Подтверждает наличие специального процесса для обработки крайне проблемного контента (вероятно, ЦП), включающего копирование поста, связанных изображений от того же IP в треде и логирование деталей для потенциального репортинга внешним организациям (NCMEC).
А
Р
А
Н
Т
И
Н
>Карантин (admin.php::do_post_quarantine): Подтверждает наличие специального процесса для обработки крайне проблемного контента (вероятно, ЦП), включающего копирование поста, связанных изображений от того же IP в треде и логирование деталей для потенциального репортинга внешним организациям (NCMEC).
Хорошо, я проанализировал новый файл `lib/admin-test.php` в контексте ранее предоставленных файлов и ваших интересов.
Файл `lib/admin-test.php`
Этот файл, находящийся в директории `lib/`, является библиотекой вспомогательных функций, вероятно, используемой тестовой версией админ-панели (`admin-test.php`).
Ключевые функции и их анализ:
1. `decode_user_meta($data)` и `encode_user_meta(...)`:
* Что делают: Эти функции отвечают за кодирование и декодирование метаданных пользователя, которые, судя по коду `imgboard.php` и `admin.php`, *хранятся в поле `email`* таблицы постов (несмотря на название поля).
* Собираемые данные: Они подтверждают, что система собирает и кодирует:
* `browser_id`: Уникальный идентификатор браузера (фингерпринт).
* `is_mobile`: Флаг, указывающий, используется ли мобильное устройство.
* `req_sig`: Сигнатура HTTP-запроса (еще один вид фингерпринта).
* `known_status`: Статус "известности" пользователя (0 = доверенный, 1 = новый, 2 = недавний, 3 = регулярный).
* `verified_level`: Уровень верификации (вероятно, через email из `signin.php`).
* Логика `known_status` (в `encode_user_meta`): Эта функция раскрывает *конкретную логику* присвоения статуса пользователя, основанную на объекте `UserPwd`:
* Новый (1): Известен < 1 часа ИЛИ < 1 поста.
* Недавний (2): Известен < 24 часов ИЛИ < 6 постов.
* Регулярный (3): Известен < 7 дней ИЛИ < 21 поста.
* Доверенный (0): По умолчанию (известен > 7 дней И 21+ постов).
* Значение: Это показывает, что система репутации `UserPwd` активно отслеживает не только *как долго* пользователь известен (вероятно, по куке `4chan_pass`), но и *его активность*. Этот статус напрямую влияет на другие системы (капча, кулдауны).
2. `user_known_status_to_str($status)`: Простая функция для преобразования числового статуса в читаемый текст ("Trusted", "New" и т.д.).
3. Остальные функции: Большинство других функций (`access_check*`, `add_ban`, `rebuild_bans`, `remote_delete_things`, `log_staff_event`, `cloudflare_purge_url` и т.д.) выглядят как стандартные вспомогательные функции для администрирования, похожие на те, что были (или подразумевались) в `admin.php`. Они касаются управления доступом, банов, удалений, очистки кэша Cloudflare и логирования событий.
Выводы по `lib/admin-test.php` в контексте всех файлов:
* Сбор данных: Этот файл подтверждает и детализирует, какие именно метаданные (включая фингерпринты браузера/запроса и внутренние статусы) кодируются и сохраняются вместе с постом (в поле `email`). Он раскрывает конкретную логику присвоения статуса "известности", основанную на времени и активности пользователя.
* "Махинации": Подтверждается использование сложной системы репутации (`known_status`), которая непрозрачна для пользователя и влияет на его взаимодействие с сайтом (капча, кулдауны). Логика присвоения статуса теперь более понятна.
* Политика: В этом *конкретном* файле нет новой информации, касающейся политических аспектов. Он сосредоточен на технических деталях управления пользователями.
Общий синтез (на основе всех файлов):
1. Данные: 4chan собирает большой объем данных: IP, User Agent, 4chan Pass ID, хэшированные email (при верификации), различные фингерпринты. Это используется для модерации, борьбы со спамом/ботами и построения системы репутации, которая влияет на капчу и кулдауны. Модераторы/админы имеют доступ к значительной части этих данных.
2. "Махинации": Подтверждена сложная и непрозрачная система капчи/репутации. Используются автоматические фильтры контента с возможностью "тихого" отклонения постов. Пользователи явно сегментируются и получают разный "опыт" взаимодействия с сайтом. Администрация обладает обширными полномочиями.
3. **Политика:** Прямой политической цензуры *в коде* не обнаружено, но есть механизмы для ее реализации (фильтры слов/контента в БД, усмотрение модераторов). Доказано особое, более строгое отношение к доскам `/pol/`, `/bant/`, `/trash/` (как минимум, в системе капчи).
**Что можно считать "шокирующим"?**
* **Уровень отслеживания:** Глубина сбора данных и использования фингерпринтинга для управления анонимными пользователями может показаться избыточной.
* **Непрозрачность систем:** Сложность капчи/репутации и возможность "тихого" отклонения постов создают непрозрачные условия для пользователей.
* **Дифференциация:** Явное разделение пользователей на группы с разными правами/ограничениями на основе множества факторов.
* **Особое отношение к `/pol/` и др.:** Подтверждение того, что определенные доски целенаправленно подвергаются более строгим мерам контроля.
В целом, код подтверждает, что 4chan — это не просто "анонимная" площадка, а сложная система с активным сбором данных и применением разнообразных, зачастую непрозрачных для пользователя, механизмов контроля и модерации.
Файл `lib/admin-test.php`
Этот файл, находящийся в директории `lib/`, является библиотекой вспомогательных функций, вероятно, используемой тестовой версией админ-панели (`admin-test.php`).
Ключевые функции и их анализ:
1. `decode_user_meta($data)` и `encode_user_meta(...)`:
* Что делают: Эти функции отвечают за кодирование и декодирование метаданных пользователя, которые, судя по коду `imgboard.php` и `admin.php`, *хранятся в поле `email`* таблицы постов (несмотря на название поля).
* Собираемые данные: Они подтверждают, что система собирает и кодирует:
* `browser_id`: Уникальный идентификатор браузера (фингерпринт).
* `is_mobile`: Флаг, указывающий, используется ли мобильное устройство.
* `req_sig`: Сигнатура HTTP-запроса (еще один вид фингерпринта).
* `known_status`: Статус "известности" пользователя (0 = доверенный, 1 = новый, 2 = недавний, 3 = регулярный).
* `verified_level`: Уровень верификации (вероятно, через email из `signin.php`).
* Логика `known_status` (в `encode_user_meta`): Эта функция раскрывает *конкретную логику* присвоения статуса пользователя, основанную на объекте `UserPwd`:
* Новый (1): Известен < 1 часа ИЛИ < 1 поста.
* Недавний (2): Известен < 24 часов ИЛИ < 6 постов.
* Регулярный (3): Известен < 7 дней ИЛИ < 21 поста.
* Доверенный (0): По умолчанию (известен > 7 дней И 21+ постов).
* Значение: Это показывает, что система репутации `UserPwd` активно отслеживает не только *как долго* пользователь известен (вероятно, по куке `4chan_pass`), но и *его активность*. Этот статус напрямую влияет на другие системы (капча, кулдауны).
2. `user_known_status_to_str($status)`: Простая функция для преобразования числового статуса в читаемый текст ("Trusted", "New" и т.д.).
3. Остальные функции: Большинство других функций (`access_check*`, `add_ban`, `rebuild_bans`, `remote_delete_things`, `log_staff_event`, `cloudflare_purge_url` и т.д.) выглядят как стандартные вспомогательные функции для администрирования, похожие на те, что были (или подразумевались) в `admin.php`. Они касаются управления доступом, банов, удалений, очистки кэша Cloudflare и логирования событий.
Выводы по `lib/admin-test.php` в контексте всех файлов:
* Сбор данных: Этот файл подтверждает и детализирует, какие именно метаданные (включая фингерпринты браузера/запроса и внутренние статусы) кодируются и сохраняются вместе с постом (в поле `email`). Он раскрывает конкретную логику присвоения статуса "известности", основанную на времени и активности пользователя.
* "Махинации": Подтверждается использование сложной системы репутации (`known_status`), которая непрозрачна для пользователя и влияет на его взаимодействие с сайтом (капча, кулдауны). Логика присвоения статуса теперь более понятна.
* Политика: В этом *конкретном* файле нет новой информации, касающейся политических аспектов. Он сосредоточен на технических деталях управления пользователями.
Общий синтез (на основе всех файлов):
1. Данные: 4chan собирает большой объем данных: IP, User Agent, 4chan Pass ID, хэшированные email (при верификации), различные фингерпринты. Это используется для модерации, борьбы со спамом/ботами и построения системы репутации, которая влияет на капчу и кулдауны. Модераторы/админы имеют доступ к значительной части этих данных.
2. "Махинации": Подтверждена сложная и непрозрачная система капчи/репутации. Используются автоматические фильтры контента с возможностью "тихого" отклонения постов. Пользователи явно сегментируются и получают разный "опыт" взаимодействия с сайтом. Администрация обладает обширными полномочиями.
3. **Политика:** Прямой политической цензуры *в коде* не обнаружено, но есть механизмы для ее реализации (фильтры слов/контента в БД, усмотрение модераторов). Доказано особое, более строгое отношение к доскам `/pol/`, `/bant/`, `/trash/` (как минимум, в системе капчи).
**Что можно считать "шокирующим"?**
* **Уровень отслеживания:** Глубина сбора данных и использования фингерпринтинга для управления анонимными пользователями может показаться избыточной.
* **Непрозрачность систем:** Сложность капчи/репутации и возможность "тихого" отклонения постов создают непрозрачные условия для пользователей.
* **Дифференциация:** Явное разделение пользователей на группы с разными правами/ограничениями на основе множества факторов.
* **Особое отношение к `/pol/` и др.:** Подтверждение того, что определенные доски целенаправленно подвергаются более строгим мерам контроля.
В целом, код подтверждает, что 4chan — это не просто "анонимная" площадка, а сложная система с активным сбором данных и применением разнообразных, зачастую непрозрачных для пользователя, механизмов контроля и модерации.
Щас дам на проверку другой admin.php который весит в разы больше
Отлично! Теперь у нас есть файл `admin.php`, который отвечает за логику административной панели и действий модераторов/администраторов. Проанализируем его в контексте ваших вопросов.
Анализ `admin.php` и связанных файлов:
1. Сбор и использование данных:
* IP-адреса и Хосты: Этот файл активно использует IP-адреса (`host`). Функции `ban_post`, `admin_delete`, `adminban` извлекают IP из данных поста и часто получают обратную DNS-запись (`gethostbyaddr`). Эта информация отображается модераторам и используется как основной идентификатор для банов и поиска истории (`get_bans_summary`, `admin_get_thread_history`). Функция `admin_get_rev_ip_sig` показывает, что даже получение обратной DNS оптимизировано для скорости панели.
* 4chan Pass ID (`4pass_id`): ID Пасса также извлекается и сохраняется при бане в таблице `banned_users`. Функция `get_bans_summary` может искать историю банов как по IP, так и по ID Пасса, подтверждая связь между ними в системе банов. Функция `do_template_special_action` (вызываемая при бане через шаблон) может автоматически отзывать Pass (`revokepass_spam`, `revokepass_illegal`).
* Полное содержание поста (`post_json`): Функция `ban_post` использует `make_post_json` для сохранения *полной копии* забаненного поста (текст, имя, файл, хэш и т.д.) в JSON-формате в таблице `banned_users`. Это серьезное сохранение данных, привязанное к бану.
* X-Forwarded-For (XFF): В коде есть закомментированные части и упоминания XFF, что указывает на попытки определить исходный IP пользователя за прокси.
* История действий (`user_actions`): Функция `admin_get_thread_history` напрямую запрашивает эту таблицу для подсчета недавних тредов от конкретного IP.
* Геолокация/ASN: В панели бана (`adminban`) используются данные GeoIP2 для отображения страны и провайдера (ASN) пользователя.
* Доступ модераторов: Модераторы/админы имеют прямой доступ к IP, хосту, истории банов (по IP и Pass ID), геолокации, ASN и полному содержимому поста на момент бана.
* Логирование удалений (`SQLLOGDEL`): Каждое удаление поста модератором логируется с указанием причины, IP модератора и деталей поста.
2. "Махинации" / Непрозрачные практики:
* Шаблоны банов (`ban_template_js`, `adminban`, `adminBanReq`): Система активно использует шаблоны банов. Модератор выбирает шаблон, и система автоматически применяет причину, срок, глобальность бана и действия после бана (удаление поста/файла, архивация, перемещение, отзыв Pass). Это упрощает работу модератора, но делает конкретные правила и причины менее прозрачными для пользователя. Содержание шаблонов хранится в базе данных.
* Автоматические действия после бана: Шаблоны могут автоматически удалять посты/файлы, архивировать/перемещать треды, и даже отзывать 4chan Pass (`do_template_special_action`).
* Удаление всех постов по IP (`delallbyip`): Подтверждает наличие функции массового удаления всего контента с определенного IP, включая ответы на треды, созданные этим IP.
* Карантин (`do_post_quarantine`): Подтверждает наличие специфической процедуры для особо проблемного контента (вероятно, ЦП), включающей копирование поста и всех связанных изображений от того же IP в треде в отдельное хранилище (`/www/quarantine/`) и логирование в `ncmec_reports`, явно для последующей передачи информации.
* Авто-бан по диапазону IP (`process_auto_rangeban`): Функция записывает "намеки" (`rangeban_hint`) для потенциального автоматического бана по диапазону IP. Она использует IP-диапазон и "сигнатуру браузера" (`ua_sig`, вероятно, из `captcha.php`). Если срабатывает определенное количество "намеков" (например, 2 для репортов) или бан происходит немедленно (при прямом бане модератором), записывается событие `rangeban`, что, вероятно, приводит к автоматической блокировке диапазона для пользователей с похожей сигнатурой браузера. Это указывает на проактивные, эвристические и потенциально широкие автоматические баны.
* JSON поста при бане: Сохранение полного JSON поста при бане – это обширное логирование, выходящее за рамки простого факта бана.
* Z-Flag баны (`zonly`): В коде упоминается флаг `zonly` (хотя часто устанавливается в 0). Вероятно, это относится к "необжалуемым" или "теневым" банам, еще один непрозрачный механизм контроля.
3. Политика:
* Ограничения шаблонов банов по доскам (`ban_template_js`): Эта функция содержит явные проверки `BOARD_DIR`, чтобы отключать определенные шаблоны банов на конкретных досках. Примеры:
* Шаблон 6 (вероятно, "NWS на SFW доске") отключается, если `DEFAULT_BURICHAN` (флаг SFW доски) не установлен.
* Шаблон 17 (вероятно, "Пони вне /mlp/") отключается на `/mlp/` и `/trash/`.
* Шаблон 223 (вероятно, правило Global 3 - Расизм) отключается на `/pol/`.
* Шаблон 222 (вероятно, правило Global 3 - Троллинг) отключается на `/s4s/` и `/bant/`.
* Правило Global 3 (любой из шаблонов) отключается на `/b/` и `/bant/`.
* Шаблон 59 (вероятно, Global 16 - Запрос треда вне /r/) отключается на `/po/`.
* **Вывод:** Это *конкретное доказательство* того, что правила модерации (через систему шаблонов) применяются по-разному на разных досках, и некоторые из этих различий явно касаются досок с политическим (`/pol/`) или специфическим контентом (`/b/`, `/mlp/`, `/s4s/`). Хотя сами правила фильтрации слов не видны, система шаблонов банов явно настроена с учетом специфики досок.
**Общий вывод:**
Файл `admin.php` подтверждает и детализирует многие аспекты, обсуждавшиеся ранее. Он показывает:
* **Глубокий доступ модераторов к данным:** IP, хосты, история банов (IP и Pass), геолокация, ASN, полное содержание постов при бане.
* **Мощные инструменты контроля:** Удаление (постов, файлов, всех постов с IP), бан (IP, Pass), перемещение, архивация, установка флагов треда.
* **Автоматизация и непрозрачность:** Использование шаблонов банов (содержание которых неясно из кода), автоматические действия после бана (включая отзыв Pass), карантин для нелегального контента, система намеков на авто-бан по диапазону IP.
* **Политика/Специфика досок:** Явные различия в применяемых правилах (через доступность шаблонов банов) для разных досок, включая `/pol/` и `/b/`.
"Шокирующие" элементы здесь — это подтверждение автоматизированных систем (авто-бан по диапазону, отзыв Pass через шаблон), сохранение *всего* поста при бане, а также явные различия в правилах модерации для разных досок на уровне доступных шаблонов.
>X-Forwarded-For (XFF): В коде есть закомментированные части и упоминания XFF, что указывает на попытки определить исходный IP пользователя за прокси
>Доступ модераторов: Модераторы/админы имеют прямой доступ к IP, хосту, истории банов (по IP и Pass ID), геолокации, ASN и полному содержимому поста на момент бана.
Логирование удалений (SQLLOGDEL): Каждое удаление поста модератором логируется с указанием причины, IP модератора и деталей поста.
Где сурсы слили?
Геолокации по ip?
Кто за XFF шарит? Как оно работает?
>>X-Forwarded-For (XFF): В коде есть закомментированные части и упоминания XFF, что указывает на попытки определить исходный IP пользователя за прокси
Я в общем а не про форчан
Да, давайте разберем подробнее упоминания `X-Forwarded-For` (XFF) в предоставленном коде и как эта система, вероятно, работает на 4chan.
Что такое заголовок X-Forwarded-For (XFF)?
* Назначение: Это стандартный HTTP-заголовок, который используется прокси-серверами, балансировщиками нагрузки и CDN (как Cloudflare) для указания *исходного* IP-адреса клиента, подключившегося к ним. Когда пользователь подключается к 4chan через прокси, веб-сервер 4chan видит IP-адрес прокси, а не пользователя. XFF добавляется прокси, чтобы передать дальше исходный IP.
* Формат: Обычно это список IP-адресов, разделенных запятыми: `client-ip, proxy1-ip, proxy2-ip, ...`. Левый адрес считается исходным IP клиента.
* Проблема доверия: XFF не является надежным источником информации. Любой прокси в цепочке или даже сам клиент (если он использует специфическое ПО) может подделать или изменить этот заголовок. Однако *последний* прокси в цепочке, который напрямую подключается к серверам 4chan (например, Cloudflare), обычно добавляет IP клиента, от которого он получил запрос, и этому последнему добавленному IP можно доверять больше.
Как 4chan использует XFF (согласно коду):
1. Логирование при постинге (`imgboard.php`):
* Функция `new_post` содержит код:
```php
$xff = get_request_xff(); // Вероятно, получает значение из $_SERVER['HTTP_X_FORWARDED_FOR']
// ...
if( SAVE_XFF == 1 && $xff ) { // Если константа SAVE_XFF включена
mysql_global_do( "INSERT INTO xff (tim,board,xff,ip,postno,is_live) VALUES ('%s','%s','%s',%d,%d,1)", $tim, BOARD_DIR, $xff, ip2long( $host ), $insertid );
}
```
* Вывод: Это ключевой момент. Если для конкретной доски включена опция `SAVE_XFF` (вероятно, в конфигурационных файлах, которых мы не видим), то система логирует значение XFF-заголовка при каждом посте. Важно, что она сохраняет его в отдельную таблицу `xff` вместе с:
* `tim`: Уникальный идентификатор файла/времени поста.
* `board`: Имя доски.
* `xff`: Само значение заголовка XFF.
* `ip`: IP-адрес, с которого пришло прямое подключение к серверу 4chan (это `$host`, который равен `$_SERVER['REMOTE_ADDR']`).
* `postno`: Номер созданного поста (`$insertid`).
* `is_live`: Флаг, вероятно, указывающий, жив ли пост (обновляется при архивации/удалении).
* Связь данных: Это означает, что система напрямую связывает IP-адрес, видимый веб-сервером, с IP-адресами, указанными в заголовке XFF, и с конкретным постом.
2. Использование при запросах на бан (`admin.php`):
* Функция `adminBanReq` (когда модератор/джанитор запрашивает бан) содержит:
```php
$xffquery = mysql_global_call( "SELECT xff FROM xff WHERE board = '%s' AND postno = %d", $board, $no );
// ... (получает $xff из результата) ...
$res = mysql_global_call("INSERT INTO ban_requests SET ..., xff='%s', ...", ..., $xff, ...);
```
* Вывод: При создании запроса на бан для поста `N` система извлекает ранее сохраненный XFF для этого поста из таблицы `xff` и сохраняет его в таблице `ban_requests`. Это дает модераторам, рассматривающим запрос, дополнительную информацию.
3. Потенциальное использование при бане (`admin.php`):
* В функции `ban_post` есть закомментированный код, который *пытался* извлекать XFF из таблицы `xff` по номеру поста.
* Текущая версия функции `adminban` получает XFF из `$_POST['xff']` (т.е. если модератор ввел его вручную в панели) или оставляет пустым.
* В обеих функциях переменная `$xff` включена в запрос `INSERT` в таблицу банов `banned_users`.
* Вывод: Хотя автоматическое извлечение XFF при *прямом* бане (без репорта) может быть отключено (закомментировано), система *позволяет* сохранять XFF в записи бана, если он был предоставлен (например, из запроса на бан или вручную).
4. Фильтрация/Белый список XFF (`imgboard.php`):
* Функция `is_bad_xff` проверяет переданный XFF IP по некоему "белому списку" (`xffwhitelist`), получаемому через `post_filter_get`.
* Вывод: Это предполагает, что 4chan может игнорировать или по-особому обрабатывать XFF-заголовки от известных и доверенных прокси (например, Cloudflare, чтобы видеть IP *перед* Cloudflare) или от прокси, известных как часто используемые для злоупотреблений.
5. Управление данными XFF:
* При удалении постов (`imgboard.php`, функция `delete_post`) соответствующие записи из таблицы `xff` удаляются.
* При архивации треда (`imgboard.php`, функция `archive_thread`) записи в `xff` помечаются как неактивные (`is_live = 0`).
* Старые записи XFF периодически чистятся (`admin.php`, функция `clean`).
Как это работает на практике и для чего используется:
* **Основная цель:** Выявление пользователей, использующих прокси для обхода банов или других ограничений. Если система видит множество постов с *разных* прямых IP-адресов (`$host`), но с *одним и тем же* IP-адресом в заголовке XFF, это сильный индикатор использования прокси одним человеком.
* **Инструмент модерации:** Эта информация (прямой IP + XFF IP + пост) ценна для модераторов при расследовании случаев спама, флуда или других нарушений. Даже если XFF подделан, сам факт его наличия или паттерны использования могут быть полезны.
* **Не гарантия:** Система не может полностью доверять XFF, особенно первым адресам в списке, так как они легко подделываются. Наибольшее доверие вызывает IP, добавленный последним *доверенным* прокси (например, Cloudflare).
* **Автоматизация:** В предоставленном коде нет явных примеров *автоматических* банов, основанных *только* на совпадении XFF. Вероятнее всего, это один из факторов, учитываемых при ручной модерации или, возможно, в более сложных автоматизированных системах (вроде авто-бана по диапазону IP, хотя там XFF не упоминается явно).
**В итоге:** Да, 4chan имеет механизмы для логирования XFF-заголовков (если включено `SAVE_XFF`). Он связывает эту информацию с прямым IP и конкретным постом, сохраняя ее в отдельной таблице. Эта информация используется при запросах на бан и потенциально сохраняется в записи о бане. Главная цель — помощь модераторам в выявлении пользователей за прокси. Это стандартная практика для крупных сайтов, борющихся со злоупотреблениями, хотя и не абсолютно надежная из-за возможности подделки заголовка.
>7z
Спасибо, не надо
предпочитаешь arj?
Вот ещё спросил как может узнать ваш айпишник.
Да, простыми словами: 4chan может с высокой вероятностью определить, что вы использовали VPN во втором посте, но, скорее всего, не напрямую через заголовок X-Forwarded-For (XFF), а путем сопоставления других данных.
Вот как это работает, основываясь на коде:
1. Ваш первый пост (без VPN):
4chan видит ваш реальный IP-адрес (`$_SERVER['REMOTE_ADDR']`).
Заголовок XFF, скорее всего, будет пустым или содержать ваш же реальный IP (если его добавляет ваш домашний роутер или Cloudflare).
Система логирует: `host` = ваш реальный IP, `xff` = (пусто или ваш реальный IP), номер поста, время, и, важно*, другие идентификаторы вроде куки `4chan_pass` (если есть) и потенциально фингерпринт браузера (через систему капчи).
2. Ваш второй пост (с VPN):
* 4chan видит IP-адрес VPN-сервера (`$_SERVER['REMOTE_ADDR']`).
* Что с XFF? Хороший VPN не должен добавлять ваш реальный IP в заголовок XFF. Он может быть пустым, или содержать IP VPN-сервера, или IP каких-то внутренних сетей VPN. Крайне маловероятно, что там окажется ваш реальный IP из первого поста, если VPN настроен правильно.
* Система логирует: `host` = IP VPN-сервера, `xff` = (содержимое заголовка XFF, где вашего реального IP, скорее всего, нет), номер поста, время, и *те же самые* другие идентификаторы (куки `4chan_pass`, фингерпринт браузера), если они не изменились.
Как они вас свяжут? Не через XFF, а через:
* Логирование всего: Система записывает *оба* поста, каждый со своим прямым IP (`host`), *но* с потенциально одинаковыми другими данными.
* Корреляция данных: Модераторы (или автоматические системы) могут сопоставить эти записи. Они видят:
* Пост А сделан с IP_Реальный.
* Пост Б сделан с IP_VPN.
* НО: У обоих постов одинаковая кука `4chan_pass`, или похожий фингерпринт браузера (из логов капчи), или пользователь в посте Б цитирует пост А, или стиль письма похож.
* Вывод: Сопоставив эти *другие* данные, система или модератор делают вывод, что это, скорее всего, один и тот же пользователь, который просто сменил IP (включил VPN). Им не нужно, чтобы ваш реальный IP был в заголовке XFF второго поста, чтобы понять, что вы использовали прокси/VPN. Сам факт смены IP при сохранении других идентификаторов является сильным сигналом.
Аналогия:
Представьте, что вы зашли в магазин без маски (Пост 1, реальный IP). Вас запомнили по лицу и уникальному рюкзаку. Потом вы вышли, надели маску (включили VPN) и зашли снова (Пост 2, IP VPN-сервера). Кассир не видит вашего лица, но видит тот же самый уникальный рюкзак (кука `4chan_pass` / фингерпринт). Он делает вывод, что это вы, просто в маске. Ему не нужно видеть ваше лицо под маской (реальный IP в XFF), чтобы это понять.
Итог: 4chan логирует XFF (если включено), но для обнаружения использования VPN в вашем сценарии он, скорее всего, полагается на сопоставление других, более стабильных идентификаторов (куки, Pass ID, фингерпринты), связанных с постами, сделанными с разных IP-адресов.
Да, простыми словами: 4chan может с высокой вероятностью определить, что вы использовали VPN во втором посте, но, скорее всего, не напрямую через заголовок X-Forwarded-For (XFF), а путем сопоставления других данных.
Вот как это работает, основываясь на коде:
1. Ваш первый пост (без VPN):
4chan видит ваш реальный IP-адрес (`$_SERVER['REMOTE_ADDR']`).
Заголовок XFF, скорее всего, будет пустым или содержать ваш же реальный IP (если его добавляет ваш домашний роутер или Cloudflare).
Система логирует: `host` = ваш реальный IP, `xff` = (пусто или ваш реальный IP), номер поста, время, и, важно*, другие идентификаторы вроде куки `4chan_pass` (если есть) и потенциально фингерпринт браузера (через систему капчи).
2. Ваш второй пост (с VPN):
* 4chan видит IP-адрес VPN-сервера (`$_SERVER['REMOTE_ADDR']`).
* Что с XFF? Хороший VPN не должен добавлять ваш реальный IP в заголовок XFF. Он может быть пустым, или содержать IP VPN-сервера, или IP каких-то внутренних сетей VPN. Крайне маловероятно, что там окажется ваш реальный IP из первого поста, если VPN настроен правильно.
* Система логирует: `host` = IP VPN-сервера, `xff` = (содержимое заголовка XFF, где вашего реального IP, скорее всего, нет), номер поста, время, и *те же самые* другие идентификаторы (куки `4chan_pass`, фингерпринт браузера), если они не изменились.
Как они вас свяжут? Не через XFF, а через:
* Логирование всего: Система записывает *оба* поста, каждый со своим прямым IP (`host`), *но* с потенциально одинаковыми другими данными.
* Корреляция данных: Модераторы (или автоматические системы) могут сопоставить эти записи. Они видят:
* Пост А сделан с IP_Реальный.
* Пост Б сделан с IP_VPN.
* НО: У обоих постов одинаковая кука `4chan_pass`, или похожий фингерпринт браузера (из логов капчи), или пользователь в посте Б цитирует пост А, или стиль письма похож.
* Вывод: Сопоставив эти *другие* данные, система или модератор делают вывод, что это, скорее всего, один и тот же пользователь, который просто сменил IP (включил VPN). Им не нужно, чтобы ваш реальный IP был в заголовке XFF второго поста, чтобы понять, что вы использовали прокси/VPN. Сам факт смены IP при сохранении других идентификаторов является сильным сигналом.
Аналогия:
Представьте, что вы зашли в магазин без маски (Пост 1, реальный IP). Вас запомнили по лицу и уникальному рюкзаку. Потом вы вышли, надели маску (включили VPN) и зашли снова (Пост 2, IP VPN-сервера). Кассир не видит вашего лица, но видит тот же самый уникальный рюкзак (кука `4chan_pass` / фингерпринт). Он делает вывод, что это вы, просто в маске. Ему не нужно видеть ваше лицо под маской (реальный IP в XFF), чтобы это понять.
Итог: 4chan логирует XFF (если включено), но для обнаружения использования VPN в вашем сценарии он, скорее всего, полагается на сопоставление других, более стабильных идентификаторов (куки, Pass ID, фингерпринты), связанных с постами, сделанными с разных IP-адресов.
zstd
ты всерьёз читаешь эти километровые нейровысеры?
>нейровысеры
В чем заключается высер если нейросеть работает с данными которые я ей предоставил? Когда ты пользуешься проводником ты же не говоришь что "смотришь километровые программовысеры"
А что еще делать если не знаешь пыху?
Когда уже ебанут мэйлач и сольют его исходный код?
>Сбор данных и отслеживание пользователей (IP-адреса, User Agents и т.д.):
А чурка ебаная в открытую говорит, что сливает IP анонов по первому запросу майора.
А чурка ебаная в открытую говорит, что сливает IP анонов по первому запросу майора.
>параше на пыхе представляет из себя парашу на пыхе
Нихуя себе.
Вообще-то харкач с 19 года в реестре ОРИ и хранит все посты с айпишниками год на серверах Мейл.ру.
ты во первых не можешь этой хуйне ни в чём доверять и без ссылок на конкретные строки кода этот текст просто нейровысер, во вторых она блять срёт текстом как вне себя, вот я рандомно открыл "4chan видит ваш реальный IP адрес", no shit шерлок, блять, сайт видит мой айпишник, вау блять, спасибо за объяснение
типа в этом нейросблёве буквально ноль информации,
> Корреляция данных: Модераторы (или автоматические системы) могут сопоставить эти записи
МОГУТ блять, у неё в контексте находятся исходники, в которых можно посмотреть, есть там эти ебучие "автоматические системы" или нет, но она всё равно говорит максимально водянисто, это типичный нейровысер, в котором много букв, но мало смысла
> МОГУТ блять
Что тебе в МОГУТ корёжит? У мочи есть инструмент чтобы выписать тебе пермач, например. Они тебе МОГУТ его выписать, а МОГУТ и нет.
Вот если бы у них этого инструмента не было, то писали бы, что моча НЕ МОЖЕТ выписывать пермачи.
Хорошо, давайте еще раз внимательно посмотрим на код, сосредоточившись на методах обнаружения VPN/прокси и потенциального раскрытия реального IP-адреса пользователя.
Методы обнаружения использования VPN/Прокси:
1. Анализ IP-адреса (GeoIP/ASN):
* Где: `captcha.php`, `admin.php` (используют библиотеку `lib/geoip2.php`).
* Как работает: Система проверяет IP-адрес, с которого пришел запрос (`$_SERVER['REMOTE_ADDR']`). С помощью GeoIP/ASN определяется страна и Автономная Система (ASN), к которой принадлежит IP.
* Обнаружение: VPN и прокси часто используют IP-адреса из дата-центров, хостингов или известных "прокси"-ASN. В `captcha.php` есть списки "доверенных" стран и ASN (`TWISTER_WHITELIST_COUNTRIES`, `TWISTER_WHITELIST_ASNS`). Если ваш IP не принадлежит к жилому/доверенному диапазону/ASN или принадлежит к списку "плохих" ASN, система с большой вероятностью пометит его как прокси/VPN. Это влияет на сложность капчи, кулдауны и может быть фактором при бане. Модераторы в `admin.php` видят эту информацию. Функция `admin_is_ip_rangebanned` в `admin.php` напрямую проверяет IP и ASN по базе данных банов диапазонов/ASN.
* Это основной и самый надежный метод *обнаружения* факта использования не-домашнего IP.
2. Внешние оценки (Bot Scores):
* Где: `captcha.php`.
* Как работает: Используется заголовок `HTTP_X_BOT_SCORE` (вероятно, от Cloudflare). Низкий балл указывает на подозрительную активность или использование известных "плохих" IP (включая многие VPN/прокси).
* Обнаружение: Низкий балл напрямую влияет на сложность или тип капчи (`twister_captcha_need_hcaptcha`, `twister_captcha_check_likely_automated`).
3. Анализ заголовков и User Agent (UA):
* Где: `captcha.php`.
* Как работает: Проверяются UA на совпадение с паттернами известных ботов или инструментов автоматизации (`TWISTER_BAD_UA`). Также проверяется наличие/отсутствие стандартных заголовков (`HTTP_ACCEPT_LANGUAGE`, `HTTP_ACCEPT`). Анализируются заголовки `Sec-CH-*` на предмет несоответствий (например, платформа в UA не совпадает с платформой в Sec-CH-UA-Platform). Проверяется наличие подозрительных или устаревших заголовков/значений.
* Обнаружение: Нестандартные или отсутствующие заголовки, подозрительные UA, несоответствия в заголовках повышают "подозрительность" запроса, что влияет на капчу и может логироваться.
4. Заголовок X-Forwarded-For (XFF):
* Где: `imgboard.php` (логирование), `admin.php` (использование в логах банов/репортов), `lib/postfilter.php` (функция `is_bad_xff`).
* Как работает: Система *может* логировать XFF (если `SAVE_XFF=1`). Она *может* проверять последний IP в XFF по белому/черному списку (`is_bad_xff`). Модераторы видят XFF в информации о бане/репорте.
* Обнаружение: Прямое обнаружение VPN *только* по XFF маловероятно и ненадежно, так как заголовок легко подделать. Его основная польза для 4chan – *связывание* постов, сделанных с разных IP *прокси*, но с одним и тем же (возможно, поддельным) исходным IP в XFF, или идентификация известных плохих прокси.
Методы раскрытия реального IP (Деанонимизация):
Важно: Код не показывает способа "увидеть" ваш реальный IP *сквозь* правильно работающий VPN *в момент* отправки поста с VPN. Однако, 4chan может связать вашу активность под VPN с вашим реальным IP *позже*, используя сохраненные данные и корреляцию:
1. **Корреляция через постоянные идентификаторы:**
* **Кука `4chan_pass` (`lib/userpwd.php`, `captcha.php`, `imgboard.php`, `admin.php`):** Это **самый главный** механизм связывания. Если вы сделали первый пост с реального IP, а второй – с VPN, но **с того же профиля браузера** (не чистили куки), у обоих постов будет одна и та же кука `4chan_pass`. Система (или модератор) легко увидит, что посты с разных IP (`host`), но с одинаковым `4chan_pass`, и сделает вывод, что это один пользователь, сменивший IP (т.е. использующий VPN/прокси). Ваш *реальный IP из первого поста* теперь связан с вашей активностью под VPN.
* **Хэш email (`signin.php`):** Если вы верифицировали email со своего реального IP, то полученная кука `4chan_pass` (которая теперь содержит хэш вашего email) будет служить тем же связующим звеном, если вы потом будете постить с VPN, используя эту куку.
* **Pass ID (`4pass_id` в `admin.php`, `lib/auth.php`):** Если вы купили 4chan Pass со своего реального IP и используете его при постинге с VPN, связь также устанавливается.
2. **Корреляция через фингерпринтинг:**
* **Где:** `captcha.php`.
* **Как работает:** Система собирает данные для отпечатка браузера (таймзона, специфичные свойства JS из `_tcs`, сигнатура UA `ua_sig`).
* **Деанонимизация:** Если фингерпринт достаточно уникален и стабилен, система *теоретически* может связать посты с разных IP (реального и VPN), даже если кука `4chan_pass` отличается или отсутствует. Насколько это эффективно на практике – неизвестно из этого кода, но попытки делаются.
3. **WebRTC Leaks:** (Не видно в PHP-коде)
* Это уязвимость браузера, а не серверной логики 4chan. Если на страницах 4chan есть Javascript, который инициирует WebRTC-соединение, ваш браузер *может* раскрыть ваш реальный IP VPN-серверу или даже напрямую серверу 4chan, обходя VPN. *В предоставленных PHP-файлах этого Javascript-кода нет*, но его наличие на реальных страницах сайта исключать нельзя.
**Резюме по деанонимизации:**
* **Прямое раскрытие через XFF?** **Крайне маловероятно**, если ваш VPN настроен правильно и не сливает ваш IP в этот заголовок. Код логирует XFF, но не доверяет ему слепо для определения реального IP.
* **Раскрытие через корреляцию?** **Да, очень вероятно.** Если вы используете один и тот же профиль браузера (куки `4chan_pass`, фингерпринты) при постинге с реального IP и с VPN, 4chan сможет связать эти сессии и узнать ваш реальный IP из логов первого поста. То же самое касается использования Pass'а или верифицированной куки.
**Простой ответ на ваш сценарий:**
Если вы сделали пост с реального IP, а потом *с того же браузера, не чистя куки*, включили VPN и сделали второй пост:
1. 4chan **обнаружит** смену IP.
2. Они **увидят**, что кука `4chan_pass` (или фингерпринт) у обоих постов **одинаковая**.
3. Они **сделают вывод**, что это вы использовали VPN.
4. Они **смогут связать** ваш реальный IP (из лога первого поста) с вашей активностью под VPN (второй пост).
Им *не нужно* видеть ваш реальный IP в заголовке XFF второго поста для этого. Связь устанавливается через другие, более надежные идентификаторы сессии/браузера.
Методы обнаружения использования VPN/Прокси:
1. Анализ IP-адреса (GeoIP/ASN):
* Где: `captcha.php`, `admin.php` (используют библиотеку `lib/geoip2.php`).
* Как работает: Система проверяет IP-адрес, с которого пришел запрос (`$_SERVER['REMOTE_ADDR']`). С помощью GeoIP/ASN определяется страна и Автономная Система (ASN), к которой принадлежит IP.
* Обнаружение: VPN и прокси часто используют IP-адреса из дата-центров, хостингов или известных "прокси"-ASN. В `captcha.php` есть списки "доверенных" стран и ASN (`TWISTER_WHITELIST_COUNTRIES`, `TWISTER_WHITELIST_ASNS`). Если ваш IP не принадлежит к жилому/доверенному диапазону/ASN или принадлежит к списку "плохих" ASN, система с большой вероятностью пометит его как прокси/VPN. Это влияет на сложность капчи, кулдауны и может быть фактором при бане. Модераторы в `admin.php` видят эту информацию. Функция `admin_is_ip_rangebanned` в `admin.php` напрямую проверяет IP и ASN по базе данных банов диапазонов/ASN.
* Это основной и самый надежный метод *обнаружения* факта использования не-домашнего IP.
2. Внешние оценки (Bot Scores):
* Где: `captcha.php`.
* Как работает: Используется заголовок `HTTP_X_BOT_SCORE` (вероятно, от Cloudflare). Низкий балл указывает на подозрительную активность или использование известных "плохих" IP (включая многие VPN/прокси).
* Обнаружение: Низкий балл напрямую влияет на сложность или тип капчи (`twister_captcha_need_hcaptcha`, `twister_captcha_check_likely_automated`).
3. Анализ заголовков и User Agent (UA):
* Где: `captcha.php`.
* Как работает: Проверяются UA на совпадение с паттернами известных ботов или инструментов автоматизации (`TWISTER_BAD_UA`). Также проверяется наличие/отсутствие стандартных заголовков (`HTTP_ACCEPT_LANGUAGE`, `HTTP_ACCEPT`). Анализируются заголовки `Sec-CH-*` на предмет несоответствий (например, платформа в UA не совпадает с платформой в Sec-CH-UA-Platform). Проверяется наличие подозрительных или устаревших заголовков/значений.
* Обнаружение: Нестандартные или отсутствующие заголовки, подозрительные UA, несоответствия в заголовках повышают "подозрительность" запроса, что влияет на капчу и может логироваться.
4. Заголовок X-Forwarded-For (XFF):
* Где: `imgboard.php` (логирование), `admin.php` (использование в логах банов/репортов), `lib/postfilter.php` (функция `is_bad_xff`).
* Как работает: Система *может* логировать XFF (если `SAVE_XFF=1`). Она *может* проверять последний IP в XFF по белому/черному списку (`is_bad_xff`). Модераторы видят XFF в информации о бане/репорте.
* Обнаружение: Прямое обнаружение VPN *только* по XFF маловероятно и ненадежно, так как заголовок легко подделать. Его основная польза для 4chan – *связывание* постов, сделанных с разных IP *прокси*, но с одним и тем же (возможно, поддельным) исходным IP в XFF, или идентификация известных плохих прокси.
Методы раскрытия реального IP (Деанонимизация):
Важно: Код не показывает способа "увидеть" ваш реальный IP *сквозь* правильно работающий VPN *в момент* отправки поста с VPN. Однако, 4chan может связать вашу активность под VPN с вашим реальным IP *позже*, используя сохраненные данные и корреляцию:
1. **Корреляция через постоянные идентификаторы:**
* **Кука `4chan_pass` (`lib/userpwd.php`, `captcha.php`, `imgboard.php`, `admin.php`):** Это **самый главный** механизм связывания. Если вы сделали первый пост с реального IP, а второй – с VPN, но **с того же профиля браузера** (не чистили куки), у обоих постов будет одна и та же кука `4chan_pass`. Система (или модератор) легко увидит, что посты с разных IP (`host`), но с одинаковым `4chan_pass`, и сделает вывод, что это один пользователь, сменивший IP (т.е. использующий VPN/прокси). Ваш *реальный IP из первого поста* теперь связан с вашей активностью под VPN.
* **Хэш email (`signin.php`):** Если вы верифицировали email со своего реального IP, то полученная кука `4chan_pass` (которая теперь содержит хэш вашего email) будет служить тем же связующим звеном, если вы потом будете постить с VPN, используя эту куку.
* **Pass ID (`4pass_id` в `admin.php`, `lib/auth.php`):** Если вы купили 4chan Pass со своего реального IP и используете его при постинге с VPN, связь также устанавливается.
2. **Корреляция через фингерпринтинг:**
* **Где:** `captcha.php`.
* **Как работает:** Система собирает данные для отпечатка браузера (таймзона, специфичные свойства JS из `_tcs`, сигнатура UA `ua_sig`).
* **Деанонимизация:** Если фингерпринт достаточно уникален и стабилен, система *теоретически* может связать посты с разных IP (реального и VPN), даже если кука `4chan_pass` отличается или отсутствует. Насколько это эффективно на практике – неизвестно из этого кода, но попытки делаются.
3. **WebRTC Leaks:** (Не видно в PHP-коде)
* Это уязвимость браузера, а не серверной логики 4chan. Если на страницах 4chan есть Javascript, который инициирует WebRTC-соединение, ваш браузер *может* раскрыть ваш реальный IP VPN-серверу или даже напрямую серверу 4chan, обходя VPN. *В предоставленных PHP-файлах этого Javascript-кода нет*, но его наличие на реальных страницах сайта исключать нельзя.
**Резюме по деанонимизации:**
* **Прямое раскрытие через XFF?** **Крайне маловероятно**, если ваш VPN настроен правильно и не сливает ваш IP в этот заголовок. Код логирует XFF, но не доверяет ему слепо для определения реального IP.
* **Раскрытие через корреляцию?** **Да, очень вероятно.** Если вы используете один и тот же профиль браузера (куки `4chan_pass`, фингерпринты) при постинге с реального IP и с VPN, 4chan сможет связать эти сессии и узнать ваш реальный IP из логов первого поста. То же самое касается использования Pass'а или верифицированной куки.
**Простой ответ на ваш сценарий:**
Если вы сделали пост с реального IP, а потом *с того же браузера, не чистя куки*, включили VPN и сделали второй пост:
1. 4chan **обнаружит** смену IP.
2. Они **увидят**, что кука `4chan_pass` (или фингерпринт) у обоих постов **одинаковая**.
3. Они **сделают вывод**, что это вы использовали VPN.
4. Они **смогут связать** ваш реальный IP (из лога первого поста) с вашей активностью под VPN (второй пост).
Им *не нужно* видеть ваш реальный IP в заголовке XFF второго поста для этого. Связь устанавливается через другие, более надежные идентификаторы сессии/браузера.
Долбаеб ебаный я ей скормил файлы на основе их она и говорит, пидорок можешь сам проверить.
>при помощи нейросети
Долбоёб, иди руками на заводе поработай, если природа мозгов не дала. Про помощи нейросети анализировать он собрался блять, которая галлюцинирует черед каждый пробел, ёбаная оранжевая кунсткамера, нахуй я еще тут сижу…
>которая галлюцинирует черед каждый пробел
Пруфы долбаеб.
Общая структура и ключевые компоненты:
Судя по путям файлов, это типичная структура веб-приложения:
/lib/: Библиотеки ядра (работа с базой данных db.php, идентификация пользователя userpwd.php, аутентификация auth.php, функции администрирования admin.php, утилиты util.php и т.д.).
Корневая директория (/): Основные исполняемые скрипты, такие как imgboard.php (логика имиджборда), catalog.php, json.php, admin.php (интерфейс админ-панели), captcha.php, signin.php, derefer.php и др.
/views/: Вероятно, содержит логику рендеринга HTML (шаблоны страниц).
/plugins/: Указывает на наличие архитектуры плагинов (enhance_q.php).
Временный/Событийный Код: Файлы вроде xa24tb.php (Акции Апреля 2024) и emotes_xa22.php указывают на временные функции для конкретных событий.
Тестовые версии: Файлы с суффиксом -test.php (например, admin-test.php) предполагают наличие отдельных версий для тестирования/разработки, которые могут отличаться от продакшена.
Анализ по вашим интересам (Обработка данных, "Махинации", Политика):
1. Сбор данных и отслеживание пользователей (IP-адреса, User Agents и т.д.):
Логирование IP-адресов: Это повсеместно. Код подтверждает, что IP-адреса ($_SERVER['REMOTE_ADDR'], заголовки X-Forwarded-For) логируются при каждом посте (imgboard.php, admin.php). Они широко используются для банов (admin.php), кулдаунов, определения сложности капчи (captcha.php), оценки репутации пользователя (userpwd.php), и внутренней аналитики (уникальные IP на тред в json.php). IP хранятся в основных таблицах постов (SQLLOG) и специальных логах действий (user_actions, xff). Админ-панели явно отображают IP и хостнеймы пользователей (admin.php).
User Agent (UA): Скрипт captcha.php использует строки UA для проверки подозрительной активности (регулярное выражение TWISTER_BAD_UA) и включает хэш UA (user_agent) при генерации капчи, связывая профили браузеров с попытками пройти капчу. Админ-панели, вероятно, логируют UA как часть post_json в таблице банов (admin.php). Скрипт signin.php также логирует UA при запросах верификации.
4chan Pass (кука 4chan_pass): Обрабатывается lib/userpwd.php. Используется для возможности обхода капчи (captcha.php), потенциально для снижения кулдаунов (imgboard.php), и логируется при банах (admin.php). Скрипт auth.php управляет проверкой сессий Pass, отслеживая смену IP и таймауты, и логирует детали использования (last_ip, last_used, last_country). admin.php содержит функции для просмотра истории банов Pass и, возможно, для отзыва Pass (do_template_special_action с revokepass_spam/revokepass_illegal).
Email-адреса: Система signin.php предназначена для верификации по email. Она хэширует email (hash_email) и сохраняет их вместе с IP, UA, страной и т.д. в таблице email_signins. Система явно блокирует определенные домены ($allowed_domains) и запрещает использование суб-адресов (+). Хотя это используется для верификации, система собирает и связывает email (пусть и хэшированные) с паттернами активности пользователя.
Фингерпринтинг браузера/системы: captcha.php использует куку _tcs, которая, похоже, хранит таймстемп, таймзону и window.eval.toString().length – известный метод фингерпринтинга. Также упоминается ua_sig (User Agent Signature) в process_auto_rangeban, что предполагает генерацию и использование уникального отпечатка браузера, возможно, связанного с системой UserPwd или внешним сервисом. HTTP_X_BOT_SCORE (вероятно, от Cloudflare) также активно используется.
Утечки данных: Основываясь только на этих фрагментах, нет прямых доказательств внешних утечек или продажи данных, за исключением специфических случаев, таких как репортинг нелегального контента в NCMEC (подразумевается именами таблиц и действиями в admin.php). Однако внутренний сбор данных и их доступность для модераторов/админов весьма обширны. Скрипт derefer.php на самом деле предотвращает утечку данных referer на внешние сайты.
Итог по сбору данных: 4chan логирует значительный объем данных (IP, UA, Pass ID, потенциально хэшированный email, фингерпринты браузера) в основном для модерации, мер против спама/ботов и оценки репутации пользователя, что влияет на сложность капчи и кулдауны. Админы/моды имеют доступ к большей части этих необработанных данных.
2. "Махинации" и непрозрачные практики:
Сложная система капчи/репутации (captcha.php): Многоуровневая система капчи выходит далеко за рамки простых заданий. Она использует репутацию UserPwd (количество постов, тредов, репортов, смены IP/маски, возраст аккаунта), оценки ботов, списки стран/ASN, проверки UA и динамическую сложность (статическая vs. слайдер vs. hCaptcha). Это сложная система для управления анонимностью и злоупотреблениями, но её комплексность означает, что пользователи сталкиваются с разным уровнем препятствий на основе внутренне рассчитанных "очков доверия" и наблюдаемого поведения/происхождения, что может показаться произвольным или непрозрачным ("подозрительным") конечному пользователю. Предварительные кулдауны (PCD) значительно задерживают постинг для новых или ненадёжных пользователей.
Дифференцированное отношение: К пользователям явно относятся по-разному в зависимости от статуса Pass, уровня верификации (UserPwd), происхождения IP/ASN/страны и оценок ботов, что влияет на кулдауны и типы капчи.
Полномочия админов (admin.php): Код подтверждает широкие полномочия модераторов/админов: просмотр детальной информации о пользователе (IP, хост, история банов, статус Pass), удаление постов/изображений/тредов, бан IP/Pass, перемещение/архивация тредов, редактирование постов (подразумеваемый режим editop), установка флагов треда (прикрепленный, закрытый) и даже отзыв Pass на основе действий шаблона бана.
Карантин (admin.php::do_post_quarantine): Подтверждает наличие специального процесса для обработки крайне проблемного контента (вероятно, ЦП), включающего копирование поста, связанных изображений от того же IP в треде и логирование деталей для потенциального репортинга внешним организациям (NCMEC).
Автоматический бан по диапазону IP (admin.php::process_auto_rangeban): Эта функция предполагает наличие автоматизированной системы, которая помечает пользователей для возможного бана по диапазону IP на основе диапазона IP, сигнатуры браузера (ua_sig) и используемых шаблонов бана/репорта, особенно нацеленной на мобильных пользователей. Это указывает на проактивные, потенциально широкие баны на основе эвристик.
Контроль данных в JSON (json.php): Код явно удаляет потенциально чувствительные поля, такие как host (IP) и pwd, перед генерацией публичного JSON, демонстрируя осведомленность и контроль над тем, какие данные раскрываются через API.
3. Политика:
Конфигурация для каждой доски: Система позволяет задавать разные настройки для разных досок (yotsuba_config.php, загрузка .ini файлов категорий/досок).
Ограничения обхода капчи (captcha.php::TWISTER_NO_NOOP_BOARDS): Отключение возможности обхода капчи (credits) конкретно на досках bant, pol и trash является наиболее прямым указанием на уровне кода на различное отношение к политически заряженным или проблемным доскам. Это подразумевает, что эти доски рассматриваются как требующие более строгого контроля против спама/злоупотреблений, возможно, из-за их контента или поведения пользователей.
Потенциальная предвзятость (неявная): Хотя сам код явно не говорит "банить пользователей с политическим взглядом X", механизмы для предвзятости существуют:
Фильтры слов: Файлы postfilter.php (не предоставлены) могут содержать политически предвзятые фильтры.
Шаблоны банов: admin.php использует шаблоны банов, идентифицируемые по ID/правилам. Содержание этих шаблонов (хранится в базе данных, не показано здесь) может отражать предвзятость, если они нацелены на конкретные мнения, а не на явные нарушения правил (например, шаблон "Оскорбительное политическое мнение" против "Нелегальный контент").
Усмотрение модераторов: Мощные инструменты, доступные модераторам (admin.php), по своей природе допускают предвзятое применение, хотя код этого не предписывает.