Русский
Русский
English
Авторизация
Ip-адрес
Восстановление пароля
Регистрация
Статистика
Реклама

Конфиденциальность

5 стадий неизбежности принятия ISOIEC 27001 сертификации. Торг

06.07.2020 22:14:15 | Автор: admin
Третья стадия эмоционального реагирования на изменения торг. Разобравшись со своим гневом и эмоциональной составляющей, мы начали думать о том, что реально нужно сделать для того, что у нас всё заработало. Настало время изучить стандарт более детально, применить его к нашей текущей ситуации и адаптировать его требования под нашу компанию. Здесь важно было при соблюдении требований стандарта обойтись малой кровью. Любые изменения должны были быть адекватными то есть соизмеримыми с соответствующим риском. Затраты на защиту не должны были превышать возможный ущерб от реализации риска.

image

На этом пути нам пришлось решить множество вопросов, с которыми мы никогда не сталкивались ранее:

Выбор средства для работы над библиотекой политик


Первый (казалось бы, очень простой) вопрос, с которым мы столкнулись где создавать и как хранить все необходимые документы системы менеджмента информационной безопасности? Для нас было крайне важно сохранять версионность документов и иметь возможность откатить версию политики на несколько редакций назад. Изучив предложения на рынке, мы остановились на вики-системе Confluence и используем её по сей день.

В качестве системы версионирования (контроля версий) мы могли использовать git, но для удобства пользователей мы выбрали портальное решение (Confluence). Мы сумели ограничиться бесплатной версией (до 10 авторизованных пользователей): больше нам и не понадобилось, так как неавторизованные могли просматривать библиотеку.

Подготовка плана внедрения


Здесь мы не стали применять какие-то креативные методики просто запросили у нашего консультанта перечень необходимых политик, назначили ответственных за их написание и согласование, проставили ключевые даты и оформили это всё в виде диаграммы Ганта (которая также была подгружена в Confluence).

Оценка рисков компании


Очевидно, что для выбора средств защиты нам нужно было оценить риски (чтобы тратить ресурсы только туда, где это реально нужно). Для этого мы создали перечень активов компании, которые мы планируем защищать в него входили как физические активы (рабочие станции, сервера, бумажные документы и т.д.), так и нематериальные (клиентская информация в электронном виде, пароли и т.д.).

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

После того, как риски были разнесены по группам, мы поняли, с какими из них нам следует работать в первую очередь:

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

2. Отсутствие резервных вычислительных мощностей
Данная проблема требовала больших финансовых и человеческих ресурсов, поэтому оставлять ее на конец было неправильно. Мы подобрали площадку для резервирования наших основных сервисов: на первоначальном этапе мы пользовались IaaS (инфраструктура как сервис), которая позволила нам быстро и бюджетно настроить резерв основных сервисов компании; в дальнейшем мы закупили дополнительное оборудование и настроили резерв в отдельном ЦОДе (co-location). Впоследствии мы отказались от облачного решения в пользу ЦОДа ввиду большого объема данных.

3. Контроль за супер-пользователями, а также за теми, кто работает с особой, чувствительной информацией
Другими словами, нам необходимо было установить контроль за пользователями, которые имеют обширный доступ к конфиденциальной информации. Эту проблемы мы решили с помощью DLP системы. Мы выбрали отечественное ПО StaffCop благодаря приемлемой цене и хорошей технической поддержке.

Написание политик


Здесь мы подключили все возможные ресурсы:
использовали политики других компаний, которые нашли в открытом доступе;
запросили примеры политик у нашего консультанта по внедрению;
сочиняли тексты политик самостоятельно, основываясь на требованиях стандарта.
В итоге лучше всего сработал именно третий (самый сложный путь). Это было довольно долго, но зато на выходе мы получили хорошо составленные именно для нашей компании документы. Так на выходе у нас получилось 36 основных политик Системы Менеджмента Информационной Безопасности.

Распределение ролей


Очевидно, что не все эти политики реально были необходимыми нашим сотрудникам в ежедневной работе. Чтобы не заставлять их читать лишнее, мы сделали следующее: присвоили каждому сотруднику одну или несколько ролей в СМИБ. Всего их было 5 штук:

Абсолютно у всех сотрудников была как минимум одна роль пользователь.

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

Вовлечение коллег


К оценке рисков и описанию требований заинтересованных сторон помимо менеджера проекта и Руководителя отдела ИТ/ИБ был привлечен Операционный директор компании. Потребовалось существенное вовлечение и Руководителя отдела HR ей требовалось описать в политике полный жизненный цикл сотрудника: от заявки на вакансию до периода после его увольнения. К счастью, все коллеги понимали важность сертификации и шли нам навстречу.

Технические аспекты


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

Таким образом, для адаптации требований стандарта под нашу компанию нам пришлось проделать довольно существенное количество работы.

В предыдущих материалах:

5 стадий неизбежности принятия ISO/IEC 27001 сертификации. Отрицание: заблуждения о сертификации ISO 27001:2013, целесообразность получения сертификата/
5 стадий неизбежности принятия ISO/IEC 27001 сертификации. Гнев: С чего начать? Исходные данные. Затраты. Выбор провайдера.
Подробнее..
Категории: Информационная безопасность , Хранение данных , Iso 27001 , Смиб , Сертификация , Конфиденциальность

5 стадий неизбежности принятия ISOIEC 27001 сертификации. Депрессия

07.08.2020 18:11:02 | Автор: admin
Четвертая стадия эмоционального реагирования на изменения депрессия. В этой статье мы расскажем вам о нашем опыте прохождения самой затяжной и малоприятной стадии об изменениях бизнес-процессов компании с целью достижения их соответствия стандарту ISO 27001.



Ожидание


Первый вопрос, которым мы задались после выбора сертифицирующего органа и консультанта сколько времени нам реально понадобится на все необходимые изменения?

Изначальный план работ был расписан так, что мы должны были уложиться за 3 месяца.



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

Технические изменения также не выглядели устрашающими: необходимо было настроить сбор и хранение событий, проверить, соответствуют ли бэкапы политике, которую мы написали, дооснастить, где это необходимо, кабинеты СКУДом и еще немного разного по мелочи.
Команда, готовящая все необходимое для сертификации, состояла из двух человек. Мы планировали, что они будут заниматься внедрением параллельно со своими основными обязанностями, и у каждого это будет отнимать максимум 1,5-2 часа в день.
Резюмируя, можно сказать, что наш взгляд на предстоящий объем работ был довольно оптимистичным.

Реальность


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



Экспертизы команды было катастрофически мало настолько, что её не хватало даже на то, чтобы задавать правильные вопросы консультанту (который, к слову, не проявлял большого количества инициативы). Дело стало продвигаться еще медленнее, так как через 3 месяца после старта внедрения (то есть в тот момент, когда всё уже должно было быть готово), команду покинул один из двух ключевых участников. На его место пришел новый руководитель IT-службы, которому предстояло в короткий срок завершить процесс внедрения и обеспечить систему менеджмента информационной безопасности всем самым необходимым с технической точки зрения. Задача выглядела сложной Ответственные начали впадать в депрессию.

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

Спойлер: В итоге СМИБ была героически внедрена за 6 месяцев. И даже никто не умер!

Что изменилось больше всего?


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

  • Формализация процесса оценки рисков

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

  • Контроль над съемными носителями информации

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

  • Контроль за суперпользователями

Одной из основных проблем был тот факт, что все сотрудники IT-отдела имели абсолютные права во всех системах компании обладали доступом ко всей информации. При этом их при этом никто толком не контролировал.

Мы внедрили систему Data Loss Prevention (DLP) программа для контроля действий сотрудников, которая занимается анализом, блокировкой и оповещениями об опасной и непродуктивной деятельности. Сейчас оповещения о действиях сотрудников ИТ-отдела приходят на почту Операционному Директору компании.

  • Подход к организации информационной инфраструктуры

Сертификация потребовала глобальных изменений и подходов. Да, нам пришлось модернизировать ряд серверного оборудования, в связи с увеличившейся нагрузкой. В частности, мы выделили отдельный сервер под системы сбора событий. Сервер был укомплектован объемными и быстрыми накопителями SSD. Мы отказались от ПО для бэкапов и сделали выбор в пользу систем хранения, которые из коробки имеют весь необходимый функционал. Сделали несколько больших шагов в сторону концепции инфраструктура как код, что позволило сэкономить много дискового пространства, за счет отказа от резервного копирования ряда серверов. В кратчайшие сроки (1 неделя) было модернизировано все ПО на рабочих станциях до Win10. Один из вопросов, который решила модернизация возможность включения шифрации (в версии Pro).

  • Контроль за бумажными документами

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

  • Аренда резервного дата-центра

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

  • Тестирование непрерывности бизнеса

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



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

Реакция сотрудников на изменения


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

  • Все ключевые сотрудники понимали важность и неизбежность этого мероприятия;
  • Все прочие сотрудники равнялись на ключевых сотрудников.

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

Мы подготовили новый обязательный тренинг по ISO 27001 и тестирование для всех наших сотрудников. Все послушно сняли со своих мониторов стикеры с паролями и разобрали заваленные документами столы. Никакого громкого недовольства замечено не было в общем, с сотрудниками нам очень повезло.

Таким образом, мы прошли самую болезненную стадию депрессии связанную с изменениями наших бизнес-процессов. Это было тяжело и сложно, но результат в итоге превзошел все самые смелые ожидания.

Читайте предыдущие материалы из цикла:

5 стадий неизбежности принятия ISO/IEC 27001 сертификации. Отрицание: заблуждения о сертификации ISO 27001:2013, целесообразность получения сертификата.

5 стадий неизбежности принятия ISO/IEC 27001 сертификации. Гнев: С чего начать? Исходные данные. Затраты. Выбор провайдера.

5 стадий неизбежности принятия ISO/IEC 27001 сертификации. Торг: подготовка плана внедрения, оценка рисков, написание политик.

5 стадий неизбежности принятия ISO/IEC 27001 сертификации. Депрессия.

5 стадий неизбежности принятия ISO/IEC 27001 сертификации. Принятие.
Подробнее..
Категории: Информационная безопасность , Хранение данных , Iso 27001 , Смиб , Сертификация , Конфиденциальность

Из песочницы Значение VPN для анонимности в эпоху тотальной слежки

02.10.2020 18:16:15 | Автор: admin

Существует ли всё ещё такая вещь, как настоящая анонимность?


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

image

Но как именно мы можем оградиться от архитектуры угнетения, если она насаждается вокруг нас, нами и для нас же самих?


В оригинальном Манифесте Шифропанка от 1993 года Эрик Хьюз писал, что Открытому обществу в электронном веке необходима конфиденциальность. здесь он затрагивает концепции, которые помогут нам сформулировать ответ на вопрос Что делает VPN?, или, скорее, Что должен делать VPN?.
Эрик Хьюз Люди веками защищали частную жизнь при помощи шёпота, темноты, конвертов, закрытых дверей, тайных рукопожатий и курьеров. Технологии прошлого не позволяли обеспечить строгую конфиденциальность, но теперь это позволяют электронные технологии. Эрик Хьюз.
Прошли десятилетия, но эти электронные технологии не принесли спасение, на которое надеялся Хьюз. Технологии будущего, похоже, забрали большую часть нашей конфиденциальности, вместо того чтобы укрепить её. Интернет становится всё менее свободным, с увеличением вмешательства в онлайн-выборы и усилением государственного надзора, который распространяется на социальные сети.

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

Непрерывная и постоянная лента нашей жизни навсегда вписана в историю Интернета. Ваша жизнь теперь в буквальном смысле открытая книга.

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

Подпольная торговля нашими личными данными превратилась в коммерцию и, как и все ценные товары, теперь превращено в оружие. В докладе Свобода сети за 2019 год отмечается, что 89% интернет-пользователей (почти 3 млрд чел.) из 40 исследованных стран подвергаются действию программ мониторинга социальных сетей.

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

Восток встречается с Западом


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

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

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

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

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

Независимо от того, сколько информации мы оставляем в интернете добровольно, конфиденциальность должна быть стержнем и фундаментом сильной и открытой интернет-среды.


Анонимность


image
Я не знаю, почему люди так стремятся публично раскрывать подробности своей частной жизни; они забывают, что таинственность это сверхсила.
Бэнкси.

Текст на стене: Если повторять ложь достаточно часто, она станет правдой политикой

Принципиальная разница между конфиденциальностью и анонимностью


Между конфиденциальностью и анонимностью следует проводить важное различие.

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

image

Анонимность это почти такая же концепция, только наоборот. Быть анонимным это значит, что ваша личность скрыта, но можно увидеть ваши действия. Кто-то может понять, что вы делаете, но не зная, кто это делает. Блокчейны зачастую являются псевдоанонимными, то есть вы можете просматривать каждую транзакцию, которая производится, но не должны иметь возможность идентифицировать личность отправителя или получателя.

Анонимность, как правило, очерняется, поскольку анонимное поведение часто ассоциируется с нелегальной деятельностью. В какой-то момент сформировался даркнет онлайн-обитель чёрных рынков, таких как Silk Road (Шёлковый Путь), создатель которой отбывает пожизненное заключение.


imageSilk Road должен был дать людям свободу делать собственный выбор, гнаться за собственным счастьем, каким бы они его себе лично ни представляли. Это оказалось наивной и дорогостоящей идеей, о которой я глубоко сожалею. Росс Ульбрихт в письме к своему судье.


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

image

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

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


Идея может стать самой влиятельной вещью в мире


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

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



Несмотря на всеобщую поддержку прав человека в онлайн-среде, по всей видимости, принципы это не панацея. Во всём мире более четверти (27%) интернет-пользователей живут в таких местах, где их могут арестовать за публикации, репосты или даже лайки, оставленные в соцсетях. Аресты, связанные с политическими, социальными или религиозными высказываниями в соцсетях, были произведены в 47 странах. При настоящей анонимности слова могут использоваться для освобождения людей, а не против них. Вы не можете посадить идею в тюрьму.

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

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

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

Закрашивание камеры краской из баллончика


Эпоха слежки


Но цензура и слежка это не просто реалии диктатуры. Правительства повсюду регулярно пытаются предотвратить использование инструментов шифрования и анонимности в любой форме. Это нацелено якобы на то, чтобы препятствовать незаконной деятельности, такой как терроризм и незаконный оборот наркотиков. За последнее десятилетие Управлением по борьбе с наркотиками США конфисковано более 4 миллиардов долларов у граждан на основании одного только подозрения в преступной деятельности. Тем не менее, более 81% этих арестов никогда не приводили к предъявлению официальных обвинений.

Во многих случаях правительство США может законно запрашивать без ордера цифровые данные, которыми владеют компании. Законопроект EARN IT в настоящее время обсуждается на конгрессе, и если он будет принят, он может приковать компании наручниками к сложному для изменения набору процедур. Одним из пунктов в том чек-листе может оказаться устранение сквозного шифрования в мессенджерах, лишающее мир безопасного средства связи.

Несколько лет назад президент Дональд Трамп принял закон, позволяющий интернет-провайдерам собирать и делиться личными данными своих клиентов без их согласия, например, вашей веб-историей и тем, какие приложения вы используете. hightech.fm/2018/01/31/mass-digital-surveillance
Британский Разведывательный Устав предоставляет правительству право легально контролировать использование интернета своими гражданами. Общий посыл заключается в том, что если вы законопослушный гражданин, то вам не о чем беспокоиться.
image
Утверждать, что вам наплевать на право конфиденциальности, потому что вам нечего скрывать это всё равно что утверждать, что вам наплевать на свободу слова, потому что вам нечего сказать. Эдвард Сноуден.


image
Вопрос только в том, почему правительство хочет заполучить ваши персональные данные, когда у вас есть право на конфиденциальность?

Используйте свою цифровую свободу, чтобы дать отпор


В утопическом цифровом мире анонимность, конфиденциальность, безопасность и антицензура слились бы в одно целое для формирования идеального интернета.

Но как нам сделать интернет безопасным, а конфиденциальность настройкой по умолчанию? Законы, которые регулируют нашу частную жизнь и помогают нам свободно высказывать своё мнение, приносят пользу в основном корпорациям, государствам и их органам. Мы не можем полагаться на изменение законов или ждать, когда интернет-провайдеры начнут служить нашим интересам. Децентрализованная VPN (dVPN) это один из способов вернуть себе контроль.

Более четверти пользователей интернета в мире уже используют VPN. Основные мотивы для его использования: получить доступ к соцсетям и новостным службам (34%), сохранить анонимность при выходе в интернет (31%), скрыть от властей информацию о посещении сайтов (18%) и получить доступ к сети Tor (17%). Однако в странах, где граждане больше всего нуждаются в VPN Венесуэле, Китае, России, Турции, Иране, ОАЭ его, разумеется, стремятся запретить и заблокировать.

Для спасения жертв от цензуры и слежки был разработан dVPN. Обычный VPN соединяет вас с дата-центрами, которые управляемы компаниями, что делает их уязвимыми к обнаружению правительствами и интернет-провайдерами. Эти сервисы также часто медлительны, имеют различные ограничения, и что самое неприятное, могут централизованно хранить журналы онлайн-активности всех своих пользователей. Исследование 62 коммерческих провайдеров показало, что у многих из них (возможно, и не преднамеренно) происходит утечка пользовательского трафика различными путями.

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

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

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

Также можно присоединиться к сети узлов, чтобы помочь сохранить анонимность самовыражения в интернете, защитив личные данные журналистов, активистов, жертв цензуры и слежки по всему миру.

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

Вперёд.
Подробнее..
Категории: Информационная безопасность , Сетевые технологии , Vpn , Распределенные системы , Будущее здесь , Децентрализация , Анонимность , Децентрализованные сети , Блокчейн , Конфиденциальность , Слежка , Приватность , Технологии будущего , Свобода слова , Криптовалюта , Mysterium network , Dvpn , Цензура , Myst , Распределённые сети , Социальный кредит , Идентификация личности , Правозащитники , Silk road , Гонконг

Перевод Clubhouse в Китае безопасны ли данные? Исследование SIO

24.02.2021 14:21:40 | Автор: admin

На прошлой неделе в аудиочате Clubhouse прошли активные дебаты на мандаринском языке среди пользователей IOS с материкового Китая. Это случилось прежде, чем приложение резко заблокировала онлайн-цензура страны (08 февраля 2021 года).

Помимо непринужденных разговоров о путешествиях и здоровье, пользователи откровенно обсуждали концентрационные лагеря уйгуров в Синьцзяне, протесты на площади Тяньаньмэнь в 1989 году и личный опыт допросов полицией. Китайское правительство ограничивает обсуждение этих тем, поддерживая Великий Брандмауэр, чтобы блокировать доступ внутренней аудитории ко многим иностранным приложениям и веб-сайтам. Хотя ещё в начале февраля Clubhouse не был заблокирован фаерволом, некоторые пользователи с материка беспокоились, что правительство может прослушать разговор, что приведёт к репрессиям.

В последние годы китайское правительство во главе с председателем Си Цзиньпином проявляет всё большую готовность преследовать своих граждан за критические высказывания в адрес режима, даже когда эти выступления блокируются в Китае. Аудиосообщения приложения Clubhouse, в отличие от записей в Twitter, не оставляют никаких публичных записей после того, как происходит диалог, что в теории усложняет усилия китайского правительства по мониторингу.

SIO подтвердила, что Agora, Шанхайский поставщик ПО для взаимодействия пользователей в реальном времени, поставляет серверную инфраструктуру для платформы Clubhouse. Эта связь и ранее широко подозревалась, но публично не подтверждалась. Кроме того, SIO определила, что уникальный идентификационный клубный номер пользователя и идентификатор чата передаются в виде открытого текста, и Agora, скорее всего, будет иметь доступ к необработанному аудио пользователей, потенциально обеспечивая тем самым доступ китайскому правительству. По крайней мере в одном из случаев SIO наблюдал, как метаданные комнаты ретранслируются на серверы, которые, вероятно, размещены в КНР. Также в теории можно связать идентификаторы Clubhouse с профилями пользователей.

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

Что такое Agora?

Agora это Шанхайский стартап со штаб-квартирой в США в Кремниевой долине, который продаёт платформу голосового и видео взаимодействия в реальном времени для других компаний-разработчиков ПО. Другими словами, он предоставляет готовую структуру, чтобы другие приложения, такие как Clubhouse, могли сосредоточится на дизайне интерфейса, конкретных функциях и общем пользовательском опыте. Если приложение работает на инфраструктуре Agora, конечный пользователь может об этом и не догадываться.

Откуда мы знаем, что он обеспечивает поддержку Clubhouse?

Аналитики SIO наблюдали за веб-трафиком Clubhouse с помощью общедоступных инструментов сетевого анализа, таких как Wireshark. Наш анализ показал, что исходящий веб-трафик направляется на серверы, управляемые компанией Agora, в том числе qos-america.agoralab.co. Присоединение к каналу, например, генерирует пакет, направленный на внутреннюю инфраструктуру Agora. Этот пакет содержит метаданные о каждом пользователе, включая их уникальный идентификационный номер клуба и идентификатор комнаты, в которую они вступают.

Эти метаданные передаются через интернет в виде открытого текста (не зашифрованного), что означает, что любая третья сторона, имеющая доступ к сетевому трафику пользователя, может получить к ним доступ. Таким образом, подслушивающий может узнать, разговаривают ли 2 пользователя друг с другом, обнаружив, что эти пользователи подключаются к одному и тому же каналу.

Анализ документации платформы Agora также показывает, что компания, скорее всего, будет иметь доступ к необработанному аудиотрафику Clubhouse. Если Clubhouse не использует технологию сквозного шифрования (Е2ЕЕ), передаваемый звук может быть перехвачен, расшифрован и иным образом сохранен Agora.

Почему это играет важную роль?

Поскольку Agora базируется совместно в США и Китае, она попадает под действие закона КНР о кибербезопасности. В заявлении, поданном в комиссию по ценным бумагам и биржам США, компания признала, что она будет обязана оказывать помощь и поддержку в соответствии с законодательством КНР, включая защиту национальной безопасности и уголовные расследования. Поэтому если китайское правительство определит, что аудиосообщение угрожает национальной безопасности, платформа будет юридически обязана помочь правительству в его обнаружении и хранении.

Разговоры о протестах на площади Тяньаньмэнь, лагерях Синьцзяна или протестах в Гонконге могут квалифицироваться как преступная деятельность. Как это было раньше.

Ильхам Тохти, ученый и защитник осажденных уйгуров Китая, арестованный в 2014 году.Ильхам Тохти, ученый и защитник осажденных уйгуров Китая, арестованный в 2014 году.

Но Agora утверждает, что не занимается хранением пользовательских аудио или метаданных. В их задачу входит мониторинг качества сети и выставление счетов своим клиентам. Если это правда, то китайское правительство не сможет легально запрашивать данные пользователей ибо их у платформы просто нет. Или КНР теоретически могло прослушивать и записывать данные самостоятельно, если Agora искажает свои методы хранения данных. (Huawei, крупная китайская софтверная компания, имеющая тесные связи с военными силами страны, также заявляет, что не передает данные правительству. В чем многие эксперты сомневаются.)

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

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

Можно ли получить доступ к аудио, хранящемуся в Clubhouse?

Кратко: вероятно, нет, пока аудио хранится в США.

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

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

Есть ли вероятность, что материковые пользователи столкнуться с репрессиями за общение в Clubhouse?

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

  1. Узнать какие пользователи присутствуют в каких чатах. Это, как уже говорилось, можно сделать через Agora или вручную. Для ручного сбора данных кто-то в комнате должен был записывать профили всех, кто там находится.

  2. Нужно реальное желание наказать пользователей. А есть ли это желание пока что неясно. Китайское правительство иногда может быть терпимо к публичной критике, когда она не получает широкого распространения и не способствует коллективным действиям. Поскольку приложение доступно только для приглашённых и для владельцев сравнительно дорогих iPhone (менее 10% всех китайских пользователей), оно, вероятно, не было широко использовано за пределами городской элиты Китая.

Почему Clubhouse запретили в Китае именно сейчас?

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

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

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

  3. Запрет приложения требует времени. Решение о запрете возможно было задержано из-за простой бюрократической волокиты.

Но всё это лишь предположения. Ответ может оказаться ни одним из пунктов вышеперечисленного.

Технический анализ приложения

Согласно документации Agora, аудио ретранслируется через платформу с использованием их стандартного набора разработки real time communication (RTC), standard development kit (SDK). Подумайте об этом как о старом сетевом операторе: чтобы связаться с другим человеком, оператор должен соединить двух пользователей. В этом случае Clubhouse это телефон двух пользователей, а Agora оператор.

Файл списка свойств приложения Clubhouse (.plist) содержит идентификатор AgoraФайл списка свойств приложения Clubhouse (.plist) содержит идентификатор Agora

Когда пользователь присоединяется или создаёт чат в Clubhouse, приложение делает запрос через безопасный HTTP (HTTPS) к инфраструктуре Angora. Чтобы сделать запрос, телефон связывается с интерфейсом прикладного программирования Clubhouse, или API. Телефон отправляет запрос [ POST / api / create_channel ] API Clubhouse. API возвращает токен полей и rtm_token , где токен это токен Agora RTC, а rtm_token - токен RTM (обмен сообщениями в реальном времени). Эти токены затем используются для установления пути связи для последующего обмена аудио трафиком между пользователями.

Запрос на создание канала в API Clubhouse возвращает токены Agora.Запрос на создание канала в API Clubhouse возвращает токены Agora.

Затем SIO наблюдала, как телефон пользователя отправляет пакеты данных через UDP (более легкий механизм передачи) на сервер под названием qos-america.agoralab.co. Пакеты пользователя содержат в незашифрованном виде метаданные о канале, например, запросил ли пользователь присоединение к чату, идентификационный номер клуба пользователя и отключил ли он себя.

Пакет, отправленный в Agora, содержит в открытом виде идентификатор канала и идентификатор пользователя.Пакет, отправленный в Agora, содержит в открытом виде идентификатор канала и идентификатор пользователя.

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

Последовательность и содержание UDP-трафика от устройства, присоединяющегося к клубной комнате.Диаграмма SIO.Последовательность и содержание UDP-трафика от устройства, присоединяющегося к клубной комнате.Диаграмма SIO.

Единственный способ, при котором у Agora не будет доступа к необработанному аудио пользователя это если Clubhouse использует сквозное шифрование (E2EE) с использованием индивидуального метода шифрования. Хотя это теоретически возможно, для этого потребуется, чтобы Clubhouse раздал открытые ключи всем пользователям. Этого ещё не существует. Таким образом, E2EE крайне маловероятен.

Подробнее..
Категории: Информационная безопасность , Безопасность , Тестирование мобильных приложений , It-компании , Сша , Китай , Исследования и прогнозы в it , Конфиденциальность , Блог компании веб-студия и дата-центр itsoft , Clubhouse , Репрессии

Рой и пользовательский опыт в подарок Большому Брату

06.05.2021 20:17:21 | Автор: admin

Необходимое предупреждение - эта статья является личным мнением автора

Не так давно Apple представили AirTags - очередной продукт из своей экосистемы, который был почему-то практически проигнорирован прессой. Вспомните, какими непрерывными потоками раньше выходили обзоры - на новые iPhone, iPad, Macbook и просто Mac, на AirPods и Apple Watch, а сейчас? Мне это показалось незаслуженно пропущенным событием - и естественно, захотелось это исправить. Нет-нет-нет, не сделать "самый правильный обзор" - пусть этим Висла занимается.

Намного интересней предыстория и последствия появления этого сервиса.

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

Надо заметить, что Apple отнюдь не открыл Америку сделав сервис с такой роевой архитектурой - всё навигационные сервисы - Google Maps, Яндекс.Карты и другие - работают по тому же принципу, передавая свое местоположение владельцу сервиса и позволяя ему локализовать транспортные затруднения (пробки). Apple "всего лишь" начал собирать не только данные самого устройства - но и данные о всех устройствах поблизости.

Теперь все устройства Apple превращены в огромный инструмент сбора данных. Причем собираются не только данные об устройствах Apple - но вообще обо всех устройствах. Весь этот собраный массив отправляется в Apple, где из него извлекается вся доступная информация, и та часть которая относится к геосервисам Apple, будет становиться доступной пользователям. Вот только одно "но" - компания получит данные обо всех устройствах поблизости. Ведь ни один закон не заставляет компанию удалять данные, если они "обезличены". Нельзя сопоставить MAC пользователю - всё, нет нужды удалять.

Вы верите, что собранные данные будут удалены? Я - нет.

Огромное недремлющее радиооко, которое передает одной компании информацию обо всех устройствах поблизости от своих агентов - не только об устройствах Apple. Спецслужбы неправильных стран ушли в запой с горя, спецслужбы "правильной" страны кушают смузи с кукурузным бренди. Боб Шоу с его "Светом Былого" (в оригинале Other Days, Other Eyes) с восхищением и ужасом наблюдает за происходящим.

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

За счет чего Apple удалось реализовать это решение? Trusted Computing:

  1. Устройство, выполняет только подписанный код

  2. Устройство не позволяет загрузить неодобренный код

  3. Пользователь лишен привилегии полного контроля над устройством

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

В этой гонке Google, которая когда-то сделал ставку на открытый Android, не может победить и Fucsia родилась во многом именно поэтому - компании нужна её собственная абсолютно контролируемая платформа.

Закрытие платформы, тивоизация и другие инструменты "оконтроливания" платформ будут становиться майнстримом, поскольку позволяют с околонулевыми затратами реализовывать новые распределенные сервисы... И повышать норму прибыли. Давайте сделаем некоторую базовую аппаратную платформу, сделаем её закрытой, а фичи превратим в программно отключаемые платные опции - привет автопилот Tesla, автоматическое запирание дверей Ford Focus, автоматическое переключение на ближний свет BMW и многие другие "гениальные оптимизации".

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

И нас всех ждут очень веселые времена, когда все заинтересованные стороны - корпорации и государство - будут агрессивно торговаться за право заглянуть в то, что мы ещё недавно считали своей если не тайной, то как минимум привилегией. И еще более "интересные", когда они договорятся

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

И всё чаще нам будут предлагать "дать согласие" на активацию очередных опций, которые ну вот точно-точно нужны для достижения очередного "ещё более уникального пользовательского опыта", или приобрести очередной продукт, который "входит в экосистему" и (ну так уж получилось, вы же понимаете, это другое), естественно, закрытый.

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

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

Подробнее..
Категории: Информационная безопасность , Apple , Облачные сервисы , Конфиденциальность , Privacy , Airtags , Opensorce

Можно ли анонимно оплачивать через Apple Pay?

18.05.2021 12:12:57 | Автор: admin

Конечно, нельзя называть Apple Pay анонимным в принципе, хотя бы потому что к ней привязана наша банковская карта. Однако, в момент оплаты что о нас узнаёт продавец? Какие наши персональные данные получает продавец от Apple Pay? Можно ли избежать передачи данных и, тем самым, сделать оплату анонимной в глазах продавца?

Когда мы полагаем, что оплачиваем через Apple Pay, то можем заблуждаться. В зависимости от того что мы приобретаем, используется один из двух механизмов Apple. При покупке любой материальной услуги действительно применяется Apple Pay. Однако, когда мы приобретаем цифровой контент в экосистеме Apple, применяется In-App Purchase. Заказываете Uber через Apple Pay? Верно, это Apple Pay. Оформляете подписку в Apple Music? Это уже In-App Purchase.

Ниже мы рассказываем, какие данные утекают продавцу при оплате внутри приложений. Мы не стали разбирать ситуацию, когда товар оплачивается через POS-терминал, так как она требует отдельного внимания.

Визуально оба механизма очень похожи, но под капотом все иначе. Визуально оба механизма очень похожи, но под капотом все иначе.

In-App Purchase

Как уже было сказано выше, данный механизм оплаты используется только для цифрового контента. Электронные книги в Amazon Kindle, дополнительное пространство в Dropbox, скины в PUBG - это всё примеры цифрового контента.

При анализе In-App Purchase выяснилось, что мы анонимны перед продавцом. Некоторая информация о нас все же передается продавцу, но в обезличенном виде. Если мы купим неприличную книгу в LitRes, то разработчики приложения не узнают, что именно мы её приобрели. При условии, что мы не поделились с приложением личной информацией иным путем.

Какие данные передаются продавцу

Ниже представлена таблица, где мы видим какие данные In-App Purchase передает продавцу.

In-App Purchase

Как предотвратить передачу?

Дата первой установки приложения

Никак

Список всех сделанных покупок

Никак

Биллинговая ошибка на стороне клиента (не хватает денег, карта неактивна)

Никак

Дата первой установки приложения

Можно определить, когда мы первый раз скачали приложение, даже если удалим сейчас, но скачаем заново через пол года.

Список всех сделанных покупок

По сути, только дата покупки и что за продукт был приобретен.

Биллинговая ошибка на стороне клиента

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

Технические подробности

Спойлер

  1. Приложение предлагает пользователю какой-то контент.

  2. Пользователь инициирует процесс покупки.

  3. Приложение показывает ему окно для совершения транзакции.

  4. После подтверждения приложение какое-то время думает.

  5. Контент предоставлен.

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

Пример receipt

MIITuAYJKoZIhvcNAQcCoIITqTCCE6UCAQExCzAJBgUrDgMCGgUAMIIDWQYJKoZIhvcNAQcBoIIDSgSCA0YxggNCMAoCAQgCAQEEAhYAMAoCARQCAQEEAgwAMAsCAQECAQEEAwIBADALAgEDAgEBBAMMATMwCwIBCwIBAQQDAgEAMAsCAQ4CAQEEAwIBWjALAgEPAgEBBAMCAQAwCwIBEAIBAQQDAgEAMAsCARkCAQEEAwIBAzAMAgEKAgEBBAQWAjQrMA0CAQ0CAQEEBQIDAYfPMA0CARMCAQEEBQwDMS4wMA4CAQkCAQEEBgIEUDI1MDAYAgEEAgECBBA04jSbC9Zi5OwSemv9EK8kMBsCAQACAQEEEwwRUHJvZHVjdGlvblNhbmRib3gwHAIBAgIBAQQUDBJjb20uYmVsaXZlLmFwcC5pb3MwHAIBBQIBAQQUJzhO1BR1kxOVGrCEqQLkwvUuZP8wHgIBDAIBAQQWFhQyMDE4LTExLTEzVDE2OjQ2OjMxWjAeAgESAgEBBBYWFDIwMTMtMDgtMDFUMDc6MDA6MDBaMD0CAQcCAQEENedAPSDSwFz7IoNyAPZTI59czwFA1wkme6h1P/iicVNxpR8niuvFpKYx1pqnKR34cdDeJIzMMFECAQYCAQEESfQpXyBVFno5UWwqDFaMQ/jvbkZCDvz3/6RVKPU80KMCSp4onID0/AWet6BjZgagzrXtsEEdVLzfZ1ocoMuCNTOMyiWYS8uJj0YwggFKAgERAgEBBIIBQDGCATwwCwICBqwCAQEEAhYAMAsCAgatAgEBBAIMADALAgIGsAIBAQQCFgAwCwICBrICAQEEAgwAMAsCAgazAgEBBAIMADALAgIGtAIBAQQCDAAwCwICBrUCAQEEAgwAMAsCAga2AgEBBAIMADAMAgIGpQIBAQQDAgEBMAwCAgarAgEBBAMCAQEwDAICBq4CAQEEAwIBADAMAgIGrwIBAQQDAgEAMAwCAgaxAgEBBAMCAQAwEAICBqYCAQEEBwwFdGVzdDIwGwICBqcCAQEEEgwQMTAwMDAwMDQ3MjEwNjA4MjAbAgIGqQIBAQQSDBAxMDAwMDAwNDcyMTA2MDgyMB8CAgaoAgEBBBYWFDIwMTgtMTEtMTNUMTY6NDY6MzFaMB8CAgaqAgEBBBYWFDIwMTgtMTEtMTNUMTY6NDY6MzFaoIIOZTCCBXwwggRkoAMCAQICCA7rV4fnngmNMA0GCSqGSIb3DQEBBQUAMIGWMQswCQYDVQQGEwJVUzETMBEGA1UECgwKQXBwbGUgSW5jLjEsMCoGA1UECwwjQXBwbGUgV29ybGR3aWRlIERldmVsb3BlciBSZWxhdGlvbnMxRDBCBgNVBAMMO0FwcGxlIFdvcmxkd2lkZSBEZXZlbG9wZXIgUmVsYXRpb25zIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTE1MTExMzAyMTUwOVoXDTIzMDIwNzIxNDg0N1owgYkxNzA1BgNVBAMMLk1hYyBBcHAgU3RvcmUgYW5kIGlUdW5lcyBTdG9yZSBSZWNlaXB0IFNpZ25pbmcxLDAqBgNVBAsMI0FwcGxlIFdvcmxkd2lkZSBEZXZlbG9wZXIgUmVsYXRpb25zMRMwEQYDVQQKDApBcHBsZSBJbmMuMQswCQYDVQQGEwJVUzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKXPgf0looFb1oftI9ozHI7iI8ClxCbLPcaf7EoNVYb/pALXl8o5VG19f7JUGJ3ELFJxjmR7gs6JuknWCOW0iHHPP1tGLsbEHbgDqViiBD4heNXbt9COEo2DTFsqaDeTwvK9HsTSoQxKWFKrEuPt3R+YFZA1LcLMEsqNSIH3WHhUa+iMMTYfSgYMR1TzN5C4spKJfV+khUrhwJzguqS7gpdj9CuTwf0+b8rB9Typj1IawCUKdg7e/pn+/8Jr9VterHNRSQhWicxDkMyOgQLQoJe2XLGhaWmHkBBoJiY5uB0Qc7AKXcVz0N92O9gt2Yge4+wHz+KO0NP6JlWB7+IDSSMCAwEAAaOCAdcwggHTMD8GCCsGAQUFBwEBBDMwMTAvBggrBgEFBQcwAYYjaHR0cDovL29jc3AuYXBwbGUuY29tL29jc3AwMy13d2RyMDQwHQYDVR0OBBYEFJGknPzEdrefoIr0TfWPNl3tKwSFMAwGA1UdEwEB/wQCMAAwHwYDVR0jBBgwFoAUiCcXCam2GGCL7Ou69kdZxVJUo7cwggEeBgNVHSAEggEVMIIBETCCAQ0GCiqGSIb3Y2QFBgEwgf4wgcMGCCsGAQUFBwICMIG2DIGzUmVsaWFuY2Ugb24gdGhpcyBjZXJ0aWZpY2F0ZSBieSBhbnkgcGFydHkgYXNzdW1lcyBhY2NlcHRhbmNlIG9mIHRoZSB0aGVuIGFwcGxpY2FibGUgc3RhbmRhcmQgdGVybXMgYW5kIGNvbmRpdGlvbnMgb2YgdXNlLCBjZXJ0aWZpY2F0ZSBwb2xpY3kgYW5kIGNlcnRpZmljYXRpb24gcHJhY3RpY2Ugc3RhdGVtZW50cy4wNgYIKwYBBQUHAgEWKmh0dHA6Ly93d3cuYXBwbGUuY29tL2NlcnRpZmljYXRlYXV0aG9yaXR5LzAOBgNVHQ8BAf8EBAMCB4AwEAYKKoZIhvdjZAYLAQQCBQAwDQYJKoZIhvcNAQEFBQADggEBAA2mG9MuPeNbKwduQpZs0+iMQzCCX+Bc0Y2+vQ+9GvwlktuMhcOAWd/j4tcuBRSsDdu2uP78NS58y60Xa45/H+R3ubFnlbQTXqYZhnb4WiCV52OMD3P86O3GH66Z+GVIXKDgKDrAEDctuaAEOR9zucgF/fLefxoqKm4rAfygIFzZ630npjP49ZjgvkTbsUxn/G4KT8niBqjSl/OnjmtRolqEdWXRFgRi48Ff9Qipz2jZkgDJwYyz+I0AZLpYYMB8r491ymm5WyrWHWhumEL1TKc3GZvMOxx6GUPzo22/SGAGDDaSK+zeGLUR2i0j0I78oGmcFxuegHs5R0UwYS/HE6gwggQiMIIDCqADAgECAggB3rzEOW2gEDANBgkqhkiG9w0BAQUFADBiMQswCQYDVQQGEwJVUzETMBEGA1UEChMKQXBwbGUgSW5jLjEmMCQGA1UECxMdQXBwbGUgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxFjAUBgNVBAMTDUFwcGxlIFJvb3QgQ0EwHhcNMTMwMjA3MjE0ODQ3WhcNMjMwMjA3MjE0ODQ3WjCBljELMAkGA1UEBhMCVVMxEzARBgNVBAoMCkFwcGxlIEluYy4xLDAqBgNVBAsMI0FwcGxlIFdvcmxkd2lkZSBEZXZlbG9wZXIgUmVsYXRpb25zMUQwQgYDVQQDDDtBcHBsZSBXb3JsZHdpZGUgRGV2ZWxvcGVyIFJlbGF0aW9ucyBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMo4VKbLVqrIJDlI6Yzu7F+4fyaRvDRTes58Y4Bhd2RepQcjtjn+UC0VVlhwLX7EbsFKhT4v8N6EGqFXya97GP9q+hUSSRUIGayq2yoy7ZZjaFIVPYyK7L9rGJXgA6wBfZcFZ84OhZU3au0Jtq5nzVFkn8Zc0bxXbmc1gHY2pIeBbjiP2CsVTnsl2Fq/ToPBjdKT1RpxtWCcnTNOVfkSWAyGuBYNweV3RY1QSLorLeSUheHoxJ3GaKWwo/xnfnC6AllLd0KRObn1zeFM78A7SIym5SFd/Wpqu6cWNWDS5q3zRinJ6MOL6XnAamFnFbLw/eVovGJfbs+Z3e8bY/6SZasCAwEAAaOBpjCBozAdBgNVHQ4EFgQUiCcXCam2GGCL7Ou69kdZxVJUo7cwDwYDVR0TAQH/BAUwAwEB/zAfBgNVHSMEGDAWgBQr0GlHlHYJ/vRrjS5ApvdHTX8IXjAuBgNVHR8EJzAlMCOgIaAfhh1odHRwOi8vY3JsLmFwcGxlLmNvbS9yb290LmNybDAOBgNVHQ8BAf8EBAMCAYYwEAYKKoZIhvdjZAYCAQQCBQAwDQYJKoZIhvcNAQEFBQADggEBAE/P71m+LPWybC+P7hOHMugFNahui33JaQy52Re8dyzUZ+L9mm06WVzfgwG9sq4qYXKxr83DRTCPo4MNzh1HtPGTiqN0m6TDmHKHOz6vRQuSVLkyu5AYU2sKThC22R1QbCGAColOV4xrWzw9pv3e9w0jHQtKJoc/upGSTKQZEhltV/V6WId7aIrkhoxK6+JJFKql3VUAqa67SzCu4aCxvCmA5gl35b40ogHKf9ziCuY7uLvsumKV8wVjQYLNDzsdTJWk26v5yZXpT+RN5yaZgem8+bQp0gF6ZuEujPYhisX4eOGBrr/TkJ2prfOv/TgalmcwHFGlXOxxioK0bA8MFR8wggS7MIIDo6ADAgECAgECMA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlVTMRMwEQYDVQQKEwpBcHBsZSBJbmMuMSYwJAYDVQQLEx1BcHBsZSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEWMBQGA1UEAxMNQXBwbGUgUm9vdCBDQTAeFw0wNjA0MjUyMTQwMzZaFw0zNTAyMDkyMTQwMzZaMGIxCzAJBgNVBAYTAlVTMRMwEQYDVQQKEwpBcHBsZSBJbmMuMSYwJAYDVQQLEx1BcHBsZSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEWMBQGA1UEAxMNQXBwbGUgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAOSRqQkfkdseR1DrBe1eeYQt6zaiV0xV7IsZid75S2z1B6siMALoGD74UAnTf0GomPnRymacJGsR0KO75Bsqwx+VnnoMpEeLW9QWNzPLxA9NzhRp0ckZcvVdDtV/X5vyJQO6VY9NXQ3xZDUjFUsVWR2zlPf2nJ7PULrBWFBnjwi0IPfLrCwgb3C2PwEwjLdDzw+dPfMrSSgayP7OtbkO2V4c1ss9tTqt9A8OAJILsSEWLnTVPA3bYharo3GSR1NVwa8vQbP4++NwzeajTEV+H0xrUJZBicR0YgsQg0GHM4qBsTBY7FoEMoxos48d3mVz/2deZbxJ2HafMxRloXeUyS0CAwEAAaOCAXowggF2MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBQr0GlHlHYJ/vRrjS5ApvdHTX8IXjAfBgNVHSMEGDAWgBQr0GlHlHYJ/vRrjS5ApvdHTX8IXjCCAREGA1UdIASCAQgwggEEMIIBAAYJKoZIhvdjZAUBMIHyMCoGCCsGAQUFBwIBFh5odHRwczovL3d3dy5hcHBsZS5jb20vYXBwbGVjYS8wgcMGCCsGAQUFBwICMIG2GoGzUmVsaWFuY2Ugb24gdGhpcyBjZXJ0aWZpY2F0ZSBieSBhbnkgcGFydHkgYXNzdW1lcyBhY2NlcHRhbmNlIG9mIHRoZSB0aGVuIGFwcGxpY2FibGUgc3RhbmRhcmQgdGVybXMgYW5kIGNvbmRpdGlvbnMgb2YgdXNlLCBjZXJ0aWZpY2F0ZSBwb2xpY3kgYW5kIGNlcnRpZmljYXRpb24gcHJhY3RpY2Ugc3RhdGVtZW50cy4wDQYJKoZIhvcNAQEFBQADggEBAFw2mUwteLftjJvc83eb8nbSdzBPwR+Fg4UbmT1HN/Kpm0COLNSxkBLYvvRzm+7SZA/LeU802KI++Xj/a8gH7H05g4tTINM4xLG/mk8Ka/8r/FmnBQl8F0BWER5007eLIztHo9VvJOLr0bdw3w9F4SfK8W147ee1Fxeo3H4iNcol1dkP1mvUoiQjEfehrI9zgWDGG1sJL5Ky+ERI8GA4nhX1PSZnIIozavcNgs/e66Mv+VNqW2TAYzN39zoHLFbr2g8hDtq6cxlPtdk2f8GHVdmnmbkyQvvY1XGefqFStxu9k0IkEirHDx22TZxeY8hLgBdQqorV2uT80AkHN7B1dSExggHLMIIBxwIBATCBozCBljELMAkGA1UEBhMCVVMxEzARBgNVBAoMCkFwcGxlIEluYy4xLDAqBgNVBAsMI0FwcGxlIFdvcmxkd2lkZSBEZXZlbG9wZXIgUmVsYXRpb25zMUQwQgYDVQQDDDtBcHBsZSBXb3JsZHdpZGUgRGV2ZWxvcGVyIFJlbGF0aW9ucyBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eQIIDutXh+eeCY0wCQYFKw4DAhoFADANBgkqhkiG9w0BAQEFAASCAQCJ9ctD+7Yi9JWvl6G+1HOcDO++mhY6rc6japAgogVF4xmIdh275IKRwZKpQbhoJmxXwElbMjkIsXks/48/EzuaHDQBNIVowq8qQaSUb3msvfAZfi7RGnhaJGzkXf7azr9NLMxX29R2jTiw2oaz2ri49piggmrGfXsLjWs9zTHWHHNRN1fLTPtcWb95JbQNAiQqlecG5a95/+KZ7+joh8fQwbthe8oWs5Tla0DDwrEoIbc5yjFT18Dln5bndTvWQJZcsbI4xa7BAEhjg/nfwPhaL17tHZeW8mOcCtG9UcuAgXXC6usVAOSocenhmKUR8W+D6F/jhBn0k9ahApPDmpZh

receipt нужен для того, чтобы приложение смогло проверить, действительно ли пользователь совершил эту покупку. Обычно приложение передает эту строку на свой бекенд, а тот - в Apple, чтобы проверить покупку. Apple в ответ на запрос пришлет JSON. Он то нам и нужен:

{    "receipt": {        "receipt_type": "ProductionSandbox",        "adam_id": 0,        "app_item_id": 0,        "bundle_id": "com.belive.app.ios",        "application_version": "3",        "download_id": 0,        "version_external_identifier": 0,        "receipt_creation_date": "2018-11-13 16:46:31 Etc/GMT",        "receipt_creation_date_ms": "1542127591000",        "receipt_creation_date_pst": "2018-11-13 08:46:31 America/Los_Angeles",        "request_date": "2018-11-13 17:10:31 Etc/GMT",        "request_date_ms": "1542129031280",        "request_date_pst": "2018-11-13 09:10:31 America/Los_Angeles",        "original_purchase_date": "2013-08-01 07:00:00 Etc/GMT",        "original_purchase_date_ms": "1375340400000",        "original_purchase_date_pst": "2013-08-01 00:00:00 America/Los_Angeles",        "original_application_version": "1.0",        "in_app": [{            "quantity": "1",            "product_id": "test2",            "transaction_id": "1000000472106082",            "original_transaction_id": "1000000472106082",            "purchase_date": "2018-11-13 16:46:31 Etc/GMT",            "purchase_date_ms": "1542127591000",            "purchase_date_pst": "2018-11-13 08:46:31 America/Los_Angeles",            "original_purchase_date": "2018-11-13 16:46:31 Etc/GMT",            "original_purchase_date_ms": "1542127591000",            "original_purchase_date_pst": "2018-11-13 08:46:31 America/Los_Angeles",            "is_trial_period": "false"        }]    },    "status": 0,    "environment": "Sandbox"}

Оба примера взяты со StackOverflow.

Чтобы определить дату первой установки, в JSON необходимо найти поле original_purchase_date. Это просто дата, когда приложение было скачано тем самым iTunes аккаунтом, через который совершается покупка.

Поле in_app даст информацию о почти всех покупках, совершенных с этого iTunes аккаунта. Почти, потому что в нем не хранится информация о всех consumable покупках, только о текущей (как в примере выше). Consumable покупки - это покупки, которые можно совершать любое число раз, например, наборы монеток или кристаллов, за которые в приложении можно купить что-то. Все остальные покупки будут всегда храниться в этом поле. Причем, что интересно, если мы сделаем возврат покупки через Apple, то это действие также отобразится в этом массиве. То есть, когда мы в следующий раз придем покупать или восстанавливать покупку, разработчик может узнать не только как часто мы покупаем, но и как часто отменяем покупку.

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

Apple Pay

Просто напомню, что Apple Pay предназначен для материальных товаров и услуг. Примерами могут быть: доставка еды в UberEATS, аренда дома в Airbnb, авиабилеты в Skyscanner.

Исследование Apple Pay показало нам, что продавец однозначно понимает, кто у него покупает товар/услугу. Мы полностью открыты в глазах продавца. Можно ограничить доступ к некоторой информации о себе, но кардинально ситуацию не изменить.

Какие данные передаются продавцу

Ниже представлена таблица, где мы видим какие данные Apple Pay передает продавцу.

До подтверждения оплаты

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

Поле

Значение

Как предотвратить передачу?

Тип карты

Дебетовая/Кредитная

Никак

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

Страна, область, город, почтовый индекс

Исказить или убрать в iOS. Настройки iOS Wallet и Apple Pay Параметры оплаты по умолчанию

Примерный платежный адрес пользователя (если не запрошен адрес доставки)

Страна, область, город, почтовый индекс

Исказить или убрать в iOS. Приложение Wallet Карта Настройки Адрес плательщика[1]

Информация о банке эмитенте карты (при наличии договоренности между разработчиком и банком)

Название банка

Никак

После подтверждения оплаты

Как только мы подтверждаем оплату с помощью Face ID, Touch ID или пароля, продавец получает новую порцию данных.

Поле

Значение

Как предотвратить передачу?

Платежная система

Mastercard

Никак

Название карты с последними символами реальной карты

MasterCard 2780

Никак

Точный адрес доставки пользователя

Страна, область, город, почтовый индекс, улица, дом, квартира

До подтверждения оплаты исказить текст в самой шторке

Точный платежный адрес пользователя

Страна, область, город, почтовый индекс, улица, дом, квартира

Исказить или убрать в iOS. Приложение Wallet Карта Настройки Адрес плательщика[1]

Имя Фамилия

Иван Иванов

Исказить или убрать в iOS. Находится там же, где и адрес доставки или платежный адрес.

Номер телефона

+77990001122

1. Либо до подтверждения оплаты исказить текст в самой шторке

2. Либо исказить/убрать в iOS. Настройки Wallet и Apple Pay Параметры оплаты по умолчанию[2]

Email

Ivan@gmail.com

От банка-эквайера

После успешной оплаты продавец может запросить дополнительную информацию о нас. Информация запрашивается у того, кто непосредственно обрабатывает нашу оплату (эквайер).

Поле

Значение

Как предотвратить передачу?

IP покупателя

81.18.144.51

Никак

Страна банка эмитента

Россия

Никак

Имя держателя карты

IVAN IVANOV

Никак

Срок истечения действия карты

202109

Никак

Маскированный номер карты, использованной для оплаты (указывается не реальный номер карты, а токен, который был привязан к устройству)

520424**0010

Никак

Как выглядит подтверждение оплаты

Шторка с подтверждением оплаты может выглядеть по-разному. Все зависит от того, какую информацию о нас запрашивает продавец. Любая запрошенная информация обязательна к заполнению.

Технические подробности

Спойлер

Обратимся к официальной документации и к тестовому приложению и попробуем сделать в нем платеж. Как только приложение показывает окно с суммой и просьбой подтвердить покупку, вызывается метод:

func paymentAuthorizationController(_ controller: PKPaymentAuthorizationController, didSelectPaymentMethod paymentMethod: PKPaymentMethod, handler completion: @escaping (PKPaymentRequestPaymentMethodUpdate) -> Void)

Eсли при формировании let paymentRequest = PKPaymentRequest() еще запросить requiredShippingContactFields, то вызывается следующее:

func paymentAuthorizationController(_ controller: PKPaymentAuthorizationController, didSelectShippingContact contact: PKContact, handler completion: @escaping (PKPaymentRequestShippingContactUpdate) -> Void)

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

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

let paymentRequest = PKPaymentRequest()paymentRequest.requiredShippingContactFields = [  .postalAddress,   .name,  .phoneNumber,  .emailAddress]paymentRequest.requiredBillingContactFields = [  .postalAddress,  .name,  .phoneNumber,  .emailAddress]

Стоит отметить, что если запрашивать requiredBillingContactFields вместе с requiredShippingContactFields, то billingAddress не будет возвращаться до подтверждения покупки.

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

func paymentAuthorizationController(_ controller: PKPaymentAuthorizationController, didSelectPaymentMethod paymentMethod: PKPaymentMethod, handler completion: @escaping (PKPaymentRequestPaymentMethodUpdate) -> Void)

Из объекта paymentMethod: PKPaymentMethod мы получим:

payment.token.paymentMethod.billingAddress givenName nilpayment.token.paymentMethod.billingAddress middleName nilpayment.token.paymentMethod.billingAddress familyName nilpayment.token.paymentMethod.billingAddress                              street=,                             subLocality=,                             city=Москва,                             subAdministrativeArea=,                             state=Москва,                             postalCode=125009,                             country=Россия,                             countryCode=RUpayment.token.paymentMethod.type 2

А если запросим requiredShippingContactFields, то из метода didSelectShippingContact мы получим:

payment.shippingContact email nilpayment.shippingContact name                          namePrefix:                          givenName:                          middleName:                          familyName:                          nameSuffix:                          nickname:                          phoneticRepresentation:                         givenName:                          middleName:                          familyName:   payment.shippingContact postalAddress                         street=,                         subLocality=,                         city=Москва,                         subAdministrativeArea=,                         state=Москва,                         postalCode=125009,                         country=Россия,                         countryCode=RUpayment.shippingContact phoneNumber nil

Пользователь узнает требуются ли эти данные только после того, как окно платежа уже покажется, а данные - уйдут.

Но если пользователь подтвердит покупку - мы получим еще больше:

payment.billingContact          street=Тверская улица 1 123,         subLocality=,         city=Москва,         subAdministrativeArea=,         state=Москва,         postalCode=125009,         country=Россия,         countryCode=RU

Кроме адреса можно запросить еще ФИО, email и номер телефона. Они будут получены после подтверждения оплаты:

payment.shippingContact email ivan@ivanov.rupayment.shippingContact name                         namePrefix:                          givenName: Иван                         middleName:                          familyName: Иванов                         nameSuffix:                          nickname:                          phoneticRepresentation:                           givenName: Ivan                           middleName:                            familyName: Ivanovpayment.shippingContact phoneNumber stringValue=+77990001122

Но email и номер телефона можно получить только в случае запроса адреса доставки. При запросе адреса платежа такая информация не возвращается:

payment.billingContact email nilpayment.billingContact name                        namePrefix:                         givenName: Иван                        middleName:                         familyName: Иванов                        nameSuffix:                         nickname:                         phoneticRepresentation:                           givenName: Ivan                           middleName:                            familyName: Ivanov  payment.billingContact phoneNumber nil

Также после подтверждения платежа мы получим последние 4 цифры карты, ее платежную систему и название. Ниже пример такой информации для одной из тестовых карт Apple:

paymentMethod.displayName Discover 2780payment.token.paymentMethod.network PKPaymentNetwork(_rawValue: Discover)

Чтобы разобраться с тем, что можно получить от эквайера, обратимся к документации Сбербанка

Там много разной информации, но самыми интересными выглядят следующие параметры:

  • ip - IP покупателя

  • bankInfo - наименование страны банка-эмитента, если доступно

  • cardAuthInfo - данные карты, привязанной к устройству

    • expiration - срок истечения действия карты

    • pan - маскированный номер карты

      • номер, привязанный к мобильному устройству покупателя и выполняющий функции номера платёжной карты в системе Apple Pay

    • cardholderName - имя держателя карты латиницей, если доступно

Примечания

  1. Если адрес не выбран явно, то будет подтягиваться тот, что указан в адресе доставки.

  2. В этих настройках данные могут быть заданы напрямую, либо подтягиваться из карточки контакта из телефонной книги. Если данные были заданы здесь, то в телефонной книге их нельзя будет найти. Если же данные были введены в телефонной книге, то здесь они будут видны, но удалить их можно только через телефонную книгу. Это будет заметно по подписи под email или телефоном (домашний, рабочий и тд) и по тому, что не будет возможности удалить его.

Подробнее..
Категории: Информационная безопасность , Apple , Анонимность , In-app purchases , Персональные данные , Конфиденциальность , Блог компании postuf , Приватность , Apple pay

Перевод Шесть причин, по которым Google Maps самое пугающее приложение на вашем смартфоне

16.11.2020 00:15:06 | Автор: admin

Google знает, где вы находитесь как и рекламодатели




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

То, что у приложения Google Maps есть возможность следить за каждым вашим шагом, не означает автоматически, что оно этими возможностями злоупотребляет. Но могло бы что является проблемой само по себе, особенно из-за того, что штаб-квартира Google находится в США, где частная жизнь охраняется хуже, чем в Европе, а разведка замечена в слежке за гражданскими лицами.

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

Google Maps нужна история ваших поисков



Автоматические настройки при создании новой учётной записи в Google

Настройки Web & App Activity в Google описывают, как компания собирает данные о пользователях, в частности, о его местонахождении, чтобы обеспечивать ему быстрее работающий сервис и персонализированный контент. А проще говоря, что абсолютно все места, что вы искали в картах будь то стрип-клуб, шаурмячная или место, где вы встречаетесь со своим поставщиком наркотиков, приезжающим туда на мопеде сохраняются, интегрируясь в поисковый алгоритм Google на 18 месяцев.

В Google знают, что вам это кажется неприятным. Поэтому компания использует т.н. скрытые закономерности [dark patterns] интерфейсы, подталкивающие нас к выбору, который мы вряд ли сделали бы сами. Это может быть выделение одного из вариантов выбора другим шрифтом или более яркими цветами.

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

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

Google Maps ограничивает возможности, если вы не хотите делиться историей поиска



Google Maps, когда у вас нет связи

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

К сожалению, Google Maps не позволит вам сохранять часто посещаемые места, если вы не зайдёте в учётку. Если вы пользуетесь картами, не входя в учётку, по нажатию на поисковую строку вы увидите кнопку устали печатать?, предлагающую вам войти, и склоняющую вас тем самым к тому, чтобы собирать больше ваших данных.

Google Maps могут настучать на вас



Google Maps Хронология

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

И речь не только о хакерах Google может также делиться данными с государственными агентствами, например, с полицией. На странице вопросов и ответов Google написано, что юридическая команда рассматривает каждый такой случай отдельно. Каждые шесть месяцев компания выпускает отчёт о прозрачности. Для 2020 года пока ничего нет. С июля по декабрь 2019 года Google получила 81 785 запросов, касающихся 175 715 учётных записей со всего мира, и в большинстве случаев выдала запрашиваемую информацию.


График запросов на раскрытие информации со всего мира, с 2009 по 2019

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

Google Maps хочет знать ваши привычки



Выдуманные отзывы для примера

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

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

Если вы пожалеете о своём отзыве, Google, по крайней мере, даёт вам возможность скрыть обзоры после их публикации. Неинтуитивный путь к этой возможности такой (в мобильном приложении Android): иконка профиля Ваш профиль Изменить профиль Настройки профиля и доступа прокрутить вниз Профиль с ограниченным доступом. После включения этой возможности следить за вашим профилем и вашими отзывами смогут только одобренные вами пользователи.

Google Maps не любит быть в офлайне



Google Maps в офлайне

Помните GPS-навигаторы? Возможно, они были неуклюжими и тяжеловесными, однако они служат хорошим напоминанием тому, что получать направления движения можно и без подключения к интернету. В других приложениях есть офлайн-навигация. Для Google Maps можно скачать карты, однако офлайн-навигация предлагается только для автомобилей. Маловероятно, что техногигант не может разобраться в том, как подсказывать направления пешеходам и велосипедистам без доступа к интернету.

Google притворяется, что делает всё это для вашего же блага


Предоставление полезных и осмысленных услуг основа деятельности Google, говорится на веб-сайта компании. Там же указано, что по этим же причинам для компании важно знать, где вы находитесь. Она утверждает, что использует эту информацию для всяких полезных вещей, типа безопасности и настроек языка и, конечно, продажи рекламы. Также Google продаёт рекламодателям возможность оценивать степень достижения кампанией цели (то есть, вас), и смотреть, как часто люди заходят в физические магазины
анонимно путём агрегации информации. Но только если вы этого захотите (или забудете отключить эту опцию).

Google Maps есть альтернативы, но не такие хорошие


Иногда для проблемных приложений есть альтернативы. Например, есть альтернатива WhatsApp, но не Google Maps. Настройки конфиденциальности у Apple Maps жёстче, но для Android таких карт нет. Приложения типа Here WeGo и OsmAnd тоже собирают информацию, а пользоваться ими не так угодно. Но если вы любите ходить пешком, предпочитая быть в офлайне, то OsmAnd и Maps.me, по крайней мере, покажут вам направления без подключения к интернету.
Подробнее..
Категории: Геоинформационные сервисы , Конфиденциальность , Слежка , Личные данные , Google maps

Библиотека дляработы сiOS-пермишенами, отидеи дорелиза (часть1)

07.12.2020 20:14:08 | Автор: admin

Привет! Из этого мини-цикла статей ты узнаешь:

  • Как унаследовать Swift-класс не целиком, а лишь то в нём, что тебе нужно?

  • Как позволить юзеру твоей CocoaPods- или Carthage-библиотеки компилировать лишь те её части, что он действительно использует?

  • Как раздербанить ресурсы iOS, чтобы достать оттуда конкретные системные иконки и локализованные строки?

  • Как поддержать completion blocks даже там, где это не предусмотрено дефолтным API системных разрешений?

А вообще, здесь о том, как я попытался написать ультимативную библиотеку для работы с пермишенами в iOS с какими неожиданностями столкнулся и какие неочевидные решения нашёл для некоторых проблем. Буду рад, если окажется интересно и полезно!

Немного о самой либе

Однажды мне пришла в голову следующая мысль всем мобильным разработчикам то и дело приходится работать с системными разрешениями. Хочешь использовать камеру? Получи у юзера пермишен. Решил присылать ему уведомления? Получи разрешение.

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

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

В итоге я решил написать собственную библиотеку. Попытаться сделать идеально. Буду благодарен, если напишете в комментариях, получилось ли. А вообще, PermissionWizard...

  • Поддерживает новейшие фичи iOS 14 и macOS 11 Big Sur

  • Отлично работает с Mac Catalyst

  • Поддерживает все существующие типы системных разрешений

  • Валидирует твой Info.plist и защищает от падений, если с ним что-то не так

  • Поддерживает коллбэки даже там, где этого нет в дефолтном системном API

  • Позволяет не париться о том, что ответ на запрос какого-нибудь разрешения вернётся вневедомом потоке, пока ты его ждёшь, например, в DispatchQueue.main

  • Полностью написан на чистом Swift

  • Обеспечивает унифицированное API вне зависимости от типа разрешения, с которым ты прямо сейчас работаешь

  • Опционально включает нативные иконки и локализованные строки для твоего UI

  • Модульный, подключай лишь те компоненты, что тебе нужны

Но перейдём наконец-то к действительно интересному...

Как унаследовать класс не целиком, а лишь то в нём, что тебе нужно?

Начав работать над PermissionWizard, я довольно быстро понял, что для большинства поддерживаемых типов разрешений мне нужны одни и те же элементы:

  • Свойство usageDescriptionPlistKey

  • Методы checkStatus и requestAccess

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

Кроме того, я собирался задокументировать каждый метод, каждое свойство в библиотеке, а поскольку Swift и Xcode не позволяют переиспользовать комментарии к коду, подобное наследование убивает сразу двух зайцев мне не нужно из класса в класс копировать одни итеже комментарии.

Только вот оказалось всё сложнее, чем можно было ожидать:

  • Некоторые типы пермишенов (например, дом и локальная сеть) не позволяют проверить текущий статус разрешения, не выполнив собственно запрос на доступ к нему, и унаследованное объявление checkStatus оказывается в таком случае неуместным. Оно лишь сбивает с толку торчит в автоподстановке, хотя не имеет имплементации.

  • Для работы с пермишеном геолокации не годится стандартное объявление requestAccess(completion:), поскольку для запроса на доступ необходимо определиться, нужен он нам всегда, или только когда юзер активно пользуется приложением. Здесь подходит requestAccess(whenInUseOnly:completion:), но тогда опять-таки выходит, что унаследованная перегрузка метода болтается не в тему.

  • Пермишен на доступ к фотографиям использует сразу два разных plist-ключа один на полный доступ (NSPhotoLibraryUsageDescription) и один, чтобы только добавлять новые фото и видео (NSPhotoLibraryAddUsageDescription). Видим, что опять-таки наследуемое свойство usageDescriptionPlistKey получается лишним логичнее иметь два отдельных и с более говорящими названиями.

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

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

class SupportedType {    func requestAccess(completion: (Status) -> Void) { }}final class Bluetooth: SupportedType { ... }final class Location: SupportedType {    @available(*, unavailable)    override func requestAccess(completion: (Status) -> Void) { }        func requestAccess(whenInUseOnly: Bool, completion: (Status) -> Void) { ... }}

Переопределение метода, помеченное атрибутом @available(*, unavailable), не только делает его вызов невозможным, возвращая при сборке ошибку, но и полностью скрывает его из автоподстановки в Xcode, то есть фактически как будто исключает метод из наследования.

Разумеется, я не открыл здесь никакой Америки, однако решение оказалось не слишком широко известным, поэтому решил им поделиться.

Как позволить юзеру твоей CocoaPods- или Carthage-библиотеки компилировать лишь те её части, что он действительно использует?

PermissionWizard поддерживает 18 видов системных разрешений от фото и контактов до Siri и появившегося в iOS 14 трекинга. Это в свою очередь означает, что библиотека импортирует и использует AVKit, CoreBluetooth, CoreLocation, CoreMotion, EventKit, HealthKit, HomeKit и ещё много разных системных фреймворков.

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

CocoaPods

В случае с этим менеджером зависимостей решение найти относительно просто. Разбиваем библиотеку на независимые компоненты, позволяя выборочно устанавливать лишь те, что нужны разработчику. Заодно отделяем компонент с иконками и локализованными строками, поскольку нужны они далеко не всем.

pod 'PermissionWizard/Assets' # Icons and localized stringspod 'PermissionWizard/Bluetooth'pod 'PermissionWizard/Calendars'pod 'PermissionWizard/Camera'pod 'PermissionWizard/Contacts'pod 'PermissionWizard/FaceID'pod 'PermissionWizard/Health'pod 'PermissionWizard/Home'pod 'PermissionWizard/LocalNetwork'pod 'PermissionWizard/Location'pod 'PermissionWizard/Microphone'pod 'PermissionWizard/Motion'pod 'PermissionWizard/Music'pod 'PermissionWizard/Notifications'pod 'PermissionWizard/Photos'pod 'PermissionWizard/Reminders'pod 'PermissionWizard/Siri'pod 'PermissionWizard/SpeechRecognition'pod 'PermissionWizard/Tracking'

В свою очередь, Podspec нашей библиотеки (файл, описывающий её для CocoaPods) выглядит примерно следующим образом:

Pod::Spec.new do |spec|    ...    spec.subspec 'Core' do |core|    core.source_files = 'Source/Permission.swift', 'Source/Framework'  end    spec.subspec 'Assets' do |assets|    assets.dependency 'PermissionWizard/Core'    assets.pod_target_xcconfig = { 'SWIFT_ACTIVE_COMPILATION_CONDITIONS' => 'ASSETS' }        assets.resource_bundles = {      'Icons' => 'Source/Icons.xcassets',      'Localizations' => 'Source/Localizations/*.lproj'    }  end    spec.subspec 'Bluetooth' do |bluetooth|    bluetooth.dependency 'PermissionWizard/Core'    bluetooth.pod_target_xcconfig = { 'SWIFT_ACTIVE_COMPILATION_CONDITIONS' => 'BLUETOOTH' }    bluetooth.source_files = 'Source/Supported Types/Bluetooth*.swift'  end    ...    spec.default_subspec = 'Assets', 'Bluetooth', 'Calendars', 'Camera', 'Contacts', 'FaceID', 'Health', 'Home', 'LocalNetwork', 'Location', 'Microphone', 'Motion', 'Music', 'Notifications', 'Photos', 'Reminders', 'Siri', 'SpeechRecognition', 'Tracking'  end

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

#if BLUETOOTH    final class Bluetooth { ... }#endif

Carthage

Здесь всё оказывается немного сложнее. Этот менеджер зависимостей не поддерживает дробление библиотек, если только не разделить их по-настоящему на разные репозитории, к примеру. Выходит, нужен какой-то обходной путь.

В корне нашей либы создаём файл Settings.xcconfig и пишем в нём следующее:

#include? "../../../../PermissionWizard.xcconfig"

По умолчанию Carthage устанавливает зависимости в директорию Carthage/Build/iOS, так что вышеприведённая инструкция ссылается на некий файл PermissionWizard.xcconfig, который может быть расположен юзером нашей библиотеки в корневой папке своего проекта.

Очертим и его примерное содержимое:

ENABLED_FEATURES = ASSETS BLUETOOTH ...SWIFT_ACTIVE_COMPILATION_CONDITIONS = $(inherited) $(ENABLED_FEATURES) CUSTOM_SETTINGS

Наконец, необходимо указать нашей либе, что она должна ссылаться на Settings.xcconfig как на дополнительный источник настроек для сборки. Чтобы это сделать, добавляем в проект библиотеки ссылку на указанный файл, а затем открываем project.pbxproj любым удобным текстовым редактором. Здесь ищем идентификатор, присвоенный только что добавленному в проект файлу, как на примере ниже.

A53DFF50255AAB8200995A85 /* Settings.xcconfig */ = {isa = PBXFileReference; lastKnownFileType = text.xcconfig; path = Settings.xcconfig; sourceTree = "<group>"; };

Теперь для каждого имеющегося у нас блока XCBuildConfiguration добавляем строку с базовыми настройками по следующему образцу (строка 3):

B6DAF0412528D771002483A6 /* Release */ = {isa = XCBuildConfiguration;baseConfigurationReference = A53DFF50255AAB8200995A85 /* Settings.xcconfig */;buildSettings = {...};name = Release;};

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

#if BLUETOOTH || !CUSTOM_SETTINGS    final class Bluetooth { ... }#endif

На этом пока всё

В следующей части поговорим о том, как я среди 5 гигабайт прошивки iOS 14 нашёл нужные мне локализованные строки и как добыл иконки всех системных пермишенов. А ещё расскажу, как мне удалось запилить requestAccess(completion:) даже там, где дефолтное системное API разрешений не поддерживает коллбэки.

Спасибо за внимание!

Подробнее..
Категории: Разработка под ios , Xcode , Swift , Библиотеки , Конфиденциальность , Приватность , Cocoapods , Наследование , Атрибуты , Permissions , Разрешения , Carthage , Info.plist

Перевод Как саботировать данные, которые технологические гиганты используют для слежки за вами

23.03.2021 20:04:37 | Автор: admin

Алгоритмы не работают без качественных данных. Общественность может использовать их, чтобы требовать перемен.

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

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

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

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

  • Бойкот данных (Data strikes), вдохновленный забастовками рабочих. Он включает в себя скрытие или удаление вашей личной информации, чтобы технологическая компания не могла ее использовать. Можно покинуть платформу или установить инструменты для защиты конфиденциальности.

  • Порча данных (Data poisoning), которая включает в себя передачу бессмысленной или вредоносной информации. Так, можно пользоваться расширением для браузера AdNauseam. Оно нажимает на каждое рекламное объявление, показанное вам, и тем самым сбивает с толку алгоритмы таргетинга Google.

  • Осознанная публикация данных (Conscious data contribution), или предоставление значимых данных конкуренту платформы, против которой вы хотите протестовать. Загрузите ваши фотографии в Tumblr вместо Facebook, например.

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

Но что произойдет, если миллионы людей будут координировать свои действия и отравят пул данных одной компании? Это даст им возможность отстоять свои требования.

Возможно, уже несколько раз удавалось это сделать. В январе миллионы пользователей удалили учетные записи WhatsApp и перешли к конкурентам, включая Signal и Telegram. Это произошло после того, как Facebook (владелец популярного мессенджера прим. пер) объявил, что откроет доступ к данным WhatsApp всей компании. Массовый исход вынудил Facebook отложить внесение изменений в политику.

Буквально на этой неделе Google также объявил, что прекратит отслеживать людей в сети и таргетировать рекламу. Пока неясно, реальное ли это изменение или ребрендинг. Винсент отмечает, что широкое использование инструментов вроде AdNauseam могло повлиять на это решение, так как снизило эффективность алгоритмов компании. (Конечно, точно сказать трудно. Только технологическая компания действительно знает, насколько эффективно использование данных повлияло на систему, говорит исследователь).

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

Приятно видеть такое исследование, говорит Али Алхатиб, научный сотрудник Центра прикладной этики данных Университета Сан-Франциско, не принимавший участия в исследовании. Интересно наблюдать, что авторы обращаются к коллективному или целостному подходу. Мы можем портить данные массово и предъявлять требования, угрожая этим. Потому что это наша информация, и вся вместе она формирует общий пул.

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

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

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

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

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

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

Читайте другие наши переводы на тему искусственного интеллекта:

Напоминаем, что для читателей Хабрав магазине гаджетов Madrobotsдействуетскидка 5%на все продукты.Введите промокод: HABR

Подробнее..
Категории: Apple , Машинное обучение , Big data , Google , Amazon , Большие данные , Конфиденциальность , Блог компании madrobots

Перевод FLeet гроза Большого Брата?

23.02.2021 18:07:11 | Автор: admin


Новое исследование EPFL и INRIA показывает, что наши мобильные устройства могут выполнять обучение моделей самостоятельно, являясь частью распределённой сети и не раздавая наши данные технологическим компаниям.


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


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


Исследования, проведённые в Лаборатории распределённых вычислений и Лаборатории масштабируемых вычислительных систем (Distributed Computing Laboratory и Scalable Computing Systems Laboratory), входящих в состав Школы вычислительных и коммуникационных наук (School of Computer and Communication Sciences) (IC) EPFL и государственный институт исследований в информатике и автоматике (INRIA) Франции, показали, что машинное обучение, то есть выполнение компьютерных алгоритмов, которые работают всё лучше и лучше благодаря опыту, который они накапливают возможно на наших мобильных устройствах, в режиме реального времени; без ущерба функциональности и без необходимости делиться с кем-то нашими данными.


Совместная лаборатория EPFL/INRIA, представляет FLeet революцию в распределённом машинном обучении глобальную модель, обученную с помощью обновлений, вычисленных на мобильных устройствах. Данные при этом остаются только на устройствах. Распределённое машинное обучение очень привлекательно преимуществами в области конфиденциальности, но поскольку оно разработано таким образом, чтобы не влиять на энергопотребление и производительность мобильных устройств, оно не подходит для приложений, требующих частого обновления, например, для рекомендации новостей.


FLeet сочетает конфиденциальность стандартного распределённого обучения и точность онлайн-обучения благодаря двум основным компонентам: I-Prof это новый легковесный профайлер, который прогнозирует и контролирует влияние задач обучения на устройство, и AdaSGD устойчивый к отложенным обновлениям адаптивный алгоритм обучения.


Один из авторов статьи, профессор EPFL Рашид Геррауи (Rachid Guerraoui), напоминает, что сегодня наши смартфоны обладают как данными, так и питанием от батареи, которое позволяет выполнять распределённое машинное обучение.


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


Профессор Анна-Мари Кермаррек, также автор статьи, рассказывает: Мы показали, что если сложим мощность телефонов вместе, они начнут составлять большую вычислительную мощность, которая будет соответствовать мощности Google, и это даст людям альтернативу не полагаться на централизованные мощные компьютерные фермы. Это поистине коллективное обучение, когда локальные модели агрегируются и вносят вклад в глобальную модель, но вы не делитесь сырыми данными, защищая конфиденциальность, а это огромная мотивация для разработки архитектуры подобного рода.


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


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

Подробнее..
Категории: Гаджеты , Машинное обучение , Распределенные системы , Конфиденциальность

Как в системах, построенных на технологии блокчейн, осуществлять операции с ценностями, не разглашая их содержание?

13.10.2020 16:15:52 | Автор: admin
Последние годы в мире активно развивается технология блокчейн, которая представляет собой распределенную архитектуру, состоящую из множества равноправных узлов. Узлы в свою очередь осуществляют обмен информацией в виде транзакций, содержащих информацию как о движении ценностей, так и о выполнении смарт-контрактов. При этом сама технология обеспечивает группировку этих транзакций в блоки, выработку консенсусов с целью включения блоков в существующие последовательности, выбор единственно верной цепочки блоков (блокчейн) и обеспечение распространения верной цепочки блоков между всеми узлами.

Технология блокчейн позволяет обеспечить наличие в каждом узле корректной цепочки блоков, что также можно назвать технологией распределенного реестра.

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

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

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

image

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

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

Особенности использования Протокола с нулевым разглашением секрета

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

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

Шаги раунда:
1. Доказывающий производит генерацию одноразового секретного ключа, а также одноразового открытого ключа, который затем отправляет Проверяющему;
2. Проверяющий получает одноразовый открытый ключ от Доказывающего и затем производит генерацию случайного бита, который затем посылает Доказывающему;
3. Доказывающий получает бит информации и производит над ним вычисления.

Получившийся результат Доказывающий отправляет Проверяющему для проверки.

Во всех раундах проверки вероятность правильного ответа равна 50 %, то есть в каждом раунде Доказывающий может обладать знанием истины с вероятностью 50 %.

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

Основными проблемами при использовании протоколов с нулевым разглашением секрета являются:
1. Требуемая длина открытого ключа;
2. Уверенность в том, что секрет не был разглашен каким-то другим способом.

Рассмотрим теоретическую составляющую нескольких протоколов с нулевым разглашением секрета и составим сравнительную таблицу их характеристик.

Протокол zkSNARKs

zkSNARKs означает неинтерактивный аргумент знания с нулевым разглашением.

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

Для работы протокол должен удовлетворять основным требованиям нулевого разглашения секрета.

Например, был создан смарт-контракт. Пользователь сможет получить платеж, если сделает определенные действия. Что делать, если пользователь не хочет раскрывать детали, потому что они являются конфиденциальными и секретными для конкурентов?

Для этого используется протокол с нулевым разглашением zkSNARKs, который доказывает, что шаги были исполнены согласно условиям смарт-контракта, не раскрывая, что это за действия. Он может просто показать часть процесса, не показывая весь процесс, и доказать, что пользователь честен.

zkSNARKs состоит из 3 алгоритмов: G, P и V.

Генератор (C программа, input, которая не должна раскрываться (конфиденциально)):

(pk,vk) = G(,C)

Доказывающий (x общедоступный input, w секретное заявление, которое нужно доказать, но не рассказывать):

= P(pk,x,w) доказательство prf

Проверяющий:

V(vk,x,) == ( w s.t.C(x,w)) true или false

G является генератором ключей, принимающим input (который не должен раскрываться ни при каких обстоятельствах) и программу C. Затем генерируется два общедоступных ключа: ключ проверки pk (для пруфера) и доказательный ключ vk (для верификатора). Эти ключи являются доступными для любой из заинтересованных сторон.

P это тот, кто будет использовать 3 элемента в качестве входных данных. Проверяющий ключ pk, случайный input x, который является общедоступным, и заявление, которое нужно доказать, но не рассказывать, что это на самом деле. Назовем этого оператора w. Алгоритм P порождает доказательство prf такое, что: prf = P (pk,x,w).

Алгоритм верификатора V возвращает логическую переменную. Логическая переменная имеет только два варианта: она может быть TRUE (правда) или FALSE (ложь). Итак, верификатор принимает ключ, input X и доказательство prf в качестве входных данных, таких как: V(vk,x,prf). А затем определяет, правда это или ложь.

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

Таким образом, запуск генератора должен являться безопасным процессом, защищенным от того, чтобы кто-то мог узнать или украсть параметр .

Протокол zkSTARKs

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

zkSTARKs не полагаются на пары закрытых и открытых ключей (такие как ECDSA), но полагаются на хеширование для интерактивных решений, устойчивое к столкновениям,, и случайную модель оракула (которая обычно используется вместо общих криптографических хеш-функций, где для вывода оракула требуются строгие предположения о случайности) для неинтерактивных доказательств (zknSTARKs, n = неинтерактивный), поэтому zkSTARKs могут быть устойчивы к атакам квантовых компьютеров.

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

Можно выделить четыре категории, связанные с масштабируемостью (результаты, полученные из документа zkSTARKs):
1. Сложность арифметической схемы (в системах zkSNARK и zkSTARK код для создания программ zk написан таким образом, чтобы они могли разбить на схемы, а затем вычислить фактически сложность схемы выше ее вычислительной эффективности;
2. Сложность связи (по мере роста объема вычислений растет и сложность связи zkSNARK линейным способом, в отличие от zkSTARKs, который растет незначительно с ростом размера вычислений);
3. Доказательная сложность (zkSTARKs по сравнению с zkSNARK примерно в 10 раз быстрее, чем размер вычислений);
4. Сложность верификатора (По мере роста объема вычислений zkSTARKs растут лишь незначительно по сравнению с zkSNARK, которые имеют тенденцию к линейному росту, что является существенным преимуществом zkSTARKs по сравнению с zkSNARK, когда дело доходит до установки времени).

Протокол zkSTARKs планировали использовать в Ethereum в проверяемых вычислениях и потенциально безопасных / анонимных транзакциях, а также в приложениях Dapps, где важна конфиденциальность, таких как веб-браузер Brave, использующий токен Basic Attention.

Существует новая компания под названием StarkWare Industries, которая стремится решить некоторые проблемы с использованием ZK-STARK (одной из которых является размер доказательства), а также коммерциализировать технологию, которая может быть использована во многих отраслях, включая реализации систем распределённых реестров.

Технология Bulletproofs

Подразделение разработок распределённых реестров банка ING экспериментирует с технологией Bulletproofs (в переводе с англ. пуленепробиваемый), которая ориентирована на конфиденциальность и основана на современных криптографических алгоритмах.

Технология Bulletproofs основана на работах Джонатана Бутла (Jonathan Bootle) и других авторов от 2016 года, посвященных повышению эффективности использования дискретного логарифмирования, которое лежит в основе доказательства с нулевым разглашением. и представляет собой более эффективную форму этого самого доказательства.

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

Доказательства Bulletproofs представлены в гораздо более общем виде, нежели доказательства диапазона и могут использоваться для произвольных утверждений с нулевым знанием. По своей эффективности технология сопоставима с zkSNARKs или zkSTARKs, но имеет встроенную поддержку открытых ключей на эллиптической кривой и обязательств Педерсена (поэтому, как правило, отсутствует необходимость осуществлять вычисления эллиптической кривой внутри проверенной программы). Также, в отличие от zkSNARKs, доказательства Bulletproofs имеют полный 128-битный уровень криптостойкости в соответствии со стандартными предположениями без использования доверенной установки. И, в отличие от zkSTARKs, они достаточно быстры, чтобы можно было доказывать и проверять разумные по масштабу задачи на обычном вычислительном оборудовании.

По сравнению с технологией ZKP, которая требует больших вычислительных мощностей, технология Bulletproofs примерно в 10 раз быстрее, так как позволяет проводить транзакции без обмена платежными данными.
Ключевые пункты по данной технологии (протоколу):
в основе технологии Bulletproofs лежат общие принципы доказательства с нулевым разглашением (как и в zkSNARKs);
технология может использоваться для расширения многосторонних протоколов, таких как мультиподписи или условные платежи с нулевым знанием;
Bulletproofs предоставляет гораздо более эффективную версию доказательств диапазона конфиденциальных транзакций (при использовании пакетной верификации скорость проверки увеличивается более чем в 23 раза);
такие доказательства диапазона могут быть объединены внутри транзакции, при этом её размер будет расти логарифмически;
при должном агрегировании, таком как Provisions, пакетная верификация дает более чем 120-кратный прирост скорости по сравнению с прежними доказательствами.

Сравнительная таблица характеристик протоколов

Составим сравнительную таблицу с характеристиками рассмотренных протоколов с нулевым разглашением секрета

image

Выводы

1. zk-SNARKs и zk-STARKs имеют множество областей применения, в том числе для целей реализации простых электронных подписей, а также создания систем электронного документооборота, предполагающего обеспечение конфиденциальности информации.
2. В целом, протоколы с нулевым разглашением являются очень перспективными и становятся более практичными для использования в системах на основе технологии распределенного реестра. На данный момент каждая реализация по-своему выделяется, однако, все они требуют ресурсов, и существует необходимость в эффективных решениях с нулевым диапазоном знаний.
3. Одним из недостатков, на наш взгляд, выступает отсутствие реализации Протокола с нулевым разглашением секрета, использующего отечественные криптографические алгоритмы и средства криптографической защиты информации, что является существенным ограничением для применения протокола (к примеру, для обработки информации, защищаемой в соответствии с законодательством Российской Федерации).

Список литературы
1. ГОСТ 34.13-2018 Информационная технология (ИТ). Криптографическая защита информации. Режимы работы блочных шифров // docs.cntd.ru URL: docs.cntd.ru/document/1200161709 (дата обращения: 31.05.2020);
2. Recommendation for Key Management Part 1: General // nvlpubs.nist.gov URL: nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r5.pdf (дата обращения: 11.05.2020);
3. ГОСТ Р ИСО/МЭК 12207-2010 // docs.cntd.ru/ URL: docs.cntd.ru/document/gost-r-iso-mek-12207-2010 (дата обращения: 11.05.2020);
4. Recommendation for Cryptographic Key Generation // nvlpubs.nist.gov/ URL: nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-133r1.pdf (дата обращения: 11.05.2020);
5. Recommendation for Key Management Part 2 Best Practices for Key Management Organizations // nvlpubs.nist.gov URL: nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt2r1.pdf (дата обращения: 11.05.2020);
6. Security Requirements for Cryptographic Modules // nvlpubs.nist.gov URL: nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.140-2.pdf (дата обращения: 11.05.2020);
7. Payment Card Industry (PCI) Data Security Standard // pcisecuritystandards.org URL: www.pcisecuritystandards.org/documents/PCI_DSS_v3-2-1.pdf?agreement=true&time=1589494129851 (дата обращения: 11.05.2020);
8. Управление ключами шифрования и безопасность сети // intuit.ru URL: www.intuit.ru/studies/courses/553/409/info (дата обращения: 11.05.2020).
9. Базовые конструкции протоколов распределения ключей // cryptowiki.net/ URL: cryptowiki.net/index.php?title=Базовые_конструкции_протоколов_распределения_ключей (дата обращения: 11.05.2020);
10. Kerberos_(protocol) // en.wikipedia.org URL: en.wikipedia.org/wiki/Kerberos_(protocol) (дата обращения: 11.05.2020)
11. RFC5280 Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile;
12. Recommendation for Key Management Part 3: Application-Specific Key Management Guidance // nvlpubs.nist.gov URL: nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57Pt3r1.pdf (дата обращения: 11.05.2020);
13. Blockchain reference architecture // ibm.com URL: www.ibm.com/cloud/architecture/files/blockchain-architecture-diagram.pdf (дата обращения: 24.05.2020).
14. Key management // cloud.ibm.com URL: cloud.ibm.com/docs/blockchain?topic=blockchain-ibp-security (дата обращения: 24.05.2020);
15. Воронов, Д. С. Обзор требований безопасности для криптографических модулей / Д. С. Воронов. Текст: непосредственный // Молодой ученый. 2016. 1 (105). С. 141-143. URL: moluch.ru/archive/105/24663 (дата обращения: 31.05.2020).
16. CKMS Система управления криптографическими ключами // www.cryptomathic.com URL: www.cryptomathic.com/hubfs/Documents/Product_Sheets/Cryptomathic_CKMS_-_Product_Sheet.pdf (дата обращения: 31.05.2020);
17. Аппаратные модули безопасности HSM // www.croc.ru URL: www.croc.ru/promo/insafety/design/hardware-security-module (дата обращения: 31.05.2020);
18. Функционально технические требования к HSM // cbr.ru URL: cbr.ru/Content/Document/File/104755/FT_35.pdf (дата обращения: 30.05.2020);
19. AWS Key Management Service // aws.amazon.com URL: aws.amazon.com/ru/kms (дата обращения: 30.05.2020);
20. Руководящий документ. Безопасность информационных технологий. Критерии оценки безопасности информационных технологий // zakonbase.ru URL: zakonbase.ru/content/part/1250444 (дата обращения: 31.05.2020);
21. Diffie Hellman Protocol // mathworld.wolfram.com URL: mathworld.wolfram.com/Diffie-HellmanProtocol.html (дата обращения: 31.05.2020);
22. STS Protocol // archive.dimacs.rutgers.edu URL: archive.dimacs.rutgers.edu/Workshops/Security/program2/boyd/node13.html (дата обращения: 31.05.2020);
23. The Needham-Schroeder Protocol // www.cs.utexas.edu URL: www.cs.utexas.edu/~byoung/cs361/lecture60.pdf (дата обращения: 31.05.2020);
24. Otway Rees protocol // www.lsv.fr URL: www.lsv.fr/Software/spore/otwayRees.pdf (дата обращения: 31.05.2020);
25. Payment Card Industry (PCI) PTS HSM Security Requirements // www.pcisecuritystandards.org URL: www.pcisecuritystandards.org/documents/PTS_HSM_Technical_FAQs_v3_May_2018.pdf (дата обращения: 31.05.2020);
26. Что такое zk-SNARK? // z.cash/ru URL: z.cash/ru/technology/zksnarks (дата обращения: 31.05.2020);
27. Что такое zk-SNARKs и zk-STARKs? // academy.binance.com/ru URL: academy.binance.com/ru/blockchain/zk-snarks-and-zk-starks-explained (дата обращения: 31.05.2020);
28. Bulletproofs: Short Proofs for Confidential Transactions and More // web.stanford.edu URL: web.stanford.edu/~buenz/pubs/bulletproofs.pdf (дата обращения: 31.05.2020);
29. Что такое технология распределенного реестра Автор Татьяна Чепкова // beincrypto.ru URL: beincrypto.ru/learn/chto-takoe-tehnologiya-raspredelennogo-reestra (дата обращения: 31.05.2020);
30. 12 консенсус-протоколов для распределенных систем // dou.ua URL: dou.ua/lenta/articles/12-konsensus-protocols (дата обращения: 31.05.2020);
31. СТ РК ISO/IEC 11770-1-2017. Информационные технологии Методы обеспечения безопасности Менеджмент ключей Часть 1 СТРУКТУРА // www.egfntd.kz URL: www.egfntd.kz/rus/tv/391980.html?sw_gr=-1&sw_str=&sw_sec=24 (дата обращения: 31.05.2020);
32. Consensus algorithm // whatis.techtarget.com URL: clck.ru/Nvade (дата обращения: 31.05.2020);
33. Introduction to Zero Knowledge Proof: The protocol of next generation Blockchain // medium.com URL: medium.com/@kotsbtechcdac/introduction-to-zero-knowledge-proof-the-protocol-of-next-generation-blockchain-305b2fc7f8e5 (дата обращения: 31.05.2020).
Подробнее..
Категории: Криптография , Конфиденциальность , Блог компании россельхозбанк

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru