Вот так Да, всё так, по слоям разложили точно. Добавлю пару мелочей с нашей стороны.
Порт уникален, пока живо соединение. Но его выдаёт NAT оператора, и при смене IP все соединения рвутся. После смены клиент приходит уже с другим адресом и другим портом, поэтому по сокету его не связать.
А cookie, как вы и пишете, смена IP вообще не касается. Об этом статья и была: новый адрес сбрасывает лимиты и капчу, но сессию и отпечаток браузера не трогает.
С парсерами под видом браузера тоже согласен. Банить мобильный адрес неудобно: у нас больше половины адресов за сутки побывали у нескольких модемов, а за ними сидят и обычные люди. Поэтому сайтам приходится смотреть на всё сразу, а не только на IP.
Справедливо, canvas в статье нет, и это сознательно. Я разбирал только то, что сервер видит в самом соединении, ещё до того, как на странице выполнится первая строчка JS: SYN, ClientHello, первые кадры HTTP/2 и ритм запросов. Canvas живёт уровнем выше. Чтобы его получить, антибот должен отдать страницу со скриптом, а клиент должен этот скрипт выполнить и отрисовать картинку.
Отсюда и про «если канваса нет». Клиент без браузерного движка, тот же requests или curl, до canvas обычно не доходит. Его JA4 и SETTINGS в HTTP/2 не похожи ни на один браузер, и отсечь его можно ещё на ClientHello, без всякого JS. Так что вы правы, просто узнают такого клиента раньше.
Интереснее, когда canvas есть. Тут два случая, и оба антиботу удобны.
Хеш стабильный. Тогда это такой же отпечаток, как JA4, и смена IP его не трогает. Один и тот же canvas каждые 120 секунд с нового адреса того же оператора связывается так же легко, как всё остальное в статье.
Хеш шумит, то есть в пиксели подмешивается случайность. Тогда признаком становится сам шум: canvas меняется от сессии к сессии, а JA4, параметры HTTP/2 и TCP-профиль ноды остаются прежними. К тому же canvas должен сходиться с остальным: с WebGL-рендерером, User-Agent и шрифтами. Заявленный смартфон, который рисует через программный рендерер, выглядит хуже честного десктопа.
Для темы статьи вывод тот же, что и по остальным слоям. Canvas считается в браузере клиента, прокси его не видит и не меняет, смена IP на него не влияет никак. Цифр по canvas у нас нет и не будет, это JS и содержимое HTTPS на стороне клиента.
Если дойдём до стенда, о котором я писал в разделе «Что не получилось», canvas и WebGL логично замерить там же, пятым слоем.
Вот так Да, всё так, по слоям разложили точно. Добавлю пару мелочей с нашей стороны.
Порт уникален, пока живо соединение. Но его выдаёт NAT оператора, и при смене IP все соединения рвутся. После смены клиент приходит уже с другим адресом и другим портом, поэтому по сокету его не связать.
А cookie, как вы и пишете, смена IP вообще не касается. Об этом статья и была: новый адрес сбрасывает лимиты и капчу, но сессию и отпечаток браузера не трогает.
С парсерами под видом браузера тоже согласен. Банить мобильный адрес неудобно: у нас больше половины адресов за сутки побывали у нескольких модемов, а за ними сидят и обычные люди. Поэтому сайтам приходится смотреть на всё сразу, а не только на IP.
Справедливо, canvas в статье нет, и это сознательно. Я разбирал только то, что сервер видит в самом соединении, ещё до того, как на странице выполнится первая строчка JS: SYN, ClientHello, первые кадры HTTP/2 и ритм запросов. Canvas живёт уровнем выше. Чтобы его получить, антибот должен отдать страницу со скриптом, а клиент должен этот скрипт выполнить и отрисовать картинку.
Отсюда и про «если канваса нет». Клиент без браузерного движка, тот же requests или curl, до canvas обычно не доходит. Его JA4 и SETTINGS в HTTP/2 не похожи ни на один браузер, и отсечь его можно ещё на ClientHello, без всякого JS. Так что вы правы, просто узнают такого клиента раньше.
Интереснее, когда canvas есть. Тут два случая, и оба антиботу удобны.
Хеш стабильный. Тогда это такой же отпечаток, как JA4, и смена IP его не трогает. Один и тот же canvas каждые 120 секунд с нового адреса того же оператора связывается так же легко, как всё остальное в статье.
Хеш шумит, то есть в пиксели подмешивается случайность. Тогда признаком становится сам шум: canvas меняется от сессии к сессии, а JA4, параметры HTTP/2 и TCP-профиль ноды остаются прежними. К тому же canvas должен сходиться с остальным: с WebGL-рендерером, User-Agent и шрифтами. Заявленный смартфон, который рисует через программный рендерер, выглядит хуже честного десктопа.
Для темы статьи вывод тот же, что и по остальным слоям. Canvas считается в браузере клиента, прокси его не видит и не меняет, смена IP на него не влияет никак. Цифр по canvas у нас нет и не будет, это JS и содержимое HTTPS на стороне клиента.
Если дойдём до стенда, о котором я писал в разделе «Что не получилось», canvas и WebGL логично замерить там же, пятым слоем.