WhatsApp в России депутаты обещают заблокировать уже в очень скором времени. Доверие к Telegram у многих довольно сильно было подорвано после публикации расследования одного издания об особенностях их протокола вкупе с подробностями о том, кто владеет их сетевой инфраструктурой и с кем он связан, да и недавнее появление Telegram в реестре РКН тоже оптимизма в их отношении не добавляет. Max - оставим для сумасшедших и безвыходных, учитывая, кто и зачем его создал. Signal - отличный мессенджер и всем хорош, но в России его тоже периодически пытаются заблокировать.

На фоне всего этого многие начали задумываться о поднятии своего сервера для обмена сообщениями. С самодельными серверами и "не-попсовыми" протоколами всегда встает проблема "а с кем там общаться?", потому что перетащить прям вот вообще всех собеседников и контрагентов на что-то им непривычное практически нереально. Но если речь идет только, например, об инструменте общения внутри семьи, небольшой группы единомышленников или внутри одной компании, то это может быть вполне неплохим вариантом.

В наше время как self-hosted альтернативу популярным мессенджерам часто упоминают Matrix, например, с клиентом Element. На Хабре есть подробные инструкции, например вот эта: https://habr.com/ru/articles/837904/. Я попробовал, и мне не понравилось. Клиенты тормозные, через нестабильный интернет-канал все работает просто отвратительно, а сам сервер просто неповоротливый и укладывает не слишком богатый на процессор и память VPS даже всего с парой клиентов.

И тут мне вспомнилось про XMPP, он же Jabber. Он родом еще из тех времен, когда люди пользовались процессорами на 200-300 мегагерц и подключались к интернету через dial-up модемы - то есть он изначально очень нетребовательный к ресурсам. Между тем, развитие его не замерло на месте, а на сегодняшний день он умеет почти все то что требуется от современного мессенджера: хранение истории, передача файлов, аудио-видео звонки, end-to-end шифрование, и другое.

На Хабре уже было несколько публикаций про новые принятые в Госдуме поправки (https://habr.com/ru/news/928638/, https://habr.com/ru/companies/amnezia/articles/928378/, https://habr.com/ru/news/928332/ и т.д.), и там в комментариях звучало много довольно схожих вопросов на тему "а как оно может быть?", на которые я постараюсь сегодня ответить.

Сразу говорю, разбирать будем именно с технической, а не с юридической точки зрения. С юридической точки зрения там, конечно, тоже есть интересные моменты.

Многие люди, занимающиеся информационной безопасностью, включая меня, давно считают Telegram подозрительным и ненадежным. Теперь, основываясь на выводах, опубликованных расследовательским журналистским изданием IStories*, и моем собственном анализе перехватов пакетов из Telegram для Android и протокола Telegram, описанного ниже, я считаю Telegram неотличимым от ханипота для слежки.

Мы раскрыли новый метод отслеживания, используемый компаниями Meta* и Яндекс, который потенциально затрагивает миллиарды пользователей Android. Мы обнаружили, что нативные приложения Android — включая Facebook, Instagram и несколько приложений Яндекса, таких как Карты и Браузер — незаметно слушают определенные локальные порты в целях отслеживания.

Эти нативные приложения Android получают метаданные браузеров, куки и команды от скриптов Meta* Pixel и Яндекс.Метрики, встроенных на тысячи веб-сайтов. Эти скрипты загружаются в мобильных браузерах пользователей и незаметно связываются с нативными приложениями, работающими на том же устройстве, через локальные сокеты (localhost). Так как нативные приложения программно получают доступ к идентификаторам устройства, таким как рекламный идентификатор Android (AAID), или обрабатывают идентификацию пользователя, как в случае приложений Meta, этот метод позволяет этим организациям связывать сессии мобильного браузера и веб-куки с личностью пользователя, тем самым деанонимизируя посетителей сайтов, на которых размещены их скрипты.

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

Просили нас тут рассказать про протокол технологию XHTTP в контексте XRay, VLESS и прочих. Просили — рассказываем!

Для начала немного истории. Классическое использование VLESS и подобных прокси‑протоколов (в том числе с использование XTLS‑Reality) предполагает подключение клиента напрямую к прокси‑серверу, который крутится на каком‑нибудь VPS. Однако во многих странах (и в России тоже) под блокировки (или замедления) начали попадать подсети популярных хостеров целиком, а в других странах цензоры начали отслеживать подключения к «одиночным» адресам с большим объемом трафика. Поэтому еще с давних времен обдумывались и проверялись идеи подключения к прокси‑серверам через CDN (сети доставки контента). Чаще всего для этого использовался websocket‑транспорт, но у этого варианта есть два больших недостатка: у него есть один характерный признак (не буду указывать его тут, чтобы не облегчать работу РКН), а во‑вторых, число CDN, которые поддерживают проксирование вебсокетов, не так уж велико, и хотелось бы иметь возможность проксироваться и через те, что не умеют.

Поэтому сначала в известном проекте Tor для бриджей (мостов) придумали транспорт meek, который позволял передавать данные с помощью многочисленные запросов‑ответов по HTTP, и таким образом позволял подключаться к мостам (прокси) через любые CDN. Чуть позже этот же транспорт реализовали в ненадолго воскресшем из мертвых V2Ray. Но у meek есть два очень существенных недостатка, которые вытекают из его принципа работы: скорость работы очень низкая (по сути дела у нас полудуплексная передача и огромный оверхед на постоянные запросы‑ответы), и из‑за огромного количества GET/POST‑запросов каждую секунду, бесплатные CDN довольно быстро могут нас выгнать на мороз, а платные — выкатить солидный счет.

Привет, меня снова зовут Егор Гаврилов, и сегодня будет продолжение той статьи, уже в контексте того, как установить заветный "голый дед" (GoldED+) на свой телефон, вместе со стандартным тоссером Husky, и мейлером BinkD, а также получить первого поинта в сети.

Привет всем! Меня снова зовут Егор Гаврилов, и я расскажу интересную историю, как я стал самым молодым фидошником в настоящее время.

Если вкратце - я являюсь полноценным участником сети FidoNet (согласно POLICY4), так как я являюсь полноценным сисопом (системный оператор - примечание автора) своей ноды (узла в сети FidoNet - примечание автора) 2:5015/519. Я также являюсь автором форка FidoIP под названием FidoIP-NG - улучшенная версия, которая позволяет ещё больше ускорить настройку ноды и поинта в сети FidoNet. Нода на момент написания статьи находится в Cloud.ru - спасибо им за дешёвый тариф (который "free tier"), который позволяет многое.

Привет всем! Меня зовут Егор Гаврилов. И я сегодня покажу все секреты того, на чём основаны прошивки приёмников Триколора, и как всё внутри основано.

От переводчика: Эта статья, написанная в 2021 году, хоть и фокусируется на Европе, а конкретно на Нидерландах, на самом деле очень актуальна и по сей день и для других стран, в том числе и для России (за некоторыми исключениями). Она очень хорошо, например, отвечает на классические вопросы к статьям со статистикой зарплат вида "Где вы такие зарплаты находите, никто из моих знакомых столько не получает!" и вполне объясняет, почему большинство работников мало заметили уход международных компаний с российского рынка.

Я работаю нанимающим менеджером в Uber, в Амстердаме, уже более 4 лет. За это время рынок - и зарплаты - для программистов двигались вверх невероятными темпами.

Но интересно, что многие не заметили значимых изменений в зарплате за эти годы. В опросе разработчиков Honeypot Amsterdam за 2019 год говорится, что «самые опытные разработчики зарабатывают в среднем 55 000 евро и более 70 000 евро». В отчете о зарплатах Talent.io за 2021 год зарплата самых опытных разработчиков программного обеспечения в Амстердаме составляет 60 000 евро в год.

Между тем, по моим наблюдениям, средняя общая сумма вознаграждения старших сотрудников Uber почти удвоилась со 110 000 евро в 2015 году до 170 000-230 000 евро в год к 2020 году. И это не только в Uber: в Booking.com общая сумма вознаграждения старших сотрудников выросла на 50% - с €100 000 в 2016 году до €150 000+ в рамках проводимого мной исследования зарплат в ЕС.

Откуда же берется такое несоответствие в наблюдениях?

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

Matrix — открытый протокол мгновенного обмена сообщениями и файлами с поддержкой голосовой и видеосвязи. Почему стоит обратить на него внимание, если у нас уже есть WhatsApp и Telegram? Причин несколько.

Во-первых, в последние дни Роскомнадзор снова начал развлекаться блокировками WhatsApp и Telegram, и иногда у него это даже получается более-менее успешно. В таких условиях всегда неплохо иметь запасной вариант, и Matrix здесь очень хорошо подходит, потому что во-первых он позволяет создавать свои собственные сервера, а во-вторых его протокол со стороны выглядит как самый обычный HTTPS.

Во-вторых, все больше и больше людей не доверяют WhatsApp и Telegram. В случае с Matrix же можно поднять свой личный сервер, протокол Matrix - открытый, исходники клиентов - открыты, исходники серверов - тоже открыты, а в самом протоколе end-to-end шифрование включено для чатов по умолчанию из коробки (в отличие, например, от Telegram, где оно доступно только в "секретных чатах"). Ну и само собой, не требуется нигде вводить телефонный номер для регистрации.

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

Сервер Matrix может работать как изолированно ("только для своих"), так и в составе "федерации" - когда разные серверы общаются между собой, и пользователи, подключенные к разным серверам, могут общаться друг с другом. Есть здесь олды, которые помнят Jabber и IRC? Ну вот, здесь такой же принцип. Я бы даже сказал, что Matrix - это этакий хипстерский Jabber на стероидах.

В этом посте я кратко поведаю о разных интересных возможностях XRay (клиент и сервер для протоколов VMess, VLESS, Trojan и других, в том числе с XTLS-Reality и XTLS-Vision), о которых, кажется, мало кто знает, но которые могут оказаться очень полезными.

Оглавление:

- Фрагментирование запросов
- QUIC-транспорт
- Мониторинг и автоматический выбор outbound'а
- Сбор статистики
- Browser dialer

Представляю вашему вниманию короткий обзор что же произошло в России и в мире в области цензуры интернета и того, как этому противостоят энтузиасты. На всякий случай напоминаю, что статья «Надежный обход блокировок в 2024: протоколы, клиенты и настройка сервера от простого к сложному» заблокирована на Хабре для пользователей из РФ, но по‑прежнему без проблем открывается через прокси/VPN с иностранных адресов. Ну а мы сейчас разберем, что же изменилось с тех пор.

Сегодня в программе: Замедление YouTube — проблемы с Google Cache или намеренное вредительство? Можно ли заблокировать Shadowsocks и как РКН смог это сделать? Новые транспорты в XRay: HTTPUpgrade и SplitTunnel. Новости из мира Tor, и многое другое.

Довольно часто в последнее время на разных форумах и чатах люди жалуются, что когда они пользуются VPN или прокси, то у них после подключения на устройствах как-то странно начинают работать некоторые приложения. Например, не приходят сообщения в WhatsApp, не загружаютя сторис в Instagram, и другие подобные вещи. Причем нередко проблема чинится сама по себе спустя 10-15 минут после подключения, но после переподключения или переоткрытия клиента начинается снова. Иные жалобы состоят в том, что не смотря на то, что пользователь выходит в интернет через VPN или прокси, некоторые заблокированные сервисы и сайты у него все равно не открываются. И в том и в том обычно винят баги прокси/VPN-клиентов, администраторов серверов, и кого угодно еще. И я вам скажу: зря. Все гораздо проще и гораздо сложнее одновременно.

В предыдущей статье обсуждалась функция ROW_NUMBER. Сейчас же мы рассмотрим другие функции ранжирования: RANK, DENSE_RANK и NTILE. Начнем с RANK и DENSE_RANK. Эти функции по функциональности и реализации аналогичны ROW_NUMBER. Разница в том, что ROW_NUMBER присваивает уникальное (возрастающее) значение каждой строке без учета связей в значениях ORDER BY, а функции RANK и DENSE_RANK присваивают одно и то же значение строкам, имеющим одинаковое значение ORDER BY. Разница между функциями RANK и DENSE_RANK заключается в том, как значения присваиваются строкам. Проще всего проиллюстрировать разницу между всеми этими функциями на простом примере:

Эта статья о том, что нового появилось в SQL Server Management Studio 20 (SSMS), и является второй из серии статей на эту тему. Первую статью можно почитать тут: Upcoming changes for SQL Server Management Studio (SSMS) — Part 1.Заключительной статьёй в серии является: Upcoming changes for SQL Server Management Studio (SSMS) — Part 3. SSMS 20 может удивить Вас сразу после установки, когда вдруг обнаружится что по умолчанию предполагается шифрованное соединение SSMS с сервером баз данных. На то, чтобы помочь пользователям SSMS справится с этой проблемой и добиться лучшей защиты соединения с помощью новых механизмов шифрования SQL Server 2022, как раз и направлена эта статья.

На Хабре неоднократно в комментариях звучало мнение, что Россия впереди планеты всей по онлайн‑сервисам. Мол, у нас и госуслуги, и финтех, и такси, и доставки — все на высочайшем уровне, а в остальных странах, а особенно в отсталой Европе бедные бюргеры до сих пор стоят в многочасовых очередях, заполняют вручную тонны бумажек и ждут в очередях на кассах чтобы сделать банковский перевод, а курьер не привезет им ночью смузи в течении получаса после заказа. Давайте разбираться, так это или нет.

Четыре функции ранжирования: ROW_NUMBER, RANK, DENSE_RANK и NTILE появились в SQL Server 2005 и отличаются от обычных скалярных функций тем, что результат, который они выдают для строки, зависит от других строк выборки. От агрегатных функций они отличаются тем, что возвращают только одну строку для каждой строки на входе, т. е. они не объединяют набор строк в одну. В этой статье мы рассмотрим ROW_NUMBER — самую простую из всех функций ранжирования.

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

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

Написать этот материал меня побудило... отсутствие хороших статей по корутинам в C++ в русскоязычном интернете, как бы странно это не звучало. Ну серьезно, C++20 существует уже несколько лет как, но до сих пор почти все статьи про корутины, что встречаются в рунете, относятся к одному из двух типов. Или обзор начинается с самых глубин и мелочей, пересказывая cppreference, а потом автор выдыхается и все сводится к "ну а дальше все понятно, возьмите и примените это в своем коде", что напоминает известную картинку с совой. Либо иногда в статьях рассматривается применение корутин на примере генераторов, и этим все и ограничивается. Но, давайте будем честны, генераторы — это замечательно, но за все время моей многолетней карьеры разработчика я, вероятно, делал что‑то подобное генераторам разве что разок, в то время как асинхронный ввод‑вывод приходится использовать почти в каждом проекте. И поэтому меня гораздо больше интересует реализация асинхронного ввода‑вывода с использованием корутин, а не генераторы. Поэтому пришлось разбираться во всем самому.

В предыдущей статье Внутренняя оптимизация операций изменения для индексов было рассказано о том, что планы запроса для UPDATE состоят из двух частей: курсора чтения, который выбирает строки, которые необходимо изменить, и курсора записи, который и выполняет изменения. SQL Server использует такую логику изменения, следуя которой курсоры чтения и записи в плане с UPDATE выполняются двумя отдельными шагами или фазами. Другими словами, фактическое изменение в строке не должно влиять на выбор строк изменения. С этим связана описанная ниже проблема, для преодоления которой нужно обеспечить такую работу курсора записи в плане с UPDATE, чтобы он не влиял на курсор чтения, эта проблема известна под названием «Halloween Protection». Такое имя она получила поскольку была обнаружена исследователями IBM более 30 лет назад в Хэллоуин.