Спасибо за статью. Интересно! А что если скармливать ИИ не сам js-код, а d.ts файлы? Мне кажется, что количество токенов можно уменьшить в разы. d.ts файлы они и код описывают, и комментарии содержат. Например, DeepSeek выдавал вполне сносные выводы по скормленным d.ts файлам.
Нулевой секрет (тот, который используется для расшифровки других зашифрованных секретов) может вполне вычисляться из пароля и соли. Не вижу никакой проблемы. Где его будет хранить пользователь - личное дело пользователя. Но это подходит больше для систем с шифрованием end2end.
Нулевой секрет вполне может себе храниться в отдельном хранилище нулевых секретов сервиса. Доступ к которому строго контролируется, недоступен извне. Расшифровка может вестись даже без участия пользователя на сервере. Зато вся информация на сервере хранится в зашифрованном виде. Таким образом безопасность строится за счёт изоляции хранилища нулевых секретов от основного хранилища.
А ваше видение какое? Как нужно организовать безопасность?
Спасибо, хорошая статья! Можно еще добавить, что web crypto доступен и в принципе рекомендован к использованию в воркерах, чтобы не замедлять ui во время работы с криптографией. На маленьких сообщениях это незаметно, а вот при работе с большими файлами там другая история.
Прочитал с большим интересом! Кстати, у нас с вами идеи довольно похожи. Вот тут я писал о кастомных идентификаторах и скоупах: https://habr.com/ru/articles/892326/. Будет интересно, загляните.
Ну, если уж говорить про эксперименты, то мы пришли к выводу оформлять любые самостоятельные части отдельными пакетами.
Работа с api сервера - отдельный пакет. Всякие сервисы, например, шифрование, - отдельный пакет. UI kit - отдельный пакет. Даже общий компонент как меню навигации для группы страниц - тоже может стать полноценным отдельным пакетом.
Вот такая структура позволяет сосредоточиться на реальном фронтенде: сама страничка, импортированные сконфигурированные ui-компоненты и бизнес-логика.
Даже если вы работаете в соло, можно импортировать пакеты из локальных папок и прекрасно с этим работать.
Чем проще, понятнее, тем быстрее напишете продукт.
Одно дело не скрывать алгоритм шифрования, потому что безопасность не должна зависеть от скрытости алгоритма, конфиденциальность и целостность информации должна зависеть от ключа. И это правильно. Но раскрывать все другие методы безопасности, как и чему противодействуют - это как влияет на безопасность продукта и его пользователя? Даже наоборот.
Я так понял, что речь идёт о создании мессенджера, в котором будут только верифицированные аккаунты.
Следующий этап - определение социальной значимости каждого гражданина.
Да, это тоже смутило. И явную рекламу курсов.
Кстати, вполне вероятно, что его будут использовать для оптимизации работы hr: для снижения количества кандидатов. Нет серта - собеса не будет.
Если с телефона проходить, то надо быть очень осторожным с блокировкой экрана. Система считает, что схалтурил.
Так я тоже пишу на JS с комментариями на jsdoc. Только в дополнение с помощью typescript я генерирую d.ts.
Удаляю из трекера. Уже скучно.
Спасибо за статью. Интересно! А что если скармливать ИИ не сам js-код, а d.ts файлы? Мне кажется, что количество токенов можно уменьшить в разы. d.ts файлы они и код описывают, и комментарии содержат. Например, DeepSeek выдавал вполне сносные выводы по скормленным d.ts файлам.
Не имею к продукту автора никакого отношения.
Нулевой секрет (тот, который используется для расшифровки других зашифрованных секретов) может вполне вычисляться из пароля и соли. Не вижу никакой проблемы. Где его будет хранить пользователь - личное дело пользователя. Но это подходит больше для систем с шифрованием end2end.
Нулевой секрет вполне может себе храниться в отдельном хранилище нулевых секретов сервиса. Доступ к которому строго контролируется, недоступен извне. Расшифровка может вестись даже без участия пользователя на сервере. Зато вся информация на сервере хранится в зашифрованном виде. Таким образом безопасность строится за счёт изоляции хранилища нулевых секретов от основного хранилища.
А ваше видение какое? Как нужно организовать безопасность?
Шутливое обращение к абстрактному автору
Зависит от реализации. Может приватный ключ кто-то создаёт из пароля и соли.
"A" в русском языке - это союз. Он используется для присоединения однородных членов предложения, частей сложного предложения или простых предложений.
Спасибо, хорошая статья! Можно еще добавить, что web crypto доступен и в принципе рекомендован к использованию в воркерах, чтобы не замедлять ui во время работы с криптографией. На маленьких сообщениях это незаметно, а вот при работе с большими файлами там другая история.
Хеш обычно используется для проверки правильности пароля. Он не полностью идентичен паролю.
Хеш в криптографии часто используется для проверки целостности данных. Например, с его помощью проверяется верный ли использовался ключ.
Прочитал с большим интересом! Кстати, у нас с вами идеи довольно похожи. Вот тут я писал о кастомных идентификаторах и скоупах: https://habr.com/ru/articles/892326/. Будет интересно, загляните.
Ну, если уж говорить про эксперименты, то мы пришли к выводу оформлять любые самостоятельные части отдельными пакетами.
Работа с api сервера - отдельный пакет. Всякие сервисы, например, шифрование, - отдельный пакет. UI kit - отдельный пакет. Даже общий компонент как меню навигации для группы страниц - тоже может стать полноценным отдельным пакетом.
Вот такая структура позволяет сосредоточиться на реальном фронтенде: сама страничка, импортированные сконфигурированные ui-компоненты и бизнес-логика.
Даже если вы работаете в соло, можно импортировать пакеты из локальных папок и прекрасно с этим работать.
Чем проще, понятнее, тем быстрее напишете продукт.
То есть лучше переходить на AES 512?
Есть такая штука как нотариально заверенный скриншот. Иначе никак. И важно чтобы заход на сайт был с компьютера нотариуса.
Эх, улица такого драчуна потеряла.
Одно дело не скрывать алгоритм шифрования, потому что безопасность не должна зависеть от скрытости алгоритма, конфиденциальность и целостность информации должна зависеть от ключа. И это правильно. Но раскрывать все другие методы безопасности, как и чему противодействуют - это как влияет на безопасность продукта и его пользователя? Даже наоборот.