Там весьма криво описан протокол. Конкретно описанная проблема там решается через внешнего актора. То есть есть внешний независимый сервис ("проверяемой энтропии"), которые каждые 3 секунды публикует случайный ключ и у которого можно запросить, а что он опубликовал в какой-то прошлый момент времени. Оператор лотерии не выбирает drand, он выбирает только время ("номер раунда"), когда наш сервис энтропии опубликует ключ — и вот ключ в этот момент времени и станет нашим drand.
Но сам протокол, вообще говоря, не предназначен для произвольных лотерей типа 6/36. Конкретно uvLotery работает только для случайных перемешиваний кандидатов. Впрочем, на суть проблем это не сильно влияет.
Для своей работы он требует целых два внешних сервиса: проверямоего источника времени и проверяемого источника энтропии. Что кмк не очень хорошо ввиду всяких угроз сговоров =/
Кмк, было бы интересно рассмотреть вариант, когда drand формируется именно что участниками. Условно, чтобы после того, как список участников закомичен, у участников была бы возможность добавить своих байт в пул энтропии. При этом, чтобы порядок добавления зависел от предыдущих добавленных байт — таким образом нельзя будет добавить своего участника в конце. Правда это плохо масштабируется (на миллионы участников).
Tl;Dr; сам протокол в статье толком не описан, нужно читать оригинал. Мб сделать нормальный разбор протокола...
От этого в вебе никуда не деться, и я это не прячу.
Так это, в определённом смысле, ставит крест на всей затее. Если у нас нет доверия к серверу, то браузерный E2EE не имеет смысла декларировать.
Здесь нужно менять подход. Хотя бы банально сделать расширение для браузера, чтобы шифрование в нём происходило.
Или, что круче, это расширение браузера для контролируемых обновлений: ведёт локальный, или распределённый) реестр версий сайтов и выдаёт алерт при любом обновлении. Тогда можно было бы попробовать восстановить доверие к браузерному e2ee.
P.S. не увидел в коде собственно стримминга. Ожидал бы, что крипто библиотека выдаёт именно стрим, который сразу гонится на сервер/в загрузку, без полной буферизации...
Вы здесь путаете фальсифицируемость и возможность ошибки. Если единственный способ опровергнуть утверждение — это найти ошибку в его выводе/получении, то утверждение не фальсифицируемо. По крайней мере, так воспринимают данный термин большинство физиков и математиков, с которыми я знаком.
Впрочем, спор об определениях и потому не имеет смысла.
Так а где здесь фальсификация? От того, что Евклидова геометрия неприменима для решения задач на поверхности земли она разве стала менее верной?
Математикам, которые занимаются Евклидовой геометрией вобщем-то без разницы, выполняются ли её аксиомы на поверхности земли, или нет. Фальсифицируемы науки, которые применяют соответствующие результаты математики, но на то математика и язык.
Честно говоря, я видел достаточно примеров, как самые самые разные системы и модели описывались буквально "несколькими буквами". Поэтому для меня это не то чтобы удивительно. Здесь вопрос лишь в том, насколько хорошо авторы сумеют замести всю сложность под ковёр.
Ну а если мы начинаем учитывать не только основную формулу, но и описание целиком — то получается не так уж и мало. Поэтому мне тяжело согласится с тем, что Ньютоновская динамика есть простое описание — я видел много гораздо более простых моделей.
Но действительно, как всегда спор об определениях =/
Математике всё равно. В математике нет как таковых истин, она просто она просто занимается перекладыванием закорючек по каким-то правилам — а истинны эти закорючки, или ложны — ей без разницы. Ну или, попробуйте привести "истину" в математике (которая не являлась бы определением)
Во-вторых, язык (потенциально, в пределе) способен на полное описание действительности. А математика — нет.
Почему нет?
Ту, которая очищена от качеств (и содержаний?), и состоит из количеств (и форм?).
Не уверен до конца, что это значит. Но вообще говоря, математика описывает далеко не только количества. Более того, современная математика количества практически не описывает.
Взять например ту же топологию. Она, по сути говорит, что если у Вас есть топологическое свойство, то оно не может нарушиться/поменяться при непрерывных преобразованиях. Поэтому если в какой-то физической системе обнаруживается топологический инвариант, то пока эта физическая система развивается непрерывно, данный инвариант не нарушится. Заметьте, здесь нет никаких количеств, мы не имеем никаких количественных описаний системы — а математику применить всё равно можем.
Потому что мы так придумали. Вопрос же в том, что такое F и что такое m. По сути своей, какова бы не была реальность, её можно в определённых пределах описать вторым законом Ньютона. Ну и напомню, что он является лишь приближением.
Но даже если отставить это в сторону и просто посмотреть на саму силу(которой не существует в объективной реальности, мы выдумали этот концепт). Допустим вот сила трения — это просто? Не особо.
Соотношение работает лишь как довольно грубое приближение. Коэффициент трения меняется в зависимости от кучи условий. Даже банально у движущегося тела и у покоящегося будут разные коэффициенты трения. Есть ещё сила трения покоя, которая вообще зависит от того, как сильно Вы пытаетесь пододвинуть тело. Есть вязкое трение, которое зависит от скорости. И так далее...
Ну и даже соотношениеявляется довольно сложным с точки зрения математики. Тут нужны какие-то вещественные числа, бесконечности и даже диффуры. Условный КА, или машина Тьюринга — гораздо проще этого закона.
К тому же, можно сделать функцию tokenize отдельной, которая бы создавала лексер и сразу вызывала функцию lexer.tokenize, и таким образом будет удобный для модификаций лексер и простой удобный юзерский интерфейс.
Об этом и речь. Не имею ничего против контекста. Просто не нужно показывать его в публичном интерфейсе.
Почитал исходники шифрования. Каких-то прям уязвимостей не увидел сходу. Хотя кажется многие вещи можно сделать проще. Например, попытки в ctime, которые ничего не дают (но они и не нужны здесь). Но это не шибко важно.
Важно то, что схема исходно сломана. Шифрование на клиенте принципиально требует доверия к серверу. Проблема в том, что ничего не мешает серверу просто взять и отдать конкретному одному клиенту другой жс код, который, например, пришлёт пароль на сервер.
Мобильное приложение чуть лучше защищает от подобной атаки, т.к. в магазине приложений видны все версии приложения. И то, тут есть вопросы ко всяким A/B тестам, которые магазины могут предлагать разработчикам...
В идеале, для шифрования на клиенте, обновление кода должно происходить только при подтверждении пользователя. Плюс какой-нибудь transparency report от третьих лиц...
Во-первых, в этой функции надо будет создавать обьект лексера, чтобы был общий контекст.
Ну так создайте, в чём проблема. Можете даже сделать реализацию функции tokenize как Lexer::new(s).tokenize(). Суть ведь не в этом.
Суть в том, чтобы публичный интерфейс был простым для простых использований. Если понадобятся опции — сделаете функцию tokenize_with_opts; ну либо уже через объект лексера. См каноничный пример serde_json::from_str.
Потому что в расте миллион объектов могут (в среднем будут) весить меньше чем сто тысяч в Питоне, не?
Просто напросто в расте в целом чуть оптимальнее используется память, т.к. меньше индерекций, плюс нет заголовков объектов*. Всё остальное не имеет особого значения.
Примечание*: про rc/arc немного другой разговор.
И Вы не совсем правы по поводу того, что все 4 упомянутых языка реализуют async fn как стейт-машину. Полностью как стейт-машину их реализует только раст и питон. C# и js используют гибридный подход: одну функцию они реализуют через стейт-машину, но вызов другой функции они обрабатывают через коллбэки.
Простое подходит для простых случаев. Если задача исходно сложная, её нельзя решить просто. Так называемая intrinsic complexity.
Про пересекающие списки. Как будет выглядеть Ваш барабан, если в нём будет 20-40-100 элементов? По идее, у него должен быть неполный круг, и где-то должны быть точка рождения и точка уничтожения иконок. То есть когда прокручивается барабан, крайняя иконка с одной стороны исчезает, а с другой стороны появляется новая, следующая иконка.
Точно такие же точки рождения и уничтожения находятся сверху и снизу линейного списка.
Предложение в том, чтобы объеденить одну из точек уничтожения барабана с точкой рождения списка. То есть, когда какая-то иконка пропадает с барабана при прокрутка, она тут же появляется сверху/снизу списка. Ну и они соответственно скролятся синхронно.
В том то и дело, что пользователь сам добавляет узлы и выстраивает пути
Пользователь может сам выстроить пути, или обязан? Я, как пользователь, не всегда хочу заниматься организацией. Я это знаю по опыту настройки папок и рабочего стола.
Ну, то есть, я готов настроить несколько наиболее важных мне пунктов. Но всё остальное — не то. На настройку уходит много времени и итераций. Особенно, когда регулярно добавляются новые позиции(контакты, приложения и прочее).
И уж тем более я не готов заниматься настройкой в процессе работы. Если мне написал человек, я хочу взять и ответить ему, а не сидеть и выбирать куда его распределить.
Про порядок и навигацию не понимаю опасений если честно, но возможно это мои проблемы/особенности
Я не знаю, о чём Вы. Процитируйте, пожалуйста, конкретный фрагмент моего (исходного) сообщения.
Я даже пробовал делать разные уровни или разделы по цветами, но что иконки, что цвета превращают всё в аляпистую мусорку.
Проблема не в дизайне, а скорее в том, что тяжело распознать, что значит иконка. Подписи в этом плане универсальнее.
P.S. на хабре есть блоки цитат, используйте их пожалуйста.
Вообще, такие радиальные меню уже давно отточили во всяких Maya и Blender. Как по мне там этим очень удобно пользоваться. И его даже не в отсутствии подписей (они там есть) — скорее дело в более равномерном ux и меньшей точности.
Увидеть эту идею на телефоне — это очень интересно. Но меня смущает несколько практических вопросов.
Для начала вопрос иконок. Подобрать хорошие иконки — это прям очень сложно. Почти никто с этим не справляется. Подписи нужны.
А второй вопрос: как подбирать категории. Если это статическая навигация — то может, конечно и ок. Но если пункты добавляются пользователем, то это дерево быстро становится неуправляемым. Тут либо делать какую-то хитрую автоматику (что сложно), либо заставлять пользователя заниматься организацией.
Например, если говорить об интерфейсе мессенджер, хочется иметь возможность не заниматься организацией своих контактов. А в таком случае, плоский список удобнее, т.к. в нём просто больше пунктов помещается.
Быть может имеет смысл какой-то гибридный подход, как в Maya сделать: основные, или часто используемые пункты в радиальном меню, а все остальные списком (сверху). Можно даже дальше пойти и синхронизировать скролл списка: чтобы при прокручивании радиального меню, пункты из него перетакали в список, а из списка в радиальное меню.
Даже если lookup это malloc, даже выровненный по страницам, никаких гарантий, что следующая страница будет защищена. А часто lookup лежит вообще не стеке — тогда тем более.
Можно конечно через secure_malloc выделить память, но он медленный довольно. Там же нужно два лишних mprotect на старте и в конце сделать, плюс нельзя толком аллокации переиспользовать. Кажется эти сисколы съедят почти весь профит от выкидывания проверки.
В общем, кажется такой подход применим крайне редко. Гораздо чаше и гораздо проще просто оптимизировать проверку через условный SIMD.
Там весьма криво описан протокол. Конкретно описанная проблема там решается через внешнего актора. То есть есть внешний независимый сервис ("проверяемой энтропии"), которые каждые 3 секунды публикует случайный ключ и у которого можно запросить, а что он опубликовал в какой-то прошлый момент времени. Оператор лотерии не выбирает drand, он выбирает только время ("номер раунда"), когда наш сервис энтропии опубликует ключ — и вот ключ в этот момент времени и станет нашим drand.
Но сам протокол, вообще говоря, не предназначен для произвольных лотерей типа 6/36. Конкретно uvLotery работает только для случайных перемешиваний кандидатов. Впрочем, на суть проблем это не сильно влияет.
Для своей работы он требует целых два внешних сервиса: проверямоего источника времени и проверяемого источника энтропии. Что кмк не очень хорошо ввиду всяких угроз сговоров =/
Кмк, было бы интересно рассмотреть вариант, когда drand формируется именно что участниками. Условно, чтобы после того, как список участников закомичен, у участников была бы возможность добавить своих байт в пул энтропии. При этом, чтобы порядок добавления зависел от предыдущих добавленных байт — таким образом нельзя будет добавить своего участника в конце. Правда это плохо масштабируется (на миллионы участников).
Tl;Dr; сам протокол в статье толком не описан, нужно читать оригинал. Мб сделать нормальный разбор протокола...
Так это, в определённом смысле, ставит крест на всей затее. Если у нас нет доверия к серверу, то браузерный E2EE не имеет смысла декларировать.
Здесь нужно менять подход. Хотя бы банально сделать расширение для браузера, чтобы шифрование в нём происходило.
Или, что круче, это расширение браузера для контролируемых обновлений: ведёт локальный, или распределённый) реестр версий сайтов и выдаёт алерт при любом обновлении. Тогда можно было бы попробовать восстановить доверие к браузерному e2ee.
P.S. не увидел в коде собственно стримминга. Ожидал бы, что крипто библиотека выдаёт именно стрим, который сразу гонится на сервер/в загрузку, без полной буферизации...
Вы здесь путаете фальсифицируемость и возможность ошибки. Если единственный способ опровергнуть утверждение — это найти ошибку в его выводе/получении, то утверждение не фальсифицируемо. По крайней мере, так воспринимают данный термин большинство физиков и математиков, с которыми я знаком.
Впрочем, спор об определениях и потому не имеет смысла.
Фальсифицируют аксиомы и гипотезы, а не теоремы/доказательства. Ошибка есть просто ошибка.
Я об этом же. Именно поэтому математика не есть наука (не использует научный метод)
Так а где здесь фальсификация? От того, что Евклидова геометрия неприменима для решения задач на поверхности земли она разве стала менее верной?
Математикам, которые занимаются Евклидовой геометрией вобщем-то без разницы, выполняются ли её аксиомы на поверхности земли, или нет. Фальсифицируемы науки, которые применяют соответствующие результаты математики, но на то математика и язык.
Честно говоря, я видел достаточно примеров, как самые самые разные системы и модели описывались буквально "несколькими буквами". Поэтому для меня это не то чтобы удивительно. Здесь вопрос лишь в том, насколько хорошо авторы сумеют замести всю сложность под ковёр.
Ну а если мы начинаем учитывать не только основную формулу, но и описание целиком — то получается не так уж и мало. Поэтому мне тяжело согласится с тем, что Ньютоновская динамика есть простое описание — я видел много гораздо более простых моделей.
Но действительно, как всегда спор об определениях =/
Математике всё равно. В математике нет как таковых истин, она просто она просто занимается перекладыванием закорючек по каким-то правилам — а истинны эти закорючки, или ложны — ей без разницы. Ну или, попробуйте привести "истину" в математике (которая не являлась бы определением)
Почему нет?
Не уверен до конца, что это значит. Но вообще говоря, математика описывает далеко не только количества. Более того, современная математика количества практически не описывает.
Взять например ту же топологию. Она, по сути говорит, что если у Вас есть топологическое свойство, то оно не может нарушиться/поменяться при непрерывных преобразованиях. Поэтому если в какой-то физической системе обнаруживается топологический инвариант, то пока эта физическая система развивается непрерывно, данный инвариант не нарушится. Заметьте, здесь нет никаких количеств, мы не имеем никаких количественных описаний системы — а математику применить всё равно можем.
Нет. Она нефальсифицируема. Более того, в математике нет такого понятия как "ложная аксиома" — а это есть одно из ключевых требований дл науки.
Потому что мы так придумали. Вопрос же в том, что такое F и что такое m. По сути своей, какова бы не была реальность, её можно в определённых пределах описать вторым законом Ньютона. Ну и напомню, что он является лишь приближением.
Но даже если отставить это в сторону и просто посмотреть на саму силу(которой не существует в объективной реальности, мы выдумали этот концепт). Допустим вот сила трения — это просто? Не особо.
Соотношение
работает лишь как довольно грубое приближение. Коэффициент трения меняется в зависимости от кучи условий. Даже банально у движущегося тела и у покоящегося будут разные коэффициенты трения. Есть ещё сила трения покоя, которая вообще зависит от того, как сильно Вы пытаетесь пододвинуть тело. Есть вязкое трение, которое зависит от скорости. И так далее...
Ну и даже соотношение
является довольно сложным с точки зрения математики. Тут нужны какие-то вещественные числа, бесконечности и даже диффуры. Условный КА, или машина Тьюринга — гораздо проще этого закона.
Об этом и речь. Не имею ничего против контекста. Просто не нужно показывать его в публичном интерфейсе.
Почитал исходники шифрования. Каких-то прям уязвимостей не увидел сходу. Хотя кажется многие вещи можно сделать проще. Например, попытки в ctime, которые ничего не дают (но они и не нужны здесь). Но это не шибко важно.
Важно то, что схема исходно сломана. Шифрование на клиенте принципиально требует доверия к серверу. Проблема в том, что ничего не мешает серверу просто взять и отдать конкретному одному клиенту другой жс код, который, например, пришлёт пароль на сервер.
Мобильное приложение чуть лучше защищает от подобной атаки, т.к. в магазине приложений видны все версии приложения. И то, тут есть вопросы ко всяким A/B тестам, которые магазины могут предлагать разработчикам...
В идеале, для шифрования на клиенте, обновление кода должно происходить только при подтверждении пользователя. Плюс какой-нибудь transparency report от третьих лиц...
По поводу использования библиотек - ок.
Ну так создайте, в чём проблема. Можете даже сделать реализацию функции tokenize как Lexer::new(s).tokenize(). Суть ведь не в этом.
Суть в том, чтобы публичный интерфейс был простым для простых использований. Если понадобятся опции — сделаете функцию tokenize_with_opts; ну либо уже через объект лексера. См каноничный пример serde_json::from_str.
Вообще, лексер гораздо проще написать через Logos. Да и эффективнее это.
Также, лучше чтобы tokenize была функцией str -> Tokens, а не методом Lexer-а...
Потому что в расте миллион объектов могут (в среднем будут) весить меньше чем сто тысяч в Питоне, не?
Просто напросто в расте в целом чуть оптимальнее используется память, т.к. меньше индерекций, плюс нет заголовков объектов*. Всё остальное не имеет особого значения.
Примечание*: про rc/arc немного другой разговор.
И Вы не совсем правы по поводу того, что все 4 упомянутых языка реализуют async fn как стейт-машину. Полностью как стейт-машину их реализует только раст и питон. C# и js используют гибридный подход: одну функцию они реализуют через стейт-машину, но вызов другой функции они обрабатывают через коллбэки.
Если рассматривать "как можно ближе" в смысле достижения минимума выражения:
То эта задача в точности эквивалентна комивояжёру для графа из этих точек.
Но вообще говоря слишком много простора в формулировке.
Простое подходит для простых случаев. Если задача исходно сложная, её нельзя решить просто. Так называемая intrinsic complexity.
Про пересекающие списки. Как будет выглядеть Ваш барабан, если в нём будет 20-40-100 элементов? По идее, у него должен быть неполный круг, и где-то должны быть точка рождения и точка уничтожения иконок. То есть когда прокручивается барабан, крайняя иконка с одной стороны исчезает, а с другой стороны появляется новая, следующая иконка.
Точно такие же точки рождения и уничтожения находятся сверху и снизу линейного списка.
Предложение в том, чтобы объеденить одну из точек уничтожения барабана с точкой рождения списка. То есть, когда какая-то иконка пропадает с барабана при прокрутка, она тут же появляется сверху/снизу списка. Ну и они соответственно скролятся синхронно.
Пользователь может сам выстроить пути, или обязан? Я, как пользователь, не всегда хочу заниматься организацией. Я это знаю по опыту настройки папок и рабочего стола.
Ну, то есть, я готов настроить несколько наиболее важных мне пунктов. Но всё остальное — не то. На настройку уходит много времени и итераций. Особенно, когда регулярно добавляются новые позиции(контакты, приложения и прочее).
И уж тем более я не готов заниматься настройкой в процессе работы. Если мне написал человек, я хочу взять и ответить ему, а не сидеть и выбирать куда его распределить.
Я не знаю, о чём Вы. Процитируйте, пожалуйста, конкретный фрагмент моего (исходного) сообщения.
Проблема не в дизайне, а скорее в том, что тяжело распознать, что значит иконка. Подписи в этом плане универсальнее.
P.S. на хабре есть блоки цитат, используйте их пожалуйста.
Вообще, такие радиальные меню уже давно отточили во всяких Maya и Blender. Как по мне там этим очень удобно пользоваться. И его даже не в отсутствии подписей (они там есть) — скорее дело в более равномерном ux и меньшей точности.
Увидеть эту идею на телефоне — это очень интересно. Но меня смущает несколько практических вопросов.
Для начала вопрос иконок. Подобрать хорошие иконки — это прям очень сложно. Почти никто с этим не справляется. Подписи нужны.
А второй вопрос: как подбирать категории. Если это статическая навигация — то может, конечно и ок. Но если пункты добавляются пользователем, то это дерево быстро становится неуправляемым. Тут либо делать какую-то хитрую автоматику (что сложно), либо заставлять пользователя заниматься организацией.
Например, если говорить об интерфейсе мессенджер, хочется иметь возможность не заниматься организацией своих контактов. А в таком случае, плоский список удобнее, т.к. в нём просто больше пунктов помещается.
Быть может имеет смысл какой-то гибридный подход, как в Maya сделать: основные, или часто используемые пункты в радиальном меню, а все остальные списком (сверху). Можно даже дальше пойти и синхронизировать скролл списка: чтобы при прокручивании радиального меню, пункты из него перетакали в список, а из списка в радиальное меню.
Последнее время, много где предпочитают хоть и не очень структурированный/понятный текст, но написанный вручную.
Даже если lookup это malloc, даже выровненный по страницам, никаких гарантий, что следующая страница будет защищена. А часто lookup лежит вообще не стеке — тогда тем более.
Можно конечно через secure_malloc выделить память, но он медленный довольно. Там же нужно два лишних mprotect на старте и в конце сделать, плюс нельзя толком аллокации переиспользовать. Кажется эти сисколы съедят почти весь профит от выкидывания проверки.
В общем, кажется такой подход применим крайне редко. Гораздо чаше и гораздо проще просто оптимизировать проверку через условный SIMD.
А так, это скорее прямой путь к cve...