Пароль нужен коллеге на десять минут. В переписке он останется на годы. Ну, если просто вставить его в сообщение и пообещать себе: «Потом удалю».
Одноразовые записки придуманы как раз для таких мелочей, из которых вырастают неприятности. Privnote давно сделал этот способ передачи привычным: написал, получил ссылку, отправил. Получатель прочитал — записки больше нет.
Зачем тогда искать аналоги Privnote в 2026 году? Не потому, что знакомый сервис вдруг стал плохим. Просто «отправить секрет» бывает разной задачей. Одному нужно перекинуть пароль без регистрации, другому — встроить выдачу доступов в скрипт, третьему нельзя выносить данные за пределы корпоративной сети. Одна кнопка на всех тут уже не очень-то помогает.
Если без долгого выбора: для разовой отправки без аккаунта подойдёт генератор одноразовых ссылок Secure Link; если вы уже работаете в Bitwarden — присмотритесь к Send; для собственного сервера и кода есть PrivateBin. OneTimeSecret интереснее там, где нужен API. Теперь — к оговоркам. Они, пожалуй, важнее названий.
Что стоит проверить, прежде чем доверить сервису пароль
Надпись «зашифровано» сама по себе говорит немного. Где именно происходит шифрование? Кто получает исходный текст? Можно ли посмотреть код, а не только обещания на главной?
Privnote описывает клиентское шифрование в своей политике конфиденциальности. При этом полный исходный код его backend не опубликован. JavaScript в браузере изучить можно — это не то же самое, что проверить всю систему. И наоборот: открытый репозиторий ещё не даёт гарантии, что на сервере запущена именно эта версия. Доверие не исчезает от галочки Open Source.
Есть и менее очевидная деталь. Сторонний скрипт, работающий на странице, может прочитать window.location.href целиком, вместе с ключом после #. Поэтому рекламные вставки и аналитика рядом с секретной запиской — не просто вопрос вкуса. Это дополнительный доступ к странице.
С паролем примерно та же история: важно не наличие поля ввода, а то, что происходит после неверной попытки. Есть ли ограничения? Расходуется ли лимит открытий? Предусмотрен ли режим приманки на случай принуждения? Пароль — полезная защита, но не индульгенция.
Сравнение аналогов Privnote — в одной таблице
Сначала про ботов, чтобы не обещать лишнего. Telegram, Slack, WhatsApp и Discord могут загружать ссылки ради превью. Если такая загрузка считается чтением, записка способна исчезнуть раньше получателя.
В Secure Link обычная HTML-загрузка просмотр не расходует. Но заметка с корректным ключом в # открывается в браузере автоматически: отдельной кнопки «Я человек, открыть» на этом пути нет. Бот, который умеет выполнять JavaScript и получил полный URL, — уже другая история. Здесь нужен пароль или передача ключа отдельным каналом, а не вера в то, что любой робот обязательно остановится у превью.
В таблице ниже указаны механизмы и ограничения. Не сертификат неуязвимости.
| Параметр | Secure Link | Privnote | OneTimeSecret | Bitwarden Send | PrivateBin |
|---|---|---|---|---|---|
| Открытый исходный код | Да | Полный код не опубликован | Да | Да | Да |
Шифрование в браузере (ключ в # URL) | Да, AES-256-GCM | Заявлено; закрытый backend | Нет, шифрование на сервере | Да, в клиенте | Да, в клиенте |
| Без регистрации для отправки | Да | Да | Да, базовый режим | Нет, нужен аккаунт | Да |
| Защита от ботов превью (Telegram/Slack) | HTML-превью не расходует просмотр; бот с JS и ключом — отдельный риск | Подтверждённой гарантии нет | Экран раскрытия секрета | Ключ в клиенте; зависит от настроек доступа | Зависит от версии и инстанса |
| Уникальные функции защиты | Split-link, Burn-on-Failure, Режим приманки (Decoy Mode) | Уведомление на email | REST API, платные кастомные домены | Передача файлов в экосистеме Bitwarden | Self-hosted, подсветка кода и Markdown |
Secure Link: передать секрет без регистрации
Этот блог ведёт команда Secure Link, так что сразу обозначим: это наш сервис. При этом объяснять его удобнее не словом «лучший», а тем, что именно происходит с заметкой.
Вы вводите текст. Браузер шифрует его через WebCrypto API по алгоритму AES-256-GCM, и на сервер уходит уже шифртекст. В режиме ссылки с ключом этот ключ остаётся после символа #: HTTP-запрос его не содержит. Расшифровка тоже происходит в браузере.
На страницах нет внешних рекламных и аналитических трекеров, которые могли бы собирать URL с ключом. Хорошо? Да. Достаточно, чтобы забыть обо всех рисках? Нет: вредоносное расширение или заражённое устройство этим не обезвредить.
У Split-link задача попроще. Ссылку и ключ можно скопировать отдельно и разнести по разным каналам — например, ссылку отправить в рабочий чат, ключ сообщить другим способом. Суть не в двух сообщениях подряд в одной переписке, а в том, чтобы утечка одного канала не отдавала всё сразу.
Burn-on-Failure расходует доступные просмотры при неверном вводе пароля в штатном клиенте. Когда лимит исчерпан, заметка сгорает. Это не повод выбирать пароль покороче: сильная парольная фраза всё ещё нужна.
Режим приманки, или Decoy Mode, решает другую задачу. Можно задать второй пароль, который покажет безобидный подготовленный текст вместо настоящего секрета. На случай принуждения — дополнительный вариант, не обещание справиться с любой опасной ситуацией.
Для разового пароля, API-ключа или другой короткой записи такого набора может хватить с запасом. Для особенно чувствительных данных лучше добавить пароль или воспользоваться Split-link. Без героизма.
OneTimeSecret: когда ссылку должен создавать скрипт
Есть ситуации, где браузерная форма вообще не главное. Секрет появляется в рабочем процессе, и ссылку на него удобнее получить через API, а не копировать руками. Вот тут OneTimeSecret стоит рассмотреть внимательнее.
У проекта открытый код и REST API; в платных предложениях есть кастомные домены. Базовая отправка доступна без регистрации. Если нужно встроить одноразовую передачу секретов в автоматизацию, это вполне понятный кандидат.
Только не перепутайте архитектуру с клиентским Zero-Knowledge. В классической схеме OneTimeSecret шифрует текст на сервере. Исходное содержимое при создании проходит через backend по HTTPS, а значит, сервер приложения остаётся стороной, которой вы доверяете.
Собственный инстанс меняет владельца этой границы доверия, но не место шифрования. Грубо говоря, backend теперь ваш — он не перестаёт быть backend. Если нужно отделить от него и сам секрет, текст придётся дополнительно зашифровать до отправки.
Это не приговор OneTimeSecret. Это различие, которое полезно понять до выбора, а не после.
Bitwarden Send — если менеджер паролей уже открыт
Зачем искать ещё один сайт, если нужный инструмент уже под рукой?
Send встроен в Bitwarden: текст и файлы шифруются на стороне клиента, содержимое передаётся со сквозным шифрованием. Ключ находится в URL-фрагменте и используется при расшифровке в клиенте. Открытый код и аудиты — тоже часть картины, а не мелкий шрифт внизу страницы.
Для команды, которая и так пользуется этим менеджером, всё выглядит естественно. Передача файлов доступна на платных тарифах — это стоит учесть, если выбираете инструмент не только для коротких паролей.
Но отправителю нужен аккаунт и вход в Bitwarden. На своём рабочем компьютере это не проблема. На чужом устройстве, где ради одной ссылки совсем не хочется открывать хранилище паролей, — уже повод выбрать другой способ. Получателю аккаунт для чтения не нужен.
Нам кажется, Send удобнее оценивать как продолжение привычного рабочего места, а не как универсальную замену любой одноразовой записке.
PrivateBin: не только пароли, но и логи с кодом
Представьте другой обмен: коллега присылает лог или фрагмент конфигурации. Тут уже хочется сохранить переносы строк, подсветку синтаксиса, нормальное форматирование. Минималистичная форма для пароля может оказаться тесновата.
PrivateBin вырос из ZeroBin и ближе по характеру к защищённому Pastebin. Он шифрует и расшифровывает содержимое в браузере, хранит ключ в #-фрагменте, поддерживает Markdown и подсветку кода. Его можно развернуть у себя, в том числе через Docker, и оставить обмен внутри своей инфраструктуры.
Обратная сторона — настройка и обслуживание теперь тоже ваши. А у публичного инстанса свои лимиты, версия и администратор. Название проекта одинаковое; условия использования могут заметно различаться. С поведением ботов предпросмотра, кстати, та же история: смотреть надо на конкретный инстанс и его версию.
Для разработчиков это зачастую уместный набор возможностей. Для человека, которому нужно один раз получить пароль от кабинета, интерфейс редактора может быть лишним. Это не недостаток сам по себе — просто задача другая.
И вот что объединяет все пять вариантов, включая Privnote: одноразовая ссылка сокращает срок жизни секрета в хранилище, но не отбирает у получателя буфер обмена, скриншот или возможность сохранить текст. Выбирайте способ передачи под задачу, а права доступа и срок действия самого пароля настраивайте отдельно. Записка исчезла — доступ к системе от этого сам не отозвался.