Криптоблоги
Dec. 4th, 2007 11:33 am![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
vitus_wagnerТут в связи с приобретением ЖЖ СУПом пошла новая волна обсуждений того, как бы заменить ЖЖ на что-нибудь неподконтольное ни одной коммерческой структуре. Волна эта далеко не первая (см мой журнал по тэгу distributed-blog). Предыдущие как-то к созданию чего-либо реального не привели. Ну кроме lj.rossia.org, который представляет себе всего лишь площадку, подконтрольную ДРУГОЙ структуре.
Тут я еще немножко подумал и предлагаю структуру сети, которая обеспечивает примерно функциональность ЖЖ в смысле френдования, прав доступа подзамочных постов, скрытия комментариев etc, но при этом является распределенной. Причем, чем более популярен журнал, тем больше его копий существует в сети.
Сеть взаимосвязанных блогов состоит из узлов двух типов - узлов публикации и узлов чтения. Узел публикации - это обычный web-сервер, более-менее постоянно доступный в сети. который раздает блог и френдленту некоторого пользователя (пользователей). При этом копирует к себе все посты и комментарии к постам друзей этого пользователя. Соответственно, читать некоторый журнал можно через сервер любого из его френдов. Там же можно комментировать, и можно даже постить. Посты и комментарии будут реплицироваться по всем серверам, несущим данный блог. Поскольку копия foaf-файла у данного сервера есть, он всех их знает.
Узел чтения - это программа, работающая на локальном компьютере пользователя. Она либо встроена в браузер, либо работает прокси между браузером и интернетом. Выкачивая странцу блога, поста или френдленты она выполняет необходимые криптографические операции - проверяет подписи под постами и комментами, расшифровывает подзамочные посты и скрытые комментарии (если у данного пользователя есть на них право).
При постинге она подписывает текст поста или комментария, или, если необходимо, его шифрует.
На узлах публикации все открытые посты и комментарии хранится в виде xhtml-файлов, отдельные фрагменты которых подписаны в соответствии со спецификацией xml-dsig. То есть для того чтобы прочитать их, ничего кроме браузера не надо. Если совсем не предпринимать никаких усилий, то каждый пост/комментарий будет сопровождаться строчкой base64-символов, представляющих электронную подпись. Если чуточку не полениться, её можно скрыть средствами CSS.
Посты, предназначенные для узкого круга ограниченных людей хранятся в виде PGP ASCII-armored данных, т.е. тоже base64, зашифрованных для всех получателей (ведь у каждого участника системы, имеющего узел чтения, есть ключевая пара, открытую часть которой могут получить остальные участники). Когда это читается через узел чтения, оно автоматически (Прозрачно для пользователя, за исключением запроса passphrase один раз за сеанс) расшифровывается и показывается как было.
Пользователи системы делятся на три категории - свои, чужие и анонимы. Свои - это те, у кого есть узел чтения и ключевая пара.
Чужие - это те, кто постит комментарии, авторизуясь по OpenID с OpenID-провайдеров, не входящих в систему.
Их пост отправляется браузером на узел публикации (ведь узла чтения у них нет) и подписывается ключом этого узла. Эта подпись удостоверяет, что такой-то узел такого-то числа во столько-то аутентифицировал автора данного комментария по OpenID как такого-то. Ну, и также то, что никто другой с тех пор текста этого комментария не менял.
Аналогичным образом подписываются анонимные комментарии.
Если согласно настройкам блога или конкретной записи чужой или анонимный комментарий должен быть скрыт, он шифруется узлом публикации только для хозяина блога. То же самое делается если узел чтения, который так же, как и узел публикации видел эти настройки, не зашифровал комментарий сам.
С точки зрения узла публикации, все пользователи системы (т.е. свои) равны, но некоторые равнее других. Равнее других, естественно, те, которые платят за хостинг данного узла публикации. Они имеют единственное преимущество перед всеми остальными - если они кого-то добавляют себе во френды, узел публикации, узнав об этом (получив то-ли с узла чтения то-ли с другого узла публикации обновления foaf-файла этого пользователя, естественно, им подписанное) тут же начинает кэшировать блог нового френда.
В норме, конечно, каждый юзер читает свою френдленту через свой узел публикации. Но если вдруг что случилось (злые электрики вырубили свет в серверной, бульдозерист переехал кабель или кровавая гэбня конфисковала сервер) юзер может попытаться прочитать свою френдленту через любой другой узел публикации. Благо локальная копия foaf-файла у него в узле чтения есть, и тот может автоматически попытаться выяснить, какой из имеющихся в онлайне узлов публикации содержит копии наибольшего количества блогов его френдов. Узел чтения может даже попытаться автоматически собрать полную френдленту из данных с нескольких узлов публикации.
Узлы публикации синхронизируются между собой по протоколу, представляющему собой нечто среднее между RSS и NNTP - публикуется feed новых поступлений (как постов, так и комментариев, в том числе отредактированных постов, раскрытых владельцем блога комментариев etc). Увидев в feed-е идентификатор объекта, который у него отсутствует или устарел, другой узел публикации идет и забирает этот объект. По обычному HTTP.
Идентификаторы постов должны включать в себя
1. Идентификатор блога (url или e-mail-образныай адрес владельца)
2. Идентификатор (hostname) узла, где пост впервые попал в систему (узел чтения может ставить свой собственный идентификатор)
3. Некий уникальный номер внутри данного узла для данного автора.
Идентификтаор комментария должен включать в себя
1. Идентификатор поста.
2. Идентификатор узла,
3. Уникальный номер
Кроме того, в комментарии должен так или иначе присутствовтаь идентификатор комментария, ответом на который он является.
В фиде указываются идентификаторы объектов и даты выработки подписи под ними. Что автоматически позволяет определить устаревания объектов.
В качестве PKI используется pgp-шная PKI, так как она
1. Распределенная, не требует выделенных удостоверяющих центров
2. Работает давно и хорошо
3. Документирована на понятном для простых пользователю языке. Точно помню, что в комплекте pgp 2.6.3 была дока для чайников. На сайте gnupg я её сейчас не нашел, ну в крайнем случае из старых архивов выкопаем.
P.S. Следует помнить, что электронные подписи обладают свойством non-repudiation. Поэтому храните свой секретный ключ от узла чтения так, чтобы он не попал в руки кровавой гэбне. А то он послужит доказательством что именно вы написали то, что им подписано. От всего остального можно отрекаться. Даже наличие некоторого блога на вашем сервере не означает что автор его вы - мало ли, вы просто его почитать решили, а сервер взял и выкачал весь.
Тут я еще немножко подумал и предлагаю структуру сети, которая обеспечивает примерно функциональность ЖЖ в смысле френдования, прав доступа подзамочных постов, скрытия комментариев etc, но при этом является распределенной. Причем, чем более популярен журнал, тем больше его копий существует в сети.
Сеть взаимосвязанных блогов состоит из узлов двух типов - узлов публикации и узлов чтения. Узел публикации - это обычный web-сервер, более-менее постоянно доступный в сети. который раздает блог и френдленту некоторого пользователя (пользователей). При этом копирует к себе все посты и комментарии к постам друзей этого пользователя. Соответственно, читать некоторый журнал можно через сервер любого из его френдов. Там же можно комментировать, и можно даже постить. Посты и комментарии будут реплицироваться по всем серверам, несущим данный блог. Поскольку копия foaf-файла у данного сервера есть, он всех их знает.
Узел чтения - это программа, работающая на локальном компьютере пользователя. Она либо встроена в браузер, либо работает прокси между браузером и интернетом. Выкачивая странцу блога, поста или френдленты она выполняет необходимые криптографические операции - проверяет подписи под постами и комментами, расшифровывает подзамочные посты и скрытые комментарии (если у данного пользователя есть на них право).
При постинге она подписывает текст поста или комментария, или, если необходимо, его шифрует.
На узлах публикации все открытые посты и комментарии хранится в виде xhtml-файлов, отдельные фрагменты которых подписаны в соответствии со спецификацией xml-dsig. То есть для того чтобы прочитать их, ничего кроме браузера не надо. Если совсем не предпринимать никаких усилий, то каждый пост/комментарий будет сопровождаться строчкой base64-символов, представляющих электронную подпись. Если чуточку не полениться, её можно скрыть средствами CSS.
Посты, предназначенные для узкого круга ограниченных людей хранятся в виде PGP ASCII-armored данных, т.е. тоже base64, зашифрованных для всех получателей (ведь у каждого участника системы, имеющего узел чтения, есть ключевая пара, открытую часть которой могут получить остальные участники). Когда это читается через узел чтения, оно автоматически (Прозрачно для пользователя, за исключением запроса passphrase один раз за сеанс) расшифровывается и показывается как было.
Пользователи системы делятся на три категории - свои, чужие и анонимы. Свои - это те, у кого есть узел чтения и ключевая пара.
Чужие - это те, кто постит комментарии, авторизуясь по OpenID с OpenID-провайдеров, не входящих в систему.
Их пост отправляется браузером на узел публикации (ведь узла чтения у них нет) и подписывается ключом этого узла. Эта подпись удостоверяет, что такой-то узел такого-то числа во столько-то аутентифицировал автора данного комментария по OpenID как такого-то. Ну, и также то, что никто другой с тех пор текста этого комментария не менял.
Аналогичным образом подписываются анонимные комментарии.
Если согласно настройкам блога или конкретной записи чужой или анонимный комментарий должен быть скрыт, он шифруется узлом публикации только для хозяина блога. То же самое делается если узел чтения, который так же, как и узел публикации видел эти настройки, не зашифровал комментарий сам.
С точки зрения узла публикации, все пользователи системы (т.е. свои) равны, но некоторые равнее других. Равнее других, естественно, те, которые платят за хостинг данного узла публикации. Они имеют единственное преимущество перед всеми остальными - если они кого-то добавляют себе во френды, узел публикации, узнав об этом (получив то-ли с узла чтения то-ли с другого узла публикации обновления foaf-файла этого пользователя, естественно, им подписанное) тут же начинает кэшировать блог нового френда.
В норме, конечно, каждый юзер читает свою френдленту через свой узел публикации. Но если вдруг что случилось (злые электрики вырубили свет в серверной, бульдозерист переехал кабель или кровавая гэбня конфисковала сервер) юзер может попытаться прочитать свою френдленту через любой другой узел публикации. Благо локальная копия foaf-файла у него в узле чтения есть, и тот может автоматически попытаться выяснить, какой из имеющихся в онлайне узлов публикации содержит копии наибольшего количества блогов его френдов. Узел чтения может даже попытаться автоматически собрать полную френдленту из данных с нескольких узлов публикации.
Узлы публикации синхронизируются между собой по протоколу, представляющему собой нечто среднее между RSS и NNTP - публикуется feed новых поступлений (как постов, так и комментариев, в том числе отредактированных постов, раскрытых владельцем блога комментариев etc). Увидев в feed-е идентификатор объекта, который у него отсутствует или устарел, другой узел публикации идет и забирает этот объект. По обычному HTTP.
Идентификаторы постов должны включать в себя
1. Идентификатор блога (url или e-mail-образныай адрес владельца)
2. Идентификатор (hostname) узла, где пост впервые попал в систему (узел чтения может ставить свой собственный идентификатор)
3. Некий уникальный номер внутри данного узла для данного автора.
Идентификтаор комментария должен включать в себя
1. Идентификатор поста.
2. Идентификатор узла,
3. Уникальный номер
Кроме того, в комментарии должен так или иначе присутствовтаь идентификатор комментария, ответом на который он является.
В фиде указываются идентификаторы объектов и даты выработки подписи под ними. Что автоматически позволяет определить устаревания объектов.
В качестве PKI используется pgp-шная PKI, так как она
1. Распределенная, не требует выделенных удостоверяющих центров
2. Работает давно и хорошо
3. Документирована на понятном для простых пользователю языке. Точно помню, что в комплекте pgp 2.6.3 была дока для чайников. На сайте gnupg я её сейчас не нашел, ну в крайнем случае из старых архивов выкопаем.
P.S. Следует помнить, что электронные подписи обладают свойством non-repudiation. Поэтому храните свой секретный ключ от узла чтения так, чтобы он не попал в руки кровавой гэбне. А то он послужит доказательством что именно вы написали то, что им подписано. От всего остального можно отрекаться. Даже наличие некоторого блога на вашем сервере не означает что автор его вы - мало ли, вы просто его почитать решили, а сервер взял и выкачал весь.
no subject
Date: 2007-12-04 09:49 am (UTC)no subject
Date: 2007-12-04 10:59 am (UTC)no subject
Date: 2007-12-04 11:28 am (UTC)no subject
Date: 2007-12-04 12:06 pm (UTC)Механизм extensions в openid эту проблему частично решает, ибо, в процессе аутентификации сервер сможет вернуть e-mail, только вот мне совсем не понятно а что будет если этот e-mail сменится, получается что сайты про смену узнают только при повторной аутентификации, т.е. получаем то же что и на lj.rossia.ru где e-mail можно ввести руками, только в данном случае ручной ввод производится автоматический.
no subject
Date: 2007-12-04 12:12 pm (UTC)no subject
Date: 2007-12-04 12:26 pm (UTC)Впрочем, осталось всего ничего - заставить openid сайты что-то подобное использовать.
no subject
Date: 2007-12-04 12:33 pm (UTC)no subject
Date: 2007-12-04 12:40 pm (UTC)no subject
Date: 2007-12-04 12:45 pm (UTC)no subject
Date: 2007-12-04 12:52 pm (UTC)no subject
Date: 2007-12-04 12:57 pm (UTC)no subject
Date: 2007-12-04 12:20 pm (UTC)no subject
Date: 2007-12-04 12:26 pm (UTC)