Зачем Android-устройства отправляют GET-запросы на IP-адреса Google вида /generate_204?

собственно, первая ссылка с поисковика

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

Сначала браузер сравнит адрес с локальным списком припаркованных доменов. При обнаружении совпадения он отправит хешированную частичную копию URL в Google, чтобы проверить правильность данных в списке. При этом используется тот же метод, что и для работы функции безопасного просмотра (он описан в разделе "Фишинг и вредоносное ПО" выше).

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

Кроме того, если имя домена не найдено, Chrome анализирует причину сбоя, пытаясь определить заданное имя хоста (“google.com”) с помощью общего DNS-сервера Google и DNS-сервиса, установленного для вашей системы по умолчанию. Это позволяет пользователю получить больше информации об ошибке.

Если время ожидания подключения по протоколу SSL истечет, возникнут ошибки с сертификатом или другие проблемы с сетью, связанные с работой адаптивного портала (например, сети Wi-Fi в отеле), то Chrome отправит по адресу www.gstatic.com/generate_204 специальный запрос без файлов cookie, чтобы проверить отклик. Если запрос будет переадресован на другую страницу, она будет открыта в новой вкладке (скорее всего, это будет страница входа). Запросы на страницу проверки адаптивного портала не регистрируются.

Функцию подсказок при ошибках навигации можно отключить, сняв соответствующий флажок в разделе "Личные данные" в настройках Google Chrome.

Спасибо. Немного погуглив в эту сторону, нашел упоминания об этом в файле WifiWatchdogStateMachine.java в исходниках, но не во всех версиях. Видимо, позже этот алгоритм был впилен в другие места, но не суть важно. Это называется как-то вроде "walled garden check".

https://android.googlesource.com/platform/framewor...

"On DNS success, the WatchdogService initiates a walled garden check via an http get. A browser window is activated if a walled garden is detected."

Судя по той теме на stackoverflow, этот запрос много где используется. И однажды можно словить переход на страницу, что "данный ресурс заблокирован" (в случае с блокировкой от провайдера).

Что, собственно, я только что протестил. В уведомлениях появляется пункт, что требуется авторизация, после захода в браузер. Нажатие на него перекидывает туда, куда ведет редирект с этого адреса.

В принципе сделано логично все это, но блокировать IP гугла нельзя.

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

@386DX Я имею в виду другое. Блокировку не на уровне L3, а на уровне L7 по заголовку в пакете http (Host). Это делает squid tproxy для ip-адресов из списка запрещенных сайтов, которые через эту проксю проходят после анонса по bgp.

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

Сейчас сделаю исключения насчет этого. Кстати говоря, собираюсь статью на хабр написать касательно реестра вообще, но не уверен, что ее хорошо примут. Для меня это все ради интереса, а не репрессивного сапога ради. Вообще обо всем: и о реестре, и о том, как это сделано, и о скриптах, которые все это делают (а там уже не просто портянка, а нечто похожее на нормальное ПО).

Хм.. ответил на комментарий, а его уже нет %)

@DmitryPhilimonov Deep packet inspection просто дороже вот ответ. Написано про это уже много

@386DX Кстати говоря, в свое время (чуть более года назад) не встретил ни одной вменяемой статьи насчет того, как это реализовано. Из хорошего есть только про выгрузку из реестра от netangels вроде. Но о примерах внутри провайдеров, полноценного опенсорса для работы с реестром, тонкости/фейлы в реестре (коих там много), как можно законно и правильно его обойти, а также почему не катят линуксовые возможности для организации именно DPI (а не прокси) ничего или почти ничего. На других ресурсах есть частные примеры, отрывки инфы, на хабре в основном политический уклон. Сейчас ситуация на хабре не изменилась. У меня уже есть в черновиках статья, плюс наработки, никак не могу закончить..)

Ну да ладно, вопрос был не об этом, так что не стоит тут флудить.