В этом семестре мы проходим в Висконсинском университете курс «Введение в алгоритмы» (577), где нам рассказывают о способах доказательства корректности программ, динамическом программировании, сетевом потоке и обстоятельствах, при которых Дейкстра изобрёл свой алгоритм поиска кратчайшего пути.

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

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

Однако, наверно, разработчики поняли, что у системы есть уязвимость, которую невозможно пропатчить — друзья. Если они учатся на том же курсе, что и ты, то, лёжа в кроватке, можно отправлять им сообщения со слёзными просьбами поделиться кодом.

Поэтому для лекторов-параноиков TopHat реализовала фичу «надёжной проверки посещаемости», которая, согласно описанию, определяет местоположение «по геолокации устройства и близости к аудитории и другим студентам».

Когда я впервые услышал об этой системе, то задался вопросом, какую точность «геолокации» она обеспечивает. Существует множество традиционных сервисов «IP-геолокации», использующих IP-адрес и ASN: и то, и другое можно считать достаточно уникальными идентификаторами, отправляемыми веб-странице при её загрузке и позволяющими определять местоположение пользователя. В зависимости от того, где вы находитесь, результаты могут довольно сильно варьироваться. Когда я находился в Мэдисоне и Нью-Йорке, популярные сервисы IP-геолокации могли определить, что я примерно в миле от моего истинного местоположения. В моём пригородном районе погрешность увеличивается до уровня города¹. Разумеется, TopHat при определении посещаемости не полагалась бы на столь неточные показатели — студенты, живущие в кампусе Чедбёрн-Холла, не пошедшие на лекции в Mosse Humanities (их разделяет примерно 75 метров), вполне бы считались прилежно посещающими учёбу. Это было бы катастрофой!

Geolocation API

Увы, TopHat использует другую геолокацию. Как говорилось выше, определение геолокации IP происходит достаточно прямолинейно — веб-страницы могут видеть IP-адрес подключающегося к ним пользователя. Однако при попытке местоположение TopHat отображает большое страшное диалоговое окно!

Очевидно, что оно запрашивает нечто совершенно иное, настолько точное, что требует моего явного согласия.

Это Geolocation API — фича всех современных браузеров, позволяющая определять местоположение с гораздо большей точностью (потому и отображается всплывающее окно). На момент написания этого поста IP-геолокация отправляла меня куда-то в район Лейкшора (расстояние 1-2 мили), однако Chrome Geolocation API определял здание, в котором я нахожусь (Morgridge Hall), что на порядки величин точнее.

Когда мой ноутбук впервые выдал меня подобным образом, я задался вопросом: «Как это происходит?» В ноутбуке нет какого-то особенного устройства, доступ к которому позволил бы браузеру точнее определять местоположение… Или нет? В моём ноутбуке нет GPS-приёмника², который бы позволял определять местоположение так, как это происходит в телефоне (и он не просто использует GPS моего телефона, потому что такой же API определения местоположения есть и в устройствах с Windows).

В этом виноваты вы

Когда вы нажимаете во всплывающем окне «Разрешить», браузер при помощи эвристики точности определяет, каким из способов можно получить наиболее точное местоположение. Это может быть GPS (в устройстве с подключением к сотовой сети) или вышеупомянутое IP-геолокация, но, скорее всего, наибольшую точность обеспечит система позиционирования по Wi-Fi, использующая для определения местоположения окружающие пользователя беспроводные точки доступа.

Вот, как это работает: после того, как вы дадите браузеру разрешение на доступ к местоположению, веб-сайт получает доступ к функции getCurrentPosition(). При её вызове браузер просит у операционной системы передать ему список окружающих точек доступа Wi-Fi, а точнее, силу их сигнала, SSID и BSSID.

SSID сети — это просто удобное её имя, например, UWNet или eduroam. BSSID определяется на основе MAC-адреса точки доступа (но не всегда с ним совпадает), уникального для каждого устройства. Наличие уникального идентификатора у каждой точки доступа крайне важно, потому что множество точек доступа имеет одинаковое название. Для примера вот карта точек доступа с названием UWNet рядом с кампусом:

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

Wardriving

Привязка сетей Wi-Fi к их физическому местоположению остаётся важной ещё с начала 2000-х. Насколько я знаю, первой в коммерческих масштабах этой задачей начала заниматься Skyhook Wireless при помощи методики под названием wardriving. Она заключается в следующем: нужно сесть в машину и ездить по дорогам, перехватывая информацию о как можно большем количестве сетей Wi-Fi. Так как выполняющие сканирование сетей устройства точно знают своё местоположение (через GPS), достаточно связать местоположения обнаружения сети с силой её сигнала. Выполнив RSSI-трилатерацию, можно получить приблизительную карту сетей Wi-Fi и соответствующих физических точек.

Обладая всеми этими данными, можно выполнить обратный процесс — отправить с пользовательского устройства список доступных сетей Wi-Fi (и соответствующих RSSI), получив в ответ приблизительное местоположение устройства в мире. Долгое время именно так и вели себя мобильные устройства (в том числе и Apple до iOS 3.2), полагаясь на приватно собранный Skyhook или Google список. Любопытно, что последняя какое-то время использовала для записи информации о Wi-Fi свои машины, делавшие снимки Street View.

Однако позже компании осознали потенциальное преимущество получения этой информации от устройств пользователей. В конце концов, они всё равно часто проверяют своё GPS-местоположение и связываются с вышками сотовой связи, так почему бы заодно и не передавать анонимизированные данные о местоположении Wi-Fi?

Так и начали поступать устройства Apple, Google и Microsoft. Их сервисы определения местоположения стали по умолчанию собирать данные о SSID и BSSID точек доступа Wi-Fi в окрестностях (и их местоположения) и записывать их, чтобы другие устройства использовали эту информацию для более точного определения геопозиции. Примерно так же всё происходит и в современных устройствах. Когда Chrome говорит мне, что веб-сайт хочет воспользоваться моим местоположением, и я даю согласие на это, в Google передаётся список близких ко мне точек доступа. Благодаря тому, что десятки тысяч людей, имеющих устройства с GPS тоже пингуют сети, это позволяет моему компьютеру получать крайне точную оценку моего местонахождения. Так что спасибо за это стоит сказать всем пользователям.

Сомнительность такого решения

Возможно, вас немного нервирует то, что ваш телефон накапливает и передаёт информацию о местоположении каждой сети Wi-Fi, с которой вы взаимодействовали. И вы такой не один! Существует множество инцидентов, связанных с неэтичным использованием этой технологии.

Начнём с серьёзного примера: помните, в разделе о wardriving я говорил, что Google раньше использовала свои автомобили Street View для получения информации о сетях для своих сервисов определения местоположения? Как оказалось, компания вынюхивала гораздо больше, чем просто заголовки пакетов — она агрегировала сырые кадры данных 802.11 Wi-Fi, в том числе незашифрованную полезную нагрузку HTTP-пакетов. Предположу, что в 2010 году очень малая часть Интернета использовала HTTPS, поэтому в 600 гигабайтах данных, о которых отчиталась компания, определённо содержалось что-то, чем пользователи не хотели с ней делиться.

Ещё более серьёзные и обоснованные опасения вызывает возможность отслеживания местоположения пользователя. Обеспокоенность этой темой возникла ещё с момента появления WPS, и одним из самых старых из обнаруженных мной примеров стал доклад Эли Бурштейна с коллегами и его пост «Использование API геолокализации Microsoft для определения того, где находился ноутбук с Windows». В то время был обнаружен баг, из-за которого Windows сохраняла записи о каждом MAC-адресе, к которому она подключалась, что позволяло отслеживать перемещения пользователя при помощи какого-нибудь из существовавших тогда API определения местоположения.

Подобные уязвимости встречаются и сегодня — Эрик Рай и Дейв Левин из Мэрилендского университета написали в 2024 году статью «Surveilling the Masses with Wi-Fi-Based Positioning Systems», подробно описывающую изъян в сервисах определения местоположения Apple, позволивший им извлечь позиции почти двух миллиардов BSSID благодаря хитрой фильтрации пространства MAC-адресов. Это прекрасная научная статья, в которой затрагиваются реальные угрозы попадания информации в руки злоумышленников; например, можно следить за людьми, постоянно определяя BSSID их маршрутизатора или мониторить плотность населения в условиях боевых действий, наблюдая за перемещением групп устройств (и спутниковых Интернет-систем наподобие Starlink).

Со временем поставщики услуг определения местоположения усилили безопасность разрабатываемых ими API. Это крайне важно, учитывая рассмотренные нами угрозы, особенно из-за того, что почти каждое произведённое ими устройство по умолчанию³ передаёт такую информацию изготовителю. Почти каждая компания, участвующая в WPS, позволяет пользователю отказаться от мониторинга его BSSID, или изменив имя SSID, или указав MAC-адрес в какой-нибудь форме:

Заключение

У этой технологии есть название — Wi-Fi positioning system (WPS). По-прежнему существует активное сообщество любителей позиционирования по Wi-Fi: https://wigle.net/ — это краудсорсинговая база данных поклонников wardriving, в которую за последние 25 лет сохранили почти два миллиарда сетей. В ней можно посмотреть информацию о своём городе и увидеть плотность сетей Wi-Fi рядом с собой. Можно даже проверить, отметил ли кто-нибудь вашу собственную сеть!

Кроме того, было бы упущением с моей стороны не упомянуть и https://beacondb.net/ — «базу данных геолокации по беспроводным сетям в публичном доступе». Хоть мне и не удалось пока её изучить, по описанию это похоже на очень многообещающую открытую версию трекеров, которые мы сегодня так активно используем. Эта база данных не такая подробная, как у других поставщиков, и это отсутствие однородности данных у мелких поставщиков радует. Она доказывает, что данные действительно другие!

Было очень интересно исследовать эту область и узнать, как наши устройства определяют своё местоположение. Это довольно нишевые знания, которые я воспринимал, как нечто само собой разумеющееся; и мне определённо было невдомёк, что, находясь на лекции, я могу отметить своё присутствие благодаря тому, что тысячи других студентов (сами того не зная) пинговали сервера по всему миру.

Примечания

1. Вывод о том, что степень погрешности зависит от плотности застройки — моя личная гипотеза. Удивительно, насколько мало информации можно найти онлайн о том, как эти сервисы пытаются определить местоположение на основании только IP-адреса. В Википедии есть статья об IP-геолокации, но подробности реализации описаны в ней довольно невнятно…

2. Немного отойду от темы: а вы знали, что до мая 2000 года GPS-спутники (которыми владеют и управляют Космические силы США) передавали общественности сигнал со встроенной в него намеренной погрешностью? Это называлось Selective Availability; из-за такой погрешности точность показаний GPS снижались примерно до 100 метров по горизонтали. По множеству причин эта функция была отключена; одна из них заключается в том, что Differential GPS позволяет с лёгкостью обходить такие искажения благодаря сравнению сигнала с местоположением опорной станции, координаты которой известны.

3. В большинстве устройств эта опция связана с функцией «Службы геолокации», из-за чего нельзя отказаться от передачи телефоном сигналов окружающих его Wi-Fi устройств без полного отключения возможности получения своего местоположения.