Читал документацию SXT и застрял на вопросе менее эффектном, чем доказательства с нулевым разглашением: кому вообще разрешено записывать данные в таблицу.
Когда разработчик создаёт таблицу с помощью подписанного оператора CREATE TABLE, он может выбрать одну из трёх моделей записи: публичная запись, когда строки может отправлять кто угодно; запись с разрешением владельца, когда это может делать только владелец или пользователь из списка разрешённых; и запись с подтверждением пользователя, когда для каждой строки нужна подпись пользователя ECDSA/ED25519, а проверку при желании можно дополнить zkTLS или верификацией индексатором.
Мне нравится, что эти модели не рассматриваются как универсальные разрешения на все случаи жизни. У публичной ленты активности, набора данных под управлением протокола и записей, отправленных пользователями, разные предположения о доверии. Полномочия владельца также можно делегировать с помощью токенов авторизации Biscuit, поэтому управление не обязательно должно оставаться у кошелька, создавшего таблицу.
Не думаю, что сама по себе такая гибкость — это недостаток. Но она ставит разработчика перед важным выбором: уровень данных может обеспечивать заданную ему политику, но не спасёт приложение от выбора слишком разрешительной политики. Для токенизированных активов или записей DeFi неудачная политика записи может иметь серьёзные последствия задолго до того, как кто-нибудь задаст хитрый вопрос на SQL.
Всё думаю, будут ли разработчики считать разрешения на таблицы важной частью проектирования безопасности или просто ещё одним параметром настройки, который можно быстро пролистать. Что должно быть настройкой по умолчанию для чувствительных наборов данных: запись под контролем владельца или строки с подписью пользователя??
#SXT @SpaceandTime $SXT
#sxt $SXT @SpaceandTime #SXT
Когда разработчик создаёт таблицу с помощью подписанного оператора CREATE TABLE, он может выбрать одну из трёх моделей записи: публичная запись, когда строки может отправлять кто угодно; запись с разрешением владельца, когда это может делать только владелец или пользователь из списка разрешённых; и запись с подтверждением пользователя, когда для каждой строки нужна подпись пользователя ECDSA/ED25519, а проверку при желании можно дополнить zkTLS или верификацией индексатором.
Мне нравится, что эти модели не рассматриваются как универсальные разрешения на все случаи жизни. У публичной ленты активности, набора данных под управлением протокола и записей, отправленных пользователями, разные предположения о доверии. Полномочия владельца также можно делегировать с помощью токенов авторизации Biscuit, поэтому управление не обязательно должно оставаться у кошелька, создавшего таблицу.
Не думаю, что сама по себе такая гибкость — это недостаток. Но она ставит разработчика перед важным выбором: уровень данных может обеспечивать заданную ему политику, но не спасёт приложение от выбора слишком разрешительной политики. Для токенизированных активов или записей DeFi неудачная политика записи может иметь серьёзные последствия задолго до того, как кто-нибудь задаст хитрый вопрос на SQL.
Всё думаю, будут ли разработчики считать разрешения на таблицы важной частью проектирования безопасности или просто ещё одним параметром настройки, который можно быстро пролистать. Что должно быть настройкой по умолчанию для чувствительных наборов данных: запись под контролем владельца или строки с подписью пользователя??
#SXT @SpaceandTime $SXT
#sxt $SXT @SpaceandTime #SXT