За идеи по поводу новых ocr спасибо, обязательно попробую. Просто конкретно мой случай это к сожалению не пиксель в пиксель. Это кривые, косые фоточки сделанные телефоном на бегу
Но, пока приложение не создаёт слишком сложных сценариев использования, и мне хватает отладки и чтения логов на моём тестовом телефоне, на котором я прогоняю функциональное тестирование. Так что пока все ок
А вот про палку интересно, уточните: где вы видите перегиб — в отказе от синхронизации или в отключённом бэкапе? Я сам считаю эти два решения самыми спорными в проекте: они защищают пользователя от меня, но заодно и от него самого. Выгрузка в markdown — попытка это уравновесить, думаете, недостаточная?
Спасибо, это самый содержательный разбор, который я получал. Три ваших пункта я принимаю целиком, по двум, кажется, статья вас подвела — отвечу по порядку.
Модель угроз. Вы правы: её не было в тексте, и без неё рассказ читается как импровизация. Добавил врезкой в начало статьи — пять пунктов «защищаем» по приоритету и три «не защищаем», ровно в том виде, в каком они лежат в README проекта. Там же теперь сказано главное: решение считается правильным, если оно закрывает пункт из первого списка и не притворяется, что закрывает пункт из второго.
Терминология. Согласен полностью. В статье «клиент» — это браузерная страница, «бэкенд» — сервер приложения, который эту страницу отдаёт и хранит документы, а key-service — отдельный сервис на отдельной машине, который хранит только ключи и документов не видит никогда. Три роли с разными правами, и названы они так, что их легко слить в одну.
Вывод про второй фактор. Здесь вы правы, и это не мелочь. Моя фраза шире того, что следует из фактов. WebAuthn с challenge от независимой стороны даёт вполне реальные вещи: заготовить подписи впрок нельзя, использовать фактор без физического присутствия человека нельзя. Чего он не даёт в вебе — привязки к намерению: устройство не показывает, что именно подписывает, а текст на экране рисует тот же бэкенд. Он покажет «доступ к документу А», а на подпись отправит challenge для документа Б.
Обиднее всего, что в моём же исходном разборе формулировка была точная: «доказательство присутствия не привязано к документу, который имел в виду пользователь». Обобщил я её уже в статье и потерял разницу между «фактор бесполезен» и «фактор подтверждает присутствие, но не выбор объекта». Поправлю.
Одноразовые токены и привязка ко времени — они есть. Разрешение на выдачу ключа: подпись Ed25519, одноразовый идентификатор, срок жизни не больше двух минут, привязка к конкретному документу, а контекст вшит в проверяемые данные шифра, так что подменить его нельзя. В статье про это сказано вскользь, отсюда и впечатление. Ваше замечание точно бьёт в WebAuthn-доказательство старой схемы, где challenge выдавал не key-service, — и это ровно то, что предписал разбор.
Отдельный сервис в изолированном контуре — это и есть моя архитектура. Раз из статьи это не считалось, написана она плохо. Что происходит при захвате каждого из двух:
Сервер с документами: данные зашифрованы, ключей на нём нет. Но он владеет ключом подписи разрешений, поэтому может законно запрашивать ключи по одному. Против этого работают лимиты (сто двадцать запросов в окно на пользователя, шестьдесят на документ), аварийная блокировка по порогу и приманки. Но фундаментально — да, он способен выкачивать в темпе лимита, и это принятый риск, а не недосмотр.
Key-service: документов там нет вовсе, мастер-ключ появляется в памяти только после ручного отпирания по локальному сокету.
Оба сразу: первый уровень падает, второй — нет, пока у атакующего нет парольной фразы, которой на серверах не существует.
То есть разделение поднимает цену атаки с «одна машина» до «две машины плюс активная малварь на устройстве пользователя». Не полная защита, но и не ноль.
И про то, зачем тогда убрали WebAuthn. Не из-за объёма работы. Я не мог поручиться, что у людей, для которых это делается, есть подходящее устройство, и не хотел, чтобы человеку со старым ноутбуком отказали в доступе к собственным записям. Это размен доступности на защиту от активной компрометации, и в решении он записан вместе с тем, что мы теряем. В статье я подал его как вывод, а не как размен, — и звучит хуже, чем есть.
Ну не зря же внесение изменений даже во вчерашний баланс, сейчас это процедура через главного бухгалтера. Вс из-за хранимых остатков. Надо все рекурсивно поправить. А если не дай бог валютный счет правится - так еще и переоценки пересчитать)))
я делал домашний раг на qwen0.6b (да, именно 0,6 млрд параметров) поиск по библиотеке документов работал очень даже достойно По сути, от модели требовалось только скомпилировать связный текст по чанкам, а векторный поиск делал основную работу
Связи двухслойные, и обе защиты — от выдуманных ссылок. На экстракции каждая порция транскрипта даёт структурированные темы, из них собирается индекс и план статей. Дальше, когда модель пишет статью, она получает белый список уже существующих заголовков и инструкцию: ссылаться [[так]] можно только на темы из списка. А на сборке vault все ссылки ещё раз проверяются против реальных страниц: неизвестная ссылка не остаётся битой — она уезжает в отдельный индекс Unlinked Mentions с указанием, кто её упоминал. Получается одновременно защита от галлюцинированных связей и очередь кандидатов на следующие статьи: у меня сейчас 47 написанных и примерно полторы тысячи отложенных тем в этом индексе.
Про агента — честно: пока нет. Пользуюсь руками в Obsidian: из статьи ссылка ведёт в чанк-источник, из чанка — в транскрипт, так что «ответ по вики» у меня — это статья плюс два клика до первоисточника. По устройству vault — готовый RAG-корпус, агент поверх напрашивается, но это следующий шаг, а не текущий.
для МВП телеграм-бота, мне кажется самое естественное - сделать оплату звездами. Но для начала, я бы дал поработать первым юзерам тестировщиками, и заодно собрать все грабли
Все поправимо). В 45 лет получите новый). Правда блики от ламината никуда не денутся
Там достаточно хитрый выбор искажений получается:
бабочка (когда края центрального разворота, как бы наверх смотрят)
Трапеция (самое простое)
Бабочку не смог победить, а она самая частая
Это уже испробовано, различными способами. Этим её, не напугать)
Клиенты кидают фотки документов, чтобы оператор оформлял их дальше
За идеи по поводу новых ocr спасибо, обязательно попробую. Просто конкретно мой случай это к сожалению не пиксель в пиксель. Это кривые, косые фоточки сделанные телефоном на бегу
Я понял идею.
Но, пока приложение не создаёт слишком сложных сценариев использования, и мне хватает отладки и чтения логов на моём тестовом телефоне, на котором я прогоняю функциональное тестирование. Так что пока все ок
А вот про палку интересно, уточните: где вы видите перегиб — в отказе от синхронизации или в отключённом бэкапе? Я сам считаю эти два решения самыми спорными в проекте: они защищают пользователя от меня, но заодно и от него самого. Выгрузка в markdown — попытка это уравновесить, думаете, недостаточная?
Спасибо!
Спасибо, это самый содержательный разбор, который я получал. Три ваших пункта я принимаю целиком, по двум, кажется, статья вас подвела — отвечу по порядку.
Модель угроз. Вы правы: её не было в тексте, и без неё рассказ читается как импровизация. Добавил врезкой в начало статьи — пять пунктов «защищаем» по приоритету и три «не защищаем», ровно в том виде, в каком они лежат в README проекта. Там же теперь сказано главное: решение считается правильным, если оно закрывает пункт из первого списка и не притворяется, что закрывает пункт из второго.
Терминология. Согласен полностью. В статье «клиент» — это браузерная страница, «бэкенд» — сервер приложения, который эту страницу отдаёт и хранит документы, а key-service — отдельный сервис на отдельной машине, который хранит только ключи и документов не видит никогда. Три роли с разными правами, и названы они так, что их легко слить в одну.
Вывод про второй фактор. Здесь вы правы, и это не мелочь. Моя фраза шире того, что следует из фактов. WebAuthn с challenge от независимой стороны даёт вполне реальные вещи: заготовить подписи впрок нельзя, использовать фактор без физического присутствия человека нельзя. Чего он не даёт в вебе — привязки к намерению: устройство не показывает, что именно подписывает, а текст на экране рисует тот же бэкенд. Он покажет «доступ к документу А», а на подпись отправит challenge для документа Б.
Обиднее всего, что в моём же исходном разборе формулировка была точная: «доказательство присутствия не привязано к документу, который имел в виду пользователь». Обобщил я её уже в статье и потерял разницу между «фактор бесполезен» и «фактор подтверждает присутствие, но не выбор объекта». Поправлю.
Одноразовые токены и привязка ко времени — они есть. Разрешение на выдачу ключа: подпись Ed25519, одноразовый идентификатор, срок жизни не больше двух минут, привязка к конкретному документу, а контекст вшит в проверяемые данные шифра, так что подменить его нельзя. В статье про это сказано вскользь, отсюда и впечатление. Ваше замечание точно бьёт в WebAuthn-доказательство старой схемы, где challenge выдавал не key-service, — и это ровно то, что предписал разбор.
Отдельный сервис в изолированном контуре — это и есть моя архитектура. Раз из статьи это не считалось, написана она плохо. Что происходит при захвате каждого из двух:
Сервер с документами: данные зашифрованы, ключей на нём нет. Но он владеет ключом подписи разрешений, поэтому может законно запрашивать ключи по одному. Против этого работают лимиты (сто двадцать запросов в окно на пользователя, шестьдесят на документ), аварийная блокировка по порогу и приманки. Но фундаментально — да, он способен выкачивать в темпе лимита, и это принятый риск, а не недосмотр.
Key-service: документов там нет вовсе, мастер-ключ появляется в памяти только после ручного отпирания по локальному сокету.
Оба сразу: первый уровень падает, второй — нет, пока у атакующего нет парольной фразы, которой на серверах не существует.
То есть разделение поднимает цену атаки с «одна машина» до «две машины плюс активная малварь на устройстве пользователя». Не полная защита, но и не ноль.
И про то, зачем тогда убрали WebAuthn. Не из-за объёма работы. Я не мог поручиться, что у людей, для которых это делается, есть подходящее устройство, и не хотел, чтобы человеку со старым ноутбуком отказали в доступе к собственным записям. Это размен доступности на защиту от активной компрометации, и в решении он записан вместе с тем, что мы теряем. В статье я подал его как вывод, а не как размен, — и звучит хуже, чем есть.
qwe
Просто выглядит, как старый способ сделать автоматизацию)
Но старый, это не значит, что плохой)
Не в 2026, немного пораньше.
Просто потому, что уже было и работало. А если работает, то зачем ломать)
А сейчас, я, после того как ушёл из казны, как раз собрал современное решение
Целая вселенная
вот вот вот
Ну не зря же внесение изменений даже во вчерашний баланс, сейчас это процедура через главного бухгалтера. Вс из-за хранимых остатков. Надо все рекурсивно поправить. А если не дай бог валютный счет правится - так еще и переоценки пересчитать)))
я делал домашний раг на qwen0.6b (да, именно 0,6 млрд параметров)
поиск по библиотеке документов работал очень даже достойно
По сути, от модели требовалось только скомпилировать связный текст по чанкам, а векторный поиск делал основную работу
Связи двухслойные, и обе защиты — от выдуманных ссылок. На экстракции каждая порция транскрипта даёт структурированные темы, из них собирается индекс и план статей. Дальше, когда модель пишет статью, она получает белый список уже существующих заголовков и инструкцию: ссылаться [[так]] можно только на темы из списка. А на сборке vault все ссылки ещё раз проверяются против реальных страниц: неизвестная ссылка не остаётся битой — она уезжает в отдельный индекс Unlinked Mentions с указанием, кто её упоминал. Получается одновременно защита от галлюцинированных связей и очередь кандидатов на следующие статьи: у меня сейчас 47 написанных и примерно полторы тысячи отложенных тем в этом индексе.
Про агента — честно: пока нет. Пользуюсь руками в Obsidian: из статьи ссылка ведёт в чанк-источник, из чанка — в транскрипт, так что «ответ по вики» у меня — это статья плюс два клика до первоисточника. По устройству vault — готовый RAG-корпус, агент поверх напрашивается, но это следующий шаг, а не текущий.
я решал похожую задачу, есть 48 часов видео с курса, и нужно собрать из них вики для собственного использования
В ито сделал готовый продукт. Все кроме экстракции сущностей, происходит локально.
Хорошая мысль написать про него статью тоже
Молодцы Понаставят барьеров, а Китай будет развиваться свободно. По-моему, их должно это больше волновать.
для МВП телеграм-бота, мне кажется самое естественное - сделать оплату звездами. Но для начала, я бы дал поработать первым юзерам тестировщиками, и заодно собрать все грабли
осталось самое главное - чтобы инженеры этой идеей прониклись и начали изобретать, вместо того, чтобы привычно бухтеть))