Слоган не проверить. Трафик — можно.
Многие судят о странице «онлайн-шифрования» по одной фразе: считается в браузере, ничего не уходит на сервер, сквозное шифрование. Такие слова могут стоять на любом сайте — в том числе на том, который делает POST файла на сервер и шифрует уже там. Это не доказательство.
На самом деле видно только то, какие запросы уходят из этой вкладки. Панель Network показывает метод, адрес, строку запроса, тело и часть статистики. Если там появляется только что выбранное имя файла, пароль или известная лишь вам «канарейка», локального шифрования уже нет.
Обратное верно лишь в узком смысле. Чистый Network говорит только, что в этом запуске эти поля не ушли как рабочие данные. Это не доказывает, что в памяти нет открытого текста, что расширение не читало буфер обмена и что следующая версия поведёт себя так же. Ценность в другом: непроверяемую рекламу превратить в повторяемое наблюдение.
Что на самом деле значит «локально»
«В браузере локально» — это не «этот домен выглядит надёжным», а «шифрование и расшифровка происходят во вкладке, которую вы сейчас смотрите». Для AES-256-GCM обычный верный путь — Web Crypto API: вывод ключа, шифрование и тег подлинности выполняются в криптографическом интерфейсе браузера, а не отдаются удалённому API вместе с открытым текстом.
Типичный сценарий с файлом: вы выбираете локальный файл, скрипт читает его в памяти двоичными блоками, шифрует каждый блок, затем браузер скачивает шифротекст. Файл .lock или .enc — это результат, а не квитанция о загрузке. Лимит 5 ГБ на один файл описывает локальную потоковую обработку, а не сервер, который принял 5 ГБ открытого текста.
Ещё отделите «рабочую отправку» от «запросов, которые страница делает всегда». Сайт инструментов без регистрации всё равно подгружает стили и скрипты и может отправлять аналитику без тела сообщения. Такие запросы не доказывают, что файл ушёл на сервер. Если же в query или теле аналитики появляется только что введённый пароль — это уже другой вывод.
Проверяемая формулировка лучше прилагательных: исходный текст и ключи генератора паролей, проверки сложности, очистки данных и шифрования файлов по умолчанию остаются в браузере; одноразовая ссылка может отправить только шифротекст, а ключ расшифровки лежит во фрагменте URL #. MakePwd реализует инструменты в этих границах: всеми можно пользоваться без аккаунта. Обещание всё равно остаётся обещанием. Network превращает его в чек-лист.
Не проводите эксперимент на настоящих ключах, номерах документов или таблицах без обезличивания. Возьмите небольшой файл, который можно выбросить, и одноразовую длинную фразу. Вы проверяете трафик, а не раскрываете данные ещё раз.
Повторяемая проверка в Network
Сначала выберите метку, которой не бывает в настоящей работе. Имя файла — canary-local-2026.xlsx, пароль — случайная длинная фраза, в содержимом — одно предложение, которое есть только в этом эксперименте. Канарейка нужна для поиска: вставьте её в фильтр Network. Совпадение — провал.
Откройте DevTools, перейдите в Network, включите Preserve log и отфильтруйте XHR / Fetch. Смотрите не только успешные запросы: отменённые или с кодом 4xx уже могли унести открытый текст.
Затем выполните действие целиком: выберите файл, введите пароль, нажмите «шифровать» или «создать». Панель не закрывайте и проверьте три места ниже.
- Сначала вставьте канарейку в фильтр и посмотрите, нет ли красного совпадения. Если есть — остановитесь и прочитайте этот запрос. Не продолжайте решать «на ощупь», локально это или нет.
- Если совпадений нет, откройте каждый XHR / Fetch и сверьте строку запроса, query и тело. Статику, шрифты и скрипты можно пропустить.
- Отдельно отфильтруйте пути аналитики и откройте query и тело. Заголовок страницы и путь могут быть. Только что введённый пароль, проверяемый пароль, исходный текст до очистки и содержимое файла — нет.
Смотрите строку запроса
Path и запрос после ? стоит читать посимвольно. Локаторы вроде id могут быть. Имена файлов, пароли, проверяемый пароль и ключ после # — нет. Сверьте всю адресную строку со строкой запроса: если часть после решётки попала в запрос, реализация приняла fragment за query либо скрипт сам прочитал её и дописал в запрос.
Смотрите тело запроса
Тело POST / PUT — второе место. Если шифрование файлов заявлено как локальное, в теле не должно быть байтов исходного файла и пароля. В одноразовой ссылке может быть поле шифротекста — это ожидаемые исходящие данные; убедитесь, что оно не похоже на только что введённый текст. Если страница проверки пароля делает POST проверяемого пароля — хоть «поиск утечек», хоть «оценка силы» — он уже покинул устройство.
Аналитику смотрите отдельно
Статистику посещений легко пропустить. Чистый рабочий API при отчёте, в котором уехал весь ввод, всё равно проваливает критерий «открытый текст остался в браузере». Фильтруя пути аналитики, не считайте, что «скрипт статистики безвреден»: это ещё один исходящий запрос, и проверяется он так же, как рабочий интерфейс.
Включите Preserve log. После шифрования переход или обновление страницы могут стереть первый запрос с открытым текстом, если галочка снята, и вы получите ложно пустую панель.
Вопрос после «?» уходит в HTTP, решётка по умолчанию нет
В URL две части, которые часто смешивают. Запрос после вопросительного знака попадает в строку HTTP-запроса: его видят сервер, обратный прокси и журналы доступа. Фрагмент после решётки браузер по умолчанию оставляет у себя, чтобы скрипт текущей страницы мог его прочитать, и не отправляет с этим запросом документа.
Поэтому если одноразовая ссылка кладёт ключ в #, при открытии s.html?id=...#ключ сервер по задумке видит только id, а не ключ. Это не отдельный криптопротокол, а обычное поведение fragment. У него есть граница: вставите полный адрес в заявку, чат или редирект, который отбрасывает hash, — и ключ из «не в HTTP» превращается в «на чужом экране и в чужих логах».
Проверка такая же конкретная: создайте тестовую одноразовую ссылку и убедитесь, что в теле запроса создания только шифротекст; откройте страницу чтения и проверьте, что в запросе документа и последующих API есть только id. Содержимое после # в адресной строке не должно появляться в этих запросах. Страница чтения открыта получателю, вход не нужен.
| Куда смотреть | Попадает ли в HTTP | Что считается проходом |
|---|---|---|
| Слоган на странице | Не участвует | Не доказательство, только для сравнения |
| Строка запроса / query | Да | Нет канарейки, нет пароля, нет ключа из fragment |
| POST body | Да | Нет исходного текста; одноразовая ссылка — только шифротекст |
Фрагмент URL # |
Обычно нет | Есть в адресной строке, нет в строке запроса |
| Аналитика | Смотрите реализацию | Нет исходного текста из поля ввода |
Что можно доказать, а что нельзя
Вывод этой проверки узкий. Записать эту границу полезнее, чем её растягивать.
Можно утверждать: в этом браузере, в этой версии и в этом действии открытый текст, пароль и ключ из fragment не покинули вкладку как наблюдаемые рабочие HTTP-данные или исходный текст аналитики.
Нельзя утверждать: никакая другая вкладка или расширение не читает буфер обмена; папка загрузок безопасна; получатель не сделает снимок после расшифровки; проверка пароля покрывает все базы утечек. Если инструмент считает только локальную энтропию и открытый список Top слабых паролей, он отвечает на вопрос «похоже ли это на типичный слабый пароль», а не «никогда не встречалось в утечке». Это не проверка HIBP по всей сети. Как записать область действия и сразу посчитать строки списка, см. Что доказывает локальный список слабых паролей — и почему это не поиск по всем утечкам.
И не считайте это тестом на проникновение. Вы не смотрели WebSocket и кэш Service Worker и не разбирали обфусцированные скрипты. Цель — сказать коллеге: я открыл Network, искал канарейку, строка запроса и тело чистые. Это ближе к инженерному разговору, чем переслать фразу «на сайте написано, что ничего не загружается».
Те же шаги примените к инструментам MakePwd
Если нужна страница, где граница вычислений написана прямо, начните с шифрования файлов MakePwd. Без регистрации. Возьмите небольшой файл без настоящих личных данных, пароль-канарейку, зашифруйте и скачайте .lock. Смотрите Network: должны быть статика и, возможно, аналитика, но не исходный файл и не пароль как рабочие поля. По описанию сайта алгоритм — AES-256-GCM в Web Crypto, один файл до 5 ГБ.
Одноразовая ссылка — второе упражнение: создайте безобидный тестовый текст и убедитесь, что наружу уходит шифротекст. Страница чтения открыта получателю; вид ссылки — s.html?id={id}#{key}. Проверка пароля — упражнение «попадает ли поле ввода в аналитику»: проверяемый пароль по описанию продукта не загружается, сверка идёт по локальному списку.
Эти упражнения не доказывают, что какой-то сайт «абсолютно безопасен». Они делают один и тот же чек-лист привычным. На любой странице, которая обещает локальное шифрование, шаги те же: канарейка, Preserve log, строка запроса, тело, отчёт аналитики.
Три вещи, которые стоит запомнить в следующий раз
Первое: смотрите трафик, не слоган. Второе: исходящий шифротекст допустим, ключ и исходный текст — нет. Третье: сменив браузер, версию или функцию, снова поищите канарейку. В собственные заметки по безопасности стоит писать только то, что можно повторить.
Если дальше хочется понять, почему ключ можно класть после решётки, читайте Почему ключ после решётки в URL удобно класть и когда эта защита ломается. Здесь только вопрос «покинул ли открытый текст эту вкладку» превращён в проверку, которую можно закончить сразу.