Spritely представляет концепцию создания децентрализованных и безопасных по умолчанию приложений, исходя из решения трёх основных проблем распределённых систем: управления доступом, взаимодействия процессов и именования ресурсов. Об этом рассказали Christine Lemmer-Webber, исполнительный директор Spritely Institute, и David Thompson, технический директор института.
Идея исходит из того, что централизованные сервисы проще с инженерной точки зрения, но дают оператору широкие возможности изменять сервис, наблюдать за пользователями или полностью закрывать продукт. Spritely считает, что зависимость от централизованных платформ оставляет пользователей с ограниченным выбором, а некоторые законы, разработанные для воздействия на крупные компании, могут превратиться в «законодательные рвы», делающие соблюдение требований дорогостоящим для небольших проектов и самостоятельного хостинга.
Безопасность начинается с возможностей, а не с общих разрешений
В материале критикуются модели списков контроля доступа и ролей, поскольку они часто опираются на широкие группы и разрешения, а также на централизованного администратора, выдающего полномочия. Альтернатива, предлагаемая Spritely, — это безопасность на основе возможностей, где возможность представляет собой неподделываемую ссылку, объединяющую идентификацию ресурса и предоставление права на его использование.
На практике программа получает только те возможности, которые ей явно передали. Если запустить ненадёжное приложение, ему, например, можно предоставить право взаимодействовать только с экраном и клавиатурой, вместо запуска со всеми полномочиями пользователя. Эта модель позволяет ограничивать полномочия при их делегировании и передавать их другой стороне без обращения к централизованному администратору; впоследствии их также можно отозвать.
Spritely воплощает эти принципы в Goblins — безопасной распределённой среде программирования, основанной на возможностях. Материал связывает передачу возможностей с передачей аргументов в языках программирования: доступ к ресурсам становится прямым результатом того, что получает функция или процесс, а не того, к чему они могут получить неявный доступ. Goblins также поддерживает параллелизм, сохранение состояния и транзакции, включая возврат к предыдущему состоянию при сбое операции.
Модель акторов и протокол OCapN
Для организации взаимодействия между процессами Spritely использует модель акторов, в которой каждый актор получает по одному сообщению за раз и может отправлять сообщения другим акторам, создавать новых акторов или изменять своё поведение для обработки следующего сообщения. Эта модель объединяет асинхронное взаимодействие с управлением состоянием, уменьшая зависимость от общих блокировок.
Spritely считает, что REST в первую очередь подходит для клиент-серверных приложений, но не для одноранговой сети, состоящей из сторон, не доверяющих друг другу. OCapN, или Object-Capability Network, добавляет безопасную передачу ссылок к вызовам удалённых процедур. Протокол не зависит от способа транспортировки и может работать через WebSockets, onion-сервисы Tor или другие средства; он также поддерживает соединение между двумя сторонами и передачу объектов третьей стороне.
OCapN использует модель данных без схемы, заданной на базовом уровне, и поддерживает асинхронные вызовы и значения-обещания. В материале отмечается, что в настоящее время он реализован в Scheme, JavaScript и Dart.
Локальное именование вместо слепого доверия к общим именам
Spritely рассматривает проблему именования ресурсов с помощью систем petname, которые предоставляют пользователю локальные имена, выбираемые им для известных ему сторон или объектов. Это является ответом на проблемы доменных имён, такие как фишинг, захват имён и атаки с визуальным сходством.
Материал связывает эту проблему с так называемым треугольником Зуко, который предполагает сложность одновременного объединения в одной системе понятного людям имени, децентрализации и безопасности. Вместо представления глобального имени как достаточного доказательства идентичности модель petname сосредотачивается на локальной связи пользователя с ресурсом.
Что меняется на практике?
Spritely предлагает скорее набор принципов и инструментов, чем готовый продукт, заменяющий централизованные сервисы. Основная ценность заключается в попытке сделать безопасность и децентрализацию настройками по умолчанию для разработчика, избавив его от необходимости заново открывать десятилетия исследований в области распределённых систем и безопасности. Однако сама презентация не даёт окончательных ответов на вопросы широкого внедрения, пользовательского опыта, совместимости с существующими приложениями или управления ресурсами при отключении сторон или их расхождении.
Для архитекторов программного обеспечения значение этого подхода заключается в объединении детального управления полномочиями с асинхронным взаимодействием и передачей ссылок. Для разработчиков же главным остаётся вопрос зрелости инструментов и протоколов, а также доступности моделей эксплуатации, более простых, чем привычные централизованные архитектуры.