Політика конфіденційності VPN проти шляху даних: порівняльний розбір

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

Стежте за даними, а не за прикметником

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

Шифрування під час передавання нічого не говорить про зберігання, бо кінцева точка розшифровує дані перед тим, як передати їх далі.

Спершу побудуйте карту компонентів

Напишіть шість рядків: клієнтський застосунок, оператор кінцевої точки тунелю, DNS-резолвер, система облікових записів і білінгу, канал підтримки та будь-який отримувач діагностики чи звітів про збої. У кожному рядку зазначте, хто ним керує і чи ця сторона є тією самою компанією, про яку ви читаєте. Послуги під чужою маркою, підрядні служби підтримки та стороння аналітика частіше, ніж здається, роблять відповідь цікавою.

Далі перелічіть, до чого кожен компонент має технічний доступ: адреса джерела, ідентифікатор облікового запису, запитане ім'я, час підключення, переданий обсяг, відомості про пристрій, надісланий звіт. Доступність — не зберігання, але вона показує, яка частина політики має відповідати на яке питання.

Порівняйте категорії, мету, зберігання та передачу

Твердження, що місця відвідування не зберігаються, не охоплює позначок часу сеансу, а твердження про агреговану статистику не описує сирих записів, які її живили. Шукайте точну категорію, заявлену мету, строк зберігання та формулювання про передачу — саме в цьому порядку. Там, де політика каже «анонімно», перевірте, які ідентифікатори та яку точність часу вилучено, замість того щоб приймати слово за пояснення.

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

Настанови IETF щодо міркувань конфіденційності — корисна структура тут, бо вони змушують аналізувати за компонентами, а не за маркетинговими фразами.

Оцініть докази, які ви приймаєте

Відкритий клієнтський код описує, що клієнт робить з вашими даними, і мало говорить про серверну частину, яка завершує тунель. Аудит охоплює заявлену систему за заявлений період, що корисно й вужче, ніж постійна гарантія. Твердження про юрисдикцію — це твердження про правовий процес, а не про технічне журналювання. Кожен із них — доказ певного роду, і їх змішування дає самовпевнені висновки, які через рік ніхто не зможе захистити.

Шифрування під час зберігання захищає записи, які ще існують, тож відповідає на інше питання, ніж те, чи існують записи взагалі.

Запишіть, що лишилося без відповіді

Там, де в політиці немає компонента або категорія не розглядається, напишіть поруч «не пояснено». Це чесний результат, і він корисніший, ніж перетворювати мовчання на гарантію чи на обвинувачення. Тримайте версію та дату політики біля своїх нотаток, бо ці документи змінюються тихо, а порівняння без версії швидко старіє.

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