Реальная против видимой приватности: вопросы, которые стоит себе задать

Разница между архитектурной приватностью и декларативной приватностью

На протяжении семи предыдущих статей этого цикла мы прошли через различные слои одного и того же вопроса. Право международных передач со Schrems II. Математическую идею криптографического хеша, который скрепляет каждый Cuaderno. Архитектурный выбор kill switch и институциональный захват, который почти всегда его сопровождает. Механизм сквозного шифрования и операционный вопрос о том, где находятся ключи. Согласование стимулов в соответствии с бизнес-моделью. Самосуверенную криптографическую идентичность. Самостоятельное размещение как пропорциональную стратегию. Каждая статья занималась одним углом зрения. Эта, последняя в цикле, сводит их в один опросник.

Различение, которое стоит запомнить, простое: есть сервисы, чья приватность архитектурна, и есть сервисы, чья приватность декларативна. Первая встроена в технический дизайн: определённые нарушения обязательства о приватности технически сложны или невозможны, потому что архитектура их не допускает. Вторая заложена в текст правового уведомления: определённые нарушения были бы договорно наказуемы, если бы произошли, но технически ничто их не препятствует. Обе модели могут соответствовать ОРЗД; но одна защищает по конструкции, а другая защищает по обещанию, и разница операционно огромна.

Вопросы, которые следуют далее, разработаны, чтобы отличить один случай от другого. Это не продвинутые технические вопросы. Это вопросы, на которые любой честный поставщик может ответить в своей публичной документации. Качество и точность ответа говорят о продукте столько же, сколько сам ответ. Вопросы сгруппированы в шесть слоёв; стоит задать их все, прежде чем принимать сервис для чувствительных данных, а не только те, которые идентифицирует первый инстинкт.

Слой 1: архитектура

Прежде чем продолжить, уточним один термин. Под оператором мы понимаем компанию, предоставляющую услугу: субъект, который контролирует серверы и программное обеспечение, а не конкретного человека. С этим уточнением главный архитектурный вопрос таков: что оператор делает с содержимым между отправителем и получателем? Возможны три ответа, и их стоит уметь различать, потому что все три порой рекламируются схожими словами.

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

Разница между этими тремя не по степени: она по типу.

Дополнительный вопрос — уже сформулированный в Cuaderno о шифровании — таков: кто имеет криптографические ключи, позволяющие читать контент? Если их имеет пользователь и только пользователь, шифрование реально. Если их имеет ещё и оператор в любой форме — даже под названием «восстановление учётной записи» или «синхронизация между устройствами» —, шифрование номинально. Вопрос не допускает честного промежуточного ответа.

Слой 2: бизнес-модель

Вопрос о бизнес-модели важит столько же, сколько архитектурный вопрос, и по той же сущностной причине: стимулы производят с течением времени систематически различные продукты даже при идентичных заявленных целях. Как зарабатывает деньги сегодня оператор? Один источник, два, смесь? Если финансирование включает рекламу или монетизацию данных, какие данные монетизируются и на каком правовом основании ОРЗД это делается? Покрывает ли цель, заявленная в правовом уведомлении, данные третьих лиц, которые специалист намерен доверить сервису?

И вопрос второго порядка, не всегда сформулированный: каково финансовое положение оператора в перспективе трёх-пяти лет? Компания в фазе венчурного капитала работает под иным давлением, чем компания со стабильной рентабельностью. Смена модели финансирования — это, неоднократно, момент, когда неявный договор с пользователями переписывается без переговоров.

Слой 3: юрисдикция

Для европейского специалиста вопрос юрисдикции не риторичен. В какой юрисдикции зарегистрирован оператор? В какой стране физически расположены серверы, обрабатывающие данные? Ответ на два предыдущих вопроса один и тот же или разный, и если различается, какое законодательство применяется? Европейский регион, управляемый американской компанией, не является, для целей Schrems II, европейским ответом: компания подчинена FISA 702 независимо от того, где находятся серверы.

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

Слой 4: оператор и kill switch

Какую техническую способность сохраняет оператор, чтобы приостановить, заблокировать, удалить или ухудшить сервис на расстоянии? Вопрос не параноидальный: он операционный. Цифровые платформы неоднократно применяли эту способность в последние годы, иногда по собственной инициативе, иногда по предписанию правительств, иногда после смены собственности или политики. Если способность существует, стоит знать, при каких договорно заявленных предпосылках она применяется, и сохранить запас для незаявленных предпосылок, которые практика последних лет показала не менее значимыми: неожиданное судебное предписание, международная санкция, смена корпоративного руководства, поглощение субъектом с другой политикой.

Родственный вопрос — это вопрос плана непрерывности: если бы оператор применил способность против специалиста — по любой причине, справедливой или нет —, какое время активности осталось бы доступным, какая процедура экспорта данных существует и к какому альтернативному поставщику можно было бы мигрировать? Если ответ начинается с «этого не должно произойти», это не операционный ответ; это обещание.

Слой 5: идентичность и доступ

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

Что происходит с данными специалиста, если специалист теряет доступ? Существуют ли механизмы восстановления — учётной записи, файла, сессии —, зависящие от оператора? Совместимы ли эти механизмы с профессиональной деонтологией отрасли, если оператора принудят их использовать?

Слой 6: будущее

Этот последний слой часто упускают из виду, потому что он требует проекции. Что произошло бы, если бы сервис был приобретён другой компанией? Почти все поглощения влекут за собой пересмотр условий сервиса в последующие месяцы. Что произошло бы, если бы регуляторные требования изменились? Европейское право увеличило обязательства по изъятию и блокировке с 2022 года, а не уменьшило их. Что произошло бы, если бы оператор исчез? Значительная часть облачных сервисов не имеет задокументированного плана выхода для сценария закрытия оператора; специалист обнаруживает проблему, когда уже нет времени её подготовить.

Есть формулировка, которую стоит запомнить для этого слоя: архитектуры, которые меньше зависят от оператора, более устойчивы к изменениям оператора. Самостоятельное размещение в любой из его разновидностей, самосуверенная криптографическая идентичность, коммуникации без сервера посередине — все они уменьшают будущую поверхность риска посредством процедуры уменьшения нынешней поверхности зависимости. Они её не устраняют; они её уменьшают.

Разница между структурой и обещанием

Если бы нам пришлось дистиллировать цикл в одно предложение, оно было бы таким: структурные ответы сохраняются, даже если оператор, администрация или законодательство изменятся; ответы через обещание сохраняются, пока тот, кто обещает, может и хочет их сохранять. Оба могут быть правильными в момент принятия. Лишь один из двух держится независимо от хода времени и изменения обстоятельств.

Это не означает, что каждый специалист должен требовать структурных ответов от всех сервисов, которые он принимает. Пропорциональность остаётся легитимной: электронная таблица для внутренней бухгалтерии не нуждается в таком же ответе, как медицинская карта пациента. Это означает, однако, что профессионализм состоит в том, чтобы знать, какой тип ответа был принят в каждом случае, и сознательно решить, что этот тип ответа пропорционален конкретным данным.

Опросник, упорядоченный

Двенадцать конкретных вопросов, которые синтезируют цикл, упорядоченных так, чтобы ответ на каждый информировал следующий:

1. Проходит ли контент через сервер оператора? Если проходит: в открытом виде, зашифрованным ключами оператора или зашифрованным ключами, принадлежащими исключительно пользователю?
2. Если ссылаются на сквозное шифрование, где находятся криптографические ключи? Знает ли или хранит ли оператор какую-либо их часть в любой форме, включая «восстановление»?
3. Какие метаданные генерирует и хранит сервис? Как долго? Кому они видимы?
4. Как финансируется оператор? Если финансирование включает рекламу или монетизацию данных, покрывает ли заявленная цель данные третьих лиц, доверенные специалистом?
5. Каково финансовое положение оператора в перспективе трёх-пяти лет? Есть ли факторы, указывающие на неминуемую смену модели (предстоящий выход на биржу, исчерпывающийся раунд финансирования, вероятное поглощение)?
6. В какой юрисдикции зарегистрирован оператор? В какой стране физически расположены серверы? Если они различаются, какое национальное законодательство применяется к обработке?
7. Что произошло бы, если бы действующее в юрисдикции оператора разведывательное предписание потребовало выдать мои данные? Могла бы компания исполнить его технически?
8. Какую техническую способность сохраняет оператор, чтобы приостановить, заблокировать или удалить сервис? При каких договорных предпосылках? При каких исторически задокументированных недоговорных предпосылках?
9. Какой план выхода существует, если бы оператор применил эту способность против меня, справедливо или несправедливо? Есть ли задокументированная процедура экспорта данных к альтернативному поставщику?
10. Кто контролирует учётные данные доступа? Может ли оператор восстановить их без моего участия? Это меня защищает или подвергает риску?
11. Существует ли европейская, самостоятельно размещённая или без сервера посередине альтернатива для этой конкретной функции? Какова её реальная стоимость по сравнению с оценённым риском?
12. Если бы сегодняшнее решение было рассмотрено через пять лет инспектором, аудитором или клиентом, пострадавшим от утечки, был бы нынешний выбор защитимым имеющимися сегодня аргументами или потребовал бы извинений за то, что не были заданы разумные вопросы?

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

---

Этой статьёй мы закрываем второй цикл Cuadernos Lacre. Мы начали с редакционного долга, унаследованного от Schrems II, и завершаем операционным опросником. По пути мы прошли через понятия — хеш, шифрование, идентичность — и прикладные анализы — kill switch, бизнес-модель, self-hosting. Заявленное редакционное намерение издания состояло не в том, чтобы перегрузить читателя исчерпывающим перечнем проблем, а в том, чтобы дать ему инструменты, чтобы он различал, перед любым новым сервисом, какой тип ответа он принимает. Это различение — между архитектурой и обещанием — и есть инструмент. Остальное каждый специалист поставит на службу тем данным, которые в своей практике сочтёт достойными этого вопроса.