Хороший способ снизить риск для пользователей — не хранить о них конфиденциальные данные, которые вам не нужны и которые влияют на их конфиденциальность. Существует удивительное количество способов сделать это, одновременно достигая своих бизнес-целей, и стоит рассмотреть каждый из них. Ты мог бы:
- Объясните, для чего вам нужны данные.
- Собирайте данные с более низкой степенью детализации.
- Удалите данные после использования.
- Не собирать его в первую очередь.
Каждый из этих подходов может помочь вашим пользователям чувствовать себя более комфортно в отношении того, что вы делаете и почему, и это в значительной степени способствует вашим отношениям с ними. Прозрачность укрепляет доверие, и, что немаловажно, доверие может стать для вас уникальным преимуществом. Многие люди предполагают, что пользователи и клиенты доверяют им по умолчанию, но потребители постоянно оценивают продукты и услуги, и это может быть не так. Если вы строите отношения со своими пользователями, при которых они доверяют вам обращаться с их данными и вашим взаимодействием с уважением, это может дать вам конкурентное преимущество как проекту или бизнесу: это то, с чем ваши конкуренты могут не сравниться, это настоящее отличие. .
Давайте раскроем приведенные выше подходы в порядке от наиболее эффективных (но также наиболее влияющих на ваш бизнес) до наименее эффективных, но наименее разрушительных для реализации.
Не собирайте его в первую очередь
Самый очевидный способ избежать компрометации данных ваших пользователей — не собирать их. Сбор определенных данных необходим для предоставления услуг, но существует больше мест, где можно избежать сбора данных, чем вы думаете. Рассмотрим, например, гостевую кассу. Когда пользователи приходят покупать что-то с помощью вашего веб-приложения, вы можете потребовать от них зарегистрировать учетную запись, потому что тогда вы сохраните личные данные для последующего выполнения: их можно добавить в список рассылки, они уже прошли предварительную квалификацию. как заинтересованный клиент и так далее. Однако клиенты это признают, и им это не нравится: в 2021 году исследование показало, что каждая четвертая отмененная продажа произошла из-за того, что сайт потребовал от пользователя создать учетную запись. Если вам не требуется учетная запись, у вас больше шансов сохранить этих клиентов. Возможность совершить покупку без регистрации дает пользователям больше возможностей, а также означает, что у вас не так много их данных, которые нужно защищать.
«Фуззинг» ваших данных
Конечно, отказ от сбора данных вообще может оказаться невозможным. Важно собирать данные для предоставления услуг и принятия разумных бизнес-решений. Также может быть полезно выстроить маркетинговые коммуникации в контексте доверительных отношений. Однако также важно понимать, что решения, принимаемые в совокупности (то есть затрагивающие одновременно множество пользователей), принимаются в отношении данных в совокупности (то есть в отношении коллективных свойств данных).
Например, иногда полезно иметь представление о демографии вашей аудитории: к каким возрастным группам они относятся, местонахождению и т. д. Это может изменить ваше послание или ваш подход. Но это не значит, что вам нужно собирать точный возраст каждого пользователя вашего сервиса. Часто вам нужны тенденции и общие свойства. Если на решение, которое вы хотите принять, влияет то, относится ли большая часть вашей аудитории к «ключевой демографической группе 18–34 лет», тогда единственный вопрос, который вам действительно нужно задать, — это принадлежат ли ваши пользователи к этой демографической группе. Это собирает их в два «ведра»: в ту группу и не в ту группу. Могут возникнуть ситуации, когда вам потребуются более подробные данные, но вполне разумно взять список демографических данных, которые вы используете для принятия решений, и попросить пользователей классифицировать себя с помощью этого списка.
Пример
Итак, если вам полезно знать, как ваша пользовательская база делится на возрастные категории «18–34», «35–49», «49–64» и «65+», то вы можете попросить своих пользователей сделать выбор. в какую из этих категорий они попадают. Соблазнительно запросить чрезвычайно подробные, персонализированные и персонализированные данные, а затем самостоятельно классифицировать своих пользователей, поскольку это позволяет избежать необходимости задавать один и тот же вопрос более подробно позже; например, чтобы запросить точный возраст и дату рождения, а затем использовать это для создания собственных списков количества пользователей в категории «35–49». Но важно понимать, как это выглядит: как уже было рассмотрено в курсе и будет рассмотрено снова, запрос на подробные уровни данных может вызвать у людей дискомфорт и, таким образом, снизить доверие пользователей к вашей организации, одновременно увеличивая риск.
Также важно учитывать ваши потребности в данных. Иногда «потребность» в более подробных данных носит спекулятивный характер и является требованием «на всякий случай». Возможно, сейчас нам нужно только классифицировать пользователей по этим четырем возрастным группам, но в будущем мы, возможно, захотим сузить это, и поэтому нам следует собирать очень подробные данные сейчас, чтобы оставить эту опцию открытой на будущее. Возможно, стоит задуматься о том, как часто в прошлом более детальные данные использовались для принятия решений. Запрос данных, которые воспринимаются как инвазивные по сравнению с предлагаемой услугой, обязательно приводит к снижению степени доверия пользователей к вашей организации. Если эти данные собираются «на всякий случай», то вы, возможно, не просто жертвуете доверием пользователей ради более эффективных бизнес-решений, но обмениваете его просто на возможность какого-то теоретического будущего решения, которое может даже не существовать, одновременно принимая во внимание о требованиях безопасности для этой информации.
Существуют и более подробные алгоритмические способы снижения детализации собираемых данных. Методы рандомизированного ответа означают, что данные собираются с настраиваемой степенью неточности, и они десятилетиями использовались в социальных науках при сборе потенциально инвазивных или конфиденциальных данных при сохранении конфиденциальности респондента. Вышеупомянутый метод сбора данных предполагает расширение ответов пользователя (так что «сколько вам лет» становится «к какой из следующих возрастных групп вы относитесь»), где рандомизированный ответ предполагает, что определенная часть пользователей лжет о своих ответах. Если известна доля пользователей, ответивших неправильно, на основе собранных данных все равно можно сделать значимые выводы, но конфиденциальность отдельных пользователей не будет поставлена под угрозу, поскольку собранные ими данные могут быть неверными. В этом случае, если 80% вашей аудитории по-прежнему заявляют, что они относятся к возрастной группе 18–34 лет, вы можете быть относительно уверены, что это все еще самая большая доля, даже если 10% из них намеренно дают неправильные ответы. Степень неправильности также можно изменить программно, при этом правильные ответы всегда запрашиваются, но программное обеспечение изменяет определенный процент ответов перед передачей. Этот процесс и его последствия также можно объяснить пользователям при сборе данных: это означает, что пользователям не нужно верить, что вы не будете злоупотреблять их собранными данными, поскольку отдельные данные ненадежны.
Похожий, но более технически сложный процесс – это дифференцированная конфиденциальность . При этом используются математические методы для изменения хранилища данных так, чтобы совокупные свойства данных все еще присутствовали, но невозможно даже сказать, предоставил ли конкретный человек данные или какие именно данные он предоставил. Как и случайный ответ, это защищает данные пользователей даже от вас и демонстрирует четкое намерение с вашей стороны: вы не можете использовать данные своих пользователей, если у вас их нет.
Эти и подобные подходы также обеспечивают повышенную безопасность от взлома и утечки данных, поскольку собранные данные уменьшают угрозу конфиденциальности пользователей, в том числе и вас, а также снизят уровень компрометации в случае утечки данных. Однако помните, что если вы применяете на сервере методы дифференциальной конфиденциальности (то есть ваши пользователи отправляют вам неагрегированные данные, а затем вы используете методы для их агрегирования), вам все равно необходимо защитить эти необработанные пользовательские данные, а затем удалить их после обработки, а также иметь и соблюдать четкие политики, подтверждающие, что вы не используете их перед агрегацией (или четко понимать, для чего вы их используете).
Хранение: собирайте данные, а затем удаляйте их после использования.
Полезно помнить, что собранные данные имеют жизненный цикл; он собирается, используется, чтобы помочь вам принимать деловые решения, а затем, в какой-то момент, его следует удалить. Это, опять же, компромиссы: когда вы задаете пользователям вопросы или сохраняете информацию о других веб-сайтах, которые они посещали, или отслеживаете, какие вещи они просматривали и как долго, чтобы сделать прогноз об их предпочтениях, это данные, которые предоставляются вам для конкретной цели, а не в качестве бессрочного гранта, который разработчик может использовать по своему усмотрению. Когда эти данные больше не нужны для этой цели — иногда через минуту, иногда через много лет — их следует удалить.
Всякий раз, когда вы собираете информацию о своих пользователях, вы должны знать, для чего вы будете использовать эти данные (см. ниже), а также знать, когда и почему вы перестанете хранить эти данные. Это может произойти, когда пользователь решает удалить его, или когда он выходит из системы, по истечении определенного периода времени или после того, как произошло определенное событие. Отличный способ укрепить доверие в отношениях — объяснить вашим пользователям, как они могут контролировать данные о них, включая, где это возможно, односторонний отказ. Как они удаляют свои данные? Как они удаляют свой аккаунт? Помимо помощи в построении таких отношений, лучше всего хранить данные столько, сколько вам нужно для их обработки, а не дольше, и чтобы у ваших пользователей была возможность видеть и удалять данные, которые вы собираете у них или на их имени. На территориях, где вы работаете, даже может быть законодательство по этому вопросу.
Это область, где вы можете определить четкие технические цели, что помогает пользователям в самообслуживании; если ваши пользователи могут отказаться от использования вашего хранилища данных, не спрашивая разрешения, тогда они могут чувствовать себя гораздо комфортнее, согласившись, и для этого не потребуются никакие ресурсы поддержки.
Важно осознавать важность простого отказа от участия по умолчанию: «Чтобы завоевать доверие и признание, компании могут начать с заключения социального контракта, в котором они обязуются уважать свою аудиторию в каждой точке контакта, прислушиваться к ее потребностям и реагировать соответствующим образом. ", - заявляет IAPP . В Nielsen Norman Group заявляют, что пользователям «нужен четко обозначенный «аварийный выход», чтобы прекратить нежелательное действие без необходимости проходить расширенный процесс». Все знают, что подписаться проще, чем отписаться. Но, как говорит Нильсен Норман, предоставление пользователям возможности уйти, не прыгая через обручи, «воспитывает чувство свободы и уверенности». Научные исследования подтверждают это и называют это «принципом отзыва», заявляя: «Интерфейс должен позволять пользователю легко отзывать предоставленные им полномочия везде, где отзыв возможен. Пользователи должны иметь возможность отозвать такое согласие и, следовательно, уменьшить полномочия. чтобы получить доступ к их ресурсам, если это возможно». (Примеры см. в Йи и Яконо .)
Как долго хранить данные и какие данные хранить — это вопрос, который сильно различается между организациями и проектами, но есть некоторые общие рекомендации, которые следует учитывать.
Делать
Здесь полезно разрешить пользователям удалять учетные записи (и любые связанные с ними данные, если это возможно) и регулярно (например, при выходе из системы) удалять эфемерные и локально хранящиеся данные при выходе из системы с помощью Clear-Site. -Заголовок данных .
Если это возможно, укажите заголовок Clear-Site-Data чтобы удалить некоторые или все пользовательские данные, хранящиеся на стороне клиента (в файлах cookie, localStorage или IndexedDB или в кеше браузера). Очевидным вариантом использования Clear-Site-Data является выход пользователя из системы, но его также можно использовать после инцидентов безопасности, чтобы гарантировать, что потенциально скомпрометированная учетная запись не имеет следов скомпрометированных данных, хранящихся на клиенте.
Добавление поддержки Clear-Site-Data включает отправку HTTP-заголовка Clear-Site-Data при выходе пользователя из системы (или в другое время, когда вы хотите очистить хранилище на стороне клиента) на странице, подтверждающей выход из системы. статус ( https://your-site/logout или аналогичный). Этот заголовок может иметь некоторые или все следующие значения или "*" для всех:
Clear-Site-Data: "cache", "cookies", "storage"
Эти значения очищают, соответственно, кешированные страницы (и другие HTTP-кэшированные ресурсы), сохраненные файлы cookie, а также localStorage, IndexedDB и тому подобные. Вы можете увидеть ссылку на другой параметр, executionContexts , но он не поддерживается многими браузерами . Обратите внимание, что использование заголовка Clear-Site-Data вероятно, будет проще, чем самостоятельное удаление всех созданных ресурсов, поскольку оно не требует запуска кода JavaScript на клиенте (и это единственный официальный способ очистки кэша браузера). , но поддерживается не всеми браузерами .
Примечание по использованию: если вы очищаете кеш (отправляя Clear-Site-Data: cache ), то заголовок Clear-Site-Data не должен отправляться на вашу фактическую страницу выхода, а на какой-либо другой ресурс, на котором находится страница. нагрузки. Это связано с тем, что на более медленном компьютере с большим кешем страница блокируется, пока очищается кеш, и это препятствует навигации. Это может занять несколько минут, что расстроит пользователя. Это маловероятно, но это трудно проверить, поэтому лучше всего иметь это в виду.
Объясните, для чего вам нужны данные
О важности доверия в отношениях ваших пользователей с вашим сервисом говорилось неоднократно, поскольку оно увеличивает продолжительность жизни пользователей. Это также обеспечивает конкурентное преимущество. Один из способов повысить уровень доверия — обеспечить прозрачность ваших процессов, а хороший способ обеспечить прозрачность — объяснить, для чего вам нужны данные. Ранее вы узнали, что для каждой собранной вещи вы должны знать, когда эта вещь будет удалена. Чтобы это знать, вам необходимо знать, зачем вам нужны эти данные, для каких конкретных вопросов они нужны, чтобы найти ответы, и какие решения будут приниматься на основе их сбора. Как только вы поймете, зачем вам нужны эти данные, которые вы попросили вашего пользователя предоставить, это поможет укрепить доверие, объяснив это этим пользователям. В своей политике конфиденциальности или задавая вопросы о создании учетной записи опишите, почему вам нужен ответ на этот конкретный вопрос, что вы будете делать с этими данными, а также когда и как их можно удалить.
Эти объяснения гораздо более заметны, если они представлены в виде встроенного текста. Сокрытие объяснений в плотном политическом документе где-либо на веб-сайте может показаться попыткой их скрыть. Форма регистрации, оформления заказа или запроса может содержать причины для сбора данных наряду с самим сбором. Часто поле формы может иметь звездочку (*), указывающую на то, что поле является обязательным; сложные формы часто имеют информационную ссылку (i), объясняющую, что означает это поле. Рассмотрите возможность добавления к этим объяснениям описания того, почему собираются данные. Часто используемая фраза для этого: «Зачем нам это нужно?» рядом с полем формы, при нажатии на которое отображается всплывающее объяснение.
Некоторые примеры HTML могут выглядеть следующим образом, а затем CSS и JavaScript позаботятся о том, чтобы скрыть <aside> и показать его во всплывающем окне при нажатии на ссылку. (Обязательно подтвердите доступность формы, которую вы создаете для своего сайта !) Как именно ее разместить, зависит от вашего стиля и подходов, но главное здесь — напрямую связать сбор данных с объяснением того, почему эти данные собираются. Это не обязательно для каждого поля. Никому не нужны объяснения, почему вы требуете от них выбрать пароль при регистрации. Но оформление каждого запроса на личную и контактную информацию с указанием того, как вы планируете ее использовать и хранить, может помочь дать понять вашим пользователям, что вы вкладываете средства в защиту их данных.
<div>
<label for="email">Email address*</label>
<input id="email" type="email" name="email" required aria-describedby="whyemail">
<a href="#whyemail">Why do we need this?</a>
<aside id="whyemail">We need this information as a unique identifier for you, and if you forget your password we can send you a reminder. We will use your email address to send you regular updates on the service if you choose, and will delete your email address from any mailing lists if you delete your account.</aside>
</div>
Прохождение этого процесса со всем, что вы собираете о пользователе, также может помочь во внутренних процессах и обсуждениях. Ранее вы видели, как может возникнуть соблазн собрать данные «на всякий случай». Когда вы открыто говорите о причинах сбора средств, может быть совершенно очевидно, что это происходит. Если вы не хотите публично записывать, что вы хотите делать с пользовательскими данными, потому что этим пользователям не понравится объяснение, это может быть признаком того, что стоит переосмыслить их сбор. Это применимо, если неприятное объяснение слишком навязчиво («мы будем использовать это, чтобы отслеживать, куда вы посещаете почасово») или слишком широкое («мы еще не знаем, для чего мы будем это использовать, но мы хотим этого». на случай, если мы что-нибудь для этого придумаем») или слишком уклончиво («мы будем использовать это для внутренних нераскрытых целей»). Это не просто вопрос морали; люди достаточно сообразительны, чтобы признать это, как уже описано, и есть ожидания пользователей, что экспериментирование с чем-то не является началом долгосрочных обязательств. При проектировании пользовательского опыта принято стремиться сделать регистрацию как можно более простой и простой, поскольку на ранних этапах пользователь (по определению) не сильно инвестирует в ваш сервис, и поэтому важно позволить им стать легче инвестировать, когда у них еще мало желания это делать. Если снова уйти так же легко, то экспериментирование с сервисом становится именно экспериментированием, а не невольным началом вынужденного долгосрочного обязательства. Как и раньше, парадоксально, но верно, что лучший способ завоевать доверие — не требовать от пользователей доверия вам, если они этого не хотят.
У людей есть веские причины не делиться данными или делиться минимальными данными. В начале ваших отношений с ними у них может не быть причин доверять вам, да и не должно быть этого. Ваша цель — продемонстрировать, почему они должны это делать.
Делать
- Решите для всех данных, которые вы планируете собирать, зачем они вам нужны и как долго вы будете их хранить.
- Когда вы запрашиваете эти данные, объясните своим пользователям, почему вы их собираете.
- Удалите его из баз данных вашего сервера после того, как вы его использовали.
- Разрешите пользователям удалять созданные ими учетные записи и удалять сохраненные данные из своего хранилища с помощью заголовка
Clear-Site-Data.
Почему
Построение отношений с вашими пользователями основано на доверии, а доверие — на открытости. Если вы сможете продемонстрировать, что вы не просто собираете как можно больше данных о своих пользователях и скрываете, как вы их используете, это поможет укрепить доверие, которое может стать для вас конкурентным преимуществом перед менее щепетильными конкурентами.