Как стать автором
Обновить
122
38.9
xenon @xenon

Пользователь

Отправить сообщение

А что именно ругался? Вроде простой ключ - имя выходного файла. (может вы указывали входной через -o ?). Вы просто обошли -o используя редирект - ну так тоже будет работать, но и исходный вариант работать, мне кажется, тоже должен.

блокирует вообще всё непонятное

Разве? Неужели, например, мои VPN соединения или SSH ему понятны? Мне кажется, такого нет, сейчас именно черные списки используются (иногда нарисованные широкими мазками).

могут запретить использование VPN физлицами

Признаю, что я оптимист и может быть верю в то, что мне было бы приятнее верить, но мне очень нравится отрезвляющий довод "если могут сделать завтра, почему не сделали вчера?". Он заставляет взглянуть поглубже в любую ситуацию.

Сейчас, белых списков нет. И медленно варят лягушку - не хотят сорвать резьбу, не хотят резких потрясений. Пока лягушке левую ногу сварили, у нее уже правая охладилась. Proton VPN вновь работает. Носят воду в решете, в общем. То есть, что-то все-таки доносят, прогресс есть, но какой-то незначительный (А сколько времени прошло? А сколько дедушке осталось?). Инстраграмм живой, телеграмм живой, ютуб живой. Эту же госпрограмму можно было бы озаглавить "VPN в каждый дом" - потому как именно этот результат у нее действительно есть.

А вот переход в один момент к белым спискам сделал бы все потрясения единомоментными:

  • "забанили торренты" (но я через впн)

  • "забанили инстаграмм" (но я через впн)

  • "забанили игровой сервер" (но я через впн)

  • "забанили ютуб" (но я через впн)

  • "забанили порно" (но я через впн)

  • "забанили телеграм" (но я через впн)

При переходе к белым спискам, все это случится снова, причем по-настоящему (а не так как раньше - "теперь ютуб через впн") без шанса на впн и все в одну секунду. Это очень высокая цена.

Может люди не выйдут на улицы от этого (а может и выйдут. Рано или поздно соломинка ломает спину верблюду, а тут бревно просто. Зачем лотерея такая?). А сколько ITшников уедет? Их что, слишком много осталось?

У меня сложилось мнение, что тут как с импортозамещением. Оно как бы есть, как процесс, с которого кто-то пилит себе новую квартиру и джип, но каким-то результатом и не пахнет. С блокировками так же. Всерьез блокировать - и технически почти невозможно и стресс будет сильный. Лучше, долгих лет и здоровья дедушке, и все это время за хорошую зарплату делать задачу бесконечной сложности, которая никогда не кончится.

Мне кажется, тенденция в том, что во многих вопросах мир давно перешел порог разумного усложнения и по инерции прошел существенно дальше. И теперь я много где вижу откат к простоте (даже пусть и не бесплатно, с потерей каких-то плюшечек, которые не очень-то и жалко).

К примеру, сделали когда-то в *nix'ах shared библиотеки, не такой уж простой механизм, чтобы один код использовать в разных программах - хорошая идея вроде бы! Экономит место на диске, экономит оперативку. Для него пришлось использовать apt в debian/ubuntu для контроля зависимостей. При этом зависимости конфликтуют, потребовались виртуалки-контейнеры для изоляции. А тут появляется golang с простой идеей, что у них никаких shared библиотек не будет, как в gcc --static, все всегда будет собираться в один файл. Тупо как во времена MS DOS. Да, файл жирный будет, да и фиг с ним. И... оказалось, что всех устраивает! На самом деле исходно и gcc так мог легко, но не пользовались этим, и фактически это оказалось одним из преимуществ golang.

Во многих проектах виден жизненный цикл - появляется фанатский опен-сорсный проект, написанный за месяц на коленке, простой, эффективный, и он взлетает, становится популярным. Какое-то время он оправданно развивается - фиксятся баги, дописываются нужные многим функции. А потом дописывают туда одну фичу, другую, пятую, десятую, появляются корпоративные клиенты которые платят чтоб им сделали нужные им функции вроде масштабирования, резервирования. И удобный велосипед превращается в тяжеленный аэробус. А тебе-то нужно в булочную через два дома ездить. И появляются новые проекты, которые "вот то же как в том, только lite версия, только простые самые важные фукции", снова возврат к велосипеду.

Во всех, да. Меня бы совершенно устроила российская, американская, болгарская, гондурасская почта. А их нет.

Но мне все равно это объяснение кажется каким-то очень смутным, нечетким... Как можно такое сделать во всем мире? При том, что сделать почту без SMS может не только крупная корпорация (их мало, они могут сговориться), а просто любой человек. Я. Вы. Получается, это теория заговора, в которой мы все участвуем?

Как у вас все просто - "жадность". Прямо фундаментальная ошибка аттрибуции во всей красе.

А как вам мысль, что предоставление терабайта нахаляву (тоже охренненная ведь ценность!) - это было тоже проявление, если подумать, жадности? Не от щедрости же то делали.

Добро. Так же, как добро - кафешка, где дорого и невкусно. Все равно, это добро. Все претензии которые предьявляют к ним - так же можно предьявить к любой другой IT компании. Что их отличает - что они очень крупные, а это не просто так - людям нравятся их сервисы (при всех плюсах/минусах). Cloudflare - именно та кафешка, которая вам не нравится, вы туда никогда не пойдете, но вам же самому она нужна, чтобы через дорогу открылась бы другая кафешка, где будет будет вкуснее и дешевле. Потому что без конкуренции - в другой кафешке будет еще хуже и дороже.

Ну или другой вариант - все переходят на VPN и дальше эффективность РКН будет такая же, как если бы он сегодня gopher и FTP протоколы фильтровал.

Думаю, такой коробочкой может быть что-нибудь самопрошивающееся на raspberry pi или другом похожем железе. Например, предоставляющее wireguard тоннель. А завтра wireguard заблокируют, устройство само достучится (любыми обходными способами) до серверов, скачает прошивку с другим типом VPNа и снова будет работать.

Для выжимания прибыли нужен какой-то рычаг через который можно повышать цены, а пользователи не разбегуться.

Вот у яндекс.такси такой рычаг (небольшой) есть, и мы видим - такси, на мой взгляд, стало дороже (даже с учетом инфляции). Но слишком дорогим оно не станет. Всегда есть предел, после которого и люди начнут просто у обочины голосовать и мелкие фирмы начнут заниматься извозом и крупные конкуренты вновь начнут появляться.

У всяких гугл-яндекс дисков есть мощный рычаг (фиг съедешь с него, когда у тебя поклажи сотни мегабайт. Но и то: прижмет - съедешь). С почты тоже не съедешь, когда диск забился - по работе ведь все ее знают.

А какой рычаг получает cloudflare за много лет бесплатного сервиса? (сейчас у меня на нем статический сайт крутится и DNS). Что помешает мне перейти на любой другой сервис?

Как я вижу, единственное, что он реально получает - что я вижу, как он работает, вижу высокую стабильность, надежность, мне это удобно и привычно. Но ничего сверх этого. Ну 5-10 долларов я может быть согласился бы платить в месяц, но больше... просто один раз за полчаса настрою вариант на другом сервисе и все.

Не пробовал, но это же программа на Go - полагаю, что так же, из командной строки, без GUI.

Хех, у нас как раз такая комбинация и используется :-). restic'ом файловые каталоги (огромные, но мало новых файлов) бэкапируется, а age - бэкапы баз данных.

Для баз данных есть какой-то удобный способ инкрементальных бэкапов? (кроме бинлогов даже ничего и не приходит на ум). И вообще, когда проект брали - там была туева хуча баз данных непонятного предназначения и даже вот интересно было - есть ли способ узнать, за последний месяц что-то писалось в базу или нет, я не нашел инструментов для этого.

С рестиком, правда (хоть и немного оффтопик) был однажды странный глюк, из-за которого я начал чуть побаиваться его. Решили мы еще один каталог кидать в restic ежедневно, кидали. А потом просто перестали его использовать, удалили. Но по крону - кидали (несуществующий каталог). И в какой-то момент его репозиторий этого несуществующего каталога внезапно неимоверно раздулся так, что у меня мониторинг заистерил. Возможно, они его не тестили, когда сто раз делается снапшот несуществующего каталога :-)

Вы имеете в виду "симметричного", вероятно?
В случае с age будет связка: ChaCha20-Poly1305 для шифрования и PBKDF2 для наследования ключа из пароля.
В случае с gpg будет (по умолчанию) связка: AES-256 для шифрования и SHA-1 с солью для создания ключа из пароля.

И ChaCha20 более современный и считается более стойким, чем AES-256, и SHA-1 считается устаревшим для криптографических целей. Перебор паролей с SHA-1 будет гораздо быстрее, чем с PBKDF2 (специально замедленный алгоритм).

Но в целом, хоть алгоритмы в age более надежные, gpg "для дома для семьи" тоже вполне подойдет (мы же не рассматриваем вариант, что ЦРУ будет ваши файлы взламывать). Более опасная разница в том, что если начать настраивать алгоритмы ручкам в gpg, то там можно сильно напортачить (age более предсказуем в этом плане, он вот всегда с одной конфигурацией работает).

А так - если удобно - то почему бы и не тащить gpg если он привычнее? Если у вас УЖЕ есть работающая схема шифрования на gpg, она проверена и все хорошо - я бы ради преимущества в алгоритмах менять бы ее не стал (по крайней мере в обозримом будущем).

У нас немного другие риски. Да, не хотелось бы, чтобы архивы утекли. Это было бы плохо, но не катастрофа. А вот катастрофой была бы другая опасность - если нам нужен бэкап, а мы не можем его получить (или скачали, но не можем расшифровать). Например, потому что нужен ключ человека, который уволился, умер, просто потерял/поменял себе ключ. Все-таки бэкапы делаются чтобы иногда ими пользоваться. Поэтому усиливать конфиденциальность имеет смысл только до той поры, пока это не начинает конфликтовать с доступностью бэкапов для нас самих.

А про знание, откуда утек ключ - мне оно кажется очень важным. Ключи ведь не должны утекать. Значит, где-то что-то у нас неправильно. Поменяем мы ключ и новый тем же образом утечет. Надо знать, где проблема, чтобы она не повторилась снова.

Каждым из них можно расшифровать, да. Но за счет того, что их несколько - каждый хранится у отдельного человека в его темном чулане и не пересылается нигде, не оказывается в руках ни у кого. Это понижает шанс утечки.

Просто неприятный опыт с "суперключом" (единым) я наблюдал. Там правда был не ключ от шифрования, а тестовые логин/пароль к одной системе. Ими пользовались N человек, пересылали друг-другу, потом какие-то люди уходили из команды (а пароль оставался тем же), а потом он утек. И утек, как мы предполагаем - из переписки. А вот чью переписку (или мессенджер) взломали - мы так и не смогли узнать. Нет переписки, передачи, копирования ключа - нет сопряженных с этим рисков.

Кстати, это было бы очень интересно почитать. Как оплачивал домены, сервера, как админил их, какие трюки использовал. Может быть - пытались ли его вычислить, и на каком уровне это пытались сделать, а на каком уже не стали искать (очевидно, что при бесконечных ресурсах - вычислили бы).

А можно ли хранить почту (Maildir?) на S3 или каком-то еще внешнем хранилище? Может есть готовые решения?

Мне видится так, что основные расходы на почту - это на дисковое пространство, а вот ПО для почты - оно бесплатное, обслуживание почтового сервиса - простое. Даже маленькая VPSка вполне может вытащить огромное количество пользователей, если каждый дает свои реквизиты для своего собственного S3. Ну или провайдеры, которые S3 предлагают, могли бы бесплатно предоставлять почтовый сервер для этого (все равно платишь за хранение).

А как у них с SPF решается? Если мне пишут, скажем, с яндекса через cloudflare, потом он пересылает на gmail, gmail должен заподозрить неладное, т.к. cloudflare в SPF яндекса не указан.

А это насколько давняя история? Просто сейчас, с массовым добровольно-принудительным принуждением к SPF/DKIM спамерам должно поплохеть, и такие ковровые меры (а заблочим-ка мы все южнокорейские ДЦ) уже должны быть не нужны, уже можно более прицельно знать, что aaa.com - активно спамит, а bbb.com - никогда.

1
23 ...

Информация

В рейтинге
194-й
Откуда
Россия
Дата рождения
Зарегистрирован
Активность