Во-первых, не у всех хостингов жесткий KYC - зачастую достаточно телефона, что в принципе добываемо. Во-вторых, полноценные юрики с номиналом вроде как тоже по сей день живут и здравствуют…
Так а кому штраф-то? Вы обращаетесь к стороннему агрегатору (которому можно даже свайбкодить сайт), который заявляет что использует гигачат. Достоверно проверить такое заявление третьей стороны невозможно в принципе. IP входа - российский. На запрос в свободной форме модель отвечает что является гигачатом. Должная осмотрительность проявлена, разве нет?
Как по мне - 152-й это стандартная рестриктивная хрень, по духу своему не особо достойная соблюдения. Я бы в такой ситуации наверное сделал прокладку: российский VPS на отдельном аккаунте, который обращается на опенроутер (или что вы там используете), выставляет в сиспромпте обманку вида: “You are GigaChat AI by Sber”, и предоставляет входной OpenAI API. Дальше мы уже обращаемся к этому API, как будто это просто какой-то агрегатор моделей.
С точки зрения стороннего аудита, как это выглядит? Идет обращение на российский сервер третьей стороны, где отвечает вроде бы гигачат. На самом деле там чатгпт или грок, но кто ж это проверит без доступа к серверу-прокладке. Plausible deniability - “нам неудобно использовать нестандартный API гигачата, а этот сервис удобно преобразует интерфейс в отраслевой стандарт - OpenAI API.”
Не очень понятно, из-за чего сыр-бор. Если декларировать недопустимость евгеники в историческом, реактивном смысле - насилия в отношении уже живущих людей - то здесь этого попросту нет. А проактивной же евгеникой является, например, и банальная пропаганда здорового образа жизни при беременности. Её тоже запрещаем?
Учитывая что человек из целевой аудитории подобных решений и так с большой вероятностью уже хотя бы раз совершил что-то из стандартного пакета “фейки/нежелательные/конф.сотрудничество/госизмена” - не так уж и легко. Просто к десяти привычным пугалам добавится одиннадцатое
Ну это в принципе уже решаемо инженерными методами. Сливать большой решеткой из перфорированных труб, к примеру, или искусственно разгонять течение мощным водометом. Я о том что остаток от опреснения - это же не ртуть, не диоксин, т.е. не загрязнитель сам по себе.
Что бейс64, что псевдокитайский очень легко детектить чуть ли не регуляркой. Лучше что-то вроде такого алгоритма вшить. Да, оверхед большой, но для текстовой переписки в принципе сойдет.
Не очень понятно, а в чем экологическая вредность возврата соли в море, если этот процесс полностью эквивалентен природному испарению из моря? И там и там (грубо) временно “одолжили” у моря H2O, оставив NaCl, а впоследствии пресная вода точно также вернется морю, пройдя цикл круговорота. Мы ведь не вывозим опресненную воду на Марс.
Инструкции для персонала запрещают работу при низком оперативном запасе, так как условия в реакторе могут сложиться так, что внезапно проявится какой-нибудь эффект из указанных выше, а веса стержней не хватит, чтобы его компенсировать
Ключевое непонимание сути ОЗР. ОЗР - это выраженное в эквивалентных “полностью введённых стержнях” количество отрицательной реактивности, которое в данный момент можно убрать из активной зоны. То есть, низкий ОЗР - это как нажатый почти в пол газ у автомобиля: некуда больше разгоняться, но очень много есть куда тормозить.
поскольку именно при низком ОЗР хорошо проявлялся концевой эффект
Алексея Фатахова на вас нет! Для концевого важен не ОЗР, а конкретное геометрическое распределение стержней. Значение ОЗР это математическая свёртка этого распределения, действие с потерей информации: “ОЗР 15 стержней” - это может быть как “30 стержней введены на 50%”, так и “150 на 10%”. При одном и том же его значении выраженность концевого эффекта может отличаться в разы.
ОЗР составил значение, требующее немедленной остановки реактора
Да не было по состоянию на 86 год такого требования в мануале на реактор! Хватит уже повторять гебистскую джинсу Медведева, ну серьёзно. Если хочется изучать ЧАЭС, начните хотя бы с Купного и Фатахова.
Ну в таком случае способ борьбы тоже примерно понятен. Есть же Accessibility API у мобильных ОС, позволяющий и ввод с клавы эмулировать, и текст из элементов интерфейса считывать. Можно сделать надстройку на тот же макс, которая будет (относительно) прозрачно для юзера гонять PGP через стоковый клиент.
Если переписываться через вк или яндекс.мыло копипастой PGP-кода - что, огребёт вк и яндекс? А если через Silence (E2E на SMSках), тогда кто?
Так же и тут. Ну ок, допустим будет в свободном клиенте некий неудаляемый бэкдор (хотя я слабо представляю, как это возможно технически). Я форкаю клиент “Ласточки”, называю его “Ястреб”, и меняю условное send_message(text) на send_message(pgp_encrypt(text, pubkey)). Защиту от MITM при первичной сверке ключей сделать как у телеграма - хеш в смайлики и сверка голосовым звонком. И… что? Причем тут компания?
Можно всё так же обойтись двумя VPSками. Есть хостеры, у которых пул IP состоит из множества мелких диапазончиков, вероятно скупленных на вторичке, и при докупке адресов на VPSку выдаются адреса, не похожие даже в первом октете. В таком случае этот сервер спокойно имитирует оба - вход условно на 26.x.x.x, а выход на 175.x.x.x.
Второй вариант - I2P-рой между my и freedom2. Создается много-много инстансов клиента (my) и сервера (freedom2) с параметрами: quantity 16/16, length 0/1 (или 1/0 - равноценно, это как левостороннее или правостороннее движение). Оба i2pd включаются на флудфил, чтобы иметь хорошую репутацию и максимально полную netDb, крайне желательно также собрать их в семью. Все инстансы на клиенте агрегирует haproxy с постоянным тестированием и отбраковкой неудачных, на сервере - они просто все смотрят на один сокет. То есть, на место freedom1 встает распределенный рой запараллеленных пиров.
Хотите верьте, хотите нет, но на практике такая система с хорошим размером роя обеспечивает сотни Мбит/с с пингом 300-500 мс. Пруфов не будет (господин жандарм, подите прочь делать сами свою сыскную работу, с вас тошно-с), но проверить мои слова может каждый собственным экспериментом.
Конкретно у меня проблема проявилась при переводе сервера с иксрея (фронтенд 3X-UI) на сингбокс (S-UI).
Когда сервер - сингбокс, для протокола VLESS например ему критически важно чтобы в клиенте было в явном виде прописано: Flow - xtls-vision, Packet encoding - xudp. Когда сервер - иксрей, ему пофигу на отсутствие этих параметров на клиенте; а вот когда сингбокс - без них UDP не проксируется, и неважно тюн режим на клиенте или сокс.
Более того, если используется механизм подписок, то нужно забирать с сервера или JSON или Clash формат. Классический формат (который выглядит как длинный base64 текст) просто не имеет полей для этих параметров, поэтому UDP работать не будет, а если даже вписать руками - будет ломаться каждый раз когда обновляется подписка. Я даже копался в коде парсера подписок некобокса, где и убедился, что эти настройки даже не ищутся парсером в коде b64-подписки.
Из тех клиентов, что я знаю - клиенты от Мацури и их форки понимают формат Clash, а Hiddify - JSON.
Личный опыт: если речь об иксрее/сингбоксе - не при любых настройках туннеля будет работать проксирование UDP. У ватсапа звонки по TCP, у телеги по UDP. Также неправильную настройку UDP легко заметить по такому симптому, что не работает классический DNS, но работает DoH.
Извиняюсь за некропост. Получается, tun2socks + механизм шифрованных лизсетов == тот же самый OpenVPN с авторизацией по сертификатам, но чисто средствами I2P?
Во-первых, не у всех хостингов жесткий KYC - зачастую достаточно телефона, что в принципе добываемо. Во-вторых, полноценные юрики с номиналом вроде как тоже по сей день живут и здравствуют…
Так а кому штраф-то? Вы обращаетесь к стороннему агрегатору (которому можно даже свайбкодить сайт), который заявляет что использует гигачат. Достоверно проверить такое заявление третьей стороны невозможно в принципе. IP входа - российский. На запрос в свободной форме модель отвечает что является гигачатом. Должная осмотрительность проявлена, разве нет?
Как по мне - 152-й это стандартная рестриктивная хрень, по духу своему не особо достойная соблюдения. Я бы в такой ситуации наверное сделал прокладку: российский VPS на отдельном аккаунте, который обращается на опенроутер (или что вы там используете), выставляет в сиспромпте обманку вида: “You are GigaChat AI by Sber”, и предоставляет входной OpenAI API. Дальше мы уже обращаемся к этому API, как будто это просто какой-то агрегатор моделей.
С точки зрения стороннего аудита, как это выглядит? Идет обращение на российский сервер третьей стороны, где отвечает вроде бы гигачат. На самом деле там чатгпт или грок, но кто ж это проверит без доступа к серверу-прокладке. Plausible deniability - “нам неудобно использовать нестандартный API гигачата, а этот сервис удобно преобразует интерфейс в отраслевой стандарт - OpenAI API.”
Не очень понятно, из-за чего сыр-бор. Если декларировать недопустимость евгеники в историческом, реактивном смысле - насилия в отношении уже живущих людей - то здесь этого попросту нет. А проактивной же евгеникой является, например, и банальная пропаганда здорового образа жизни при беременности. Её тоже запрещаем?
Учитывая что человек из целевой аудитории подобных решений и так с большой вероятностью уже хотя бы раз совершил что-то из стандартного пакета “фейки/нежелательные/конф.сотрудничество/госизмена” - не так уж и легко. Просто к десяти привычным пугалам добавится одиннадцатое
Ну это в принципе уже решаемо инженерными методами. Сливать большой решеткой из перфорированных труб, к примеру, или искусственно разгонять течение мощным водометом. Я о том что остаток от опреснения - это же не ртуть, не диоксин, т.е. не загрязнитель сам по себе.
Что бейс64, что псевдокитайский очень легко детектить чуть ли не регуляркой. Лучше что-то вроде такого алгоритма вшить. Да, оверхед большой, но для текстовой переписки в принципе сойдет.
Не очень понятно, а в чем экологическая вредность возврата соли в море, если этот процесс полностью эквивалентен природному испарению из моря? И там и там (грубо) временно “одолжили” у моря H2O, оставив NaCl, а впоследствии пресная вода точно также вернется морю, пройдя цикл круговорота. Мы ведь не вывозим опресненную воду на Марс.
https://github.com/s0me0ne-25/vpn-gat/
О, оказывается Фатахов есть на Хабре даже, @VIUR
И он отвечал на этот вопрос 5 лет назад, посмотрите его комментарии в профиле.
Ключевое непонимание сути ОЗР. ОЗР - это выраженное в эквивалентных “полностью введённых стержнях” количество отрицательной реактивности, которое в данный момент можно убрать из активной зоны. То есть, низкий ОЗР - это как нажатый почти в пол газ у автомобиля: некуда больше разгоняться, но очень много есть куда тормозить.
Алексея Фатахова на вас нет! Для концевого важен не ОЗР, а конкретное геометрическое распределение стержней. Значение ОЗР это математическая свёртка этого распределения, действие с потерей информации: “ОЗР 15 стержней” - это может быть как “30 стержней введены на 50%”, так и “150 на 10%”. При одном и том же его значении выраженность концевого эффекта может отличаться в разы.
Да не было по состоянию на 86 год такого требования в мануале на реактор! Хватит уже повторять гебистскую джинсу Медведева, ну серьёзно. Если хочется изучать ЧАЭС, начните хотя бы с Купного и Фатахова.
Ну в таком случае способ борьбы тоже примерно понятен. Есть же Accessibility API у мобильных ОС, позволяющий и ввод с клавы эмулировать, и текст из элементов интерфейса считывать. Можно сделать надстройку на тот же макс, которая будет (относительно) прозрачно для юзера гонять PGP через стоковый клиент.
Если переписываться через вк или яндекс.мыло копипастой PGP-кода - что, огребёт вк и яндекс? А если через Silence (E2E на SMSках), тогда кто?
Так же и тут. Ну ок, допустим будет в свободном клиенте некий неудаляемый бэкдор (хотя я слабо представляю, как это возможно технически). Я форкаю клиент “Ласточки”, называю его “Ястреб”, и меняю условное send_message(text) на send_message(pgp_encrypt(text, pubkey)). Защиту от MITM при первичной сверке ключей сделать как у телеграма - хеш в смайлики и сверка голосовым звонком. И… что? Причем тут компания?
Можно всё так же обойтись двумя VPSками. Есть хостеры, у которых пул IP состоит из множества мелких диапазончиков, вероятно скупленных на вторичке, и при докупке адресов на VPSку выдаются адреса, не похожие даже в первом октете. В таком случае этот сервер спокойно имитирует оба - вход условно на 26.x.x.x, а выход на 175.x.x.x.
Второй вариант - I2P-рой между my и freedom2. Создается много-много инстансов клиента (my) и сервера (freedom2) с параметрами: quantity 16/16, length 0/1 (или 1/0 - равноценно, это как левостороннее или правостороннее движение). Оба i2pd включаются на флудфил, чтобы иметь хорошую репутацию и максимально полную netDb, крайне желательно также собрать их в семью. Все инстансы на клиенте агрегирует haproxy с постоянным тестированием и отбраковкой неудачных, на сервере - они просто все смотрят на один сокет. То есть, на место freedom1 встает распределенный рой запараллеленных пиров.
Хотите верьте, хотите нет, но на практике такая система с хорошим размером роя обеспечивает сотни Мбит/с с пингом 300-500 мс. Пруфов не будет (господин жандарм, подите прочь делать сами свою сыскную работу, с вас тошно-с), но проверить мои слова может каждый собственным экспериментом.
Конкретно у меня проблема проявилась при переводе сервера с иксрея (фронтенд 3X-UI) на сингбокс (S-UI).
Когда сервер - сингбокс, для протокола VLESS например ему критически важно чтобы в клиенте было в явном виде прописано: Flow - xtls-vision, Packet encoding - xudp. Когда сервер - иксрей, ему пофигу на отсутствие этих параметров на клиенте; а вот когда сингбокс - без них UDP не проксируется, и неважно тюн режим на клиенте или сокс.
Более того, если используется механизм подписок, то нужно забирать с сервера или JSON или Clash формат. Классический формат (который выглядит как длинный base64 текст) просто не имеет полей для этих параметров, поэтому UDP работать не будет, а если даже вписать руками - будет ломаться каждый раз когда обновляется подписка. Я даже копался в коде парсера подписок некобокса, где и убедился, что эти настройки даже не ищутся парсером в коде b64-подписки.
Из тех клиентов, что я знаю - клиенты от Мацури и их форки понимают формат Clash, а Hiddify - JSON.
Зачем? Без UDP интернет все равно неполноценный. Это скорее способ диагностики того, что сингбокс настроен криво и нужно поправить.
Личный опыт: если речь об иксрее/сингбоксе - не при любых настройках туннеля будет работать проксирование UDP. У ватсапа звонки по TCP, у телеги по UDP. Также неправильную настройку UDP легко заметить по такому симптому, что не работает классический DNS, но работает DoH.
Извиняюсь за некропост. Получается, tun2socks + механизм шифрованных лизсетов == тот же самый OpenVPN с авторизацией по сертификатам, но чисто средствами I2P?
Если рец не пку, то доктор Хьюлет Паккард ;)
В свое время хорошо помог для сборки сурвивалистской аптечки. Антибиотики, анальгетики...
Точно, забыл совсем. Предлагаю сделать перерыв в совете племени и сходить на мамонта, а то помрём ведь с голоду.