объяснялка

Как отфильтровать в гугл-аналитике залогиненных пользователей?

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

Есть способ, который рекомендует сама гугл-аналитика — User-ID. В каждом запросе к GA добавляете этот параметр и дело в шляпе. Проблемы: информация о поведении таких пользователей будет отображаться только в отдельном Property (их будет трудно сравнить с незалогиненными) и в нем будут недоступны real-time вид и отчеты по демографии. 👎

Мы решили эту задачу с помощью Custom dimensions. GA позволяет создать до 20 дополнительных полей, данные в которые можно отсылать вместе с событиями и далее фильтровать по этим полям события и пользователей. Мы назвали это поле Authenticated и отправляем в него значние Authenticated прямо с бэкенда на событиях логина и регистрации.

Удобно, что метка определена с User-level scope, а это значит, что её достаточно отправить один раз. Все последующие события от этого Client-ID (не спутайте с User-ID) будут помечены как аутентифицированные автоматически, на сервере GA. Нужно только не забыть отдельно проставить эту метку для тех, кто уже залогинен. Мы задеплоили для этого временный код на фронтенд, который выключим через месяц, когда вся «ядровая» аудитория отметится.

Теперь мы можем легко сравнить поведение залогиненных и незалогиненных посетителей сайта просто включив фильтры в GA; при этом мы сохранили возможность смотреть на суммарное поведение всех посетителей вместе и не потеряли real-time аналитику и демографию. 😎

Этот же прием можно использовать для выделения и анализа любых групп пользователей (не только по признаку залогиненности). Учтите, что удалить уже созданную кастомную метрику нельзя (можно только перепрофилировать её или перестать ею пользоваться) и их доступно всего 20, так что используйте их с умом.

Почему важно шифрование?

Австралия приняла закон, который требует компании «предоставить ключи шифрования», прямо как в России с телеграмом (и даже хуже, 2, 3). Политики по всему миру синхронно творят дичь под флагом борьбы с терроризмом и детской порнографией (добавьте борьбу с наркотиками по вкусу). Пора объяснить «на пальцах», что происходит и почему это важно.

Идея простая: математика и программирование позволяют шифровать сообщения так, что после зашифровки, их сможет прочитать только адресат. Даже тот, кто только что зашифровал сообщение — не сможет расшифровать его обратно.

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

Прослушка и слежка — мощные инструменты, а вместе с вечным хранением и возможностями машинного обучения — сравнимы с ядерной бомбой. И тут какое-то «шифрование» делает их невозможными. Примерно как пороховые пушки превратили замки из супер-оружия в развлечение для туристов.

Политики пытаются вернуть свои «права на прослушку». Как? В 1970-1990е они пытались запретить шифрование. В штатах были законы, приравнивавшие мощное шифрование к оружию, доступ и экспорт которого контролировались наравне с базуками и гаубицами. В отличие от базук — воспроизводство качественных программ шифрования не требует заводов. Достаточно знать идею, а шила в мешке не утаишь.

Современный заход политиков следующий: а давайте все, кто делает программы шифрования, добавят в них «какой-нибудь способ», чтобы при необходимости, правительства могли прослушать переписку «как раньше», а во всех остальных случаях — пусть шифрование работает «как задумано».

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

Я не случайно привожу аналогии с оружием. Разговор о праве на тайну переписки, на тайну личных записей — про власть. Про право думать — изучать, писать, обсуждать то, что хочешь, а не то, что принято. И власть это запретить. Любое изменение статуса-кво, любая революция начинаются с идеи и именно поэтому государства по всему миру прикладывают столько сил, чтобы эту свободу «обуздать».

Не думаю, что у нас есть шанс что-то изменить в законах прямо сейчас. Но просвещать, объяснять, почему свобода (тайна) переписки это свобода мысли и почему её нельзя отобрать только у «плохих людей», оставив «хорошим» — наша обязанность.

Ютуб-агитация, чтобы разбавить пафос (к сожалению, только на английском): юмористическая реклама австралийского закона от комиков-антиподов и эпизод про массовую прослушку от Джона Оливера, где он прилетает в Москву, берет интервью у Сноудена (!) и переводит все его ответы на дикпики (!!)

Проблема вагонетки — интересная этическая задача, которая принимает практическую важность из-за машин без водителя. Классическая формулировка такая: вагонетка едет по рельсам и скоро задавит пять людей; вы можете переключить стрелку и тогда вагонетка задавит только одного человека на запасном пути. Переключите ли вы стрелку?

В случае автомобилей без водителя, нам нужно выбрать, что мы хотим заранее, на этапе программирования машины. Кого спасти — ребенка или старика? Пассажира (aka владельца машины) или пешехода? Отдельный интересный вопрос — кто должен принимать эти решения? Производитель машины? Её покупатель? Общество?

В 2014 году, исследователи из MIT запустили онлайн-программу, где можно попереключать стрелки вагонетки самому. The Moral Machine стала виральной и за 4 года в ней сделали 40 миллионов моральных выборов люди из 233 стран мира. Ученые проанализировали данные и опубликовали статью в Nature на прошлой неделе.

Люди разных культур дают разные ответы на эти вопросы. Французы, например, ценят детей больше стариков, китайцы — наоборот, а эстонцам всё равно. Там много интересных наблюдений, рекомендую прочитать краткий пересказ результатов исследования в MIT Technology Review.

Этого нет в исследовании, но самые страшные, как мне кажется, китайцы — они, видимо, встроят в машины базу данных социального рейтинга и будут минимизировать суммарную потерю оного. Хочешь жить — повышай свою «полезность обществу». Что значит полезный обществу?

Попробуйте поиграть с The Moral Machine сами. Вот какой первый вопрос выпал мне (я считаю, что мужчины и женщины одинаково ценны, так что пусть едет прямо, как ехал):

В Firefox Nightly и в Cloudflare подвезли поддержку Encrypted SNI. Это рокот канонады, которая скоро накроет Роскомнадзор и остальных клоунов, блокирующих интернет.

(не-техническое описание в следующем абзаце) При установлении HTTPS соединения, клиент в незашифрованном виде передает серверу имя домена, с которым хочет установить TLS-соединение, это называется Server Name Indication, SNI. Пидоры (в плохом смысле этого слова) из Роскомнадзора парсят эту информацию (то, что называется Deep Packet Inspection, DPI) и блокируют неугодные сайты. Encrypted SNI шифрует имя домена, так что владелец канала увидит только IP-адрес и порт. Если сайт хостится на крупном CDN (типа Cloudflare), то у атакующего не будет другого выхода, кроме блокирования крупных частей интернета по IP-адресам.

Приведу аналогию с телефонными разговорами. На сегодняшний день, многие сайты не имеют своего телефонного номера (IP адреса), а пользуются общими номерами арендодателя (CDN типа Cloudflare). Это значит, что сотни тысяч сайтов используют один и тот же номер. Шифрование разговора при этом включается только после того, как вы скажете секретарю арендодателя, какой сайт вам нужен. Товарищ майор (Роскомнадзор) слушает все разговоры и обрывает ваш звонок, как только слышит имя запрещенного сайта. Новая технология позволит включить шифрование уже на этапе разговора с секретарем, так что у товарища майора не будет возможности блокировать отдельные сайты — только крупные части интернета целиком по номеру телефона (IP-адресу).

Технически, это гениальное в своей простоте решение сложной задачи. Специальный ключ домена хранится в оговоренной DNS-записи. Клиент забирает из DNS ключ и вместо ClientHello server_name делает ClientHello encrypted_server_name. Никто кроме целевого сервера не сможет расшифровать, какое имя домена просил пользовать. Понятно, что для того, чтобы это всё работало, нам нужен безопасный DNS. Тут на выручку приходит DNS over HTTPS (DoH), который уже поддерживается как минимум тремя крупными провайдерами: Google, Cloudflare и Verizon. Я до сих пор не понимаю, почему РКН не блокирует неугодные сайты через DNS (если кто знает причину — расскажите, пожалуйста), но с распространением в клиентах поддержки DoH, этот вектор атаки остается в прошлом.

Я думаю, что в перспективе 2-5 лет, власти России встанут перед выбором — двигаться по «китайскому сценарию», заблокировав внешний интернет скопом (и оставив только белые списки) или перестать блокировать точечно сайты, потому что это слишком неэффективно. Ой нет, извините, можно ещё делать хорошую мину при плохой игре и продолжать спускать деньги бюджета на бутафорию. Это — самый вероятный сценарий.

Очень жду, когда поддержка ESNI и DoH приедет в Google, AWS, Chrome, iOS и Android. И всё, пользовательский интернет станет на порядок безопаснее. В интересное время живем, товарищи!

Айфоны и андроиды. Для потребителя разница минимальна. Тот же экран блокировки с большими цифровыми часами, те же самые приложения.

Для любого человек в этом варящегося, iOS и Android - две параллельные вселенные. То, что ты сделал в одном мире - во многом не применимо в другом. Редкие программисты умеют разрабатывать приложения для обоих платформ одновременно, знают хорошо обе платформы - единицы.

Если компания хочет сделать приложение и для андроидов и для айфонов, она содержит два параллельных отдела мобильной разработки - для iOS и для Android. Каждая из двух программ выглядит немного по-своему, сроки разработки немного разные, ошибки — уникальны.

Каждые пару лет появляется новая технология «кроссплатформенной разработки». Меняются названия, технологии под капотом и компании, её продвигающие. Я на своём профессиональном веку увидел хайп и угасание гигантов PhoneGap — монструозный HTML, купленный Adobe и позже отданный в Open Source и переименованный в Apache Cordova; Xamarin — пишем на C#, который компилируется в нативные приложения для каждой платформы. Microsoft купила её в 2016.

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

Последняя модная (суперхайп) технология такого рода — React Native от Facebook. Программируем на современном lingua franca — javascript, а весь пользовательский интерфейс может быть нативным для платформы. Работает быстро, выглядит классно. Потенциально можно программировать силами веб-разработчиков (ну почти). Самое главное — в старые приложения можно добавлять новые экраны, сделанные на react-native. Технология молодая (2015 год), есть множество нерешенных проблем, но это первая кроссплатформенная балалайка, которую мне хочется попробовать. В России я знаю несколько компаний, которые успешно используют RN в продакшен-разработке. Радио Арзамас сделано на RN, например.

Отличная новость для системных администоров и всего интернета. Let's Encrypt начал поддерживать выпуск wildcard-сертификатов.

Что это значит?

Сертификаты безопасности (SSL/TLS-сертификаты) — магический математический артефакт. Он защищает сайты двумя способами: 1. шифрует соединение читателей с сайтом в интернете, так что никто* не может подсмотреть, какие страницы открывает человек или данные он передает через формы сайта 2. позволяет подтвердить**, что между сайтом и читателем не влез злоумышленник, который меняет часть сообщений на другие (например, без SSL злоумышленник мог бы перехватить и изменить ваше банковское поручение).

Система безопасности сейчас построена так, что для создания (выпуска) сертификата нужна третья сторона, так называемый центр сертификации (Certificate Authority). Это бизнес и чуваки собирают деньги за каждый сертификат. Вдобавок, каждый выпуск сертификата это ручной процесс (благо он происходит раз в год или реже).

Несколько лет назад группа людей и организаций (посмотрите About, там много звездных имен) решили, что для общей безопасности нам нужно сделать выпуск сертификатов бесплатным и автоматизированным. И это сработало! Вот безумный график их роста, а вот тут исследование показывает, что 30% пользователей COMODO перешли на Let's Encrypt.

Зачем нужны wildcard'ы?

Дело в том, что порой у сайтов есть много поддоменов (то, что перед именем сайта через точку, www.meduza.io, monitor.meduza.io, specials.meduza.io, например). Как защитить эти сайты? Можно выпустить по отдельному сертификату для каждого этого поддомена. Так многие и делают, но есть ситуации, когда гораздо лучше заказать один (wildcard) сертификат *.meduza.io, который можно использовать на любых поддоменах Медузы.

Раньше LE не умел выпускать wildcart-сертификаты, а теперь научился.

Это был один из последних*** сильных аргументов, чем коммерческие Certificate Authority лучше Let's Encrypt.

Ура!

* Ходят слухи, что у NSA есть способы
** У злоумышленников есть 101 способ обвести вас вокруг пальца. Математику мы делать научились, а интерфейсы, которые бы помогли не попасться на удочку мошенника — нет.
*** Есть ситуации, в которых сертификаты от LE не годятся, но если вы в этой ситуации — то скорее всего знаете, что делать.

Вчера ночью сняли эмбарго с информации об уязвимостях процессоров.

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

Это страшно «облакам», суть которых как раз в том, что программы разных людей делят один физический сервер. Сейчас модно называть такой подход виртуализацией. Речь идёт о более эффективном расходовании серверов: если две программы (два клиента) могут поместиться на один физический сервер - так и делаем. Принципиальное обещание «виртуализации» в том, что ваши данные так же защищены, как если бы они были на отдельном сервере. Ага.

Самих дыр не достаточно - нужно сочетание многих условий для того, чтобы извлечь из неё какую-либо «выгоду». Думаю, многие «исследователи» в кавычках и без занимаются этим вопросом прямо сейчас. Будет ли идти речь о таргетированных атаках, когда отсифонят секретные данные конкретной жертвы и используют их для дальнейших этапов атаки или о каких-то «массовых изъятиях денег у населения» - пока говорить рано. Поживём-увидим. (Я бы назвал эти уязвимости popcorn time)

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

Строго говоря, речь идёт о 3 уязвимостях: bounds check bypass CVE-2017-5753, branch target injection CVE-2017-5715 и rogue data cache load CVE-2017-5754.

Интересно, что их одновременно нашли две независимые групп исследователей. Первая - звездный Project Zero из Google. Они отправили письма производителям процессоров ещё 1 июня (!) 2017. Вторая - группа исследователей из универов. Project Zero опубликовал классный технический разбор, а университеты максимально отработали PR-сторону, нагнав страху на массовую аудиторию «дизайнерским лендингом».

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

Представьте, вы получили секретный документ. Как не запалить источник?

Как и в других ситуациях связанных с безопасностью, представим себе на месте противника.
​

Какие есть способы пометить документ?

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

Если говорить о цифровой передаче, то есть несколько механизмов. Самый кондовый — умышленно допустить разные орфографические ошибки в разных версиях файла. Вариант поизощреннее - заменять буквы на похожие. Кириллическую (русскую) букву «а» сложно отличить на глаз от латинской (английской) буквы «a», но это разные символы. Даём каждому потенциальному источнику «утечки» файл с уникальными заменами и потом смотрим, какая версия оказалась в паблике. У этого способа есть недостаток — компьютерная проверка орфографии живо выявит все такие «метки».

Сегодня я наконец-то увидел в паблике гораздо более крутой способ, основанный на «символах нулевой ширины». Вот самые известные: разделитель нулевой ширины, нужный, чтобы две буквы не «слиплись» в лигатуру; пробел нулевой ширины, порой используемый для расстановки «точек желаемого переноса»; и соединитель нулевой ширины, который, как ни странно, соединяет две буквы, которые иначе бы не слиплись (используется, например, в арабском).

Как вы уже наверное догадались, эти символы можно щедро расставить в тексте (даже автоматически, на каждое скачивание секретного файла отдавать его с уникальным «цифровым отпечатком»), и потом точно определить источник утечки. Я только что проверил популярные типографы, все они оставляют эти символы нетронутыми.

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

Вариант, когда в тексте заменяются слова на синонимы тоже имеет право на жизнь. Существует специализированный софт, который автоматизирует эти вещи.

Для желающих позалипать в википедию - вот релевантная статья про «canary trap».

Обрыв двух независимых 20kV линии питания и всей оптики до основных площадок обмена трафиком в Европе — не очень частая ситуация. Тем более хороший повод повторить основные правила.

Идеальная схема — когда запросы идут параллельно на две площадки у двух не-аффилированных провайдеров (не два ДЦ у одного и того же провайдера, а прямо разные компании). Админ в Букмейте был из старой гвардии Яндекса и поддерживал такое. В таком сетапе падение одного провайдера проходит незаметно для читателей. Это обычно сложно технически и стоит денег по ресурсам.

Чуть похуже — горячая замена (опять же у отдельного провайдера). Это когда есть копия полностью рабочего сервиса, которая стоит ждет своего времени. В этом случае вы упадете, но минут на 10. Это проще технически, но стоит денег — половина железа «простаивает».

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

В противном случае – молимся, постимся и слушаем радио Радонеж при каждом падении.

У каждого свой подход к сообщениям и уведомлениям.

Мой подход следующий:
1. Не трогать письма и уведомления, на которые не хочешь реагировать. Не кликать, не архивировать, не удалять. Посмотрел заголовки и пока. Анти zero inbox;
2. Выключать уведомления (режим do not disturb), если нужно сконцентрированно поработать. Такая возможность есть и в компьютере тоже;
3. Выключать badge count - красные шарики, показывающие, что есть непрочитанные сообщения. Они имеют удивительно сильное влияние на психику и вы поразитесь, насколько меньше будете открывать приложения на телефоне, если выключите им badge count. Особенно это касается мессенджеров. Вы не пропустите ничего важного - новые сообщения все равно отобразятся в Notification Center. Эту настройку приходится делать отдельно для каждого приложения в iOS, но только один раз.

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

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