Мне нравится современная тенденция давать имена уязвимостям: HeartBleed, ShellShock, Bashdoor. В названии этой уязвимости андроида появляется двусмысленность, если убрать первую букву.
Попробуйте язык D, который приводится в качестве примера в статье. Нативный код с GC, нет зоопарка разных компиляторов. Я использую его для решения задач из HackerRank.com и мне D показался отличным языком для написания алгоритмов.
Классная статья. Когда меня спросят «Зачем ты эту теорию чисел учил в универе?», Я отвечу — для того, чтобы уметь читать вот такие выкладки.
Я понимаю, что статья носит вводный характер и допускает некоторые упрощения, но всё равно интересно следить, как из простых конструкций получается протокол для достоверного слепого вычисления полиномов при почти-нулевом раскрытии секрета.
Зря вы всех записали в категорию «спекулянты». На Медузе была статья про очередь за iPhone X. И среди первых покупателей были те, кто «купил себе и девушке» или «один из аппаратов он подарит супруге».
Насколько Я понял, в вашей системе есть центральный сервер, который регистрирует участников голосования и разрешает/запрещает узлы с правом записи. И доверие к системе в целом равносильно доверию к центральному серверу.
Насколько Я понял из описания вашего проекта, все голоса в системе абсолютно публичны? То есть, в блокчейне хранится информация кто за кого проголосовал. А как же тайна голосования?
Или же каждый участник анонимен (известен только его публичный ключ, и блокчейн не хранит личной информации)? Как в таком случае избежать большого количества «мёртвых душ»? Ведь тот кто регистрирует пользователей может создавать их в неограниченных количествах.
Интересная статья. Но мне кажется, что автор оригинальной статьи сильно углубляется в детали реализации. Он советует какие форматы данных использовать, на каких языках программирования нужно писать. Вряд ли замена JSON на PBF решил проблемы с SQL инъекциями.
Мне кажется, что создавать новый Web нужно со стандартизации виртуальной машины, API браузера, API межпрограммного общения (аналоги OAuth и других протоколов в новой реализации). Нужно понимать, что современный Web не стоит на месте, браузеры внедряют новые возможности (работа со звуком и видео, уведомления на рабочем столе, HTTP/2). При разработке NewWeb нужно заложить расширяемость с учетом обратной совместимости. А вопросы IDE вообще не должны подниматься на этапе формирования идеи/концепции.
Почему вы так не любите букву Ё? Ведь алгоритм назван не в честь жены короля, а в честь авиаконструктора. Сложно с первого раза правильно прочитать фразу:
Посмотрите, как сейчас выглядит процесс работы с приватными ключами в Github: Generating a new SSH key and adding it to the ssh-agent, Adding a new SSH key to your GitHub account. Или например инструкция от Bitbucket: Add an SSH key to an account (целых 11 шагов с картинками). Если регистрация на Facebook будет такой сложной, то не каждый программист справится :)
И тут, мне кажется, менеджеры паролей могут взять на себя функции генерации закрытого и открытого ключа, и хранение секретной части, чтобы весь процесс сводился к нажатию кнопки «Register with public key».
Но это пока только мои хотелки, нет ни web-стандартов, ни предложений со стороны разработчиков сайтов.
В простейшем варианте — да. Но LastPass, например, предлагает 2-х факторную аутентификацию (или даже многофакторную со смарт-картами, сканерами отпечатков пальцев, с привличением SalesForce и других сервисов).
Главное, что отказ от паролей на сторонних сайтах позволит сфокусироваться на безопасности одного единственного хранилища. И тут нам помогут советы из статьи.
Вы не рассматриваете вариант KeePass + облачное хранилище? Так можно не боятся потерять всё пароли и секретные ключи с поломкой одного устройства.
Я использую LastPass на Desktop и Android. Было бы здорово открыть github.com однажды и увидеть, что разработчики добавили эллиптическую криптографию в процесс авторизации, а мой LastPass уже всё поддерживает :) Эх, мечты, мечты…
Я мечтаю, что со временем повсеместное внедрение менеджеров паролей позволит заменить пароли на криптографию с открытыми-закрытыми ключами. При регистрации генерируется закрытый ключи, сайт хранит у себя открытый ключ, а авторизация пользователей будет происходить по ЭЦП. Отпадают проблемы с кражей паролей, подбором паролей, повторением одного и того же пароля на разных сервисах, проблемы с хранением паролей на стороне сервера.
Главная проблема в такой схеме — безопасно хранить закрытые ключи на машине/устройстве пользователя.
Насколько Я понимаю, Flash как технология (язык программирования, API, VM) не умрёт. Просто браузерный плагин перестанут обновлять. Но мы можем продолжать писать на Flash + Flex под мобильники (Android, iOS) и Desktop (Windows, OS X).
Эх, тут недавно компания PayPal переписала свою архитектуру с Java на Scala+Akka и смогла уменьшить количество серверов с 100 до 8. Когда кто-нибудь покажет реальные преимущества Node.JS vs. <Any> на фактическом проекте, тогда дискуссия будет иметь смысл.
В текущей ситуации копирование данных между картами OSM, Yandex, Google и другими прямо запрещается лицензионным соглашением. У OSM лицензия Copy left типа, у остальных — проприетарная. Если вы берёте данные из OpenStreetMap, то обязаны дальше разрешать их свободное копирование.
Возможно Яндекс.Карты редактируют основываясь на тех же спутниковых снимках?
Для маленького сквера прорисовка пешеходных дорог действительно не критична. Но если вы будете в Софиевском парке (площадью 179 га), то дорогу к выходу лучше искать не по Google картам, а по OSM.
Google, конечно, молодцы. Они делают самую популярную online карту в мире, снимают города в 3D Google Earth’s Incredible 3D Imagery, Explained. Но закрытость данных убивает всякое желание такой картой пользоваться.
Я понимаю людей, которые помогают Google и Яндекс уточнять карты, чтобы потом видеть изменения в телефоне и браузере. Но продолжаю настаивать, что OpenStreetMap гораздо универсальнее, отзывчивее и гибче. Автор статьи долго сравнивает изменения внешнего вида карт Google, в то время как у нас есть Mapbox Studio, где любой желающий может создать свой дизайн, добавить или убрать обводку дорог, выбрать цвет фона, показывать или прятать отметки любого типа, рисовать свои объекты.
Я когда столкнулся с этой проблемой, то взял на вооружение Process Monitor. Настроил его так, чтобы он регистрировал все создаваемые процессы, и сел в засаде. Через какое-то время назойливое окно появилось, а Process Monitor показал название EXE файла.
Получается, в вашей реализации пользователь не может сделать Undo действиям другого пользователя?
А если Николай весь день писал документацию к проекту, а вечером Геннадий зашёл в этот документ и удалил весь текст, то Николай не может сделать Undo этой операции?
Мне кажется более естественным, если действия всех пользователей складываются в один стек и Undo отменяет последнее по времени действие независимо от того, кто это действие совершил.
Я понимаю, что статья носит вводный характер и допускает некоторые упрощения, но всё равно интересно следить, как из простых конструкций получается протокол для достоверного слепого вычисления полиномов при почти-нулевом раскрытии секрета.
С нетерпением жду продолжения.
Или же каждый участник анонимен (известен только его публичный ключ, и блокчейн не хранит личной информации)? Как в таком случае избежать большого количества «мёртвых душ»? Ведь тот кто регистрирует пользователей может создавать их в неограниченных количествах.
Мне кажется, что создавать новый Web нужно со стандартизации виртуальной машины, API браузера, API межпрограммного общения (аналоги OAuth и других протоколов в новой реализации). Нужно понимать, что современный Web не стоит на месте, браузеры внедряют новые возможности (работа со звуком и видео, уведомления на рабочем столе, HTTP/2). При разработке NewWeb нужно заложить расширяемость с учетом обратной совместимости. А вопросы IDE вообще не должны подниматься на этапе формирования идеи/концепции.
Врядли Pyston будет дальше развиваться.
И тут, мне кажется, менеджеры паролей могут взять на себя функции генерации закрытого и открытого ключа, и хранение секретной части, чтобы весь процесс сводился к нажатию кнопки «Register with public key».
Но это пока только мои хотелки, нет ни web-стандартов, ни предложений со стороны разработчиков сайтов.
Главное, что отказ от паролей на сторонних сайтах позволит сфокусироваться на безопасности одного единственного хранилища. И тут нам помогут советы из статьи.
Я использую LastPass на Desktop и Android. Было бы здорово открыть github.com однажды и увидеть, что разработчики добавили эллиптическую криптографию в процесс авторизации, а мой LastPass уже всё поддерживает :) Эх, мечты, мечты…
Главная проблема в такой схеме — безопасно хранить закрытые ключи на машине/устройстве пользователя.
Возможно Яндекс.Карты редактируют основываясь на тех же спутниковых снимках?
Я понимаю людей, которые помогают Google и Яндекс уточнять карты, чтобы потом видеть изменения в телефоне и браузере. Но продолжаю настаивать, что OpenStreetMap гораздо универсальнее, отзывчивее и гибче. Автор статьи долго сравнивает изменения внешнего вида карт Google, в то время как у нас есть Mapbox Studio, где любой желающий может создать свой дизайн, добавить или убрать обводку дорог, выбрать цвет фона, показывать или прятать отметки любого типа, рисовать свои объекты.
А если Николай весь день писал документацию к проекту, а вечером Геннадий зашёл в этот документ и удалил весь текст, то Николай не может сделать Undo этой операции?
Мне кажется более естественным, если действия всех пользователей складываются в один стек и Undo отменяет последнее по времени действие независимо от того, кто это действие совершил.