Архитектура безопасности
Как на самом деле работают заявления PDF Pro о приватности.
Всё, что на этой странице, можно проверить в DevTools браузера. Главное правило: мы не должны иметь доступа к вашим файлам — даже если бы захотели. Ниже — как это правило обеспечивается на уровне криптографии, хранения и запросов.
memoryWebAssembly и JS на стороне клиента
lockAES-256-GCM
verifiedECDSA P-256
cloud_offКлиент-сторонее зашифрованное хранение
Четыре архитектурных столпа
Четыре технических решения определяют профиль безопасности. Они обеспечиваются кодом, который работает в вашем браузере, — а не документом политики.
1. Local-first обработка
Просмотр PDF, аннотации, заполнение форм, сжатие, объединение, конвертация и подписание целиком работают в вашем браузере через WebAssembly и JavaScript. Для этих инструментов данные файла никогда не покидают устройство — это проверяется во вкладке Network.
2. Ключи генерируются на стороне клиента
Когда нужно поделиться файлом, ключ шифрования генерирует Web Crypto API внутри вашей вкладки. Он живёт в памяти, в URL-фрагменте или (в режиме парольной фразы) выводится на устройстве получателя через PBKDF2. Сервер его никогда не видит.
3. Клиент-сторонее зашифрованное хранение
Хранится только шифротекст AES-256-GCM плюс вектор инициализации (а в режиме парольной фразы — соль PBKDF2). Без ключа эти данные криптографически неотличимы от случайных байт. Даже root-доступ к базе не помог бы их расшифровать.
4. Честная граница ИИ
ИИ-инструментам (чат, сводка, перевод) нужен читаемый текст. Мы извлекаем текст на стороне клиента и отправляем поставщику модели только его — никогда сам PDF, ни изображения, ни встроенные вложения. Это разбор PDF в браузере + ИИ на сервере (Anthropic Claude). Подробности — в разделе про ИИ ниже.
Поток шифрования (Secure Transfer)
Побайтовое прохождение того, что происходит, когда вы перетаскиваете PDF в Secure Transfer и делитесь полученной ссылкой. Каждый шаг ниже выполняется в браузере, кроме самого хранения шифротекста.
Отправитель — в браузере
// 1. сгенерировать свежий 256-битный ключ
key = crypto.subtle.generateKey({name:"AES-GCM", length:256})
// 2. случайный 96-битный IV на каждый файл
iv = crypto.getRandomValues(new Uint8Array(12))
// 3. зашифровать байты PDF локально
ct = crypto.subtle.encrypt({name:"AES-GCM", iv}, key, pdfBytes)
// 4. загрузить шифротекст + iv — больше ничего
id = await fetch("/api/transfer", {method:"PUT", body: ct, headers:{"x-iv": hex(iv)}})
// 5. построить ссылку с ключом в URL-фрагменте (#)
link = `https://pdfpro.tools/s/<ID>#<KEY>`
▼
Сервер — хранит только шифротекст
ciphertext = непрозрачные байты // нельзя расшифровать без ключа
iv = 12-байтовый nonce
expiry = 24 ч (free) / 30 д (Pro)
// URL-фрагмент (#...) браузеры НИКОГДА не отправляют на сервер
▼
Получатель — в браузере
// 1. браузер загружает страницу; фрагмент "#..." остаётся клиент-сторонним
rawKey = location.hash.slice(1)
// 2. забрать шифротекст
ct = await fetch("/api/transfer/" + id)
// 3. расшифровать локально через Web Crypto
pdf = crypto.subtle.decrypt({name:"AES-GCM", iv}, importKey(rawKey), ct)
// 4. файл оказывается в папке Загрузок получателя
Гарантия безопасности держится на шаге 5 (отправитель) и шаге 1 (получатель): URL-фрагмент после # ни один совместимый браузер на сервер не отправляет. Именно это делает саму ссылку «учётной записью» для расшифровки.
Режим парольной фразы заменяет шаг 1 (отправитель) на PBKDF2-SHA256(passphrase, salt, 310_000). Соль хранится на сервере; парольная фраза передаётся получателю по отдельному каналу.
Поток подписи (ECDSA P-256)
Подпись PDF использует ECDSA на кривой NIST P-256. Закрытый ключ генерируется в вашем браузере; документ никогда не покидает устройство.
Генерация закрытого ключа
Пара ключей ECDSA P-256 генерируется через
crypto.subtle.generateKey в вашем браузере. Закрытый ключ экспортируется в защищённый паролем JSON Web Key (JWK), который можно сохранить локально.Хеш SHA-256 и подпись
Байты PDF хешируются SHA-256 на стороне клиента. Этот хеш подписывается закрытым ключом. Подпись встраивается в PDF в CMS-контейнер (профиль PAdES-B-B).
Проверяется офлайн
Любой, у кого есть открытый ключ (распространяется вместе с документом или как отпечаток), может проверить подпись офлайн. Серверный round-trip не требуется.
Чем это не является
Наши подписи криптографически проверяемы, но не являются квалифицированной электронной подписью (QES) согласно eIDAS. Это устойчивые к подделке доказательства целостности — подходят для внутренних процессов, но не для регуляторно-обязательной юридической силы.
ИИ-функции — где мы честны насчёт границы
ИИ-чат, ИИ-сводка и Перевод нуждаются в читаемом тексте. Вот ровно что покидает ваше устройство, а что — нет.
Текст извлекается в браузере
PDF разбирается локально через pdf.js. В памяти держится только извлечённый текст (или, для сканированных PDF, результат OCR) — оригинальный файл остаётся на вашем устройстве.
Поставщику — только текст
Эту строку текста мы отправляем поставщику ИИ (Anthropic Claude). Сам PDF, встроенные изображения, шрифты и данные форм никогда не загружаются ни в одну ИИ-модель.
Без обучения на ваших данных
Договоры с поставщиком запрещают обучение на пользовательских данных. Запросы stateless — каждый ограничен вашей сессией.
Когда это важно
Если документ содержит регулируемые данные (PHI, секретные, юр. привилегированные), где даже извлечение текста чувствительно, не используйте ИИ-функции — пользуйтесь локальными инструментами (просмотр, аннотации, подпись, сжатие, конвертация); они работают на 100% в браузере.
Модель угроз — от чего защищаем, от чего не можем
Чёткая модель угроз полезнее маркетинга. Вот что архитектура реально останавливает и где останавливается.
shieldОт чего защищает архитектура
- Сотрудники PDF Pro читают ваши файлы на наших серверах (мы никогда не держим ключ).
- Утечка на уровне базы данных хранилища передач (атакующий видит шифротекст, не файлы).
- Раскрытие содержимого по решению суда (мы можем выдать шифротекст — это всё, что у нас есть).
- Сохранение почтовым сервером чувствительных вложений (на ваш почтовый сервер ничего не попадает).
- Подделка подписанного PDF (проверка подписи ECDSA обнаружит любое изменение байт).
warningОт чего не защитит ни один браузерный инструмент
- Скомпрометированная конечная точка (вредонос на вашем устройстве) — ключи живут в памяти на устройстве, которому надо доверять.
- Подсматривание URL-фрагмента — относитесь к ссылке как к самому файлу.
- Слабая парольная фраза в режиме парольной фразы — PBKDF2 замедляет перебор, но не делает 6-символьную фразу безопасной.
- Получатель пересылает расшифрованный файл — транспортная защита заканчивается, как только получатель сохранил PDF.
- Компрометация самого браузера или вредоносное расширение, внедряющееся в страницу.
Никаких заявлений «невзламываемо». Сквозное шифрование значительно повышает стоимость утечки — но не устраняет весь риск, особенно на конечной точке. Для самых чувствительных случаев комбинируйте Secure Transfer с отдельной парольной фразой и обменом ключом по доверенному каналу.
Связанное чтение
Часто задаваемые вопросы
Может ли PDF Pro расшифровать мои файлы?
Нет. Ключи шифрования генерируются и хранятся в браузере пользователя. Для Secure Transfer сервер хранит только шифротекст AES-256-GCM плюс вектор инициализации (плюс соль в режиме парольной фразы). Ключ никогда не попадает в нашу инфраструктуру. Даже при полном доступе к базе наши операторы не могут расшифровать ваш файл.
Что именно работает локально, а что — на сервере?
Просмотр, аннотации, заполнение форм, сжатие, объединение, конвертация и подписание выполняются на 100% в браузере через WebAssembly и JavaScript — данные файла никогда не покидают устройство. ИИ-функции (чат, сводка, перевод) извлекают текст локально и отправляют поставщику модели только этот текст (никогда сам PDF).
Какие алгоритмы использует PDF Pro?
AES-256-GCM для симметричного шифрования (Secure Transfer), PBKDF2-SHA256 с 310 000 итераций для ключей, выводимых из парольной фразы, ECDSA на NIST P-256 для цифровых подписей и SHA-256 для хеширования документа. Всё это работает через встроенный Web Crypto API браузера, который проаудирован, стандартизован и реализован не нами.
Это юридически обязывающая электронная подпись?
Подписи PDF Pro криптографически проверяемы (ECDSA P-256 поверх SHA-256-хеша, профиль PAdES-B-B), но не являются квалифицированной электронной подписью (QES) согласно eIDAS или эквивалентным регуляциям. Для юридической силы уровня QES требуется сертифицированный поставщик доверенных услуг.
Что произойдёт, если я забуду парольную фразу или потеряю ссылку?
Файл становится безвозвратно недоступен. Это компромисс сквозного шифрования — нет пути восстановления, потому что у нас изначально не было ключа. Сохраняйте парольную фразу в менеджере паролей и ссылку — в надёжном месте.
Ведёте ли вы серверные логи активности с файлами?
Мы ведём операционные логи (тайминги запросов, коды ошибок, IP-адреса для rate limiting), но никогда не храним открытое содержимое файлов или ключи шифрования. Логи хранятся короткий срок — текущие сроки см. в нашей политике конфиденциальности.
Может ли судебный приказ заставить вас раскрыть мои файлы?
Мы можем отдать только то, что у нас есть: шифротекст. Без ключа расшифровки — а он остаётся на устройстве отправителя или в URL-фрагменте, который держит получатель — этот шифротекст не расшифровывается. Повестка не может задним числом восстановить ключ, который мы никогда не хранили.
Где можно самому проверить криптографические заявления?
Откройте DevTools браузера → вкладка Network и наблюдайте, что покидает страницу при загрузке Secure Transfer. Вы увидите PUT шифротекста на сервер, а не оригинального PDF. Код шифрования вызывает Web Crypto API, встроенный в ваш браузер, — это не наш код, и его может проверить любой.
Приватность как архитектура, а не маркетинг.
Попробуйте Secure Transfer и проверьте вкладку Network сами. Никакие файлы не загружаются в открытом виде.
lockПопробовать Secure Transfer