В 16:58 UTC мы заметили, что Facebook перестал анонсировать маршруты для своих DNS-префиксов.
Это происходит по той причине, что в DNS, как и во многих других системах в интернете, используется свой механизм маршрутизации.
Автор оригинальной статьи зачем то(может для упрощения) смешал в одну кучу 7 и 4 урони модели OSI. Маршрутизация это 4, DNS 7. И связаны они в этой истории тем, что DNS сервер, как и любой другой сервер тоже находится в сети и взаимодействует в тч на 4 уронве. И в DNS нет ни маршуртизации(в строгом смысле этого слова) ни анонсирования маршрутов.
К этому нужно вверху написать - вот вам методика, но ради всего святого, никогда так не делайте. Пользуйтесь кубером или хотябы докером. А если вам лень, то разверните аппу в Azure App Service.
Это не так. Есть расшифрованные голоса, это голоса, которые учтены. А есть весь массив голосов. Они не расшифрованы но их можно расшифровать(и это было сделано). Вот их разница и есть переголосования.
Нет другого. Нет информации о том, почему именно этот голос был изменен. Это не в публичном блокчейне и этому мы должны верить на слово Но, как я уже говорил выше, статистика показывает, что через переголосования голоса не крали.
Тут не все так просто. Хотя я против электронных выборов, нужно признать что нарисовать РЕЗУЛЬТАТЫ нельзя. Нужно рисовать голоса. А у этого бывают следы.
Операция 5 у вас не очень точно названа. В коде это add_voter_key. На фед выборах это по сути защита от переголосования. Потому что voter_key подписан сервером выдачи бюллетеней, но он его не знает, тк подписывал вслепую. Тк сервер приема голосов должен проверить что я не сдал один бюллетень два раза добавляется эта транзакция. Новый voter_key мне серевер выдачи бюллетеней не подпишет, тк он знает что Вася Пупкин уже получил бюллетень, а сервер приема полагается на уникальность ключа.
А вот какова его роль когда переголосовать можно не очень ясна.
Я вчера тоже пол ночи пытался понять как устроено переголосование. И ничего не смог найти в открытых источниках.
Без него все оч похоже на федеральные выборы, когда невозможно отследить голосовавшего(см https://habr.com/ru/post/574360/#comment_23408446, только комент а не статью, тк в статье скорее всего ошибка.)
Но если я могу переголосовать, то кто то уметь мачить мой старый голос и новый(те операции с типом 6, которые по очевидной причине не имеют voter_id)
Если есть преобразование, которое делает из C' и K' C и К значит должно существовать преобразование в С'' и K'' где С'' валидная подпись K''. А это открывает возможность голосовать 2 и более раз.
Durable mode elastic синка не работает! Не делайте так!
Я терял сообщения с тремя разными симптомами:
1) Отправка сообщений зависла до перезагрузки сервиса(три дня без мониторинга). В текстовых буферах сообщения есть, а в эластике нет.
2) Иногда одиночные сообщения есть в текстовых буферах но нет в эластике. github.com/serilog/serilog-sinks-elasticsearch/issues/125
3) Если у вас сервис падает при старте и даже если вы корректно деалете диспоуз то при определенных условиях вы ничего не получите в эластике github.com/serilog/serilog-sinks-elasticsearch/issues/130
В 16:58 UTC мы заметили, что Facebook перестал анонсировать маршруты для своих DNS-префиксов.
Это происходит по той причине, что в DNS, как и во многих других системах в интернете, используется свой механизм маршрутизации.
Автор оригинальной статьи зачем то(может для упрощения) смешал в одну кучу 7 и 4 урони модели OSI. Маршрутизация это 4, DNS 7. И связаны они в этой истории тем, что DNS сервер, как и любой другой сервер тоже находится в сети и взаимодействует в тч на 4 уронве. И в DNS нет ни маршуртизации(в строгом смысле этого слова) ни анонсирования маршрутов.
Поясните пожалуйста. Про последнюю фразу я уже писал коментом выше.
К этому нужно вверху написать - вот вам методика, но ради всего святого, никогда так не делайте. Пользуйтесь кубером или хотябы докером. А если вам лень, то разверните аппу в Azure App Service.
Я не знаю как они голосовали из за анонимности(по крайне мере в публичном блокчейне)
"я уже говорил выше, статистика показывает, что через переголосования голоса не крали." - я ошибся. Таких данных нет.
Не вполне понял. Корреляцию между какими случайными величинами?
Это не так. Есть расшифрованные голоса, это голоса, которые учтены. А есть весь массив голосов. Они не расшифрованы но их можно расшифровать(и это было сделано). Вот их разница и есть переголосования.
Нет другого. Нет информации о том, почему именно этот голос был изменен. Это не в публичном блокчейне и этому мы должны верить на слово Но, как я уже говорил выше, статистика показывает, что через переголосования голоса не крали.
Я удалил свой комментарий, тк ссылался на то, что не считал сам. Пересчитаю и верну.
Кстати, Кац тоже нашел аномалию с явкой. https://www.youtube.com/watch?v=Htb4_Vuovi0 Но я считаю что у них ошибка на картинке с явкой. https://gist.github.com/rumatavz/b806781b25db93be2890cf6aa556d8fd?fbclid=IwAR07l0e0LSPe-TKzA-5jdYX4aQA0I-9CmFAaaRIcyuDIR7SJ2b2txoBvrYE вот моим расчеты.
Если вы из Москвы и если вы записали определенные данные в момент голосования то вы можете проверить что вас голос учтен верно.
Так транзакции доступны в реалтайме на https://observer.mos.ru/all/
Тут не все так просто. Хотя я против электронных выборов, нужно признать что нарисовать РЕЗУЛЬТАТЫ нельзя. Нужно рисовать голоса. А у этого бывают следы.
Так не выйдет. Они инициализируются до начала.
Я верю:) Но иногда полезно глянуть в код:
Операция 5 у вас не очень точно названа. В коде это add_voter_key. На фед выборах это по сути защита от переголосования. Потому что voter_key подписан сервером выдачи бюллетеней, но он его не знает, тк подписывал вслепую. Тк сервер приема голосов должен проверить что я не сдал один бюллетень два раза добавляется эта транзакция. Новый voter_key мне серевер выдачи бюллетеней не подпишет, тк он знает что Вася Пупкин уже получил бюллетень, а сервер приема полагается на уникальность ключа.
А вот какова его роль когда переголосовать можно не очень ясна.
Я вчера тоже пол ночи пытался понять как устроено переголосование. И ничего не смог найти в открытых источниках.
Без него все оч похоже на федеральные выборы, когда невозможно отследить голосовавшего(см https://habr.com/ru/post/574360/#comment_23408446, только комент а не статью, тк в статье скорее всего ошибка.)
Но если я могу переголосовать, то кто то уметь мачить мой старый голос и новый(те операции с типом 6, которые по очевидной причине не имеют voter_id)
Если есть преобразование, которое делает из C' и K' C и К значит должно существовать преобразование в С'' и K'' где С'' валидная подпись K''. А это открывает возможность голосовать 2 и более раз.
Кажется тут в статье ошибка.
То что вы пишите противоречит статье. В статье сказано что на сервер отправляется ключ P' а вы говорите что на сервер отдается
crypt ( m ).Где правда?
А как тогда работает переголосование, если нет связи между выдачей бюллетеня и голосом?
Я терял сообщения с тремя разными симптомами:
1) Отправка сообщений зависла до перезагрузки сервиса(три дня без мониторинга). В текстовых буферах сообщения есть, а в эластике нет.
2) Иногда одиночные сообщения есть в текстовых буферах но нет в эластике. github.com/serilog/serilog-sinks-elasticsearch/issues/125
3) Если у вас сервис падает при старте и даже если вы корректно деалете диспоуз то при определенных условиях вы ничего не получите в эластике github.com/serilog/serilog-sinks-elasticsearch/issues/130