Size: a a a

2020 November 20

S

Stas in ctodailychat
Egor Suvorov
Почему? Администратору сервера в целом пофиг, публиковать или не публиковать ротированные ключи. Аккуратно надо, конечно — чтобы они нигде не использовались для шифрования, например. Только для подписи.
понятно зачем это надо заинтересованным, непонятно зачем это администратору почтового сервера
источник

S

Stas in ctodailychat
если только не будет закона в данной сфере
источник

ES

Egor Suvorov in ctodailychat
Stas
понятно зачем это надо заинтересованным, непонятно зачем это администратору почтового сервера
Ну, например, если будет консенсус «прилично ротировать DKIM-ключи», то это будет best practice.

Например, солить пароли тоже не требуется, но если так не сделать, посмотрят косо. Или https вместо http.
источник

S

Stas in ctodailychat
Egor Suvorov
Ну, например, если будет консенсус «прилично ротировать DKIM-ключи», то это будет best practice.

Например, солить пароли тоже не требуется, но если так не сделать, посмотрят косо. Или https вместо http.
чтобы не было потом возможности подтвердить подлинность отправленного сообщения?
источник

ES

Egor Suvorov in ctodailychat
Stas
чтобы не было потом возможности подтвердить подлинность отправленного сообщения?
Да
источник

AS

Alexey Shcherbak in ctodailychat
Egor Suvorov
Ну, например, если будет консенсус «прилично ротировать DKIM-ключи», то это будет best practice.

Например, солить пароли тоже не требуется, но если так не сделать, посмотрят косо. Или https вместо http.
Как ловко в один ряд ставятся правильные практики которые отбеливают сомнительное решение. В оригинале статьи автора бомбило что вот все пользуются сайдэффектом протокола и вот так нельзя, но кроме как "давайте сломаем сайдэффект" он ничего предложить и не смог. Non-repudiation - отличная фича DKIM, пусть даже неожиданная. Ключи можно ротировать и уже ротируют, в том числе и гугл, при этом есть группы энтузиастов кто сохраняет публичные ключи, как раз чтобы всякие утечки валидировать.
В реальности статья топит за "а дайте нам приватные старые ключи чтобы мы от своих собственных слов могли отказываться". Второй эффект публикации ключей в том, что можно нагенерить тучи фейков, подписать их и завалить разными fake news поле общественного дискурса. Пока будут разбираться - можно делать всякую херню.

Имхо призывать к отмене такого важного элемента почтовой инфраструктуры, пусть даже случайно полученного, когда вокруг полно дипфейков и фейк ньюз - очень нечистоплотные намерения
источник

VF

Vadim Fedosov in ctodailychat
Тут чуваки провели исследование источников по взрыву в Бейруте и сделали видос
https://vimeo.com/479844049
источник

VF

Vadim Fedosov in ctodailychat
Там модельки и точное определение где и как бахнуло (в какой точно точке)
источник

С

Слава in ctodailychat
Можно транскрипт? Они там выяснили нечто новое?
источник

С

Слава in ctodailychat
Потому что вроде "где и почему" уже давно известно
источник

VF

Vadim Fedosov in ctodailychat
Слава
Можно транскрипт? Они там выяснили нечто новое?
Нет, кажется. Просто интересная визуализация и хорошая работа с сорсами. Плюс они все данные выложили на гитхаб
источник

VF

Vadim Fedosov in ctodailychat
Слава
Потому что вроде "где и почему" уже давно известно
Хорошо. Где и как :)
источник

D

Denys in ctodailychat
Это прямо очень круто. Технология как в кино!
источник

ES

Egor Suvorov in ctodailychat
Alexey Shcherbak
Как ловко в один ряд ставятся правильные практики которые отбеливают сомнительное решение. В оригинале статьи автора бомбило что вот все пользуются сайдэффектом протокола и вот так нельзя, но кроме как "давайте сломаем сайдэффект" он ничего предложить и не смог. Non-repudiation - отличная фича DKIM, пусть даже неожиданная. Ключи можно ротировать и уже ротируют, в том числе и гугл, при этом есть группы энтузиастов кто сохраняет публичные ключи, как раз чтобы всякие утечки валидировать.
В реальности статья топит за "а дайте нам приватные старые ключи чтобы мы от своих собственных слов могли отказываться". Второй эффект публикации ключей в том, что можно нагенерить тучи фейков, подписать их и завалить разными fake news поле общественного дискурса. Пока будут разбираться - можно делать всякую херню.

Имхо призывать к отмене такого важного элемента почтовой инфраструктуры, пусть даже случайно полученного, когда вокруг полно дипфейков и фейк ньюз - очень нечистоплотные намерения
А в чём принципиальная разница между "правильными практиками" и "сомнительным решением"? На мой взгляд, разница исключительно политическая: первое вами считается "хорошим", второе не считается.
источник

ES

Egor Suvorov in ctodailychat
Например, почему вообще защищать данные пользователей от утечек — "правильная практика"?
источник

ES

Egor Suvorov in ctodailychat
Если хотим давать пользователем полный контроль за их данными — то пользователи также должны быть вольны их не шифровать и от них отказываться.
источник

ES

Egor Suvorov in ctodailychat
Замените, скажем, "скомпрометированную переписку начинающих террористов" на "скомпрометированную злыми захватчиками переписку мирных жителей, которые пытались праведно восстать".

Технология в любую сторону применяется.
источник

AM

Ant M in ctodailychat
источник

СА

Сергей Аксёнов... in ctodailychat
Слава
Можно транскрипт? Они там выяснили нечто новое?
Уверенно заявили, что причиной взрыва стало нарушение правил складирования взрывоопасных веществ (удобрения) и пожароопасных предметов (фейерверки и покрышки). Также я услышал точную цифру жертв - 204 погибших и 6500 раненых, но это есть в Википедии.
источник

AS

Alexey Shcherbak in ctodailychat
Egor Suvorov
А в чём принципиальная разница между "правильными практиками" и "сомнительным решением"? На мой взгляд, разница исключительно политическая: первое вами считается "хорошим", второе не считается.
Тут можно очень глубоко закопаться в том что считается правильным для одних не является правильным для других. Я просто отметил что ловко использовали массово одобряемые практики вокруг приватности для того чтобы "осветлить" другую идею
источник