Записи, збереження чи майбутнє журналювання: який запит?
Запит щодо вже наявних записів, вимога збереження та розпорядження про майбутній збір — це три різні операції. Спершу прочитайте, яку з них дозволяє документ.
Заголовок повідомляє, що провайдера VPN зобов'язали видати записи, а коментарі роблять висновок, що тепер кожен VPN має вести журнали. Документ за заголовком міг запитувати вже наявні записи, міг просити провайдера зберегти те, що є, до отримання подальшої процедури або дозволяти збір певних атрибутів у майбутньому. Це три різні операції з трьома різними межами. Прочитайте, яку з них виконує документ, перш ніж робити висновок.
Три операції, які називають повісткою
Слово в заголовку зазвичай категоріальна помилка, а не брехня. Запит наявних записів, вимога збереження та дозвіл на перспективний збір надходять як юридичні папери, і вони не взаємозамінні. Кожен називає іншу дію, інший проміжок часу та інше коло отримувачів. Прочитати, який застосовується, займає хвилину і запобігає більшості поганих висновків.
| Operation | What it asks for | What it does not do |
|---|---|---|
| Records request | Information already held by the provider | Create data that was never collected |
| Preservation | Keep existing records while process continues | Disclose them to the requester |
| Prospective collection | Capture specified attributes going forward | Read the contents of communications |
Ця таблиця — допоміжний засіб для читання, а не правова таксономія, і важливий конкретний інструмент. Класифікація сервісу, його юрисдикція та інформація, названа в документі, змінюють аналіз, тому корисне питання завжди таке: "яка операція, за який період, для яких категорій".
Те, що вже існує, — інше питання
Для прикладу зі Сполучених Штатів 18 USC 2703 передбачає різні шляхи для комунікацій і для клієнтських записів, а підрозділ (c)(2) визначає певну інформацію про абонентів, доступну за визначеною процедурою. Він не стверджує, що кожен вид інформації доступний тим самим інструментом.
Саме на цю відмінність політика конфіденційності не може відповісти за вас. Заява про збереження історії перегляду може нічого не казати про обліковий запис, платіжний запис чи звернення до підтримки, бо це різні категорії з різним збереженням.
Тому читайте політику як перелік категорій, а не як єдину обіцянку. Питайте, які записи існують, як довго і під чиїм контролем, і ставтеся до "ми не ведемо журналів" як до твердження про одну категорію, доки провайдер не скаже інше. Потім запитайте, яку категорію запит насправді називає. Розбіжність між цими двома відповідями — це місце, де більшість публічних суперечок про журналювання VPN ідуть не туди.
Збереження — це не розкриття
Збереження просить провайдера тримати докази, які в нього вже є, до отримання подальшої процедури. Воно не передає ці докази нікому й не створює нового потоку записів. Цю відмінність легко втратити в резюме, де сказано, що провайдеру "наказано зберігати дані".
Для людини, яка читає новину, це означає, що розпорядження про збереження не є доказом того, що провайдер змінив практику збору. Для оператора, який його отримує, це означає, що обов'язок стосується не знищувати щось, і це набагато вужча дія, ніж побудова конвеєра.
Обидва прочитання ведуть до одного практичного правила: заморозьте відповідний стан і припиніть його змінювати, доки кваліфікована особа не розгляне запит. Поспішне видалення й поспішний збір — обидва способи погіршити ситуацію. Письмова нотатка про те, що існувало на момент надходження вимоги, цінніша за будь-яку пізнішу реконструкцію.
Майбутній збір має власні повноваження
Перспективний збір — знову окремий механізм. У Сполучених Штатах розпорядження про pen register і trap and trace за 18 USC 3123 стосуються дозволу, визначених атрибутів комунікацій, сприяння, строків і нерозголошення, тоді як визначення у статті 3127 виключають зміст комунікацій із цих категорій.
Це виключення і є та частина, яку люди пропускають, коли роблять висновок, що розпорядження дозволяє читати повідомлення. Категорія стосується атрибутів, а не змісту, і закон конкретний щодо того, що він охоплює. Чи вписується конкретний запит у цю межу — питання для юриста, а не для запису в блозі.
З цього також випливає, що звичайна політика відсутності журналів у провайдера не є правовим щитом. Політика описує, що збирається за замовчуванням; обов'язок описує, що треба зробити за чинним інструментом. Обидва твердження можуть бути правдивими одночасно і все ж суперечити на практиці.
Що робити, коли запит надходить
Негайно передайте документ відповідальному перевіряльнику і збережіть його точно в тому вигляді, в якому отримано, включно з заголовками та вкладеннями. Занотуйте строки, умови конфіденційності та названі категорії, бо ці три факти визначають усе подальше.
Не складайте зміну збору або видалення з онлайн-резюме. Не повідомляйте постраждалого користувача, доки не перевірили, чи застосовується нерозголошення, і не припускайте, що воно застосовується, не прочитавши інструмент.
Якщо ви обираєте провайдера, а не керуєте ним, читайте політику даних поруч із його звітом про прозорість і помічайте прогалини. Відсутність опублікованих запитів не є доказом того, що вимоги технічно неможливі, а опублікована політика не є доказом того, що іншої категорії не існує.