Я считаю, что доменом должен пользоваться тот, кому он нужнее в данный момент. Если на пенсии он вам будет нужнее, чем другому человеку — подавайте в суд на него и отбирайте.
Если дача стоит во дворе чьего-то предприятия и мешает уже который год, при этом владелец никак не хочет поменять её на другую дачу — вполне можно и отобрать. И да, при этом владелец там не живёт конечно же.
А.Волков зарегистрировал и начал использование доменного имени более чем за 4 года до создания общества как юридического лица.
Что-то web archive подсказывает, что он вовсе не использовался, по крайней мере последние годы. Очевидно, что Одва не смогла договориться с владельцем, а это значит лишь то, что владелец назначил невероятную цену, за что и получил.
Если говорить о защите от продажи «налево» — можно ведь купить такой станок себе в здание, а потом продать его вместе со зданием (ну или сдавать в аренду).
У меня на похожей плате можно управлять дисплеем через FSMC, при этом дисплей, по сути, маппится в память. Этот способ взаимодействия мне кажется более простым и элегантным, чем дёрганье ножками МК. Может быть и у вас так можно?
А теперь учтите тот факт, что собеседники может быть никогда рядом не будут, а также тот факт, что ключи генерируются временные. Представляете, сколько проблем принесёт сравнение ключей каждый раз?
А поскольку пользователи могут безопасно проверить равенство ключей только находясь географически рядом друг с другом, можно достаточно легко осуществлять MITM атаки при условии, что пользователи находятся не рядом (например, определяя их положение по базовым станциям, к которым они на данный момент привязаны). Вряд ли кто-то будет отправлять друг другу скриншот картинки по ещё более защищённому соединению (да и вообще какой процент пользователей будет сверять картинки даже находясь рядом с собеседником?).
Наконец, можно провести детальный анализ сетевой активности, используя Wireshark, а также активности в файловой системе и реестре, используя procmon, да и вообще поиграться с работающей программой в Process Explorer.
А просто переименовать и запустить нужную программу нельзя?
// а, ой, это перевод
В документации предлагается выполнять проверку на безопасность простого числа. Помимо этого, есть ещё понятие «сильное простое число» с более строгими условиями, которые проверить уже намного сложнее. Как вы предлагаете это делать?
Я говорю не о secret chats, а о процессе аутентификации, где dh_prime приводится в качестве константы: link.
И вообще зачем кому-либо генерировать новые параметры для DH, если их можно сгенерировать один раз (или использовать набор параметров, как в ssh)?
Кроме того значение dh_prime взято непонятно откуда, без каких-либо пояснений и доказательств. А вдруг это какое-то «плохое» простое число, при использовании которого задача дискретного логарифмирования становится проще в разы?
Тут ещё есть такая проблема: компания в принципе не обязана разглашать истинные результаты конкурса, а сами конкурсанты в 99% случаев не имеют на это право. В результате баги могут быть найдены и за 10000$, а потенциальные клиенты будут видеть плашку «ололо, наш продукт так никто и не взломал».
Что-то web archive подсказывает, что он вовсе не использовался, по крайней мере последние годы. Очевидно, что Одва не смогла договориться с владельцем, а это значит лишь то, что владелец назначил невероятную цену, за что и получил.
Только у вас он маленький весьма получился. А вот у меня в примере работы с контроллером написано вот это:
А просто переименовать и запустить нужную программу нельзя?
// а, ой, это перевод
И вообще зачем кому-либо генерировать новые параметры для DH, если их можно сгенерировать один раз (или использовать набор параметров, как в ssh)?