Кульминация наступает, когда приходят «большие дяди» традиционной ориентации и покупают весь проект с потрохами за хорошие деньги. Тогда все пираты идут с полными сундуками пиастров искать счастья на воле, а те, кто душой прикипел к проекту, остаются тянуть лямку. Например, Mojang. Хотя там и так было видно, кто пират в душе.
Данных с такой точностью достаточно, чтобы найти вас в день получки со злым умыслом, заниматься чем угодно с вашей женой и даже напугать вашу канарейку пока вы на работе. Уже сколько было написано на эту тему, но всё «неуловимые Джо» не переведутся. Никому скан вашего паспорта уже не нужен. Достаточно «анонимизированных данных», по которым можно не только определить где находится конкретный человек, но и чем он занимается и с кем дружит.
Вы совершенно правы! Вот, посмотрите, в той самой политике конфиденциальности сказано:
«Настоящая Политика применима только к информации, обрабатываемой в ходе использования Сервисов Яндекса.»
А теперь ещё раз посмотрите в текст статьи: «Сервис Яндекса по сбору «статистики» запускается в фоновом режиме при загрузке телефона и не требует запуска самого приложения для работы».
Я понимаю, что с вашими жизненными установками вы не признаете противоречия, поэтому я предлагаю вам проконсультироваться с юристом, задав ему простой вопрос: является ли факт установки приложения (не запуска, уставновки, это важно) синонимом использования сервиса в данном случае.
NSA стандарт не диктует, их аудиторы требуют определённый уровень безопасности, а выбор средств остаётся на совести компании. Но мы уходим в сторону.
По технической части решения здесь есть с кем поговорить и так, меня же смущает вот что: у меня сложилось мнение, что современному пользователю интернета меньше всего хочется ставить ещё одно приложение. Тот же Google Authenticator есть под все актуальные платформы, RFC6238 реализован, наверное, уже на всех языках программирования, и, что немаловажно, тот же самый RFC используется не только гуглом. То есть можно иметь одно приложение для всех сервисов, при чём для тех, кому по каким-то причинам не подходит GA есть ещё и альтернативы (хотя они и так себе, если честно). С другой стороны, ваши опасения тоже небезпочвенны. Заставить пользователя не исповедовать религию Неуловимого Джо сложно, практически невозможно без насилия, но я гуманист и такой подход не люблю. Как мне кажется, хорошим выходом было бы поддерживать RFC6238 вне зависимости от крутости вашего решения, как на сервисе (ну вдруг мне мама не велит Yandex Authenticator ставить?), так и в вашем приложении (а может быть наоборот, не велит ставить GA). В конце концов, наличие достойной альтернативы GA пошло бы только на пользу.
Не вижу повода для сарказма. У Яндекса вместо NSA есть ФСБ, требования (sic!) которой вам либо уже надо учитывать, либо рано или поздно придётся. У меня нет цели раскритиковать ваше решение. Мне, например, было бы интересно посмотреть, можно ли (особенно при вашем размере пользовательской базы) эффективно поддерживать оба решения, и как это реализовать на практике.
Если отвлечься на секунду от задач Яндекса, то, в случае именно двухстадийной аутентификации, доступ к определёным ресурсам можно ограничить таким образом, чтобы для прохождения второй стадии нужено было присутствие другого человека (например, супервайзера с токеном, санкционирующего таким образом доступ). Естественно, для защиты пользовательской переписки это избыточная мера. Поэтому, в частности, меня и заинтересовал ваш подход. Однако, учитывая мою целевую аудиторию, поддержка стандартного решения TOTP первична: кроме живых людей бывают ещё средства автоматизации, которые тоже используют одноразовые пароли для определённых действий, но вот нажать на кнопку в телефоне не могут. Впрочем, это опять же очень далеко от почты.
Ну кто-то может и «вынужден», а для кого-то это благо. Вопрос в области применения. И всё же, я повторю вопрос ещё раз: возможность пользоваться TOTP по RFC останется для тех, кому iOS и сканирование QR-кодов с экрана не очень интересны? Или Яндекс планирует полностью перейти на собственное решение?
наши usability-исследования показывают, что ничто так не раздражает пользователей, как промежуточный экран, дополнительные нажатия на кнопки и прочие «неважные», с его точки зрения, действия
То есть, проблема не в том, что RFC плохой, а в том, что пользователь, в среднем, не обладает достаточной компьютерной грамотностью. На вопрос о том, стоит ли решать эту проблему изобретением собственных методов (см. xkcd://927), или лучше заняться повышением компьютерной грамотности населения каждый пусть лучше ответит самостоятельно.
Из любопытства: а возможность пользоваться TOTP по RFC останется для тех, кому iOS и сканирование QR-кодов с экрана не очень интересны?
В Debian на Python не завязано никаких ключевых компонентов системы и в базовой системе его нет. Другие дистрибутивы в проде, естественно, не используем.
Да? Спасибо за уточнение. Я почему-то был уверен, что Ansible «всё своё носит с собой», в том числе и интерпретатор, но видимо я что-то не так понял, когда тестировал его для своих нужд. Раз так, то стало быть для ещё большего круга задач Ansible абсолютно не подходит, что вообще печально, так как среди альтернатив выбора попросту нет, только CFEngine, прародитель Puppet, Chef и, в конечном итоге, Ansible. Но у него и порог входа сильно выше уровня эникеев, и баги есть досадные, которые очень тяжело исправлять, и, как следствие, меньше коммьюнити и меньше набор готовых решений.
Я в курсе, что можно, но это считается инвертированной архитектурой со всеми вытекающими последствиями. Вообще же исторически pull в Ansible был добавлен не без драм (с пассажами вроде «только идиот может хотеть pull», это почти дословная цитата) и с тех пор живёт там по остаточному принципу. И это вполне понятно, будь pull основным методом работы Ansible, было бы ещё хуже — это значит, что буквально на каждый хост нужно было бы ставить Python с набором библиотек, которые совершенно ни к чему на, скажем, публично доступном рекурсивном DNS-сервере, хотя там и SSH не нужен, если уж на то пошло. Но как я уже писал, большинство проектов проблем с архитектурой Ansible не увидит даже в перспективе, и потому нет причин волноваться. Однако, нужно быть морально готовым к тому, что в какой-то момент придётся мигрировать на более приспособленный для серьёзного использования софт.
3) Работа по ssh — наиболее удобна и соответствует принципу «мы сами знаем когда нам что-то накатывать».
Если у вас три с половиной VPS на Амазоне, то нет никакой разницы чем пользоваться — push, pull, Ansible, Chef, скрипт на баше или руками. Если у вас распределённая система с большим количеством серверов, виртуальных машин, софта, конфигураций и так далее, то наиболее скалируемый и безопасный вариант — это pull с добровольной кооперацией, когда не вы, а сервер «знает» когда ему обращаться к центральному хранилищу за новыми инструкциями и когда эти инструкции выполнять, с механизмом, позволяющим начать этот процесс по команде из центра. К сожалению Ansible в такой конфигурации не блещет совсем. С другой стороны, ниша, в которой может быть достаточно Ansible или скрипта, достаточно велика и большинство проектов не успевает настолько вырасти, чтобы увидеть эти проблемы хотя бы на горизонте.
Reductio ad hominem, второй раз уже. Дело в том, что отсутствие у меня писательского таланта и, главное, желания писать статьи, никаким образом не делает вашу статью лучше, а владение предметом более глубоким.
Что может говорить хромой об искусстве Герберта фон Караяна? Если ему сразу заявить, что он хромой, он признает себя побеждённым. О чём может спорить человек, который не поменял паспорт? Какие взгляды на архитектуру может высказать мужчина без прописки? Пойманный с поличным, он сознается и признает себя побеждённым. И вообще, разве нас может интересовать мнение человека лысого, с таким носом? Пусть сначала исправит нос, отрастит волосы, а потом и выскажется.
Я бы не ставил вас перед этой дилеммой, если бы в статье были бы хоть какие-то примеры, где fish работает лучше, чем bash или zsh. Но нет, вместо них смешные безграмотные утверждения про алиасы-функции. А про конфигурационные файлы и дополнение команд и опций даже смешно не получилось — просто откровенная демонстрация полного незнания предмета, которое и помешало написать интересную статью. Впрочем, мы квиты. Читая вашу статью я тоже мучался дилеммой: то ли вы так эникейщиков троллите, то ли вы бредите. А оказалось, что закон По применим не только к фундаментализму.
«Настоящая Политика применима только к информации, обрабатываемой в ходе использования Сервисов Яндекса.»
А теперь ещё раз посмотрите в текст статьи: «Сервис Яндекса по сбору «статистики» запускается в фоновом режиме при загрузке телефона и не требует запуска самого приложения для работы».
Я понимаю, что с вашими жизненными установками вы не признаете противоречия, поэтому я предлагаю вам проконсультироваться с юристом, задав ему простой вопрос: является ли факт установки приложения (не запуска, уставновки, это важно) синонимом использования сервиса в данном случае.
По технической части решения здесь есть с кем поговорить и так, меня же смущает вот что: у меня сложилось мнение, что современному пользователю интернета меньше всего хочется ставить ещё одно приложение. Тот же Google Authenticator есть под все актуальные платформы, RFC6238 реализован, наверное, уже на всех языках программирования, и, что немаловажно, тот же самый RFC используется не только гуглом. То есть можно иметь одно приложение для всех сервисов, при чём для тех, кому по каким-то причинам не подходит GA есть ещё и альтернативы (хотя они и так себе, если честно). С другой стороны, ваши опасения тоже небезпочвенны. Заставить пользователя не исповедовать религию Неуловимого Джо сложно, практически невозможно без насилия, но я гуманист и такой подход не люблю. Как мне кажется, хорошим выходом было бы поддерживать RFC6238 вне зависимости от крутости вашего решения, как на сервисе (ну вдруг мне мама не велит Yandex Authenticator ставить?), так и в вашем приложении (а может быть наоборот, не велит ставить GA). В конце концов, наличие достойной альтернативы GA пошло бы только на пользу.
Если отвлечься на секунду от задач Яндекса, то, в случае именно двухстадийной аутентификации, доступ к определёным ресурсам можно ограничить таким образом, чтобы для прохождения второй стадии нужено было присутствие другого человека (например, супервайзера с токеном, санкционирующего таким образом доступ). Естественно, для защиты пользовательской переписки это избыточная мера. Поэтому, в частности, меня и заинтересовал ваш подход. Однако, учитывая мою целевую аудиторию, поддержка стандартного решения TOTP первична: кроме живых людей бывают ещё средства автоматизации, которые тоже используют одноразовые пароли для определённых действий, но вот нажать на кнопку в телефоне не могут. Впрочем, это опять же очень далеко от почты.
Для нас, но мы и не почтовые аккаунты с амурной перепиской таким образом защищаем. Кроме того, таковы требования NSA.
То, что есть сейчас — бета версия. Мы, конечно, будем смотреть на то, как это работает и выбирать лучшее решение.
Такое ощущение, что за вас это предложение отдел маркетинга написал :)
То есть, проблема не в том, что RFC плохой, а в том, что пользователь, в среднем, не обладает достаточной компьютерной грамотностью. На вопрос о том, стоит ли решать эту проблему изобретением собственных методов (см. xkcd://927), или лучше заняться повышением компьютерной грамотности населения каждый пусть лучше ответит самостоятельно.
Из любопытства: а возможность пользоваться TOTP по RFC останется для тех, кому iOS и сканирование QR-кодов с экрана не очень интересны?
Если у вас три с половиной VPS на Амазоне, то нет никакой разницы чем пользоваться — push, pull, Ansible, Chef, скрипт на баше или руками. Если у вас распределённая система с большим количеством серверов, виртуальных машин, софта, конфигураций и так далее, то наиболее скалируемый и безопасный вариант — это pull с добровольной кооперацией, когда не вы, а сервер «знает» когда ему обращаться к центральному хранилищу за новыми инструкциями и когда эти инструкции выполнять, с механизмом, позволяющим начать этот процесс по команде из центра. К сожалению Ansible в такой конфигурации не блещет совсем. С другой стороны, ниша, в которой может быть достаточно Ansible или скрипта, достаточно велика и большинство проектов не успевает настолько вырасти, чтобы увидеть эти проблемы хотя бы на горизонте.
— М. М. Жванецкий.