Google Maps’s Moat

https://www.justinobeirne.com/google-maps-moat

• на гугловских картах больше зданий, чем на всех других картах
• здания очень точно повторяют очертания
• оказалось, что отображаются даже сарайки, вентиляторы на крышах, окна, которые выдаются из зданий
• это работает как для крупных городов, так и мелких населенных пунктов (13 человек), в которых никогда не ездила машина гуглоулиц
• покатые крыши, колокольни, …
• парки
• он прошелся по пресс-релизам, нашел, что первые упоминания про детали зданий - это 2012 год
• детали: аэрофотосъемки + техника компьютерного зрения -> большие здания получили много деталей
• очень эффектно смотрятся башни: seattle space needle
• Останкинская - плоский объект на 3d фотках. На карте-плане, это стоит большой цилиндр
• съемка машиной началась в 2007, распознавание снимков из космоса началось позже, но уже лучше результат
• гугл сейчас делает очень многое, чтобы больше выдавать информации (ссылка на “Visualizing Mental Maps of San Francisco”)
• сложнее - обработка данных: деловые центры в городах (где есть магазины, кафе и т.д.)
• люди эти центры знают, на картах их не показать
• карты - вообще очень сложны: нельзя лепить метки, нужно понимать на каком уровне приближения показывать какие города, улицы и т.д.
• поэтому эти деловые центры не показать, пока не приблизишься максимально близко. Т.е. глядя на карту без приближения ты их не увидишь.
• Гугл решил это тем, что начал отображать дополнительным цветом:
  • затенением областей городов с большей плотностью населения
  • коричневатым - где есть “AOI” (areas of interest)
• Гугл не говорит, как делает AOI: “algorithmic process” = “области с наибольшей концентрацией ресторанов, баров, магазинов”
• автор похоже, распознал этот алгоритм (за деталями - в статью). Главное - гуглу нужны данные о магазинах, ресторанах
• И эти данные он получает из гугломашин.
• Т.е. текущая функциональность получилась комбинацией данных из спутниковых снимков и из снимков улиц => гугл делает данные из данных
• Эппл не распознает здания на снимках, хотя использует космические снимки
• далее автор показывает, чего эппл точно не делает из снимков (на основе их карт), и показывает, что эппл отстает на несколько лет.

Tail attacks on web applications

https://blog.acolyer.org/2017/12/11/tail-attacks-on-web-applications/

• 2017
• DDoS атака на классическое n-уровневое web- приложение
• Нацеливается на увеличение latency последнего звена, так, чтобы атаку было сложно распознать
• Атака использует millibottlenecks - вызываемое буферами системы, которые будут заполнены после краткого сильного трафика
• “пульсовый” трафик атаки
• “Tail attack” создает очень короткие (сотни миллисек) нехватки определенных ресурсов (CPU, disk IO) от которой зависят многие ноды. При этом создается иллюзия для специализированного ПО
• Т.е. подается очень короткий “ON” трафика, потом долгое “OFF”, когда система успевает остыть
• Когда такие всплески подаются регулярно, милли-бутылочное горлышко проявляется на одном из уровней архитектуры
• переполняется очередь сообщений, и это переполнение потом распространяется вверх по стеку архитектуры
• доходит до фронтенда, входящие пакеты игнорируются, и клиенты не могут пользоваться сервисом, т.к. задержки будут до секунд длины
• Тестирование на EC2/Azure показывают 4x-8x увеличение 95%-ile задержек на специальном бенчмарке RUBBoS (n-уровневое web-приложение)
• Анализ:
  • Модель сетей с очередями. Много параметров.
  • атакующий выбирает значения 4 параметров, и оптимальные параметры могут быть найдены с помощью разных тулов (Java Modelling Tool, etc)
  • можно использовать обратную связь.
  • слишком слабая атака - никто не заметит
  • слишком сильная атака - заметят тулы анализа и мониторинга
• Детектирование и мониторинг:
  • Мониторинг с гранулярностью меньшей, чем период миллиботтлнека
  • Атака - чаще всего коннект разорван, очереди переполнены, миллиботтлнеки.
  • анализ IP-адресов