Антидетект-браузер на базе Safari

Большинство антидетект-браузеров строится на Chromium. Vision Browser решил добавить к нему ещё и Safari – на базе WebKit. Зачем рынку второй движок, в каких задачах он может быть полезен и почему одной подмены User-Agent недостаточно?

Обсудили это с создателем и главным разработчиком Vision Browser 0xFF. Поговорили о различиях между WebKit и Chromium, совместимости сайтов, сложности разработки и поддержке Safari-антидетекта – а ещё о том, почему красивого интерфейса и пары запросов к нейросети для такого продукта мало.

Чем технически Safari отличается от обычного антидетекта на Chrome?  Какие параметры отличаются для сайтов и систем антифрода?

Разница фундаментальна, так как браузеры работают на принципиально разных движках: Chrome базируется на Blink и V8, а Safari — на WebKit и JavaScriptCore. Большинство разработчиков антидетектов создают свои решения исключительно на базе Chromium, что вполне закономерно — с большим отрывом Chrome является лидером по количеству пользователей в мире с долей более 65%. 

В следствии этого защитные системы научились глубоко анализировать эту среду. На современных сайтах встречается масса специфических проверок, нацеленных именно на пользователей Chrome, вплоть до тайминг-атак, которые фиксируют аномалии и микрозадержки при выполнении операций — самый банальный пример, который провалит любая виртуалка.

Для систем антифрода замена User-Agent в Chrome не превращает его в Safari. Сайт анализирует огромный массив параметров:

• Специфику выполнения JavaScript и доступный набор Web API;
• Механизмы рендеринга текста, шрифтов и обработку мультимедиа;
• Отрисовку графики и текста.

Если эти параметры не соответствуют архитектуре WebKit, антифрод мгновенно считывает несостыковку отпечатка и блокирует профиль еще на этапе открытия сайта, т.к. это очень легко определяется. Подобные костыли иногда используются в продуктах, например, в Linken Sphere, где Safari реализован на базе Chrome, и этот Франкенштейн палится даже на приметивнейших антифрод-системах. 

Именно поэтому добавление Safari по своей сути равнозначно разработке полноценного нового антидетект-браузера, а не просто крупному обновлению. Мы глубоко понимаем запросы рынка и создали технически чистое решение на WebKit, которое изначально функционирует по иным законам, обходя логику проверок, заточенную под Chromium-браузеры. 

В каких сценариях пользователю может понадобиться именно Safari-браузер?

Антидетект на Safari необходим в сценариях, где целевые площадки применяют жесткие алгоритмы фильтрации к Chromium-трафику.

Главное техническое преимущество WebKit заключается в том, что этот движок по умолчанию передает сайтам гораздо меньший объем идентифицирующих параметров, а ключевые маркеры железа в нем жестко стандартизированы. В WebKit-based браузерах количество ядер процессора, объем оперативной памяти и WebGL Renderer всегда статичны. На любом устройстве, если вы используете браузер на базе WebKit и запускаете профиль даже на Linux — сайт увидит Apple GPU и типовые конфигурации macOS. Для антифрода такой фингерпринт выглядит монолитным и не вызывает подозрений, которые обычно возникают при кастомизации отпечатков в Chrome.

При этом важно учитывать специфику конкретных систем. Например, сервисы Google могут отображать QR-код вместо предложения ввести номер для получения SMS-кода через Safari чаще, чем через “родной” Chrome. А вот ситуация, например, с Hotmail несколько месяцев назад была прямо противоположная — “проходимость” массовой регистрации аккаунтов на Safari было заметно выше, чем на Chrome.

Наша глобальная задача как разработчика продукта — предоставить рынку выбор. Внутри Vision мы создали два независимых, технологически проработанных продукта под разные типы задач, чтобы наши клиенты могли гибко подбирать инструмент под конкретную архитектуру защиты тех сайтов, с которыми они работают.

Есть ли какие-то ограничения у Safari-эмуляции по сравнению с Chrome? Какие сайты или инструменты могут работать хуже-лучше?

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

При работе с продуктом на базе Safari нужно учитывать несколько ключевых нюансов совместимости с сайтами. Некоторые тяжелые веб-интерфейсы и специфический софт лучше протестированы разработчиками именно под Chromium, поэтому в Safari в редких случаях возможны незначительные отличия в функционале или верстке.

Если говорить о том, что работает лучше, то Safari демонстрирует отличные результаты на площадках с жестким фрод-мониторингом, где Chromium-трафик подвергается тотальной проверке. Из-за архитектурных особенностей WebKit здесь значительно чище проходятся капчи и реже срабатывают триггеры на роботность. Chrome же остается незаменимым стандартом для задач, требующих массовой автоматизации, использования привычных расширений и работы с сервисами самого Google.

Поэтому не стану давать каких-то конкретных рекомендаций — под каждую задачу инструменты тестировать нужно самостоятельно.

У большинства антидетектов под капотом Chrome. Вы сделали еще и Safari. Зачем? На сколько сложнее его поддерживать?

Как я уже говорил выше, наша главная цель — дать пользователям реальную диверсификацию и свободу выбора, а не просто очередную вариацию на базе того или иного ядра.

С точки зрения разработки это, конечно, колоссальный вызов. Поддержка Safari на движке WebKit — это, по сути, второе полноценное инженерное направление внутри команды разработки. Сложность поддержки возрастает в разы по нескольким причинам:

• Раздельные циклы обновлений. По понятным причинам мы не можем использовать наработки, уже реализованные для Chrome — под WebKit пишутся отдельные фиксы и обновления. Именно поэтому небольшая часть функционала, уже доступного на Chrome-профилях, в Safari пока еще не появилась.
• Специфическое тестирование совместимости. Логика изоляции профилей, сетевое поведение и десятки других нюансов в Safari принципиально отличаются и требуют дополнительного внимания и тестирования.

Сейчас появляются вайбкод антики с Safari, почему это булщит?

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

С помощью ИИ сегодня действительно можно за пару вечеров «накидать» симпатичный интерфейс и запустить стандартный WebKit. Но визуальная работоспособность — это иллюзия. Качественный Safari-антидетект требует глубокой модификации ядра, а «вайбкод-продукты» сыплются на базовых вещах:

1. Использование некорректной базы. Тот же Playwright в своей документации прямо заявляет: его сборка WebKit не является фирменным Safari. ИИ берет готовое open-source решение, которое изначально создавалось для автоматизации тестирования, а не для маскировки. Антифрод-системы щелкают такие сборки как орехи.
2. Поверхностные подмены из-за «галлюцинаций» и линейности ИИ. Нейросеть делает ровно то, что ей приказали, не видя картину целиком. Если попросить ИИ подменить User-Agent, он добавит аргумент запуска. Но он «забудет» переписать сотни связанных параметров в глубине движка (например, специфические JS-отпечатки, особенности рендеринга шрифтов или Canvas, заголовки запросов). В итоге мы получаем критический рассинхрон данных.
3. Отсутствие реальной изоляции. Безопасный антидетект — это строгая изоляция профилей, согласованное поведение сетевого стека и регулярная адаптация под новые паттерны защиты. У ИИ-разработчиков без опыта в реверс-инжиниринге и создании браузеров просто нет понимания, как это реализовать и, главное, как это поддерживать на дистанции.

В итоге, вайбкод-антики красиво выглядят на скриншотах, но абсолютно беспомощны в реальном применении. 

---

Если вдруг ещё не пользуешься Vision, то переходи по ссылке dovolnyy.com/browser и бери на 4 дня безлимитного теста.

Понравился? Используй промокод CPALIKE, он даст -20% на первую оплату.