документированные privacy-фичи есть у Telegram (secret chats), Signal (disappearing messages), WhatsApp (chat lock + Vacation Mode), KeePass и других
Privacy фичи это не тоже самое что “двойное дно”. Секретные чаты и исчезающие сообщения не прячутся так, что их появление неявно зависит от вводимого ключа. В каких-то случаях да, надо вводить дополнительные ключи, но этот факт вполне виден даже на быстром досмотре.
«Отправят на детальный досмотр» теоретически да, а вот «вскроют двойное дно без real PIN» нет, это всё равно упирается в crypto
Вы же сами писали, что не боретесь со специальными лабораториями для анализа, а тут получается, что вы увеличиваете шансы оказаться именно там. Просто “двойное дно” - это палка о двух концах, там не только плюшки есть, там и минусов хватает.
Если есть конкретные идеи как сделать иначе и не получить узнаваемую синтетику, буду рад вас выслушать.
Если с локальным ИИ связываться сложно, то я бы заранее с сервера тащил фейковые переписки (а там их обновлял бы постоянно, там мощности побольше), а в момент открытия второго дна, переписка слегка отматывается и даты проставляются от текущей назад, чтобы была иллюзия что переписка недавняя, а чтобы усилить иллюзию то самое отмотанное назад сообщение прямо “печатается” и “приходит” в момент работы с этим режимом (разумеется если подключение есть, чтобы уж прямо сразу не спалиться). Ну и там нюансы есть про повторное использование этой переписки, но это отдельный разговор. Насчет контактов, можно гибрид сделать из фековых и реальных, тут надо еще подумать. Вобщем, это тоже конечно стремный вариант, но зато дешево по меркам приложения.
Threat model тут «пятиминутный досмотр на границе»
Проблема в другом: если досматривающий знает о том, что в приложении доступно второе дно (он может ничего не знать о его устройстве - достаточно просто факта), то быстрый досмотр просто сводится к тому, что если есть подозрительное приложениие - отправить на более детальный досмотр чтобы вскрыть двойное дно. Всякие threema/signal/и т.д. не имеют документированного второго дна, поэтому они не причем - их будут досматривать по-другому.
в iOS пятикратное нажатие
Ну это в iOS, а что делать в Android? Или там биометрии не предполагается?
Decoy обновляет владелец, сам
Это очень грустно, потому что 99% людей забудут про необходимость обновлений и выглядеть это будет топорно. В наше время ИИ мог бы генерировать фейковые переписки например, а без автоматизации и только в ручном режиме - эта фича сомнительная.
Вся схема выглядит немного странной и может помочь только если очень повезет и вы тот самый “неуловимый Джо”.
Первое замечание - если пользователи знают и скрытых возможностях, их будут знать и досматривающие, и поэтому “пара контактов, несколько сообщений” - не прокатит. Если вы открываете ящик Пандоры и сообщаете о двойном дне, то его будут искать даже если вы его не используете. Это может подставить обычных пользователей, которые ничего не прячут и не используют этот функционал. Хотя у вас весь месенджер сделан с упором на анонимность, так что тут само его наличие на телефоне уже может быть триггером.
Второе, если вы предусматриваете вход по биометрии для “реальных” данных, то именно его и будут использовать и форсировать при досмотре, и тогда все ваши ухищрения с пинами становятся вообще бессмысленны.
Третье, “правдоподобно освоенный: пара контактов, несколько сообщений” - а кто будет обновлять эти данные чтобы они выглядели правдоподобно в любой момент времени?
“«Удалить аккаунт по PIN» лучше, но видно что что-то стёрто”, а чем это отличается от вашего wipe pin? Если вы уже сразу видите недостатки, зачем повторяете решение в своем продукте?
Конструкция прикольная, но что если битовый поток начинается с двух нолей? Еще к недостаткам я бы отнес использование непредсказуемого числа раз popcount при кодировании, тем более что не везде эта операция аппаратно ускорена. И невозможность заранее быстро оценить сколько займет закодированное значение, это тоже бывает важно при расчете “стоимости” хранения, когда есть выбор как кодировать.
p.s. например есть же всякие дельта коды, которые по сути гамма, у которых экспонента тоже закодирована гамма кодом - вполне себе похожие конструкции получаются.
Линкер и так выбрасывает неиспользуемое. Просто например, поддержка исключений - она либо есть везде, либо ее нет нигде, поэтому чтобы выбросить всю поддержку надо пересобрать значительную часть runtime библиотеки, вот и получается “еще один вариант”. Ну и так со многими вещами. И даже если вы нигде не используете какую-то возможность языка, это не значит что ее не использовали авторы библиотеки и таким образом она и попадает в код исполняемого файла, к тому же всегда можно попросить линкер объяснить зачем он потащил какой-то объект в код.
В итоге для всех упомянутых версий 15.2.0, 13.1.0, 10.3.0, 4.9.2 получаем стабильные 3,50 КБ (3 584 байт)
Если достаточно поиграться опциями и отключить исключения например, то у меня тот же файл выдает уже 2560 байт именно на g++. Чтобы сделать меньше надо сливать секции уже, что в случае gnu ld не так тривиально как для msvc link: надо аккуратно править скрипты линкера.
Вы можете спросить, ну а зачем компилятор сует обработку исключений в код, если из кода очевидно, что никаких исключений не предвидется? Ответ прост: специально никто ничего не сует, просто вариант runtime библиотеки один - и он на все, даже самые тяжелые, случаи. Потому что иначе пришлось бы иметь два варианта библиотек - для исключений и без них. И два варианта кажутся ерундой, но потом кто-то скажет, а мне не нужно utf8, а кому-то rtti, а кому-то потоки не нужны, а кому-то еще не нужна поддержка новых фич процессоров ну и т.д. и число вариантов билиотек устремляется к тысячам, а это банально никто не сможет поддерживать. Так что придется смириться с тем, что runtime библиотека обычно есть в паре-тройке вариантов покрывающих 97% всех программ и да, размер этой библиотеки обычно приличный, ну а для оставшихся экзотических вариантов придется выкручиваться самостоятельно.
Вообще оценивать размер исполняемого файла по очень простой программе - странно и не очень правильно. Для простых программ, где по какой-то причине важен размер, годятся все вышеуказанные ухищрения вплоть до переписывания на асемблере, потому что программа простая и это сработает. Но программы бывают и сложные. И вот интересно было бы сравнить качество кодогенерации, там где это действительно важно - во всяких узких местах, циклах, при операциях которые можно параллелить и т.д. И размер кода там конечно имеет значение, потому что раздутый код не лезет в кэши и нарушает локальность. По своему опыту могу сказать, что качество кодогенерации в целом растет, но библиотеки очевидно растут в размере на порядки быстрее. Современные runtime библиотеки, например, поддерживают какой-нибудь utf8, который добавляет довольно много кода, но если вам это не нужно - в сети есть варианты и без этого, ну или как решение можно собрать программу более старым компилятором со старой версией.
Идея выглядит прикольно, но почему бы не пойти дальше и полностью перейти на клиент-серверную архитектуру? Т.е. изначально разделить продукт на части: 1. клиент - интерфейс оболочка для взаимодействия с пользователем (GUI/TUI, поддeржка всяких расширений терминалов, X11/wayland и т.д.), 2. основная серверная часть-планировщик, которая рулит всеми асинхронными параллельными операциями и взаимодействует с клиентом(ами), включая возможность делать это по сети, и с плагинами/скриптами, если надо работает с повышенными правами, 3. выносная микросерверная часть для сценариев embedded/slow link/etc. т.е. без планировщика и поддержки плагинов, но тоже с возможностью взаимодействия по сети с основным сервисом по ssh/telnet/serial port (эта часть опциональна).
Телефоны, в которых все разблокировано и соответственно можно легко вырезать и добавить (пропатчить) системный софт можно пересчитать по пальцам. Увы, но тенденция такова, что “открытых” моделей становится все меньше и меньше с каждым годом. И даже те модели, которые ранее можно было разблокировать, спустя некоторое время, когда они теряют актуальность, становится нельзя, хотя казалось бы по логике должно быть наоборот (отдельное фи например “риалми” и подобным лавочкам). А без разблокировки большая часть манипуляций очень сложна или невозможна.
«USB-флешки теряют данные так же, как SSD» — и да, и нет.
Так получается, что флешки - это вообще ужас-ужас? Ведь умного контроллера там нет, значит они теряют данные постепенно даже если ими пользуются. Износ флешки тоже понять сложно, там зачастую никаких smart'ов нет. Ну и долго хранить на них точно ничего нельзя, ведь подключение к компу все равно ничего не исправит. Правильно?
Насколько это надежно работает с SSD/Flash? Там ведь просто запись чего попало не гарантирует, что все сектора будут реально затронуты, потому что есть резервы. Есть ли какие-нибудь исследования?
Сначала ввели подписывание прошивок и их компонентов только своими секретными ключами, исключив возможность собрать или модифицировать большую часть компонентов (я не против подписей, я против невозможности использовать свои). Потом свели почти на нет возможность разблокировки и сответственно даже установки каких-либо сторонних прошивок. Теперь сведут почти на нет возможности установки стороннего софта. Со стороны гугла и крупных вендоров это выглядит как логичный шаг по закрытию платформы, этим путем они постепенно идут уже много лет.
p.s. huawei увы играет в те же игры, разблокировки там изначально нет например, так что их система по сути ничем не отличается, просто они еще не догнали гугл.
Если вам нравится сама идея своей ОС, позвольте дать совет. Забудьте на время про загрузчики, bios, драйвера и даже про видеокарту. Это огромный объем работ, который практически невозможно полноценно сделать одному. Может когда-нибудь ИИ поможет, но пока и от него толку мало в этой части. Драйвер для nvidia под вашу ОС он вам не напишет, хотя загрузчик может и сможет написать. Начните с базовых вещей. Что делает практически любая неспециализированная ОС? Распределяет и управляет ресурсами: памятью, вычислительными мощностями, временем, привилегиями (доступом), энергопотреблением и т. д. Плюс имеет некую структуру для хранения и управления всем хозяйством, например через файлы (тогда это файловая система), или через что-то другое. И вот эти базовые вещи можно спокойно писать на любом выбранном языке, практически под любую неспециализированную архитектуру и отлаживать эти алгоритмы прямо как обычные программы. Я имею ввиду: систему управлением памятью, планировщик задач, файловую систему, систему прав и доступа, межпроцессное взаимодействие, синхронизация, систему управления временем и прочее. Это само по себе довольно интересно, здесь до сих пор делаются многие улучшения, которые потом идут в реальные ОС, и отлаживать это не так сложно, как драйвера под редкие железки.
Так а почему именно C++ да еще без макросов? Про это ни слова, особенно в контексте именно ОС, а не обычных программ. В статье написано какими плюшками языка можно пользоваться, но почему выбран именно C++ например?
Архитектурные решения и почему они важны
Это же не архитектурные решения, а просто технические моменты. А вот про архитектуру ОС у вас почти ни слова, кроме абстрактной фразы про "будет писать монолитное ядро с HAL". Хотелось бы подробностей. Почему монолитное ядро, например?
мы своими руками разберёмся в основах, поймём, как устроены операционные системы изнутри
ОС это ведь не столько работа с "железом" (которое очень разнообразно и его стараются отделить в подсистему условных драйверов), сколько точный менеджмент ресурсов: процессоров, памяти, времени, привилегий и т.д. Вот с этого стоило бы начать на мой взгялд, и главное эти алгоритмы гораздо проще тестировать в обычной среде и не надо возиться с загрузчиками и QEMU.
А если ssd подключен, но смонтирован как read-only в течении многих лет, данные на нем деградируют или контроллер сам сектора переписывает периодически тратя ресурс?
Privacy фичи это не тоже самое что “двойное дно”. Секретные чаты и исчезающие сообщения не прячутся так, что их появление неявно зависит от вводимого ключа. В каких-то случаях да, надо вводить дополнительные ключи, но этот факт вполне виден даже на быстром досмотре.
Вы же сами писали, что не боретесь со специальными лабораториями для анализа, а тут получается, что вы увеличиваете шансы оказаться именно там. Просто “двойное дно” - это палка о двух концах, там не только плюшки есть, там и минусов хватает.
Если с локальным ИИ связываться сложно, то я бы заранее с сервера тащил фейковые переписки (а там их обновлял бы постоянно, там мощности побольше), а в момент открытия второго дна, переписка слегка отматывается и даты проставляются от текущей назад, чтобы была иллюзия что переписка недавняя, а чтобы усилить иллюзию то самое отмотанное назад сообщение прямо “печатается” и “приходит” в момент работы с этим режимом (разумеется если подключение есть, чтобы уж прямо сразу не спалиться). Ну и там нюансы есть про повторное использование этой переписки, но это отдельный разговор. Насчет контактов, можно гибрид сделать из фековых и реальных, тут надо еще подумать. Вобщем, это тоже конечно стремный вариант, но зато дешево по меркам приложения.
так вы и различитель режимов хороший сразу сделали для удобства досматривающих?
Проблема в другом: если досматривающий знает о том, что в приложении доступно второе дно (он может ничего не знать о его устройстве - достаточно просто факта), то быстрый досмотр просто сводится к тому, что если есть подозрительное приложениие - отправить на более детальный досмотр чтобы вскрыть двойное дно. Всякие threema/signal/и т.д. не имеют документированного второго дна, поэтому они не причем - их будут досматривать по-другому.
Ну это в iOS, а что делать в Android? Или там биометрии не предполагается?
Это очень грустно, потому что 99% людей забудут про необходимость обновлений и выглядеть это будет топорно. В наше время ИИ мог бы генерировать фейковые переписки например, а без автоматизации и только в ручном режиме - эта фича сомнительная.
Вся схема выглядит немного странной и может помочь только если очень повезет и вы тот самый “неуловимый Джо”.
Первое замечание - если пользователи знают и скрытых возможностях, их будут знать и досматривающие, и поэтому “пара контактов, несколько сообщений” - не прокатит. Если вы открываете ящик Пандоры и сообщаете о двойном дне, то его будут искать даже если вы его не используете. Это может подставить обычных пользователей, которые ничего не прячут и не используют этот функционал. Хотя у вас весь месенджер сделан с упором на анонимность, так что тут само его наличие на телефоне уже может быть триггером.
Второе, если вы предусматриваете вход по биометрии для “реальных” данных, то именно его и будут использовать и форсировать при досмотре, и тогда все ваши ухищрения с пинами становятся вообще бессмысленны.
Третье, “правдоподобно освоенный: пара контактов, несколько сообщений” - а кто будет обновлять эти данные чтобы они выглядели правдоподобно в любой момент времени?
“«Удалить аккаунт по PIN» лучше, но видно что что-то стёрто”, а чем это отличается от вашего wipe pin? Если вы уже сразу видите недостатки, зачем повторяете решение в своем продукте?
Конструкция прикольная, но что если битовый поток начинается с двух нолей? Еще к недостаткам я бы отнес использование непредсказуемого числа раз popcount при кодировании, тем более что не везде эта операция аппаратно ускорена. И невозможность заранее быстро оценить сколько займет закодированное значение, это тоже бывает важно при расчете “стоимости” хранения, когда есть выбор как кодировать.
p.s. например есть же всякие дельта коды, которые по сути гамма, у которых экспонента тоже закодирована гамма кодом - вполне себе похожие конструкции получаются.
Линкер и так выбрасывает неиспользуемое. Просто например, поддержка исключений - она либо есть везде, либо ее нет нигде, поэтому чтобы выбросить всю поддержку надо пересобрать значительную часть runtime библиотеки, вот и получается “еще один вариант”. Ну и так со многими вещами. И даже если вы нигде не используете какую-то возможность языка, это не значит что ее не использовали авторы библиотеки и таким образом она и попадает в код исполняемого файла, к тому же всегда можно попросить линкер объяснить зачем он потащил какой-то объект в код.
Если достаточно поиграться опциями и отключить исключения например, то у меня тот же файл выдает уже 2560 байт именно на g++. Чтобы сделать меньше надо сливать секции уже, что в случае gnu ld не так тривиально как для msvc link: надо аккуратно править скрипты линкера.
Вы можете спросить, ну а зачем компилятор сует обработку исключений в код, если из кода очевидно, что никаких исключений не предвидется? Ответ прост: специально никто ничего не сует, просто вариант runtime библиотеки один - и он на все, даже самые тяжелые, случаи. Потому что иначе пришлось бы иметь два варианта библиотек - для исключений и без них. И два варианта кажутся ерундой, но потом кто-то скажет, а мне не нужно utf8, а кому-то rtti, а кому-то потоки не нужны, а кому-то еще не нужна поддержка новых фич процессоров ну и т.д. и число вариантов билиотек устремляется к тысячам, а это банально никто не сможет поддерживать. Так что придется смириться с тем, что runtime библиотека обычно есть в паре-тройке вариантов покрывающих 97% всех программ и да, размер этой библиотеки обычно приличный, ну а для оставшихся экзотических вариантов придется выкручиваться самостоятельно.
Вообще оценивать размер исполняемого файла по очень простой программе - странно и не очень правильно. Для простых программ, где по какой-то причине важен размер, годятся все вышеуказанные ухищрения вплоть до переписывания на асемблере, потому что программа простая и это сработает. Но программы бывают и сложные. И вот интересно было бы сравнить качество кодогенерации, там где это действительно важно - во всяких узких местах, циклах, при операциях которые можно параллелить и т.д. И размер кода там конечно имеет значение, потому что раздутый код не лезет в кэши и нарушает локальность. По своему опыту могу сказать, что качество кодогенерации в целом растет, но библиотеки очевидно растут в размере на порядки быстрее. Современные runtime библиотеки, например, поддерживают какой-нибудь utf8, который добавляет довольно много кода, но если вам это не нужно - в сети есть варианты и без этого, ну или как решение можно собрать программу более старым компилятором со старой версией.
Идея выглядит прикольно, но почему бы не пойти дальше и полностью перейти на клиент-серверную архитектуру? Т.е. изначально разделить продукт на части: 1. клиент - интерфейс оболочка для взаимодействия с пользователем (GUI/TUI, поддeржка всяких расширений терминалов, X11/wayland и т.д.), 2. основная серверная часть-планировщик, которая рулит всеми асинхронными параллельными операциями и взаимодействует с клиентом(ами), включая возможность делать это по сети, и с плагинами/скриптами, если надо работает с повышенными правами, 3. выносная микросерверная часть для сценариев embedded/slow link/etc. т.е. без планировщика и поддержки плагинов, но тоже с возможностью взаимодействия по сети с основным сервисом по ssh/telnet/serial port (эта часть опциональна).
Телефоны, в которых все разблокировано и соответственно можно легко вырезать и добавить (пропатчить) системный софт можно пересчитать по пальцам. Увы, но тенденция такова, что “открытых” моделей становится все меньше и меньше с каждым годом. И даже те модели, которые ранее можно было разблокировать, спустя некоторое время, когда они теряют актуальность, становится нельзя, хотя казалось бы по логике должно быть наоборот (отдельное фи например “риалми” и подобным лавочкам). А без разблокировки большая часть манипуляций очень сложна или невозможна.
Так получается, что флешки - это вообще ужас-ужас? Ведь умного контроллера там нет, значит они теряют данные постепенно даже если ими пользуются. Износ флешки тоже понять сложно, там зачастую никаких smart'ов нет. Ну и долго хранить на них точно ничего нельзя, ведь подключение к компу все равно ничего не исправит. Правильно?
Насколько это надежно работает с SSD/Flash? Там ведь просто запись чего попало не гарантирует, что все сектора будут реально затронуты, потому что есть резервы. Есть ли какие-нибудь исследования?
p.s. когда уже такую штуку для телефонов сделают?
Сначала ввели подписывание прошивок и их компонентов только своими секретными ключами, исключив возможность собрать или модифицировать большую часть компонентов (я не против подписей, я против невозможности использовать свои). Потом свели почти на нет возможность разблокировки и сответственно даже установки каких-либо сторонних прошивок. Теперь сведут почти на нет возможности установки стороннего софта. Со стороны гугла и крупных вендоров это выглядит как логичный шаг по закрытию платформы, этим путем они постепенно идут уже много лет.
p.s. huawei увы играет в те же игры, разблокировки там изначально нет например, так что их система по сути ничем не отличается, просто они еще не догнали гугл.
Если вам нравится сама идея своей ОС, позвольте дать совет.
Забудьте на время про загрузчики, bios, драйвера и даже про видеокарту. Это огромный объем работ, который практически невозможно полноценно сделать одному. Может когда-нибудь ИИ поможет, но пока и от него толку мало в этой части. Драйвер для nvidia под вашу ОС он вам не напишет, хотя загрузчик может и сможет написать.
Начните с базовых вещей. Что делает практически любая неспециализированная ОС? Распределяет и управляет ресурсами: памятью, вычислительными мощностями, временем, привилегиями (доступом), энергопотреблением и т. д. Плюс имеет некую структуру для хранения и управления всем хозяйством, например через файлы (тогда это файловая система), или через что-то другое. И вот эти базовые вещи можно спокойно писать на любом выбранном языке, практически под любую неспециализированную архитектуру и отлаживать эти алгоритмы прямо как обычные программы. Я имею ввиду: систему управлением памятью, планировщик задач, файловую систему, систему прав и доступа, межпроцессное взаимодействие, синхронизация, систему управления временем и прочее. Это само по себе довольно интересно, здесь до сих пор делаются многие улучшения, которые потом идут в реальные ОС, и отлаживать это не так сложно, как драйвера под редкие железки.
Теперь к началу холиваров будут привлекать ИИ. Так может пусть уж ИИ весь холивар и сгенерирует? И выжимку из него, как обычно его и просят?
Между операторами давно уже слово на букву О: олигополия.
Телефоны с перебиваемыми имеи слегка подорожают. Хотя бы потому что позволят экономить время и деньги.
Так а почему именно C++ да еще без макросов? Про это ни слова, особенно в контексте именно ОС, а не обычных программ. В статье написано какими плюшками языка можно пользоваться, но почему выбран именно C++ например?
Это же не архитектурные решения, а просто технические моменты. А вот про архитектуру ОС у вас почти ни слова, кроме абстрактной фразы про "будет писать монолитное ядро с HAL". Хотелось бы подробностей. Почему монолитное ядро, например?
ОС это ведь не столько работа с "железом" (которое очень разнообразно и его стараются отделить в подсистему условных драйверов), сколько точный менеджмент ресурсов: процессоров, памяти, времени, привилегий и т.д. Вот с этого стоило бы начать на мой взгялд, и главное эти алгоритмы гораздо проще тестировать в обычной среде и не надо возиться с загрузчиками и QEMU.
А если ssd подключен, но смонтирован как read-only в течении многих лет, данные на нем деградируют или контроллер сам сектора переписывает периодически тратя ресурс?
Ну опять "дефицит низкооплачиваемых высококвалифицированных кадров".