Не знаю, с границами стран очень умное решение, в мире сотни спорных территорий и сотни стран, которые по-разному на них смотрят, задолбаешься подстраиваться чтобы мозг не парили (по айпи и тд.).
Для ежедневного пользования границы стран не особо то и нужны, сложно придумать примеры. Ну и глобализация прогнозирует, что в будущем все будет сосредоточено вокруг мегаполисов.
Принудительное лицензирование - это не новый термин, применяется во многих странах (США, Британия и тд). Его как раз используют против злоупотребления своим правом зарабатывать.
«Решение бюро будет зависеть от обстоятельств. В частности, от того, как работает инструмент ИИ и как конкретно он использовался для создания окончательной работы», — заявил регулятор.
Нет, давайте лучше вместо TOTP обязательным пусть будет U2F, чтобы было проще с помощью аппаратных ключей заходить.
Саму идею для некоторых компаний я бы не стал реализовывать, потому что народ не умеет бэкапиться, синхронизировать время и тд. Даже тот же Authy привязан к номеру телефона вроде.
Кофе неплохо работает в начале, но через некоторое время приходится пить его чаще чтобы продуктивность не падала в некоторые моменты до нуля. А какой смысл тратить деньги и здоровье, если можно быть всегда нормальным?
Приватный ключ нам нужен только для следующего шага. Попробую объяснить свои мысли на грубом примере:
Ева пропускает через себя весь трафик и ждет идентификатор жертвы.
Если дождалась нужного клиента, отправляет ему, например, N=5 (можно отправлять не такое очевидное число). Т.к. клиент заходит с нового браузера, то не может проверить какие числа были при регистрации. Например, для случая N=5 у клиента небольшой выбор, это выбрать в качестве приватного ключа a=2 или a=3.
Клиент выбрал и отправил Еве публичный ключ, по нему Ева однозначно понимает какой приватный ключ выбрала жертва для текущего сеанса, т.к. остальные параметры для вычисления тоже отправляла ему Ева.
Теперь клиент хочет убедится, что этот сеанс у него с сервером. А Ева ему прислала в ответ еще один слабый параметр B (может быть тоже не таким очевидным).
Клиент вычисляет хеш М1, используя все что получал только от Евы и свой пароль. Потом отправляет этот хеш Еве.
Ева таким образом получила известный хеш от пароля жертвы даже не взламывая БД и вообще не общаясь с сервером ProtonMail.
Теперь Ева ничего не отвечая клиенту, просто разрешает ему начать новую сессию с сервером напрямую и уже не вмешивается.
Сама в это время запускает параллельные переборы на кластере.
Ладно, концовку я нафантазировал, но на самом деле, если есть ресурсы и жертва важна, журналист там или информатор ничего не заметят. Просто куча лишних действий, если твое положение дошло до того, что ты не доверяешь обычному https и хешам в базе, то такая схема тебя тоже не спасет.
Заметил интересные моменты в алгоритме, может не прав.
2. Сервер в ответ направляет клиенту «закреплённые» за ним параметры:
— модуль — генератор — соль
В этот момент Ева (Man-in-the-Middle) может подсунуть клиенту более слабые параметры.
3. Клиентское приложение генерирует приватный ключ a из допустимого диапазона 2, …, N-2 и вычисляет публичный ключ (A не равно нулю) и отправляет его на сервер.
Тут клиент выполняет вычисления с новым слабым приватным ключом и со слабыми параметрами. Результат отправляет Еве, которая может восстановить этот слабый приватный ключ и пока просто сохранить его.
5. Чтобы убедиться, что ни одну из сторон не подменили в процессе, клиент и сервер обмениваются проверочными значениями.
Сама проверка происходит на пятом шаге. Но если посмотреть внимательнее на все вычисления, то клиент просто проводит всякие хеширования уже со своим паролем и с параметрами, которые установила или знает Ева. Потом результат снова отправляется Еве.
Вроде не критично, т.к. это не сам пароль, а обычный хеш от него, но все равно как-то не очень все выглядит.
Не знаю, с границами стран очень умное решение, в мире сотни спорных территорий и сотни стран, которые по-разному на них смотрят, задолбаешься подстраиваться чтобы мозг не парили (по айпи и тд.).
Для ежедневного пользования границы стран не особо то и нужны, сложно придумать примеры. Ну и глобализация прогнозирует, что в будущем все будет сосредоточено вокруг мегаполисов.
Пишут, что будет работать этично и в следующем абзаце про защищенную запись чтобы избежать этичных рисков.
iOS-разработчики решили, что следующее приложение для айфонов все таки тоже на Swfit будут делать.
Ну для начала можно не генерировать пароль (восемь знаков) для root-пользователя, когда создаешь сервер со своим ssh-ключом.
Спасибо, что напомнили, круто
Принудительное лицензирование - это не новый термин, применяется во многих странах (США, Британия и тд). Его как раз используют против злоупотребления своим правом зарабатывать.
https://en.m.wikipedia.org/wiki/Compulsory_license
Рогалик
Про уток вопрос максимально криво сформулирован, ChatGPT должен был послать просто.
Регулятор будет регулировать.
Мне кажется, в таких случаях не нужно возвращать госпошлину.
Нет, давайте лучше вместо TOTP обязательным пусть будет U2F, чтобы было проще с помощью аппаратных ключей заходить.
Саму идею для некоторых компаний я бы не стал реализовывать, потому что народ не умеет бэкапиться, синхронизировать время и тд. Даже тот же Authy привязан к номеру телефона вроде.
Мне больше нравится JSON Lines для потоковой обработки.
https://jsonlines.org/
Посмотрел файлы, там нет модели вообще, но в дискуссии обещают в конце марта.
Они обычно на huggingface выкладывают, возможно, вот модель:
https://huggingface.co/sberbank-ai/FRED-T5-1.7B
Еще сколько самолетов рассылают маркетологи самого яндекса.
Кофе неплохо работает в начале, но через некоторое время приходится пить его чаще чтобы продуктивность не падала в некоторые моменты до нуля. А какой смысл тратить деньги и здоровье, если можно быть всегда нормальным?
Приватный ключ нам нужен только для следующего шага. Попробую объяснить свои мысли на грубом примере:
Ева пропускает через себя весь трафик и ждет идентификатор жертвы.
Если дождалась нужного клиента, отправляет ему, например, N=5 (можно отправлять не такое очевидное число). Т.к. клиент заходит с нового браузера, то не может проверить какие числа были при регистрации. Например, для случая N=5 у клиента небольшой выбор, это выбрать в качестве приватного ключа a=2 или a=3.
Клиент выбрал и отправил Еве публичный ключ, по нему Ева однозначно понимает какой приватный ключ выбрала жертва для текущего сеанса, т.к. остальные параметры для вычисления тоже отправляла ему Ева.
Теперь клиент хочет убедится, что этот сеанс у него с сервером. А Ева ему прислала в ответ еще один слабый параметр B (может быть тоже не таким очевидным).
Клиент вычисляет хеш М1, используя все что получал только от Евы и свой пароль. Потом отправляет этот хеш Еве.
Ева таким образом получила известный хеш от пароля жертвы даже не взламывая БД и вообще не общаясь с сервером ProtonMail.
Теперь Ева ничего не отвечая клиенту, просто разрешает ему начать новую сессию с сервером напрямую и уже не вмешивается.
Сама в это время запускает параллельные переборы на кластере.
Ладно, концовку я нафантазировал, но на самом деле, если есть ресурсы и жертва важна, журналист там или информатор ничего не заметят. Просто куча лишних действий, если твое положение дошло до того, что ты не доверяешь обычному https и хешам в базе, то такая схема тебя тоже не спасет.
Заметил интересные моменты в алгоритме, может не прав.
В этот момент Ева (Man-in-the-Middle) может подсунуть клиенту более слабые параметры.
Тут клиент выполняет вычисления с новым слабым приватным ключом и со слабыми параметрами. Результат отправляет Еве, которая может восстановить этот слабый приватный ключ и пока просто сохранить его.
Сама проверка происходит на пятом шаге. Но если посмотреть внимательнее на все вычисления, то клиент просто проводит всякие хеширования уже со своим паролем и с параметрами, которые установила или знает Ева. Потом результат снова отправляется Еве.
Вроде не критично, т.к. это не сам пароль, а обычный хеш от него, но все равно как-то не очень все выглядит.
У нас отдельный поддомен просто
Нет смысла искать логичное решение, это стандартная NP-полная задача о рюкзаке.