Конфиденциальность браузерных процессов на этапе проектирования

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

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

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

Определите задачу и ее границы

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

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

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

Установите границу для каждого этапа. Спросите, что предоставляет человек, что добавляет браузер, что сайту нужно вернуть и какое состояние должно сохраниться после этапа. Запрос разрешения, файл куки, загруженный файл или сохраненное предпочтение могут служить разным целям. Если свести их в одну общую категорию «данные браузера», будет сложнее выявить избыточный доступ или хранение.

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

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

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

Минимизируйте данные на протяжении всего процесса

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

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

Ищите ненужные повторы. Сайт может просить человека предоставить сведения, уже доступные в рамках текущей задачи, или процесс может хранить промежуточный результат после получения нужного итога. Проверьте, помогают ли повторы цели пользователя, надежности или необходимому пути восстановления. Если нет, удалите лишний этап или сократите срок хранения. Не сохраняйте копию только потому, что она когда-нибудь может пригодиться.

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

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

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

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

Предоставляйте пользователям понятный выбор

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

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

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

Используйте настройки по умолчанию, соответствующие обычной задаче и явно выраженным предпочтениям пользователя. Настройка по умолчанию может уменьшить число повторных решений, но не должна незаметно расширять сбор данных или превращать разовую потребность в постоянный доступ. Если у процесса есть существенно разные цели, предложите соответствующий выбор на этом этапе, а не переносите настройку дальше без объяснения.

Сделайте отказ реальным и понятным вариантом. Объясните, лишит ли отказ одной необязательной функции, приостановит ли задачу или потребует другого пути. Не называйте выбор необязательным, если без него задачу нельзя выполнить, и не подразумевайте, что согласие безвредно, если оно меняет будущий доступ. Человек должен иметь возможность принять решение, понимая непосредственные последствия и существенный срок действия.

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

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

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

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

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

Сохраняйте непрерывность там, где она необходима для цели пользователя. Для работы могут требоваться сохраненные предпочтения, сеанс аккаунта или результат незавершенной задачи. Перед очисткой или разделением состояния выясните, что от него зависит и можно ли получить тот же результат с меньшим объемом данных. Изменение конфиденциальности, которое неожиданно удаляет нужный путь восстановления, само может повлечь операционные издержки.

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

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

Учитывайте другие части среды, которыми профиль браузера не управляет. Сайт может связывать активность с аккаунтом, расширение имеет собственные разрешения, а управляемое устройство может применять правила организации. Граница профиля является лишь одним уровнем более широкой системы. Для задач с несколькими аккаунтами или контекстами укажите, какие границы контролируются локально, а какие зависят от сайта или сервиса.

Проверяйте, пересматривайте и адаптируйте проектирование

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

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

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

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

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

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

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

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

Публичные источники

• W3C: принципы конфиденциальности
• RFC 6973: вопросы конфиденциальности в интернет-протоколах