Любой бизнес включает в себя торговлю. Производство, которое никому ничего не продаёт, довольно быстро разорится :) И достаточно логично пытаться продать там и тем, где дороже, по крайней мере пока это не влечёт существенного роста затрат или необходимости расширения бизнеса. Мелкий опт с доставкой и крупный опт самовывозом не сильно отличаются по объёму и характеру, подробнее написал выше. Розница - да, отдельная тема и отдельный бизнес.
Что на каком юр. лице держать - вопрос технический и во многом зависит от тех самых набранных кредитов :)
По цветам есть большой разрыв между розницей и мелким оптом, т.к. в рознице нужен флорист, правильное расположение точек и те самые риски больше, но и маржа может быть совершенно безумная. Но это совершенно другой бизнес, в который точно как минимум не надо пытаться сразу лезть, ибо за двумя зайцами...
Мелкий же опт особо рисков не накладывает и новых компетенций не требует. Есть те же владельцы цветочных киосков и онлайн-доставка букетов, есть оптовые рынки. Первым по заявкам отвозишь каждый день сколько они заказывают с вечера - и это гарантированный сбыт, со вторыми быстро понимаешь, сколько надо привезти и почём выставить, чтобы точно продать. Но тут, конечно, легче, когда у тебя цветы растут рядом с Москвой, а не за 2000 км :)
Естественно, при этом всём должен быть следующий уровень воронки, позволяющий всё, что не получилось продать дороже, продать дешевле тем самым оптовикам с самовывозом. Но хотя бы часть имеет смысл попробовать реализовать более маржинальным способом, и потихоньку эту часть стараться увеличивать.
P.S. Это не теоретические рассуждения, у самого пара гектаров под цветы есть. В отличие от интервьюируемого товарища, десятки миллионов сразу в долг не брал, государственных субсидий/грантов боюсь как чёрт ладана, - так что расширяю объёмы потихоньку на свои и пока там не миллионы цветов, а именно мелкооптовый уровень.
Средняя мелкооптовая цена тюльпана в Мск перед 8 марта была, ЕМНИП, около 65 рублей. У интервьюируемого бизнесмена средняя продажная цена получилась 40 рублей, т.е. почти 100% своей себестоимости он отдал оптовым перепродавцам. Которые не выращивали, не рисковали, а просто наняли фуру, чтобы перевезти тюльпаны из симферопольской теплицы на какой-нибудь мелкооптовый рынок в Подмосковье. Непонятно, почему при таких-то затратах этот последний этап цепочки не был реализован самостоятельно.
Да, я посмотрел, что там есть очень производительные модели, и ценник приемлемый. Будем разбираться, чем там ещё готовые растворные узлы напичканы, что стóят по ляму на гектар и выше :)
Да, такое даже в готовых контроллерах полива есть (но это не наш путь :)
Реально интересует тема фертигации (подмеса удобрений), там много нюансов, а готовые решения сто́ят как чугунный мост, и у меня есть впечатление, что самому́ можно собрать и дешевле, и более гибкую систему. Но меня это в масштабе гектаров интересует. Посмотрю на дозаторы, которые Ваш заказчик с сити-фермой использует, любопытно, подойдут ли и что там с ценой на большие площади получится.
Тема автоматизации не раскрыта. А как же хотя бы датчики влажности почвы, чтобы не поливать в дождь? А синхронизация с онлайн прогнозом погоды, чтобы оптимизировать график полива? А датчики PH почвы, чтобы регулировать коэффициент подмеса в установках фертигации?
First, middle и last адаптируются под любую культуру, и это более или менее общепринято. У нас middle это отчество, во многих странах - второе личное имя. У нас last это фамилия, в Исландии - отчество. Если для нашей предметной области действительно важны различия между этими ситуациями, тогда надо городить сложную структуру данных, где для каждой части имени есть какой-то name_part_type, список которых мы ведём отдельно. В большинстве же случаев достаточно first/middle/last, и даже если мы не знаем, что именно в эти поля пишут жители какой-нибудь экзотической народности - можно не волноваться, наверняка они делают это каким-то общепринятым способом.
По поводу пароля, который И запомнен, И записан. Я что хотел донести - в таком случае это фактор, который двух типов одновременно. Можно или украсть листочек, или заставить сказать пароль пользователя. Т.е. 2FA с таким паролем-листочком вообще не строится никак. Добавь к нему физический ключ - украдут с листочком и без всякого фактора знания получат доступ. Добавь к нему второй не записанный пароль (или логин, или что угодно) - пользователь, ничем не обладая, чисто за счёт знания может выдать всё, что нужно для доступа.
По поводу копируемости - не отрицая её важности для планирования защиты, всё же считаю, что это вторичный критерий, на классификацию фактора сам по себе не влияющий. Довольно странно было бы считать, скажем, ключ ЭЦП на копируемом токене фактором знания (где тут знание вообще?), а на некопируемом - обладания (а на официально не копируемом, но есть народные средства, как? а если средства есть только у производителя токена?) Так что копируемость влияет на "силу" фактора обладания, но не меняет сам тип этого фактора. По крайней мере, это моё глубокое убеждение исходя из общей логики, глубоко в теорию не погружался.
Банковские карты с чипом, которые гораздо больше подходят под фактор обладания - вполне не копируются (штатными способами) и не бакапятся. Ничего, как-то живем.
Вот после появления виртуальных банковских карт, которые можно выпустить из приложения банка в любой точке мира, стало как-то ещё "ничего". А когда у меня лет 10 назад во Франции банкомат российскую карточку съел и не захотел отдавать - было крайне неприятно :) (это всё без корректировок на текущие печальные реалии, само собой, сейчас, как говорится, нам бы те проблемы...)
Тут, конечно, речь не про копирование, а про восстановление доступа, но это вопросы взаимосвязанные. По сути, любая процедура восстановления доступа - это просто дополнительный альтернативный фактор или набор факторов (и это тоже надо учитывать, а часто забывают).
Аргумент было, что если занудствовать, то фактор обладания - это то, чем можно воспользоваться, только украв или отобрав.
Да. Поэтому листочек с паролем, который мы ещё и наизусть помним, - это фактор владения ИЛИ обладания. И это самый худший случай, т.к. что к нему ни добавляй вторым фактором ("(владение ИЛИ обладание) И владение" или "(владение ИЛИ обладание) И обладание"), может получиться, что нам достаточно двух факторов одинакового типа, т.е. это не 2FA.
(А тот генератор, что у человека, так у него и остается - его никто не крал).
Ну ОК, добавим "или скопировав" :) Ключевой файл на флэшке, полный бекап телефона с Google Authenticator - всё это можно скопировать. Но чтобы скопировать - надо получить доступ. А чтобы узнать фактор знания - надо заставить / обмануть живого человека.
Т.е. фактор обладания защищает нас в ситуации, когда нас пытают, но мы успели съесть листочек, смыть в унитаз флэшку и разбить молотком ноут. А фактор знания - когда у нас всё перечисленное изъяли, но пытать нас не собираются. Как-то так вижу.
По этой причине, если возможно сделать бакап - то это уже не фактор обладания.
Почему? Это фактор обладания, просто присутствующий в нескольких экземплярах, что тоже надо учитывать при оценке рисков (где хранить бекапы). В подавляющем большинстве случаев невозможность сделать бекап влечёт куда более тяжёлые последствия (те, у кого умирала СИМка российского оператора или флэшка с неэкспортируемой ЭЦП за рубежом, поймут), но, опять же, зависит от сценария.
с тем же успехом могут украсть (заодно с паролями) и базу seed-ов для OTP, с которым, вроде, это не получается.
Моя надежда на то, что риск этого меньше, как я написал выше, основана на том, что если хранение паролей криворукий разработчик мог реализовать сам, то для TOTP он, вероятно, использовал стороннюю библиотеку, а то и сторонний сервис :)
Их тоже не нужно писать на листочке хранить плэйнтекстом и тд.
Только можно долго, упорно и бесполезно объяснять это пользователям, а можно внедрить обязательный TOTP и снять хотя бы какие-то риски (ещё, кстати, забыл ситуацию "поделиться своим паролем с коллегой, очень срочно надо", в результате которой пароль неконтролируемо расходится по рукам). Ну а п. 4-5 вообще не про это, тут никто не застрахован, даже если для одного себя любимого настраиваешь.
По этой логике и обычный пароль, если он записан на листочке, тоже фактор обладания.
Да, конечно, если мы его не помним, а каждый раз смотрим на листочек. Или пароль в базе парольного менеджера, не важно. Фактор знания - то, что у нас в голове и что мы можем рассказать. Фактор обладания - то, что мы можем потерять / у нас могут украсть или отобрать. Два разных устройства и листочек с паролем - это три фактора обладания, и это нам вообще не поможет, если все лежат в одной сумке, которую украли или изъяли.
Проблема с фактором знания в том, что он плохо масштабируется и никак не бекапится, поэтому мы и заменяем фактор знания на фактор обладания (плюс ослабленный фактор знания мастер-пароля), используя парольные менеджеры. И не так уж это плохо.
Ну а в случае, если у нас не физический ключ / локальный файл или пароль в голове, а доступ к облачному хранилищу / приложению - тут вообще сам чёрт ногу сломит, где знание, а где обладание :) Так что лучше, мне кажется, не привязываться к терминам, а реальные сценарии атак моделировать, они тоже у всех разные.
TOTP-код не записать на стикере, висящем на мониторе.
Фишинг существенно затрудняется (есть фишинговые сайты и с перехватом одноразовых кодов, но тут должна быть заточенная под конкретный сервис и незамедлительное использование кода атака).
Наличие TOTP не позволяет просто подсмотреть (вживую или через камеру наблюдения), как пароль вводится с клавиатуры (впрочем, парольный менеджер эту проблему решает и без TOTP)
Утечка со стороны удалённого сервиса может, теоретически, раскрыть пароль (если они там плейнтекстом хранятся), но не раскрыть TOTP (для чего, вероятно, используется сторонняя библиотека, разработчики которой поумнее).
Так что да, не панацея, но и небесполезно. В каждом случае надо смотреть, что и от каких атак мы защищаем, и в комплексе уже оценивать риски.
P.S. Ну и если строго про терминологию - пароль (без парольного менеджера) ещё может быть фактором знания, а вот TOTP-секрет - это 100% фактор обладания (файлом / приложением / базой / устройством).
2FA всё-таки не про разные устройства, а про разные факторы. Но в текущем разнообразии способов хранить пароли всё это очень условно.
Даже без TOTP менеджер паролей уже даёт нам два фактора - владение базой паролей и знание мастер-пароля для её расшифровки (второй, правда, ослаблен, т.к. мастер-пароль один на всех, но тем не менее). Если доступ к менеджеру паролей удалённый и сам защищён TOTP - опять другая картинка, которая не укладывается в обычную схему. А если база менеджера у нас на отдельной флэшке с аппаратным шифрованием и своим паролем? В общем, IMHO, в каждом случае надо смотреть на конкретные сценарии атаки и насколько та или иная схема в них помогает.
Так MS совершенно прекрасно умеет использовать не только свой Authenticator (ещё раз камень в огород Яндекса), но и гугловский и любой другой сторонний. Точно так же предлагает QR-код или текстовый секрет при настройке. Родное их приложение добавляет подтверждение входа без кода, просто всплывающим сообщением на смартфоне, а вот собственно TOTP-часть вполне стандартная. Если, конечно, ничего не поменяли в последние годы, уже после того как я себе настраивал.
Не проще ли взять любой парольный менеджер с поддержкой TOTP (у меня Bitwarden/Vaultwarden на своём сервере, любители держать всё локально могут и Keepass взять)? (P.S. комментом выше меня опередили, пока я свой набирал :) Заодно автозаполнение / автокопирование в буфер кодов будет, удобно.
С Microsoft у меня всё тоже работает, специально скормил oathtool сохранённый в Bitwarden секрет для учётки MS - он спокойно выдал правильный код. Вот у Яндекса свой велосипед, да...
Что вообще никак не связано с воинским учётом. Так-то мы все в куче реестров и ИС фигурируем - регистрация по месту жительства, госуслуги, ГИБДД, ОМС, я уже молчу про банки и сотовую связь. Но пока единый реестр воинского учёта, который должен слить все эти данные воедино, не создан и постоянно откладывается, военкомат о Вас из них данные в общем случае почерпнуть не может. Безусловно, ситуация будет меняться, для кого-то этот риск вообще неактуален и т.п., но упомянуть про это обстоятельство, думаю, точно надо.
Есть ещё один маленький нюанс, который в текущих условиях может перевесить все остальные. О работнике по трудовому договору работодатель обязан сообщить в военкомат для сверки данных воинского учёта. И, учитывая резко выросшие штрафы за нарушение этой обязанности и возросшую активность военкоматов и местных администраций, требующих таких сверок, - он это, скорее всего, сделает. А об ИП / самозанятом / просто физике по гражданско-правовому договору - не обязан.
Я это всё к чему вообще клоню со своими уточнениями :) IMHO, у подобной аналитики есть какой-то минимальный масштаб, начиная с которого она оправдана. Если мы хотим открыть федеральную сеть из 100 пиццерий в разных городах - наверное, и правда есть смысл начинать с такого анализа, а по его итогам выезжать на отобранные места и там уточнять решения. Но если мы хотим открыть одну пиццерию в одном из двух городов - ну право слово, куда эффективнее съездить в каждый из этих городов, погулять, посидеть там в существующих заведениях, поглядеть, куда в какое время люди ходят. В сети поглядеть панорамы, почитать местные чаты/группы/паблики... и за сравнимое время получится картинка, учитывающая десятки разных критериев, которые не то что оцифровать, но даже формализовать для себя в голове затруднительно.
Любой бизнес включает в себя торговлю. Производство, которое никому ничего не продаёт, довольно быстро разорится :) И достаточно логично пытаться продать там и тем, где дороже, по крайней мере пока это не влечёт существенного роста затрат или необходимости расширения бизнеса. Мелкий опт с доставкой и крупный опт самовывозом не сильно отличаются по объёму и характеру, подробнее написал выше. Розница - да, отдельная тема и отдельный бизнес.
Что на каком юр. лице держать - вопрос технический и во многом зависит от тех самых набранных кредитов :)
По цветам есть большой разрыв между розницей и мелким оптом, т.к. в рознице нужен флорист, правильное расположение точек и те самые риски больше, но и маржа может быть совершенно безумная. Но это совершенно другой бизнес, в который точно как минимум не надо пытаться сразу лезть, ибо за двумя зайцами...
Мелкий же опт особо рисков не накладывает и новых компетенций не требует. Есть те же владельцы цветочных киосков и онлайн-доставка букетов, есть оптовые рынки. Первым по заявкам отвозишь каждый день сколько они заказывают с вечера - и это гарантированный сбыт, со вторыми быстро понимаешь, сколько надо привезти и почём выставить, чтобы точно продать. Но тут, конечно, легче, когда у тебя цветы растут рядом с Москвой, а не за 2000 км :)
Естественно, при этом всём должен быть следующий уровень воронки, позволяющий всё, что не получилось продать дороже, продать дешевле тем самым оптовикам с самовывозом. Но хотя бы часть имеет смысл попробовать реализовать более маржинальным способом, и потихоньку эту часть стараться увеличивать.
P.S. Это не теоретические рассуждения, у самого пара гектаров под цветы есть. В отличие от интервьюируемого товарища, десятки миллионов сразу в долг не брал, государственных субсидий/грантов боюсь как чёрт ладана, - так что расширяю объёмы потихоньку на свои и пока там не миллионы цветов, а именно мелкооптовый уровень.
Я же про мелкий опт, а не про розницу. Место где-нибудь на Фуд Сити, там вообще можно с фуры торговать, и один человек.
Средняя мелкооптовая цена тюльпана в Мск перед 8 марта была, ЕМНИП, около 65 рублей. У интервьюируемого бизнесмена средняя продажная цена получилась 40 рублей, т.е. почти 100% своей себестоимости он отдал оптовым перепродавцам. Которые не выращивали, не рисковали, а просто наняли фуру, чтобы перевезти тюльпаны из симферопольской теплицы на какой-нибудь мелкооптовый рынок в Подмосковье. Непонятно, почему при таких-то затратах этот последний этап цепочки не был реализован самостоятельно.
Да, я посмотрел, что там есть очень производительные модели, и ценник приемлемый. Будем разбираться, чем там ещё готовые растворные узлы напичканы, что стóят по ляму на гектар и выше :)
Да, такое даже в готовых контроллерах полива есть (но это не наш путь :)
Реально интересует тема фертигации (подмеса удобрений), там много нюансов, а готовые решения сто́ят как чугунный мост, и у меня есть впечатление, что самому́ можно собрать и дешевле, и более гибкую систему. Но меня это в масштабе гектаров интересует. Посмотрю на дозаторы, которые Ваш заказчик с сити-фермой использует, любопытно, подойдут ли и что там с ценой на большие площади получится.
А, точно, невнимательно прочитал, показалось, что в первом случае открытый грунт.
Ну с теплицей ещё интереснее, там и несколько контуров отопления, и вентиляция, и подача CO2 - есть где автоматизатору разгуляться :)
Тема автоматизации не раскрыта. А как же хотя бы датчики влажности почвы, чтобы не поливать в дождь? А синхронизация с онлайн прогнозом погоды, чтобы оптимизировать график полива? А датчики PH почвы, чтобы регулировать коэффициент подмеса в установках фертигации?
First, middle и last адаптируются под любую культуру, и это более или менее общепринято. У нас middle это отчество, во многих странах - второе личное имя. У нас last это фамилия, в Исландии - отчество. Если для нашей предметной области действительно важны различия между этими ситуациями, тогда надо городить сложную структуру данных, где для каждой части имени есть какой-то name_part_type, список которых мы ведём отдельно. В большинстве же случаев достаточно first/middle/last, и даже если мы не знаем, что именно в эти поля пишут жители какой-нибудь экзотической народности - можно не волноваться, наверняка они делают это каким-то общепринятым способом.
По поводу пароля, который И запомнен, И записан. Я что хотел донести - в таком случае это фактор, который двух типов одновременно. Можно или украсть листочек, или заставить сказать пароль пользователя. Т.е. 2FA с таким паролем-листочком вообще не строится никак. Добавь к нему физический ключ - украдут с листочком и без всякого фактора знания получат доступ. Добавь к нему второй не записанный пароль (или логин, или что угодно) - пользователь, ничем не обладая, чисто за счёт знания может выдать всё, что нужно для доступа.
По поводу копируемости - не отрицая её важности для планирования защиты, всё же считаю, что это вторичный критерий, на классификацию фактора сам по себе не влияющий. Довольно странно было бы считать, скажем, ключ ЭЦП на копируемом токене фактором знания (где тут знание вообще?), а на некопируемом - обладания (а на официально не копируемом, но есть народные средства, как? а если средства есть только у производителя токена?) Так что копируемость влияет на "силу" фактора обладания, но не меняет сам тип этого фактора. По крайней мере, это моё глубокое убеждение исходя из общей логики, глубоко в теорию не погружался.
Вот после появления виртуальных банковских карт, которые можно выпустить из приложения банка в любой точке мира, стало как-то ещё "ничего". А когда у меня лет 10 назад во Франции банкомат российскую карточку съел и не захотел отдавать - было крайне неприятно :) (это всё без корректировок на текущие печальные реалии, само собой, сейчас, как говорится, нам бы те проблемы...)
Тут, конечно, речь не про копирование, а про восстановление доступа, но это вопросы взаимосвязанные. По сути, любая процедура восстановления доступа - это просто дополнительный альтернативный фактор или набор факторов (и это тоже надо учитывать, а часто забывают).
Да. Поэтому листочек с паролем, который мы ещё и наизусть помним, - это фактор владения ИЛИ обладания. И это самый худший случай, т.к. что к нему ни добавляй вторым фактором ("(владение ИЛИ обладание) И владение" или "(владение ИЛИ обладание) И обладание"), может получиться, что нам достаточно двух факторов одинакового типа, т.е. это не 2FA.
Ну ОК, добавим "или скопировав" :) Ключевой файл на флэшке, полный бекап телефона с Google Authenticator - всё это можно скопировать. Но чтобы скопировать - надо получить доступ. А чтобы узнать фактор знания - надо заставить / обмануть живого человека.
Т.е. фактор обладания защищает нас в ситуации, когда нас пытают, но мы успели съесть листочек, смыть в унитаз флэшку и разбить молотком ноут. А фактор знания - когда у нас всё перечисленное изъяли, но пытать нас не собираются. Как-то так вижу.
Почему? Это фактор обладания, просто присутствующий в нескольких экземплярах, что тоже надо учитывать при оценке рисков (где хранить бекапы). В подавляющем большинстве случаев невозможность сделать бекап влечёт куда более тяжёлые последствия (те, у кого умирала СИМка российского оператора или флэшка с неэкспортируемой ЭЦП за рубежом, поймут), но, опять же, зависит от сценария.
Моя надежда на то, что риск этого меньше, как я написал выше, основана на том, что если хранение паролей криворукий разработчик мог реализовать сам, то для TOTP он, вероятно, использовал стороннюю библиотеку, а то и сторонний сервис :)
Только можно долго, упорно и бесполезно объяснять это пользователям, а можно внедрить обязательный TOTP и снять хотя бы какие-то риски (ещё, кстати, забыл ситуацию "поделиться своим паролем с коллегой, очень срочно надо", в результате которой пароль неконтролируемо расходится по рукам). Ну а п. 4-5 вообще не про это, тут никто не застрахован, даже если для одного себя любимого настраиваешь.
Да, конечно, если мы его не помним, а каждый раз смотрим на листочек. Или пароль в базе парольного менеджера, не важно. Фактор знания - то, что у нас в голове и что мы можем рассказать. Фактор обладания - то, что мы можем потерять / у нас могут украсть или отобрать. Два разных устройства и листочек с паролем - это три фактора обладания, и это нам вообще не поможет, если все лежат в одной сумке, которую украли или изъяли.
Проблема с фактором знания в том, что он плохо масштабируется и никак не бекапится, поэтому мы и заменяем фактор знания на фактор обладания (плюс ослабленный фактор знания мастер-пароля), используя парольные менеджеры. И не так уж это плохо.
Ну а в случае, если у нас не физический ключ / локальный файл или пароль в голове, а доступ к облачному хранилищу / приложению - тут вообще сам чёрт ногу сломит, где знание, а где обладание :) Так что лучше, мне кажется, не привязываться к терминам, а реальные сценарии атак моделировать, они тоже у всех разные.
Защищённый канал не панацея от перехвата.
TOTP-код не записать на стикере, висящем на мониторе.
Фишинг существенно затрудняется (есть фишинговые сайты и с перехватом одноразовых кодов, но тут должна быть заточенная под конкретный сервис и незамедлительное использование кода атака).
Наличие TOTP не позволяет просто подсмотреть (вживую или через камеру наблюдения), как пароль вводится с клавиатуры (впрочем, парольный менеджер эту проблему решает и без TOTP)
Утечка со стороны удалённого сервиса может, теоретически, раскрыть пароль (если они там плейнтекстом хранятся), но не раскрыть TOTP (для чего, вероятно, используется сторонняя библиотека, разработчики которой поумнее).
Так что да, не панацея, но и небесполезно. В каждом случае надо смотреть, что и от каких атак мы защищаем, и в комплексе уже оценивать риски.
P.S. Ну и если строго про терминологию - пароль (без парольного менеджера) ещё может быть фактором знания, а вот TOTP-секрет - это 100% фактор обладания (файлом / приложением / базой / устройством).
2FA всё-таки не про разные устройства, а про разные факторы. Но в текущем разнообразии способов хранить пароли всё это очень условно.
Даже без TOTP менеджер паролей уже даёт нам два фактора - владение базой паролей и знание мастер-пароля для её расшифровки (второй, правда, ослаблен, т.к. мастер-пароль один на всех, но тем не менее). Если доступ к менеджеру паролей удалённый и сам защищён TOTP - опять другая картинка, которая не укладывается в обычную схему. А если база менеджера у нас на отдельной флэшке с аппаратным шифрованием и своим паролем? В общем, IMHO, в каждом случае надо смотреть на конкретные сценарии атаки и насколько та или иная схема в них помогает.
Так MS совершенно прекрасно умеет использовать не только свой Authenticator (ещё раз камень в огород Яндекса), но и гугловский и любой другой сторонний. Точно так же предлагает QR-код или текстовый секрет при настройке. Родное их приложение добавляет подтверждение входа без кода, просто всплывающим сообщением на смартфоне, а вот собственно TOTP-часть вполне стандартная. Если, конечно, ничего не поменяли в последние годы, уже после того как я себе настраивал.
Не проще ли взять любой парольный менеджер с поддержкой TOTP (у меня Bitwarden/Vaultwarden на своём сервере, любители держать всё локально могут и Keepass взять)? (P.S. комментом выше меня опередили, пока я свой набирал :) Заодно автозаполнение / автокопирование в буфер кодов будет, удобно.
С Microsoft у меня всё тоже работает, специально скормил oathtool сохранённый в Bitwarden секрет для учётки MS - он спокойно выдал правильный код. Вот у Яндекса свой велосипед, да...
Что вообще никак не связано с воинским учётом. Так-то мы все в куче реестров и ИС фигурируем - регистрация по месту жительства, госуслуги, ГИБДД, ОМС, я уже молчу про банки и сотовую связь. Но пока единый реестр воинского учёта, который должен слить все эти данные воедино, не создан и постоянно откладывается, военкомат о Вас из них данные в общем случае почерпнуть не может. Безусловно, ситуация будет меняться, для кого-то этот риск вообще неактуален и т.п., но упомянуть про это обстоятельство, думаю, точно надо.
Есть ещё один маленький нюанс, который в текущих условиях может перевесить все остальные. О работнике по трудовому договору работодатель обязан сообщить в военкомат для сверки данных воинского учёта. И, учитывая резко выросшие штрафы за нарушение этой обязанности и возросшую активность военкоматов и местных администраций, требующих таких сверок, - он это, скорее всего, сделает. А об ИП / самозанятом / просто физике по гражданско-правовому договору - не обязан.
С моей совиной точки зрения все эти хронотипы - какие-то мало различающиеся между собой типажи жаворонков :)
Я это всё к чему вообще клоню со своими уточнениями :) IMHO, у подобной аналитики есть какой-то минимальный масштаб, начиная с которого она оправдана. Если мы хотим открыть федеральную сеть из 100 пиццерий в разных городах - наверное, и правда есть смысл начинать с такого анализа, а по его итогам выезжать на отобранные места и там уточнять решения. Но если мы хотим открыть одну пиццерию в одном из двух городов - ну право слово, куда эффективнее съездить в каждый из этих городов, погулять, посидеть там в существующих заведениях, поглядеть, куда в какое время люди ходят. В сети поглядеть панорамы, почитать местные чаты/группы/паблики... и за сравнимое время получится картинка, учитывающая десятки разных критериев, которые не то что оцифровать, но даже формализовать для себя в голове затруднительно.