Я понимаю, что «тем» людям не нужен крайне сильный и секюрный рандом.
Однако можно рассматривать эти конкурсы абстрактно и придумать хорошую схему «на всякий случай», вдруг когда-нибудь пригодится для какой-нибудь совершенно внезапной другой области.
Я могу в онлайне транслировать видео с камеры, где я демонстрирую всем себя, сегодняшнюю газету, показываю городские часы, показываю /etc/hosts, затем открываю random.org и генерирую число, которое оказывается выбранным мной.
А всё потому что моя ОС была запущена в виртуальной машине и изменён /etc/hosts в машине выше, или вообще на роутере.
megarandom с ссылкой таким не страдает, но это посредник, которому мы должны довериться.
Если генерировать рандом именно в момент определения победителя — нужно доверие к этому сервису. Если же в момент создания страницы — то нужно во-первых доверие к схеме (например, сервис может иметь базу солей, плюс множество коллизий к этой соли и выбранному рандому), а во-вторых это неприменимо к варианту, когда рандом нужен прямо сейчас, ибо тогда нужно доверие к этому сервису.
Алсо, если организаторы в сговоре с сервисом и знают, какой рандом выпадет — ничего не мешает, например, вклиниться на нужную позицию в список по признаку, по которому идёт сортировка.
Это проблема, да. Придётся начинать всю операцию сначала (ибо тогда мы можем подсадить какое-то кол-во своих и решить, кто откажется раскрывать, а кто нет и повлиять на итог).
Но в случае с получением приза — мы ему гарантированно его ему не даём (хотя и так и так, это плохо), баним и клеймим позором (и возможно его не берут и в другие конкурсы из-за этого).
А в случае с негативным вариантом (когда тот, кто выпадет, например, «дежурит» по чём-то), просто считаем, что выбран он.
И похоже проблема ещё и с групповым сговором, когда ещё не конкретный последний, а группа видит, что один из них не может выиграть и отказываются вскрываться. Тут тоже отбираем профит, баним локально. При повторении такого поведения — глобально.
А как мы генерирум число в этом множестве? Кто за это ответственен?
Заранее неизвестный фактор это хорошо. Но нужно искать, чтобы: провайдер данных о этом факторе не мог подменить данные, данные часто менялись (если нужно, например, получить числа уже «сейчас», а следующий биткоин-блок будет только через 10 минут), обладали достаточной длиной (у курса и температуры крайне мало бит и можно предсказать промежуток, что даёт нам возможность потенциально «подсдадить» кучу народа, чтобы выпало в подставных).
А если люди будут ждать 4-5 часов для того, чтобы статистика получила процент побольше и из-за того, что масса людей «ждёт» — этот процент катится в пропасть?
Посмотрел полную версию и задав несколько дополнительных вопросов кажется осознал концепцию FRP. И теперь возможно когда-нибудь получив какую-либо сложную задачу, которую нельзя будет очевидным образом решить «традиционными» (в том смысле теми, которые я знал до этого) средствами и методиками — возможно FRP сможет помочь. Как и с любыми другими концепциями.
Может быть доклад действительно не так хорош, но с другой стороны. Если бы он был «обычный» — он не появился бы здесь. И я так и не знал бы о FRP (хотя до этого видел несколько упоминаний, но не смотрел, ибо не было очевидно, стоит ли в этом разбираться).
Ну и что, лучше, чтобы на конференцию javascript-разработчиков вышел какой-нибудь Haskell'ист и начал толкать о том, как при помощи монад, теории категорий, стрелок Клейсли и прочего очень легко и без проблем фигачить UI? Рассказывая при этом уныло и используя половину ныне существующей математики.
«Принцип только один: Доставщик всегда на посту, свою пиццу вы получите через тридцать минут, в противном случае можете пристрелить Доставщика, забрать его машину и подать групповой иск.» — «Лавина», Нил Стивенсон.
У нас в Беларуси запрещено, например, по дороге ехать:
Движение на велосипеде должно осуществляться по велосипедной дорожке, а при ее отсутствии — по обочине, тротуару или пешеходной дорожке, не создавая препятствия для безопасного движения пешеходов. При отсутствии указанных элементов дороги или невозможности движения по ним допускается движение велосипедистов по проезжей части дороги в один ряд не далее 1 метра от ее правого края.
Не работает только в постапокалиптическом мире и при ну совсем громадном заговоре.
Однако можно рассматривать эти конкурсы абстрактно и придумать хорошую схему «на всякий случай», вдруг когда-нибудь пригодится для какой-нибудь совершенно внезапной другой области.
А всё потому что моя ОС была запущена в виртуальной машине и изменён /etc/hosts в машине выше, или вообще на роутере.
megarandom с ссылкой таким не страдает, но это посредник, которому мы должны довериться.
Алсо, если организаторы в сговоре с сервисом и знают, какой рандом выпадет — ничего не мешает, например, вклиниться на нужную позицию в список по признаку, по которому идёт сортировка.
Но в случае с получением приза — мы ему гарантированно его ему не даём (хотя и так и так, это плохо), баним и клеймим позором (и возможно его не берут и в другие конкурсы из-за этого).
А в случае с негативным вариантом (когда тот, кто выпадет, например, «дежурит» по чём-то), просто считаем, что выбран он.
И похоже проблема ещё и с групповым сговором, когда ещё не конкретный последний, а группа видит, что один из них не может выиграть и отказываются вскрываться. Тут тоже отбираем профит, баним локально. При повторении такого поведения — глобально.
Нужно как-то это решить бы.
Заранее неизвестный фактор это хорошо. Но нужно искать, чтобы: провайдер данных о этом факторе не мог подменить данные, данные часто менялись (если нужно, например, получить числа уже «сейчас», а следующий биткоин-блок будет только через 10 минут), обладали достаточной длиной (у курса и температуры крайне мало бит и можно предсказать промежуток, что даёт нам возможность потенциально «подсдадить» кучу народа, чтобы выпало в подставных).
Если рандом крайне важен — найдутся ресурсы повлиять на такой сервис. Взятка/взлом/терморектальный криптоанализ.
Будет лишь оверхед в 8 байт (4 байта на тип, 4 байта на кол-во элементов).
На этот раз уже ушло печататься с RodcHenko, но следующий раз посмотрим на ваш :)
Спасибо ещё раз.
Может быть доклад действительно не так хорош, но с другой стороны. Если бы он был «обычный» — он не появился бы здесь. И я так и не знал бы о FRP (хотя до этого видел несколько упоминаний, но не смотрел, ибо не было очевидно, стоит ли в этом разбираться).
Ну и что, лучше, чтобы на конференцию javascript-разработчиков вышел какой-нибудь Haskell'ист и начал толкать о том, как при помощи монад, теории категорий, стрелок Клейсли и прочего очень легко и без проблем фигачить UI? Рассказывая при этом уныло и используя половину ныне существующей математики.
Ну и… прикольно же, не?