Это устройство. Их (устройств) немало.
А я спрашивал про проекты с миллионной аудиторией, которые бы в один прекрасный день сказали, так, ребята, пользователи, в течении года переходим на использование устройства Х. Кто не перешел, мы не виноваты. Воспользоваться нашими услугами не сможете.
При этом, использование устройства Х было бы реализовано канонически верно, без компромиссов.
в линуксе особой разницы между thread и process нет. но, да, в других ос thread/process серьезно различают.
для них разные process. в идеале браузер не должен ничего знать ни про приватный ключ, ни про пин, ни про алгоритмы подписи.
Web Crypto по сути должен предоставить доступ к api, который все это (в том числе подписание) реализует в виде отдельного приложения/драйвера. А это опять потенциальная дыра — NPAPI, Flash, java applet потому и выпилили из браузеров, что давали доступ к ресурсам ОС через браузер. В общем замкнутый круг.
Такие приложения уже есть.
Но и с ними свои сложности. Без интернета не подпишешь, как безопасно хранить приватный ключ (разработчики мобильных ОСей предоставляют специальный API, но большинство соглашается, это не гарантирует неразглашения). В общем использование мобилок привносит свои компромиссы.
Я там ниже комментировал.
Все крутится вокруг того, что если хочется честную безопасность, то приватный ключ должен быть на отдельном устройстве, и никогда его не покидать. Все остальное это компромиссы, вплоть до того, а давайте создадим «простую электронную подпись», которая к криптографии никакого отношения не имеет.
Главная проблема подписания (где угодно, хоть в браузере) — отделить собственно подписание от всего остального. Подписание должно выполняться на доверенном устройстве, в отдельном процессе (threads в ит терминах). Все манипуляции с приватным ключом должны выполняться в этом отдельном процессе, в том числе ввод пина для приватного ключа.
И вот тут главная проблема, пользовательский опыт. Люди открывая сайт, ожидают взаимодействия с этим сайтом, а не отдельным приложением. Собственно поэтому компромиссы: ввод пути до приватного файла из браузера, ввод пина из браузера, и т.д… Если сделать все канонически правильно, то таким решением смогут воспользоваться меньшее количество людей. Не видел ни одного канонически правильного решения, которое успешно работает с аудиторий от нескольких миллионов обычных людей. Приходится выбирать либо аудитория, либо каноны безопасности.
Фундаментально неверно.
Криптография так не работает.
Это все равно что сказать, а давайте всех нотариусов закроем, и откроем одного, и когда нужно будет выпустить доверенность, пусть граждане по почте шлют свои заявки, а тот нотариус обрабатывает заявки и в ответ высылает по почте готовые доверенности. Оптимизация деятельности налицо.
Подписание должно быть на доверенном устройстве (нотариус должен быть вам очно доступен).
Приватный ключ из доверенного устройства не должен уходить (ваша подпись должна ставиться на довереность только при очном присутствии нотариуса).
Если не хотите, чтобы кто-то вместо вас подписывал электронные документы (выпускал от вашего имени доверенности), эти два требования нужно соблюдать.
В случае с клиентом либо он должен доверять узлу A и предварительно внести депозит, который потом будет тратить, либо, наоборот, узел A доверяет клиенту и готов предоставить кредит. Но подобное уже происходит, например, когда банк выдаёт дебетовую или кредитную карту. То есть тут нет ничего нового.
В случае платежной карты банка, я доверяю банку, и не доверяю кофейне. И если придет списание в пользу кофейни, я попрошу банк отменить транзакцию. Начнется долгая процедура проверки, и тем не менее деньги мне вернут.
Кто вернет мне деньги в случае Lightning Network, кому писать заявление на возврат ошибочного списания?
Чего только стоило удаление кнопок отмены/повтора действия в редакторе конфлюенса, псевдоменеджер продукта решил, что они лишние там и достаточно горячих кнопок
Это общие тренды в софтостроении.
Изучается статистика, выясняется что какой-то функционал использует Х процентов, оценивается сколько стоит его поддержка, оценивается насколько опечалятся пользователи (которые пользуются этой функциональностью), оценивается сколько времени потребуется выпилить эту функциональность, и оценивается сколько времени освободится, чтобы потратить его на новые фичи. При определенном раскладе, да, принимается решение выпилить что-нибудь «ненужное». И да, какая-то часть пользователей будет этим фактом опечалена.
Так я со стороны потребителя.
Использовать atomic в продуктиве или он вскоре загнется?
Openshift стабилизировался, или будет активно архитектурно перекраиваться?
Образец — RHEL. Понятно, что он будет и через 5 лет, и ты просто используешь его.
содержать штат диспетчеров, менеджеров и, непосредственно, специалистов технической поддержки
ITIL не про людей, ITIL про роли. В экстремуме в ИТ может быть один человек, исполняющий все роли всех процессов одновременно.
более правильным сосредоточить свое внимание не на повышении качества учета обращений пользователей, а на том, чтобы причин обращаться в техническую поддержку у пользователей не было
А вот это ключевое. Иногда в ITIL почему-то видят только ИТ-составляющую. Хотя там прямо говорят про цели всех процессов. И качество регистрации заявок просто один из критериев инцидентного процесса. А цели в ITIL — они всегда бизнес-ориентированы. У инцидентов — это скорейшее восстановление. У проблем — устранение корневых причин, и т.д. И если ты очень качественно регистрируешь инциденты, но очень долго их устраняешь, то ты занимаешься ерундой.
Извиняюсь, что вклиниваюсь.
Statefull vs Stateless не про контракты, а про особенность обработки запросов конкретно в этом узле. Если какой-либо стороне нужно помнить контекст, чтобы с учетом этого контекста правильно обращаться в следующий раз, то это Statefull. В обратном случае — Stateless.
Например в вашем примере два варианта, с кукой и токеном. В общем случае клиенту, нужно помнить куку или токен. Для него это Statefull. Если он будет забывать куку или токен, то не сможет нормально обращаться к сервису. Т.е. клиент в обоих случаях должен помнить состояние.
А серверное приложение может помнить куку или токен. А может и не помнить, и при каждом запросе идти в хранилище кук или токенов и пересоздавать сессию. Тогда (во втором варианте) серверное приложение будет Stateless. У него не будет внутреннего состояния. И тогда получаем выигрыш от Stateless — возможность обрабатывать запрос на любой из имеющихся нод.
При этом в целом сервис (то как его видит клиент) — Statefull. Очевидно в недрах него где-то сохраняется его состояние, чтобы клиент мог нормально к нему обращаться.
В реальности так и есть, хехе…
Выделяется отдельный сервис — Бонусы. В него сливается тем или иным способов все, что нужно для принятия решения по бонусам. И затем либо сам сервис Бонусов строит кампании и отдает их потребителям, либо сами потребители идут в сервис Бонуса и спрашивают, есть ли что предложить для клиента Х.
А все потому, что вы верно отметили, у нас куча разных (не всегда микро) сервисов.
И не потому что кто-то очень любит сегментацию и пилит сервисы пачками. А потому, что бизнес большой и команд много, и многие команды слышали друг про друга, но реально не общались. Потому что когда команд за три десятка, общаться со всеми невозможно в принципе. И монолит даже теоретически невозможен.
Получается чувак, который спроектировал Бурж-Халифа (он еще много чего другого спроектировал), просто определил экстерьер, интерьер, планировку, освещенность рассчитал, потом получил бабло и отвалил насовсем? Дальше уже без него достраивали? И если бы что-то пошло не так, то он просто сказал, «ну ребята, я просто экстерьер, интерьер нарисовал, а что там с расчетом нагрузки я хз, идите с… разбирайтесь». и это всех бы устроило?
И архитектурный надзор — термин вымышленный, и ни кем не применяемый?
И запросто может быть архитектура несуществующих процессов. Точно также, как может быть архитектура несуществующих зданий или несуществующих информационных систем. ;)
И это не помогает от подмены информации перед подписью.
Справедливости ради, этим страдает большинство реализаций. Т.к. решения этих недостатков — не юзерфрендли.
А я спрашивал про проекты с миллионной аудиторией, которые бы в один прекрасный день сказали, так, ребята, пользователи, в течении года переходим на использование устройства Х. Кто не перешел, мы не виноваты. Воспользоваться нашими услугами не сможете.
При этом, использование устройства Х было бы реализовано канонически верно, без компромиссов.
для них разные process. в идеале браузер не должен ничего знать ни про приватный ключ, ни про пин, ни про алгоритмы подписи.
Web Crypto по сути должен предоставить доступ к api, который все это (в том числе подписание) реализует в виде отдельного приложения/драйвера. А это опять потенциальная дыра — NPAPI, Flash, java applet потому и выпилили из браузеров, что давали доступ к ресурсам ОС через браузер. В общем замкнутый круг.
Но и с ними свои сложности. Без интернета не подпишешь, как безопасно хранить приватный ключ (разработчики мобильных ОСей предоставляют специальный API, но большинство соглашается, это не гарантирует неразглашения). В общем использование мобилок привносит свои компромиссы.
Все крутится вокруг того, что если хочется честную безопасность, то приватный ключ должен быть на отдельном устройстве, и никогда его не покидать. Все остальное это компромиссы, вплоть до того, а давайте создадим «простую электронную подпись», которая к криптографии никакого отношения не имеет.
И вот тут главная проблема, пользовательский опыт. Люди открывая сайт, ожидают взаимодействия с этим сайтом, а не отдельным приложением. Собственно поэтому компромиссы: ввод пути до приватного файла из браузера, ввод пина из браузера, и т.д… Если сделать все канонически правильно, то таким решением смогут воспользоваться меньшее количество людей. Не видел ни одного канонически правильного решения, которое успешно работает с аудиторий от нескольких миллионов обычных людей. Приходится выбирать либо аудитория, либо каноны безопасности.
Приватный ключ лежит на пластике с чипом.
Раньше был NPAPI. Потом его выпилили. Начали пилить Web Crypto. Но и с ним есть проблема. Ниже опишу какая.
Криптография так не работает.
Это все равно что сказать, а давайте всех нотариусов закроем, и откроем одного, и когда нужно будет выпустить доверенность, пусть граждане по почте шлют свои заявки, а тот нотариус обрабатывает заявки и в ответ высылает по почте готовые доверенности. Оптимизация деятельности налицо.
Подписание должно быть на доверенном устройстве (нотариус должен быть вам очно доступен).
Приватный ключ из доверенного устройства не должен уходить (ваша подпись должна ставиться на довереность только при очном присутствии нотариуса).
Если не хотите, чтобы кто-то вместо вас подписывал электронные документы (выпускал от вашего имени доверенности), эти два требования нужно соблюдать.
В случае платежной карты банка, я доверяю банку, и не доверяю кофейне. И если придет списание в пользу кофейни, я попрошу банк отменить транзакцию. Начнется долгая процедура проверки, и тем не менее деньги мне вернут.
Кто вернет мне деньги в случае Lightning Network, кому писать заявление на возврат ошибочного списания?
и другое — софт, пусть и не прикладной.
Это общие тренды в софтостроении.
Изучается статистика, выясняется что какой-то функционал использует Х процентов, оценивается сколько стоит его поддержка, оценивается насколько опечалятся пользователи (которые пользуются этой функциональностью), оценивается сколько времени потребуется выпилить эту функциональность, и оценивается сколько времени освободится, чтобы потратить его на новые фичи. При определенном раскладе, да, принимается решение выпилить что-нибудь «ненужное». И да, какая-то часть пользователей будет этим фактом опечалена.
Использовать atomic в продуктиве или он вскоре загнется?
Openshift стабилизировался, или будет активно архитектурно перекраиваться?
Образец — RHEL. Понятно, что он будет и через 5 лет, и ты просто используешь его.
И openshift ждет очередная инкарнация, интеграция с rkt?
ITIL не про людей, ITIL про роли. В экстремуме в ИТ может быть один человек, исполняющий все роли всех процессов одновременно.
А вот это ключевое. Иногда в ITIL почему-то видят только ИТ-составляющую. Хотя там прямо говорят про цели всех процессов. И качество регистрации заявок просто один из критериев инцидентного процесса. А цели в ITIL — они всегда бизнес-ориентированы. У инцидентов — это скорейшее восстановление. У проблем — устранение корневых причин, и т.д. И если ты очень качественно регистрируешь инциденты, но очень долго их устраняешь, то ты занимаешься ерундой.
Там же вроде разные побочные эффекты на больших мощностях возникают.
Statefull vs Stateless не про контракты, а про особенность обработки запросов конкретно в этом узле. Если какой-либо стороне нужно помнить контекст, чтобы с учетом этого контекста правильно обращаться в следующий раз, то это Statefull. В обратном случае — Stateless.
Например в вашем примере два варианта, с кукой и токеном. В общем случае клиенту, нужно помнить куку или токен. Для него это Statefull. Если он будет забывать куку или токен, то не сможет нормально обращаться к сервису. Т.е. клиент в обоих случаях должен помнить состояние.
А серверное приложение может помнить куку или токен. А может и не помнить, и при каждом запросе идти в хранилище кук или токенов и пересоздавать сессию. Тогда (во втором варианте) серверное приложение будет Stateless. У него не будет внутреннего состояния. И тогда получаем выигрыш от Stateless — возможность обрабатывать запрос на любой из имеющихся нод.
При этом в целом сервис (то как его видит клиент) — Statefull. Очевидно в недрах него где-то сохраняется его состояние, чтобы клиент мог нормально к нему обращаться.
Вот такой дуализм
Выделяется отдельный сервис — Бонусы. В него сливается тем или иным способов все, что нужно для принятия решения по бонусам. И затем либо сам сервис Бонусов строит кампании и отдает их потребителям, либо сами потребители идут в сервис Бонуса и спрашивают, есть ли что предложить для клиента Х.
А все потому, что вы верно отметили, у нас куча разных (не всегда микро) сервисов.
И не потому что кто-то очень любит сегментацию и пилит сервисы пачками. А потому, что бизнес большой и команд много, и многие команды слышали друг про друга, но реально не общались. Потому что когда команд за три десятка, общаться со всеми невозможно в принципе. И монолит даже теоретически невозможен.
Получается чувак, который спроектировал Бурж-Халифа (он еще много чего другого спроектировал), просто определил экстерьер, интерьер, планировку, освещенность рассчитал, потом получил бабло и отвалил насовсем? Дальше уже без него достраивали? И если бы что-то пошло не так, то он просто сказал, «ну ребята, я просто экстерьер, интерьер нарисовал, а что там с расчетом нагрузки я хз, идите с… разбирайтесь». и это всех бы устроило?
И архитектурный надзор — термин вымышленный, и ни кем не применяемый?
И запросто может быть архитектура несуществующих процессов. Точно также, как может быть архитектура несуществующих зданий или несуществующих информационных систем. ;)