О, интересно. Насколько я понимаю в рамках андроида off-host означает что данные от NFC чипа будут напрямую прокидываться в UICC, которым, насколько я понимаю, может быть как SIM-карта, так и SecureElement. Но сам я таким не пользовался. Мне кажется, это довольно экзотичный случай.
Ещё, насколько я понимаю, по похожей схеме у NXP работают аппаратные SAM-модули для современных карт mifare. Чип делегирует им передачу данных от карты, а они занимаются расчётом криптографии необходимой для получения криптограмм в challenge-response схеме аутентификации секторов на чтение/запись. Таким образом данные о ключах спасаются от нахождения в памяти хост-системы к которой подключён кард-ридер
Плюсую. Вообще вроде как по идеологии NFC ответ должен быть всегда очень быстрым, но при этом современные реалии существенно скорректировали это, т.к. 13.56МГц картам, в чипе которых например крутятся апплеты, считающие тот же RSA, очевидно необходимо большее время для ответа чем LF-карточке передающей только свой ID. Насколько я понимаю, время таймаутов на получение ответа настраивается на уровне драйверов и в общем PC/SC драйвере на винде например по умолчанию составляет 5 секунд.
Я для интереса эмулировал ISO-7816 NDEF тэг на андроиде через HCE сервис. А HCE сервис в андроиде так устроен что сначала система получает ISO SELECT APDU (00 A4 04 ... ), парсит из него значение AID (идентификатора апплета с которым необходимо начать работу), затем по этому AID система смотрит есть ли среди манифестов приложений объявленые HCE-сервисы которые умеют эмулировать апплет с таким ID и если есть, то стартует этот сервис и передаёт ему управление. Это занимает время, плюс на старте сервиса у меня инициализировалось создание объектов, вычитывание данных из песочницы и т.д. что тоже занимает время, и по факту ответ на первую APDU приходил с ооооочень большой для NFC задержкой (очень много миллисекунд), но ничего - ни один ридер не подавился. Так что не исключено, что и relay-атаки вполне осуществимы
Спасибо за интерес к статье! Про механику шифрования раздела с данными и "default_password" - хорошее замечание, я не раскрыл этот момент в статье, потому что с точки зрения извлечения данных в сценарии когда у атакующего есть физический доступ это имеет значение только на телефоне без установленной блокировки экрана, а без установленной блокировки экрана злоумышленник и так сможет посмотреть всё что захочет.
Режим LTE-only, в котором запрещён fallback на более старые 3G/2G/EDGE присутствует в GrapheneOS. Несмотря на то что звучит это интересно, если я правильно понял, то эта фича встроена именно в сборку системы, и я не уверен насколько хорошо и надёжно это работает под капотом, потому что окончательные решения по использованию протоколов и режимов выбирает прошивка модема, а не андроид, и я не могу быть уверен что со стороны андроида это можно полноценно контролировать.
О, это превосходная новость! Пользуюсь maps.me много лет и очень давно ждал этого.
На FDroid долгое время существовал аналогичный форк «Maps», но человек который его делал забросил поддержку после того как в maps.me стали вносить слишком много изменений, включая кажется переход на какой-то свой формат карт вместо стандартного. Наверное этому были адекватные объяснения, но выглядело это как желание выжать форки с рынка.
К тому же, когда вы форкаете maps.me, то по правилам лицензии, да и исходя из здравого смысла, обязаны отказаться от оригинального бэкенда maps.me и перебросить приложение на свой, а его необходимо поддерживать, так что ребята проделали очень серьёзную работу. Огромный респект!
На мой взгляд название статьи немного вводит в заблуждение.
Стандарт PCI-DSS _обязывает_ производителей банкоматов и другого подобного оборудования разносить все отдельные части общей системы которые могут подвергнуться риску компрометации в отдельные модули. Например код отвечающий за проведение EMV транзакции и взаимодействие с чипом карты (NFC или контактная площадка, не важно) обязан быть вынесен в другое пространство и не выполняться на самом хосте. Это значит что и кардридер, и кассетник для работы с наличными, и ККТ с фискальником, и многие другие части не будут частью основной машины, а будут отдельными устройствами подвешенными на PCI или USB шину. Для работы с картами например в 99% случаев будет использоваться отдельное устройство, причём вся логика работы с картами будет _уже_ зашита в нём и все данные касающиеся этого никогда не будут передаваться между читалкой и хостом. На деле это означает что с компьютера внутри банкомата будут посылаться не команды «отправь карте массив байт 00A40000AABBCCDDEE00» или «прочитай массив байт из буфера куда записался ответ от карты», а «вот сформированный документ, подпиши приватным ключом и верни цифровую подпись». Т.е. позаигрывать с буферами особо не получится. В редких исключениях, в ситуациях когда подобное сильно затруднено, например в кассовых устройствах на базе android, вся эта логика будет крутиться как минимум в отдельном отгороженном со всех сторон процессе, хотя возможно и это уже запретили.
Поэтому даже скомпрометировав железку проводящую NFC взаимодействие с картой с вероятностью в 99,9% ничего дальше провернуть не получится, хотя наверняка устроить DOS в хостовой системе попробовать можно, если что-нибудь необычное отправить в сокет или на шину.
Вот заменить какие-то данные в чеке пока он находится в памяти железки общающейся с картой локально её скомпрометировав — не исключаю, такое вполне возможно, особенно зная как многие производители спешат выводить устройства на рынок, не особо оглядывая на безопасность, но для таких случаев также существует сертификация и для чипов карт, и для железок которые с ними работают. Компания производитель обязана предоставить доказательства что после разработки устройства не менее X человекочасов и Y денег было потрачено на исследование безопасности нового устройства.
Не берусь утверждать на 100%, но мне кажется что большинство упомянутых атак — возможны только гипотетически, а пример из видео в статье — вероятно как раз случай когда все звёзды сошлись. Это касса на андроиде, к которым, по крайней мере раньше, в качестве исключения применялись значительные послабления к изоляции компонентов. Т.е. взаимодействие с картой вероятно происходит через системный сервис который крутится прямо на хосте, плюс, по моему опыту, на подобных устройствах почти всегда стоят чипы от mediatek, знаменитые своими уязвимостями и сильно отстающая от актуальной версия андроида. Предполагаю что в этом конкретном случае можно нарушить правильный ход оплаты и модифицировать данные платёжного документа, вызвать DOS на устройстве, или даже воспользоваться какой-нибудь старой известной уязвимостью для локального повышения привилегий, но этот случай точно не показатель
У меня есть большая мечта - закрыться от всех в комнате, взять исходники андроида, да впилить в них много всяких разных privacy-ориентированных улучшений, по аналогии с XPrivacy, только работающих без рута и xposed, а сразу из андроид-фреймворка. Добавить реально удобных штук которые для полной безопасности необходимо впиливать на уровне исходников, вроде microG. Ещё впилить в качестве системных приложений удобные инструменты типа afwall, только перепиленные для работы без рута, запись звонков нормальную, блокировку СМС спама по регулярным выражениям, альтернативное системное вебвью от bromite, поддержку закрытия загрузчика там где это возможно и системную службу поднимающую тревогу в случае несанкционированного изменения read-only разделов, как раз для тех самых случаев физического доступа к устройствам с разблокированным загрузчиком, ну и обои нескучные тоже можно.
Проблема в том что всё это занимает огромное количество времени. Запилил что-то, а оно падает на ксяоми - ищи похожее устройство и трать тонну времени чтобы разобраться, нужно что-то нормально отладить в системном приложении - готовься тратить многие часы на пересборку и перепроверку. Вышла новая мажорная версия - сиди адаптируй свои изменения под неё, потому что с некоторой вероятностью что-то где-то поменялось и твой кусок системы больше не работает, и т.д.
Честно говоря, я готов заниматься этим в своё свободное время, потому что ловлю с этого кайф, но у меня есть работа и семья и они выжимают 90% свободного времени, в оставшиеся 10% не так просто найти силы для полноценной сложной работы, хочется посвятить некоторое время отдыху, а для поддержки продукта нужна предсказуемость, энтузиазма недостаточно. Нужно чтобы кто-то мог, не тогда когда захочет, а тогда когда это необходимо решать срочные проблемы, заниматься билдами, подливать актуальные изменения в код и т.д. Заниматься этим фултайм значит полагаться вместо зарплаты на пожертвования, а с этим всё далеко не так радужно как хотелось бы.
Обычно большинство таких проектов держится на энтузиазме ключевых людей из сообщества. Даже очень значимые FOSS проекты, всемирно значимые, собирают очень скромные суммы. Если посмотреть статистику по пожертвованиям подобным проектам, там где это возможно, то просто руки опускаются. Я как-то для интереса посмотрел сколько пожертвований собирает проект FDroid, и там было что-то около 800 евро в месяц. Вроде бы звучит и неплохо, но во-первых, им необходимо одновременно поддерживать сервера с которых качаются приложения, сборку всех приложений на них же, мобильное приложение и системное расширение для автоматической установки пакетов. Людей, которые этим занимаются явно больше одного, и, насколько я знаю, это ребята из Европы. Если пересчитать все траты, то получается они делают это исключительно из личных убеждений, тратя на это своё личное время вне работы.
Наверное поток пожертвований на финансирование подобных проектов и соответственно интерес в участии в их разработке был бы шире если бы кастомы имели возможность набирать популярность не только среди технически подкованных людей, но и среди рядовых пользователей. Тут ситуация до боли напоминает историю с продвижением Linux на десктопы. Отчасти, как и с Linux, проблему могли бы решить устройства которые бы сразу продавались прошитыми на условный LineageOS. Но рядовому пользователю сложно объяснить почему он отдал кровно заработанные деньги за телефон где нет его любимых игрушек и не работают платежи, а технарь не будет доверять тому что прошито не его руками.
Я с огромным уважением отошусь к тем кто несмотря ни на что продолжает пилить кастомы и делает это очень хорошо. Как команда LineageOS, которые довольно быстро адаптируются к постоянным неслабым изменениям в выходящих каждый год новых мажорных версиях андроида. Как тот же автор GrapheneOS, изменения которого даже иногда подтягиваются в основной код AOSP - человек феномен, который тащит проект самой безопасной кастомной прошивки буквально сам, один, умудряясь параллельно неплохо зарабатывать на жизнь через bugbounty программы различных компаний. Но его история - исключение, и истории многих FOSS проектов - тоже. Хотелось бы чтобы у людей был интерес заниматься этим без надрыва и превозмогания, чтобы вклад в развитие этих проектов не был жертвой, иначе о какой реальной альтернативе мы сможем говорить?
И заодно сильно упрощает жизнь вредоносному коду. Представляю как обрадуются авторы троянов дропперов, которым раньше для такого приходилось ломать систему и подделывать системный пермишен на установку пакетов
Можно. У меня именно так и сделано. На OpenWrt роутере стоит dnsmasq и локальный DoH (https-dns-proxy) с единственным исключением для домена провайдера (иначе в личный кабинет не зайти), остальные запросы доменов отправляются на прокси. Весь остальной трафик на 53 порт также заворачивается через iptables в прокси, на всякий случай.
Настроить не долго, а всё таки автоматический сбор информации со стороны провайдера становится сложнее. Да, при более замороченном анализе можно более менее точно восстановить историю посещения, но тут уже необходимо лишние запросы делать, а для обхода блокировок по DNS у моего провайдера этого хватает.
Раньше у меня ещё и ESNI в firefox работал исправно при обращениям к cloudflare, на котором хостится большая часть того что у нас считается запрещённым, и я вообще забыл про то что у нас в стране есть какая-то цензура и блокировки. Потом почему-то ESNI работать перестал, может разработчики из мозиллы его выключили, или поменялось что-то?
Он до этого вообще работал в Apple и разработка magisk шла бодро как никогда. Не думаю что он возьмёт и бросит проект. По поводу magiskhide он ещё давно писал что не видит смысла продолжать развитие этой фичи после того как станет широко распространена аттестация с использованием аппаратного кейстора и переход в Google тут ни при чём.
Впрочем о реальном положении вещей мы можем только догадываться.
Rust не пытается заменить kotlin. Kotlin — язык для написания кода для JVM в которой крутятся пользовательские приложения, т.е. для разработчиков приложений под андроид. Rust нужен в нативной части системы которую 99% разработчиков не трогают — специфических для андроида кусков ядра и системных сервисов, т.е. для разработчиков системы андроид. Сейчас это всё написано на С/С++ что иногда приводит к серьёзным уязвимостям, а rust позволит писать намного более безопасный код с меньшими усилиями.
Ну ещё можно на нём нативный код внутри приложений готовить. Это кстати вполне возможно уже некоторое время, кое-кто даже так делает, нужно только правильно соблюсти соглашения по сигнатурам с JNI чтобы скомпилированный код мог вызываться из JVM. Однако я считаю, что в этом нет особой необходимости, т.к. код обычных приложений исполняется внутри процесса который не может сильно навредить системе, плюс нейтив в андроиде чаще всего используется для удобного переиспользования кодовой базы на C/C++ внутри приложения.
Вот внутри системы это действительно очень важно, особенно в тех частях которые можно подёргать из обычных приложений, таких как binder. В них чаще всего и находят опасные уязвимости которые можно раскрутить в эксплоиты дающие локальное повышение привилегий. Теоретически, rust должен сделать этот код намного безопаснее
Полагаю что это так и работает. База резюме автоматически сканируется по ключевым словам, а потом им рассылается автоспам. Резюме содержащее подстроку «не пишу на Java» автоматически попадает в спам лист по Java-вакансиям.
То что эйчары не читают резюме — не новость. Однажды я общался с эйчаром из компании N, в которой я уже работал ранее. Я подробно написал о своём опыте в разработке и в конкретно касающейся вакансии предметной области, о том с чем из неё работал в других компаниях и особенно подробно о том что уже работал в N несколько лет назад, в такой-то команде, над таким-то проектом, на такой-то должности. В сопроводительном письме тоже сделал акцент на это. В результате во время созвона для неё это было открытием. Естественно ни резюме, ни сопроводительное письмо она даже не смотрела, просто отрабатывала список кандидатов по инструкции. Поэтому лично я никогда не ожидаю от эйчаров то что они будут работать «с человеческим лицом», просто отношусь к ним как к необходимому злу и стараюсь говорить им то что они хотят услышать по своему скрипту, чтобы пройти их и попасть на разговор уже с техническим представителем.
Лично эйчаров особо не осуждаю. У них по своему тяжёлая работа. Решение прочёсывать рынок подобным образом принимает компания а не эйчар. А компания зачастую вынуждена делать это потому что в противном случае всех кандидатов вычешут конкуренты. Замкнутый круг
Среди моих знакомых к счастью никто эмодзями не общается.
У меня вообще есть стойкая ассоциация между эмодзи и рекламой. Почти всегда во время листания ленты в соцсетях сообщения с обилием эмодзи оказываются спамом, рекламой, саморекламой и попыткой продать что-либо. Видимо именно потому что продающему важно надавить на чувства а не донести информацию до разума.
Спасибо за статью. Судя по затягиванию гаек во всём что касается свободы общения по всему миру, протокол matrix — платформа будущего. Я сам пользуюсь synapse, поднял себе около полугода назад для общения с семьёй и близкими.
Кстати, почему бы не воспользоваться решениями вроде этого? Там даже с настройкой париться не нужно, всё (и matrix сервер, и nginx с автообновлением сертификатов, и TURN сервер для звонков, и приложение веб клиента, и jitsi, если хочется) разворачивается в докер контейнерах натурально одной командой через ansible
Дана строка (возможно, пустая), состоящая из букв A-Z: AAAABBBCCXYZDDDDEEEFFFAAAAAABBBBBBBBBBBBBBBBBBBBBBBBBBBB
Нужно написать функцию RLE, которая на выходе даст строку вида: A4B3C2XYZD4E3F3A6B28
О, по моему скромному опыту, это одна из самых любимых задач у всех собеседующих. Не раз задавали на собеседованиях в самых разных компаниях. Возможно это как то связано с тем что она всегда выпадает в топе выдачи по запросам вроде «какую задачу дать программисту на собеседовании»
Как-то у меня был опыт попытки трудоустройства в одну известную российскую контору. Я не получил оффер по результатам собеседования, зато мне дали очень хороший и подробный фидбэк. Если я правильно понял, то у них есть регламент и таблица с примерным планом собеседования по темам, а прямо в процессе общения с кандидатом технический специалист отмечает в этом плане плюсики или минусы с кратким в 1-2 слова пояснением. В итоге фидбэк мне дали очень быстро и очень подробно. Впечатление от общения осталось максимально приятное, а отношение к компании — очень положительное.
Так что если процессы в компании минимально продуманы и налажены, то и фидбэк давать становится не затратно по времени, и репутация будет на высоте.
О, интересно. Насколько я понимаю в рамках андроида off-host означает что данные от NFC чипа будут напрямую прокидываться в UICC, которым, насколько я понимаю, может быть как SIM-карта, так и SecureElement. Но сам я таким не пользовался. Мне кажется, это довольно экзотичный случай.
Ещё, насколько я понимаю, по похожей схеме у NXP работают аппаратные SAM-модули для современных карт mifare. Чип делегирует им передачу данных от карты, а они занимаются расчётом криптографии необходимой для получения криптограмм в challenge-response схеме аутентификации секторов на чтение/запись. Таким образом данные о ключах спасаются от нахождения в памяти хост-системы к которой подключён кард-ридер
Кстати, если не ошибаюсь, андроид такое уже давненько поддерживает. Это называется off-host-NFC
Плюсую. Вообще вроде как по идеологии NFC ответ должен быть всегда очень быстрым, но при этом современные реалии существенно скорректировали это, т.к. 13.56МГц картам, в чипе которых например крутятся апплеты, считающие тот же RSA, очевидно необходимо большее время для ответа чем LF-карточке передающей только свой ID. Насколько я понимаю, время таймаутов на получение ответа настраивается на уровне драйверов и в общем PC/SC драйвере на винде например по умолчанию составляет 5 секунд.
Я для интереса эмулировал ISO-7816 NDEF тэг на андроиде через HCE сервис. А HCE сервис в андроиде так устроен что сначала система получает ISO SELECT APDU (00 A4 04 ... ), парсит из него значение AID (идентификатора апплета с которым необходимо начать работу), затем по этому AID система смотрит есть ли среди манифестов приложений объявленые HCE-сервисы которые умеют эмулировать апплет с таким ID и если есть, то стартует этот сервис и передаёт ему управление. Это занимает время, плюс на старте сервиса у меня инициализировалось создание объектов, вычитывание данных из песочницы и т.д. что тоже занимает время, и по факту ответ на первую APDU приходил с ооооочень большой для NFC задержкой (очень много миллисекунд), но ничего - ни один ридер не подавился. Так что не исключено, что и relay-атаки вполне осуществимы
Спасибо за интерес к статье! Про механику шифрования раздела с данными и "default_password" - хорошее замечание, я не раскрыл этот момент в статье, потому что с точки зрения извлечения данных в сценарии когда у атакующего есть физический доступ это имеет значение только на телефоне без установленной блокировки экрана, а без установленной блокировки экрана злоумышленник и так сможет посмотреть всё что захочет.
На FDroid долгое время существовал аналогичный форк «Maps», но человек который его делал забросил поддержку после того как в maps.me стали вносить слишком много изменений, включая кажется переход на какой-то свой формат карт вместо стандартного. Наверное этому были адекватные объяснения, но выглядело это как желание выжать форки с рынка.
К тому же, когда вы форкаете maps.me, то по правилам лицензии, да и исходя из здравого смысла, обязаны отказаться от оригинального бэкенда maps.me и перебросить приложение на свой, а его необходимо поддерживать, так что ребята проделали очень серьёзную работу. Огромный респект!
Стандарт PCI-DSS _обязывает_ производителей банкоматов и другого подобного оборудования разносить все отдельные части общей системы которые могут подвергнуться риску компрометации в отдельные модули. Например код отвечающий за проведение EMV транзакции и взаимодействие с чипом карты (NFC или контактная площадка, не важно) обязан быть вынесен в другое пространство и не выполняться на самом хосте. Это значит что и кардридер, и кассетник для работы с наличными, и ККТ с фискальником, и многие другие части не будут частью основной машины, а будут отдельными устройствами подвешенными на PCI или USB шину. Для работы с картами например в 99% случаев будет использоваться отдельное устройство, причём вся логика работы с картами будет _уже_ зашита в нём и все данные касающиеся этого никогда не будут передаваться между читалкой и хостом. На деле это означает что с компьютера внутри банкомата будут посылаться не команды «отправь карте массив байт 00A40000AABBCCDDEE00» или «прочитай массив байт из буфера куда записался ответ от карты», а «вот сформированный документ, подпиши приватным ключом и верни цифровую подпись». Т.е. позаигрывать с буферами особо не получится. В редких исключениях, в ситуациях когда подобное сильно затруднено, например в кассовых устройствах на базе android, вся эта логика будет крутиться как минимум в отдельном отгороженном со всех сторон процессе, хотя возможно и это уже запретили.
Поэтому даже скомпрометировав железку проводящую NFC взаимодействие с картой с вероятностью в 99,9% ничего дальше провернуть не получится, хотя наверняка устроить DOS в хостовой системе попробовать можно, если что-нибудь необычное отправить в сокет или на шину.
Вот заменить какие-то данные в чеке пока он находится в памяти железки общающейся с картой локально её скомпрометировав — не исключаю, такое вполне возможно, особенно зная как многие производители спешат выводить устройства на рынок, не особо оглядывая на безопасность, но для таких случаев также существует сертификация и для чипов карт, и для железок которые с ними работают. Компания производитель обязана предоставить доказательства что после разработки устройства не менее X человекочасов и Y денег было потрачено на исследование безопасности нового устройства.
Не берусь утверждать на 100%, но мне кажется что большинство упомянутых атак — возможны только гипотетически, а пример из видео в статье — вероятно как раз случай когда все звёзды сошлись. Это касса на андроиде, к которым, по крайней мере раньше, в качестве исключения применялись значительные послабления к изоляции компонентов. Т.е. взаимодействие с картой вероятно происходит через системный сервис который крутится прямо на хосте, плюс, по моему опыту, на подобных устройствах почти всегда стоят чипы от mediatek, знаменитые своими уязвимостями и сильно отстающая от актуальной версия андроида. Предполагаю что в этом конкретном случае можно нарушить правильный ход оплаты и модифицировать данные платёжного документа, вызвать DOS на устройстве, или даже воспользоваться какой-нибудь старой известной уязвимостью для локального повышения привилегий, но этот случай точно не показатель
Ох, непростую тему затронули.
У меня есть большая мечта - закрыться от всех в комнате, взять исходники андроида, да впилить в них много всяких разных privacy-ориентированных улучшений, по аналогии с XPrivacy, только работающих без рута и xposed, а сразу из андроид-фреймворка. Добавить реально удобных штук которые для полной безопасности необходимо впиливать на уровне исходников, вроде microG. Ещё впилить в качестве системных приложений удобные инструменты типа afwall, только перепиленные для работы без рута, запись звонков нормальную, блокировку СМС спама по регулярным выражениям, альтернативное системное вебвью от bromite, поддержку закрытия загрузчика там где это возможно и системную службу поднимающую тревогу в случае несанкционированного изменения read-only разделов, как раз для тех самых случаев физического доступа к устройствам с разблокированным загрузчиком, ну и обои нескучные тоже можно.
Проблема в том что всё это занимает огромное количество времени. Запилил что-то, а оно падает на ксяоми - ищи похожее устройство и трать тонну времени чтобы разобраться, нужно что-то нормально отладить в системном приложении - готовься тратить многие часы на пересборку и перепроверку. Вышла новая мажорная версия - сиди адаптируй свои изменения под неё, потому что с некоторой вероятностью что-то где-то поменялось и твой кусок системы больше не работает, и т.д.
Честно говоря, я готов заниматься этим в своё свободное время, потому что ловлю с этого кайф, но у меня есть работа и семья и они выжимают 90% свободного времени, в оставшиеся 10% не так просто найти силы для полноценной сложной работы, хочется посвятить некоторое время отдыху, а для поддержки продукта нужна предсказуемость, энтузиазма недостаточно. Нужно чтобы кто-то мог, не тогда когда захочет, а тогда когда это необходимо решать срочные проблемы, заниматься билдами, подливать актуальные изменения в код и т.д. Заниматься этим фултайм значит полагаться вместо зарплаты на пожертвования, а с этим всё далеко не так радужно как хотелось бы.
Обычно большинство таких проектов держится на энтузиазме ключевых людей из сообщества. Даже очень значимые FOSS проекты, всемирно значимые, собирают очень скромные суммы. Если посмотреть статистику по пожертвованиям подобным проектам, там где это возможно, то просто руки опускаются. Я как-то для интереса посмотрел сколько пожертвований собирает проект FDroid, и там было что-то около 800 евро в месяц. Вроде бы звучит и неплохо, но во-первых, им необходимо одновременно поддерживать сервера с которых качаются приложения, сборку всех приложений на них же, мобильное приложение и системное расширение для автоматической установки пакетов. Людей, которые этим занимаются явно больше одного, и, насколько я знаю, это ребята из Европы. Если пересчитать все траты, то получается они делают это исключительно из личных убеждений, тратя на это своё личное время вне работы.
Наверное поток пожертвований на финансирование подобных проектов и соответственно интерес в участии в их разработке был бы шире если бы кастомы имели возможность набирать популярность не только среди технически подкованных людей, но и среди рядовых пользователей. Тут ситуация до боли напоминает историю с продвижением Linux на десктопы. Отчасти, как и с Linux, проблему могли бы решить устройства которые бы сразу продавались прошитыми на условный LineageOS. Но рядовому пользователю сложно объяснить почему он отдал кровно заработанные деньги за телефон где нет его любимых игрушек и не работают платежи, а технарь не будет доверять тому что прошито не его руками.
Я с огромным уважением отошусь к тем кто несмотря ни на что продолжает пилить кастомы и делает это очень хорошо. Как команда LineageOS, которые довольно быстро адаптируются к постоянным неслабым изменениям в выходящих каждый год новых мажорных версиях андроида. Как тот же автор GrapheneOS, изменения которого даже иногда подтягиваются в основной код AOSP - человек феномен, который тащит проект самой безопасной кастомной прошивки буквально сам, один, умудряясь параллельно неплохо зарабатывать на жизнь через bugbounty программы различных компаний. Но его история - исключение, и истории многих FOSS проектов - тоже. Хотелось бы чтобы у людей был интерес заниматься этим без надрыва и превозмогания, чтобы вклад в развитие этих проектов не был жертвой, иначе о какой реальной альтернативе мы сможем говорить?
Хорошая статья, спасибо.
И заодно сильно упрощает жизнь вредоносному коду. Представляю как обрадуются авторы троянов дропперов, которым раньше для такого приходилось ломать систему и подделывать системный пермишен на установку пакетов
Можно. У меня именно так и сделано. На OpenWrt роутере стоит dnsmasq и локальный DoH (https-dns-proxy) с единственным исключением для домена провайдера (иначе в личный кабинет не зайти), остальные запросы доменов отправляются на прокси. Весь остальной трафик на 53 порт также заворачивается через iptables в прокси, на всякий случай.
Настроить не долго, а всё таки автоматический сбор информации со стороны провайдера становится сложнее. Да, при более замороченном анализе можно более менее точно восстановить историю посещения, но тут уже необходимо лишние запросы делать, а для обхода блокировок по DNS у моего провайдера этого хватает.
Раньше у меня ещё и ESNI в firefox работал исправно при обращениям к cloudflare, на котором хостится большая часть того что у нас считается запрещённым, и я вообще забыл про то что у нас в стране есть какая-то цензура и блокировки. Потом почему-то ESNI работать перестал, может разработчики из мозиллы его выключили, или поменялось что-то?
Он до этого вообще работал в Apple и разработка magisk шла бодро как никогда. Не думаю что он возьмёт и бросит проект. По поводу magiskhide он ещё давно писал что не видит смысла продолжать развитие этой фичи после того как станет широко распространена аттестация с использованием аппаратного кейстора и переход в Google тут ни при чём.
Впрочем о реальном положении вещей мы можем только догадываться.
Ну ещё можно на нём нативный код внутри приложений готовить. Это кстати вполне возможно уже некоторое время, кое-кто даже так делает, нужно только правильно соблюсти соглашения по сигнатурам с JNI чтобы скомпилированный код мог вызываться из JVM. Однако я считаю, что в этом нет особой необходимости, т.к. код обычных приложений исполняется внутри процесса который не может сильно навредить системе, плюс нейтив в андроиде чаще всего используется для удобного переиспользования кодовой базы на C/C++ внутри приложения.
Вот внутри системы это действительно очень важно, особенно в тех частях которые можно подёргать из обычных приложений, таких как binder. В них чаще всего и находят опасные уязвимости которые можно раскрутить в эксплоиты дающие локальное повышение привилегий. Теоретически, rust должен сделать этот код намного безопаснее
То что эйчары не читают резюме — не новость. Однажды я общался с эйчаром из компании N, в которой я уже работал ранее. Я подробно написал о своём опыте в разработке и в конкретно касающейся вакансии предметной области, о том с чем из неё работал в других компаниях и особенно подробно о том что уже работал в N несколько лет назад, в такой-то команде, над таким-то проектом, на такой-то должности. В сопроводительном письме тоже сделал акцент на это. В результате во время созвона для неё это было открытием. Естественно ни резюме, ни сопроводительное письмо она даже не смотрела, просто отрабатывала список кандидатов по инструкции. Поэтому лично я никогда не ожидаю от эйчаров то что они будут работать «с человеческим лицом», просто отношусь к ним как к необходимому злу и стараюсь говорить им то что они хотят услышать по своему скрипту, чтобы пройти их и попасть на разговор уже с техническим представителем.
Лично эйчаров особо не осуждаю. У них по своему тяжёлая работа. Решение прочёсывать рынок подобным образом принимает компания а не эйчар. А компания зачастую вынуждена делать это потому что в противном случае всех кандидатов вычешут конкуренты. Замкнутый круг
У меня вообще есть стойкая ассоциация между эмодзи и рекламой. Почти всегда во время листания ленты в соцсетях сообщения с обилием эмодзи оказываются спамом, рекламой, саморекламой и попыткой продать что-либо. Видимо именно потому что продающему важно надавить на чувства а не донести информацию до разума.
Кстати, почему бы не воспользоваться решениями вроде этого? Там даже с настройкой париться не нужно, всё (и matrix сервер, и nginx с автообновлением сертификатов, и TURN сервер для звонков, и приложение веб клиента, и jitsi, если хочется) разворачивается в докер контейнерах натурально одной командой через ansible
О, по моему скромному опыту, это одна из самых любимых задач у всех собеседующих. Не раз задавали на собеседованиях в самых разных компаниях. Возможно это как то связано с тем что она всегда выпадает в топе выдачи по запросам вроде «какую задачу дать программисту на собеседовании»
Так что если процессы в компании минимально продуманы и налажены, то и фидбэк давать становится не затратно по времени, и репутация будет на высоте.