Работали ли вы с фреймворком Electron?

Что проверяют

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

Как отвечать

Electron это Chromium и Node.js в одной поставке. Главный процесс живёт в Node: создаёт окна, работает с файловой системой, меню, обновлениями. Процесс отрисовки это ваша страница, и доступа к Node у него быть не должно. Связывает их обмен сообщениями через прелоад-скрипт:

contextBridge.exposeInMainWorld("api", {
  readConfig: () => ipcRenderer.invoke("config:read"),
});

Наружу отдаётся узкий список операций, а не весь канал и тем более не require. Флаг nodeIntegration выключен, изоляция контекста включена: по этому ответу видно человека, который действительно собирал приложение.

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

Где спотыкаются

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

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

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