Возьмите одно предложение из политики — то, из-за которого вы стали рассматривать провайдера, — и проследите его по всей системе. Обещание насчёт туннеля не описывает автоматически портал учётной записи, резолвер, почту поддержки или обработчика платежей. Большинство плохих сравнений возникает из-за того, что утверждение об одном компоненте читают и применяют к другому. Разбор ниже превращает эту привычку в короткий рабочий лист.

Следите за данными, а не за прилагательным

Заголовок вроде «никаких журналов активности» — это утверждение о категории, и полезный вопрос в том, какой компонент вообще мог бы создать эту категорию. Конечная точка туннеля видит адреса источника и отметки времени; резолвер видит запрошенные имена; система учётных записей видит личность и историю платежей; поддержка видит всё, что вы вставите в тикет. Две из них может обслуживать одна компания, а одна может быть подрядчиком.

Шифрование при передаче ничего не говорит о хранении, потому что конечная точка расшифровывает данные до того, как передать их дальше.

Сначала постройте карту компонентов

Напишите шесть строк: клиентское приложение, оператор конечной точки туннеля, DNS-резолвер, система учётных записей и биллинга, канал поддержки и любой получатель диагностики или отчётов о сбоях. В каждой строке отметьте, кто ею управляет и совпадает ли эта сторона с компанией, о которой вы читаете. Услуги под чужой маркой, подрядные службы поддержки и сторонняя аналитика чаще, чем кажется, делают ответ интересным.

Затем перечислите, к чему каждая компонента имеет технический доступ: адрес источника, идентификатор учётной записи, запрошенное имя, время подключения, переданный объём, сведения об устройстве, отправленный отчёт. Доступность — не хранение, но она показывает, какая часть политики должна отвечать на какой вопрос.

Сравните категории, цель, хранение и передачу

Утверждение, что места посещения не сохраняются, не охватывает отметки времени сеанса, а утверждение об агрегированной статистике не описывает сырые записи, которые её питали. Ищите точную категорию, заявленную цель, срок хранения и формулировку о передаче — именно в этом порядке. Там, где политика говорит «анонимно», проверьте, какие идентификаторы и какая точность времени удалены, вместо того чтобы принимать слово за объяснение.

Обратите внимание на разделы, которые действуют по продуктовым линиям. Расширение браузера, мобильный клиент и роутер одного бренда могут иметь разные пути данных, и политика может охватывать все три одной страницей общих фраз.

Руководство IETF по вопросам конфиденциальности — полезная структура здесь, потому что оно заставляет анализировать по компонентам, а не по маркетинговым фразам.

Оцените доказательства, которые вы принимаете

Открытый клиентский код описывает, что клиент делает с вашими данными, и мало говорит о серверной части, которая завершает туннель. Аудит охватывает заявленную систему за заявленный период, что полезно и уже, чем постоянная гарантия. Утверждение о юрисдикции — это утверждение о правовом процессе, а не о техническом журналировании. Каждое из них — доказательство определённого рода, и их смешение даёт самоуверенные выводы, которые через год никто не сможет защитить.

Шифрование при хранении защищает записи, которые всё ещё существуют, поэтому отвечает на другой вопрос, чем тот, существуют ли записи вообще.

Запишите, что осталось без ответа

Там, где в политике нет компонента или категория не рассматривается, напишите рядом «не объяснено». Это честный результат, и он полезнее, чем превращать молчание в гарантию или в обвинение. Держите версию и дату политики рядом со своими заметками, потому что эти документы меняются тихо, а сравнение без версии быстро устаревает.

Наконец, чётко скажите, что доказала ваша собственная проверка. Работающий выход и изменённый публичный адрес показывают маршрутизацию. Они ничего не говорят о хранении на стороне сервера, и именно в рабочем листе живёт это различие.

Похожие статьи