rPman

Может!
Хостер (у которого размещено физическое железо, на котором крутятся твоя ос или виртуальные машины) имеет возможность получить доступ даже если ты зашифровал файловую систему а пароль вводишь подключившись в initramfs по ssh при перезапуске, так как имеет возможность подменить загрузчик со своим трояном, который способен украсть ключи шифрования (это я не говорю про возможность сделать копию оперативной памяти - штатная фишка виртуальных машин и зашифрованного диска, извлечь из дампа ключи шифрования и расшифровать диск).

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

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

p.s. и даже в этом случае нужно будет очень очень сильно доверять производителю оборудования, биоса, прошивок (например прошивки сетевой карты, m2 диска и всего что имеет доступ к pcie) и конечно же самой ос, что там нет закладок (а они там очевидно есть).

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

p.p.s. но маловероятно что подобная атака выполняется хостером для каждого клиента (хотя такой вариант не исключен, ведь инструментарий достаточно написать один раз и поддерживать его для новых версий ядер, а потом массово взламывать все машины, так как получение снапшота диска почти бесплатная процедура, почему бы и нет)

Так вот если это не проводится на автомате с каждым клиентом, то шифрования диска со вводом пароля в момент загрузки, подключившись по IP KVM или аналогам либо в initramfs ssh либо к примеру свой гипервизор ... то твои файлы достаточно защищены (настоятельно рекомендую арендовать для таких задач физическое железо а не vps-ку и устанавливать на него свой гипервизор а задачи запускать в виртуальной машине, атака на такой конфиг тупо дороже)

Обычно в win32 приложении, помимо установки значения нужно симулировать событие EN_CHANGE но в любом случае ковыряться с win32 не универсально и на порядок сложнее чем готовые инструменты

настоятельно рекомендую использовать autoit

Поиграй с BNB, это фактически клон ethereum, но дешевый, еще из дешевых блокчейнов со смартконтрактами и достаточной ликвидностью можно предложить - Tron

а вообще полистай вот список dex бирж на блокчейнах, отсортируй по объемам и изучай

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

Отдельный демон (хоть и по крону) опрашивает api, проверяя появление новых данных или изменение. От этого api зависит, в худшем случае, если нет возможности даже даты изменений получить - запрашиваешь все данные, собираешь свой json и берешь из него как строка - хеш например md5, изменился - есть новые данные, значит записываешь json (совет если работаешь с файлами, пиши всегда файл с новым именем, и при запросе - отдавай тот что записал последним, после окончания записи старый файл удаляй, это исключит ошибку если будет запрос на чтение в момент сохранения).

Если api позволяет оценить изменения в данных, то хранить в файле json имеет смысл только если он не большой, иначе да, как то оптимизировать хранение, либо по файлу на объект либо действительно в базе данных, по желанию

с вероятностью 99% косяк провайдера
включи dns over https (безопасный dns), а публичные уже не надежны, ибо их подменяют.

Российские провайдеры в попытках (судя по всему успешных) анализировать шифрованный трафик (не всех но некоторых сайтов, и список таковых со временем меняется), сильно тормозят https подключения, и получается иногда парадоксальная ситуация, через наидешевейший тормозной vps в европе такие сайты открывает быстрее чем полугигабитный ростелеком (который может на 20-30мбайт/с грузить что-нибудь за тысячи км от ...)

Зачем выбирать специализированную версию linux - RedOS а затем уходить от ее протестированных компонент на самые новые, в 99% случаев вне зависимости от ос это непередаваемые приключения и страдания. Чем тебя qt5 версии не устраивают, которые есть в репах этой ос?

Так как готовых backports разработчики или сообщество не предоставило (наличие их отсутствия показывает размер и качество этого сообщества и разработчиков данной ОС), то собирать вам весь комплекс пакетов самостоятельно

Без знания linux боюсь будет очень сложно, ведь на таком квесте спотыкаются и опытные пользователи

RedOS Система основана на rpm пакетах, пакетный менеджер утилита dnf (ранее yum) так как скорее всего основано на centos. С некоторой вероятностью у операционной системы может быть бинарная совместимость с centos (одинаковые версии системных библиотек) а значит можно попытаться поискать готвые решения от туда.

p.s. но главное, куда поедет сертификация, после того как вы на эту ос начнете водружать системные пакеты собственной/чужой сборки?

Именно функционал клонирования, причем запущенного, есть у систем виртуализации, если физически машины имеют одинаковое железо то, на этом даже основаны системы резервирования приложений, позволяющие не прекращать их работу (доля секунды пауза) даже после смерти одной из машин (Fault Tolerance как часть High Availability у vmware).

Если речь идет о переносе настроек, то в большинстве случаев достаточно определить место их хранения и скопировать только их. Можно проконтролировать как именно приложение устанавливается на машину с помощью монитора работы с диском и реестром (этого обычно достаточно) например приложения microsoft sysinternails

На практике никто конечно не решает это проблему в лоб, на целевую машину производят штатную установку приложения, а затем копируется реестр (с помощью штатного regedit) из HKLM и HKCU /Software/.. и и файлы из appdata (плюс собственно файлы приложения, где их хранят)