Кратко

  • RFC 3693 отдельно назвала Target, Rule Maker, Rule Holder, Generator, Server, Recipient и Viewer, не сводя раскрытие геоданных к обмену двух сторон.
  • Объект местоположения мог нести правила приватности, но каждый объект не обязан был их включать, а полная система управления правилами осталась за рамками документа.

Координаты отвечают на вопрос «где?». Они не показывают, кто их получил, чьё местоположение описывают, кто вправе его видеть, с какой точностью, а также может ли получатель хранить или пересылать данные. Именно эти недостающие глаголы GEOPRIV стремилась сделать видимыми.

RFC 3693 вышла в феврале 2004 года как документ со статусом Informational. Она разделила службу геолокации на роли. Target — человек или иная сущность, чьё местоположение передаётся. Rule Maker задаёт правила доступа — обычно это сам Target, но не обязательно: в документе приводятся примеры родителя и работодателя. Rule Holder хранит и предоставляет правила. Location Generator получает координаты и создаёт объект. Location Server принимает его, применяет правила и распространяет разрешённый результат. Location Recipient получает данные, а Viewer использует их, не пересылая дальше. Data Transporter может просто передавать данные без обработки. Одно устройство может совмещать несколько ролей.

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

Объект местоположения должен был нести больше, чем координаты, но от этого не становился автоматически исполняемым предписанием. RFC 3693 требует, чтобы объект позволял третьей стороне применять правила, и говорит, что он должен уметь переносить ограниченный базовый набор. Однако определение допускает сведения о местоположении «и, возможно, правила приватности»: включать правила в каждый экземпляр не обязательно. Решение Server о раскрытии должно опираться на правила Rule Maker.

Даже Generator, не имеющий полного набора правил, обязан следовать его инструкциям; Viewer должен получать лишь ту часть правил, которая нужна для корректной обработки.

Границы документа сформулированы прямо. Управление правилами и способ доступа Server к ним не определены. Выразительность языка правил оставлена открытой. У ограничения срока хранения могут быть неоднозначные технические последствия, а его смысл может зависеть от местного права или обычая. Правила нужно аутентифицировать и защищать, но распределение ключей и подробные механизмы не входят в сферу RFC. Защита самого объекта также не предотвращает анализ трафика других заголовков и объектов.

Последующие документы показывают развитие спецификаций, а не универсальное внедрение. RFC 4119 определила формат объекта местоположения на основе PIDF; RFC 4079 описала архитектуру presence. В 2011 году RFC 6280, опубликованная как BCP 160, обновила RFC 3693 и RFC 3694 и расширила требования до более полной архитектуры. HELD, передача местоположения через SIP и разыменование URI задали отдельные способы получения, передачи и извлечения геоданных.

Исторический результат скромнее утверждения «Интернет решил проблему приватности местоположения». RFC 3693 сделала видимой плоскость контроля: кого локализуют, кто пишет правила, где они хранятся, кто их применяет, какая точность раскрывается и что получатель может делать дальше. Документ требований способен обозначить границы, но не доказывает, что конкретная служба их реализовала, получатель соблюдал правила или человек остался анонимным.

Источники