Обычные юзеры "из интереса" никуда не переходят. Если это юзер домашний, он просто жмет кнопочку "перезагрузиться" или "отложить" в очередной напоминалке, или просто встречает перезагрузившийся в результате попытки обновления комп. А там уж Вин11 либо встала, либо нет. Если же у него система не соответствует требованиям, которые вин11 к автоустановке предъявляет, он даже не задумается о смене вплоть до замены компа как минимум. Отсюда неизбежно высокая доля десятки.
А "доверие и любовь" к вин11 у юзера примерно такие же, как к любой другой винде - что стоит, то и использует. Процент юзеров, которые сознательно выбирают между разными версиями, не слишком-то велик, а уж тех, кто при этом сознательно выбирает десятку - еще меньше.
Если же этот обычный юзер корпоративный, он вообще ничего не решает, и там уже другие мотивы перехода (или нет) начинают играть.
Разница между обычным Skype и Skype for Business Server аналогична Exchange Online и Exchange Server.
Даже близко не "аналогична", это просто абсолютно разные продукты, не имеющие ничего общего, кроме слова Skype в названии. Аналогом Exchange Online в данном случае был Skype for Business Online, который был заменен на Teams.
Потеря - это потеря, пользователь либо может использовать адрес, либо нет. Если исходить не из сакральных соображений типа "я просто хочу быть собственником своего адреса, потому что хочу", то пользователю важно два вопроса - насколько сложно адрес потерять и как можно потом его восстановить. В вашем случае компрометация клиентского устройства ведет к потере адреса без возможности восстановления, и это еще умолчим о возможности злоумышленника выдавать себя за вас после этого.
Он должен перенести ключи любым безопасным, в его модели угроз, способом.
Слова, увы, ничего не значат. Просто промоделируйте ситуацию в реальности, и не для айтишника, а для рядового пользователя. Сделайте хотя бы на уровне POC демонстрацию, как это должно работать.
Это просто только для очень специфической аудитории, и никак не снимает вторую часть вопроса - доступ к собственно переписке. В целом еще и без универсального обмена с внешним миром выглядит просто как очередной мессенджер-игрушка для гиков.
Так ведь я вас спрашиваю, чтобы ваши мысли увидеть. Вы предлагаете некий сервис, мне интересно, как вы видите его работу при возникновении некоторых легко предсказуемых проблем на стороне пользователя.
По поводу компрометации (или утери) ключа вы же сами пишете - "Потеря почтового адреса может обернуться настоящим кошмаром.", аргументируя этим необходимость новой системы, и вы то же время предлагаете просто "создать новый адрес". Это не очень стыкуется друг с другом.
По работе с несколькими девайсам - ну просто промоделируйте саму ситуацию. Вот Василий завел ваш почтовый ящик на телефоне. Теперь он хочет пользоваться им еще и с ПК, планшета и умных часов. Как вы себе видите этот процесс?
В таком случае слова "такой адрес вписывается в формат @domain" ничего не значат. Если вы говорите об интероперабельности, нужны не условные обозначения, а конкретные механизмы. Как именно будет осуществляться отправка почты от xxx@eppie на xxx@domain.tld ? Как будет работать отправка в обратную сторону?
при компрометации приватного ключа нужно создать новый адрес
И вы не видите, в чем тут проблема (или даже минимум две)?
приватный ключ необходимо безопасно перенести
И здесь тоже не видите сразу две (минимум) проблемы?
Не "перестали", а "появились способы аутентификации, которые позволили их не передавать". Способы с прямой передачей паролей, в том числе открытым текстом, никуда при этом не делись, а с повсеместным распространением TLS так вообще второе рождение получили.
Потому что тогда нельзя будет сказать, что с ключами секрет по сети не передается, а вот с паролями.. :)) А если серьезно - просто неоправданная сложность. Вот если у вас уже есть инфраструктура с керберосом, тогда почему бы и нет.
Симптоматично, что в качестве одного из недостатков паролей вы указываете компрометацию клиента с возможным перехватом оных, но ту же самую проблему с SSH-ключом почему-то не упоминаете, хотя приватный ключ в клиентском контексте технически скомпрометировать гораздо проще, чем пароль.
В предыдущем комментарии вы описали достаточно сложный по исполнению теракт, а не военный конфликт. Поэтому см. выше - "есть куда более простые способы..."
Наша флагманская платформа серверной виртуализации VMmanager позволяет построить архитектуру виртуальной среды без использования физического сервера — в апреле мы внесли в решение необходимые доработки.
Переводя с маркетингового языка на реальный - мы месяц назад наконец-то смогли реализовать то, что у лидеров есть второй десяток лет? :)
Вашу кухню собирали несколько человек три дня, а мою - один за день. Но вот незадача - стоила она не дешевле, а ДОРОЖЕ, чем типичная кухня из "зеленого магазина". Хорошо так дороже. Подумайте на досуге, почему так. Некоторое количество направлений для размышлений уже другие комментаторы задали.
Обычные юзеры "из интереса" никуда не переходят. Если это юзер домашний, он просто жмет кнопочку "перезагрузиться" или "отложить" в очередной напоминалке, или просто встречает перезагрузившийся в результате попытки обновления комп. А там уж Вин11 либо встала, либо нет. Если же у него система не соответствует требованиям, которые вин11 к автоустановке предъявляет, он даже не задумается о смене вплоть до замены компа как минимум. Отсюда неизбежно высокая доля десятки.
А "доверие и любовь" к вин11 у юзера примерно такие же, как к любой другой винде - что стоит, то и использует. Процент юзеров, которые сознательно выбирают между разными версиями, не слишком-то велик, а уж тех, кто при этом сознательно выбирает десятку - еще меньше.
Если же этот обычный юзер корпоративный, он вообще ничего не решает, и там уже другие мотивы перехода (или нет) начинают играть.
Даже близко не "аналогична", это просто абсолютно разные продукты, не имеющие ничего общего, кроме слова Skype в названии. Аналогом Exchange Online в данном случае был Skype for Business Online, который был заменен на Teams.
Скорее не "не понимает", а вообще не считает это проблемой, даже если понимает объяснение. А вот минусы видит прекрасно.
Потеря - это потеря, пользователь либо может использовать адрес, либо нет. Если исходить не из сакральных соображений типа "я просто хочу быть собственником своего адреса, потому что хочу", то пользователю важно два вопроса - насколько сложно адрес потерять и как можно потом его восстановить. В вашем случае компрометация клиентского устройства ведет к потере адреса без возможности восстановления, и это еще умолчим о возможности злоумышленника выдавать себя за вас после этого.
Слова, увы, ничего не значат. Просто промоделируйте ситуацию в реальности, и не для айтишника, а для рядового пользователя. Сделайте хотя бы на уровне POC демонстрацию, как это должно работать.
Это просто только для очень специфической аудитории, и никак не снимает вторую часть вопроса - доступ к собственно переписке. В целом еще и без универсального обмена с внешним миром выглядит просто как очередной мессенджер-игрушка для гиков.
Так ведь я вас спрашиваю, чтобы ваши мысли увидеть. Вы предлагаете некий сервис, мне интересно, как вы видите его работу при возникновении некоторых легко предсказуемых проблем на стороне пользователя.
По поводу компрометации (или утери) ключа вы же сами пишете - "Потеря почтового адреса может обернуться настоящим кошмаром.", аргументируя этим необходимость новой системы, и вы то же время предлагаете просто "создать новый адрес". Это не очень стыкуется друг с другом.
По работе с несколькими девайсам - ну просто промоделируйте саму ситуацию. Вот Василий завел ваш почтовый ящик на телефоне. Теперь он хочет пользоваться им еще и с ПК, планшета и умных часов. Как вы себе видите этот процесс?
В таком случае слова "такой адрес вписывается в формат @domain" ничего не значат. Если вы говорите об интероперабельности, нужны не условные обозначения, а конкретные механизмы. Как именно будет осуществляться отправка почты от xxx@eppie на xxx@domain.tld ? Как будет работать отправка в обратную сторону?
И вы не видите, в чем тут проблема (или даже минимум две)?
И здесь тоже не видите сразу две (минимум) проблемы?
И у вас даже TLD зарегистрирован с MX записями?
А что происходит при его компрометации? А что делать, если пользователю нужна почта на нескольких устройствах?
Вот оно что... методику поменяли, "и тут-то, Петька, мне карта и поперла!".
Плотность хранения уже давно можно вычеркнуть, ибо 30+TB SSD появились даже не вчера, и форм-фактор у них отнюдь не 3.5". А вот стоимость это да.
Не "перестали", а "появились способы аутентификации, которые позволили их не передавать". Способы с прямой передачей паролей, в том числе открытым текстом, никуда при этом не делись, а с повсеместным распространением TLS так вообще второе рождение получили.
Потому что тогда нельзя будет сказать, что с ключами секрет по сети не передается, а вот с паролями.. :)) А если серьезно - просто неоправданная сложность. Вот если у вас уже есть инфраструктура с керберосом, тогда почему бы и нет.
Симптоматично, что в качестве одного из недостатков паролей вы указываете компрометацию клиента с возможным перехватом оных, но ту же самую проблему с SSH-ключом почему-то не упоминаете, хотя приватный ключ в клиентском контексте технически скомпрометировать гораздо проще, чем пароль.
Да мне не жалко, просто приличные люди ссылки на первоисточник ставят, а не на свою телегу.
В предыдущем комментарии вы описали достаточно сложный по исполнению теракт, а не военный конфликт. Поэтому см. выше - "есть куда более простые способы..."
К счастью, на практике это далеко не так легко, как вы думаете. И, к сожалению, есть куда более простые способы устроить сотни/тысячи пострадавших.
Переводя с маркетингового языка на реальный - мы месяц назад наконец-то смогли реализовать то, что у лидеров есть второй десяток лет? :)
Не знал, что блог Cloud4Y - русскоязычный филиал Tom's Hardware.
Вашу кухню собирали несколько человек три дня, а мою - один за день. Но вот незадача - стоила она не дешевле, а ДОРОЖЕ, чем типичная кухня из "зеленого магазина". Хорошо так дороже. Подумайте на досуге, почему так. Некоторое количество направлений для размышлений уже другие комментаторы задали.
Из личного опыта - Xiaomi 13 живет два дня в режиме звонилки-читалки и с неделю, если не больше (не было смысла точно мерять), "лежа на столе".