защита от MitM? Кажется, что эта схема не может быть лучше.
защита от слива базы? Эта схема позволяет имея только «серверные» данные узнать, является ли тот или иной пароль правильным. Ну а дальше делается обычный брутфорс, не вижу особенных преимуществ над обычными хорошо солеными хешами.
защита от недоверенного сервера? TLS гарантирует аутентичность, а дальше если хоть какие данные в нешифрованном виде вдруг бывают на недоверенном сервере, то можно их смело считать раскрытыми. Тут только всё шифрование на клиенте выполнять — но про это как раз в конце сказали.
Разве что здесь строго доказано, что брутфорс нельзя облегчить какой-нибудь уязвимостью в алгоритме хеширования. Но стоит ли оно того? Если вдруг злоумышленник получил доступ к базе с паролями, то имеет смысл считать, что все менее защищенные данные уже скомпрометированы. Тут остается только попытаться защитить сам пароль пользователя, но если он вдруг использует один на нескольких сервисах, то надёжность этого пароля определяется надёжностью самого уязвимого сервиса.
Предполагается, что где-то в вашей локальной сети будет машинка, которая обслуживает эту подсеть и выступает NAT из одного в другое. И она не должна быть доступна в большом интернете, ибо локальных сетей много.
Банально чтобы ходить в IPv4 вам понадобиться IPv4-адрес для этого, а их мало — пусть каждая локальная сеть решает эту проблему как-нибудь сама.
Если считать, что алгоритмы ранжирования — какие-то обученные нейросети и классификаторы, то скорее нет. Не думаю, что блобы с весами хранятся в монорепе
А почему это проблема? Мне почему-то кажется, что если температура процессора довольно низкая, то все в пределах нормы и можно ничего не делать. А когда эффективность системы охлаждения от этого падает, то он нагреется до привычной температуры и ситуация не поменяется. Кажется, что баланс будет в итоге достигнут, если система охлаждения вообще способна отводить X ватт тепла при Y температуре внутри. Но причем тогда факт, что процессоры стали холоднее?
Здесь стоит заметить, что при использовании 256 в качестве модуля, в некоторых случаях можно выяснить один бит зашифрованного секрета, не обладая всеми необходимыми ключами. В этой реализации проблема усугубляется ещё и тем, что каждый байт секрета разделяется независимо и из каждого утекает один такой бит. В итоге при разделении стандартного 256битного ключа, достаточно осведомлённый злоумышленник может вычислить 32 его бита, что звучит как дочерта (и значительно сокращает перебор)
Как это работает
окей, пусть мы не знаем одну из долей секрета, но знаем все остальные . Составим СЛАУ на коэффициенты многочлена из уравнений и неизвестных (коэффициенты, плюс недостающая нам доля). Выразим отсюда все коэффициенты через эту неизвестную долю, получим какие-то выражения вида , где y — неизвестно. Фокус в том, что мы обладаем достаточной информацией, чтобы знать, что эта дробь имеет смысл, потому что коэффициент же существует. А значит, что делится на . Если бы действие происходило в поле, то это бы ничего не дало (там можно делить что угодно), но у нас-то кольцо вычетов по непростому модулю 256. Нехитрыми размышлениями можно сократить множество возможных в два раза, а отсюда сокращается и пространство значений самого секрета. Ура!
Был один никнейм, который мне интересен, но занят каким-то арабским каналом, давно уже неактивным. Ну что же, подумал я, и забил. А теперь смотрю на аукцион и вижу его, но вполне доступным (во второй волне). Более того, в телеге и правда этот юзернейм больше никуда не ведёт, но только и занять его самому тоже нельзя.
Но это же не замена стримингов. Найти и скачать файл занимает заметно больше привычных пяти секунд, а уж о автоматических рекомендациях остаётся только мечтать.
Очень странно на Хабре видеть новости, в которых пишут "Уязвимость в ПО, лежащем в основе ..." вместо простого и понятного "Уязвимость в Electron". Так и заголовок короче, и масштаб проблемы с виду побольше — идеально же для новостей, разве нет? Понятное дело, что обыватель может не знать кто этот ваш Electron и где он применяется, но не на Хабре же.
Конкретно в случае с линуксом это будет сложно. Обратную совместимость для юзерспейса сохраняют очень жёстко и там мажорная будет всегда 1 покуда Линус жив. Внутреннее же апи так или иначе ломается постоянно и если из-за него инкрементить мажорную, то она быстро потеряет свой смысл. Так или иначе, получаются какие-то большие нечего не значащие числа. Ну, версия патча из семвера остаётся, но она и так вроде есть.
Номера версий линукса мало что значат, да и мажорный номер уже не первый раз увеличивается потому что минорный стал слишком большим числом. Наверное, можно было бы нумеровать как браузеры где уже далеко за 100+, но и текущий вариант не хуже.
Значит ли это, что для условного питона можно написать реализацию компилятора, который будет выдавать программы, сравнимые с условным rustc по производительности? Чтобы обычный наивный код с kwargs и декораторами работал также, как и обычный наивный код с traits и generics. И ещё интересно во сколько раз этот гипотетический компилятор будет сложнее условного gcc или LLVM.
Хотя бы потому что форматирование это создание где-то в памяти строки, которую потом копировать в поток. С текущим подходом каждый объект просто может как-то себя положить в поток, не используя слишком много дополнительной памяти и времени.
Потому что на Rust часто показывается только финальный вариант + чуть-чуть борьбы с компилятором. На Гошных же примерах подробно объясняется поведение программы, как оно меняется в зависимости от разных деталей, где именно можно накосячить и как это исправлять. На расте сложно элегантно демонстрировать подобные проблемы, на самом деле.
ИМХО, статья скорее должна называться "какие ошибки ловит Rust, но не ловят другие языки".
А в чём преимущество над стандартным TLS?
защита от MitM? Кажется, что эта схема не может быть лучше.
защита от слива базы? Эта схема позволяет имея только «серверные» данные узнать, является ли тот или иной пароль правильным. Ну а дальше делается обычный брутфорс, не вижу особенных преимуществ над обычными хорошо солеными хешами.
защита от недоверенного сервера? TLS гарантирует аутентичность, а дальше если хоть какие данные в нешифрованном виде вдруг бывают на недоверенном сервере, то можно их смело считать раскрытыми. Тут только всё шифрование на клиенте выполнять — но про это как раз в конце сказали.
Разве что здесь строго доказано, что брутфорс нельзя облегчить какой-нибудь уязвимостью в алгоритме хеширования. Но стоит ли оно того? Если вдруг злоумышленник получил доступ к базе с паролями, то имеет смысл считать, что все менее защищенные данные уже скомпрометированы. Тут остается только попытаться защитить сам пароль пользователя, но если он вдруг использует один на нескольких сервисах, то надёжность этого пароля определяется надёжностью самого уязвимого сервиса.
Предполагается, что где-то в вашей локальной сети будет машинка, которая обслуживает эту подсеть и выступает NAT из одного в другое. И она не должна быть доступна в большом интернете, ибо локальных сетей много.
Банально чтобы ходить в IPv4 вам понадобиться IPv4-адрес для этого, а их мало — пусть каждая локальная сеть решает эту проблему как-нибудь сама.
Если считать, что алгоритмы ранжирования — какие-то обученные нейросети и классификаторы, то скорее нет. Не думаю, что блобы с весами хранятся в монорепе
А почему это проблема? Мне почему-то кажется, что если температура процессора довольно низкая, то все в пределах нормы и можно ничего не делать. А когда эффективность системы охлаждения от этого падает, то он нагреется до привычной температуры и ситуация не поменяется. Кажется, что баланс будет в итоге достигнут, если система охлаждения вообще способна отводить X ватт тепла при Y температуре внутри. Но причем тогда факт, что процессоры стали холоднее?
Ну если вы можете из воды и углерода собрать условный спирт и половину органики заодно...
Здесь стоит заметить, что при использовании 256 в качестве модуля, в некоторых случаях можно выяснить один бит зашифрованного секрета, не обладая всеми необходимыми ключами. В этой реализации проблема усугубляется ещё и тем, что каждый байт секрета разделяется независимо и из каждого утекает один такой бит. В итоге при разделении стандартного 256битного ключа, достаточно осведомлённый злоумышленник может вычислить 32 его бита, что звучит как дочерта (и значительно сокращает перебор)
Как это работает
окей, пусть мы не знаем одну из долей секрета, но знаем все остальные
. Составим СЛАУ на коэффициенты многочлена из 
уравнений и 
неизвестных (коэффициенты, плюс недостающая нам доля). Выразим отсюда все коэффициенты через эту неизвестную долю, получим какие-то выражения вида 
, где y — неизвестно. Фокус в том, что мы обладаем достаточной информацией, чтобы знать, что эта дробь имеет смысл, потому что коэффициент же существует. А значит, что 
делится на 
. Если бы действие происходило в поле, то это бы ничего не дало (там можно делить что угодно), но у нас-то кольцо вычетов по непростому модулю 256. Нехитрыми размышлениями можно сократить множество возможных 
в два раза, а отсюда сокращается и пространство значений самого секрета. Ура!
Я про возможность в чужих чатах выбрать профиль кнопкой слева от поля ввода сообщения.
К слову, больше нельзя без премиума писать в чатах от лица своих публичных каналов.
Был один никнейм, который мне интересен, но занят каким-то арабским каналом, давно уже неактивным. Ну что же, подумал я, и забил. А теперь смотрю на аукцион и вижу его, но вполне доступным (во второй волне). Более того, в телеге и правда этот юзернейм больше никуда не ведёт, но только и занять его самому тоже нельзя.
Интересно они высвобождают имена, конечно.
Но это же не замена стримингов. Найти и скачать файл занимает заметно больше привычных пяти секунд, а уж о автоматических рекомендациях остаётся только мечтать.
Если вдруг кому-то захотелось узнать что это такое, то есть более полезная новость: https://cloud.yandex.ru/blog/posts/2022/09/yandex-query-preview (хотя бы с ссылочками на документацию)
Очень странно на Хабре видеть новости, в которых пишут "Уязвимость в ПО, лежащем в основе ..." вместо простого и понятного "Уязвимость в Electron". Так и заголовок короче, и масштаб проблемы с виду побольше — идеально же для новостей, разве нет? Понятное дело, что обыватель может не знать кто этот ваш Electron и где он применяется, но не на Хабре же.
Аккаунт разработчика стоит что-то около $100 в год у Apple.
Конкретно в случае с линуксом это будет сложно. Обратную совместимость для юзерспейса сохраняют очень жёстко и там мажорная будет всегда 1 покуда Линус жив. Внутреннее же апи так или иначе ломается постоянно и если из-за него инкрементить мажорную, то она быстро потеряет свой смысл. Так или иначе, получаются какие-то большие нечего не значащие числа. Ну, версия патча из семвера остаётся, но она и так вроде есть.
Номера версий линукса мало что значат, да и мажорный номер уже не первый раз увеличивается потому что минорный стал слишком большим числом. Наверное, можно было бы нумеровать как браузеры где уже далеко за 100+, но и текущий вариант не хуже.
Значит ли это, что для условного питона можно написать реализацию компилятора, который будет выдавать программы, сравнимые с условным rustc по производительности? Чтобы обычный наивный код с kwargs и декораторами работал также, как и обычный наивный код с traits и generics. И ещё интересно во сколько раз этот гипотетический компилятор будет сложнее условного gcc или LLVM.
Так есть же конфигурация ноутбука с предустановленной Ubuntu.
Вообще, кажется, что по каким-то причинам им проще было завернуть всё в виртуалку, чем убирать из модельного ряда вариант с DOS.
Это при любом не вполне обратимом действии: смена видимости, смена владельца, архивация, удаление.
Хотя бы потому что форматирование это создание где-то в памяти строки, которую потом копировать в поток. С текущим подходом каждый объект просто может как-то себя положить в поток, не используя слишком много дополнительной памяти и времени.
Потому что на Rust часто показывается только финальный вариант + чуть-чуть борьбы с компилятором. На Гошных же примерах подробно объясняется поведение программы, как оно меняется в зависимости от разных деталей, где именно можно накосячить и как это исправлять. На расте сложно элегантно демонстрировать подобные проблемы, на самом деле.
ИМХО, статья скорее должна называться "какие ошибки ловит Rust, но не ловят другие языки".
Удивительно, но такая фича уже существует, причем не вчера появилась. Называется inlay hints.
Выглядит плюс-минус так:
IntelliJ
VS Code