Идея комментироавания в копиях блогов выглядит как-то ненадёжно. 1) Что делать с рассинхронизацией комментариев в разных копиях блогов. 2) Популярные блоги вызовут массовое падение всей системы, если упадёт их родной сервер. Например, в каком-нибудь блоге ЖЖ с 10000 комментариев в сутки появился очередная запись, после чего ЖЖ упал (как обычно). Все эти 10000 комментаторов ведь ломанутся на кэшированные копии во фрэндлентах, и положат их сервера.

http://softwaremaniacs.org/blog/2009/08/27/scipio/

Насколько я знаю, задачку из предпоследнего абзаца так никто и не решил.

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

Если тебя соцсети интересуют, можешь посмотреть готовый код: https://github.com/grange/wordpress-comments-with-openid .

Смеюсь. Максим, Витус неоднократно и категорично заявлял, что php у него на сервере не будет в принципе. К тому же вордпресс — это далеко не лучший образец кода. Мягко говоря. Поэтому ссылаться на плагин к вордпрессу бесполезно чуть менее чем полностью.

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

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

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

После перехода по ссылке, которую гугль выдает в качестве claimed identity по OpenID. выдается RDF-файл, не содержащий ссылки на человеко-читаемые ресурсы.

Кажется, вы недооцениваете (или как-то непонятно для меня оцениваете) роль социальных сетей в идентификации человека.

Я не считаю, что в блогосфере стоит задача идентификации человека. Там стоит задача идентификации автора определенной совокупности текстов. Один там человек, несколько (как за псевдонимами Г.Л. Олди или Козьма Прутков) или один человек поддерживает несколько независимых виртуальных личностей, которые иногда ведут между собой оживленные дискуссии, не важно.

Подозреваю, что в ближайшее время будет создан, если не уже создан, робот, который способен вести осмысленные дискуссии в блогах, и которого будет жалко банить, даже когда выяснится что это не человек.

Как фикс частной проблемы недоступности удостоверяющего сервера можно использовать "отложенную авторизацию" -

Идея интересная, но требует последующей модификации уже созданных записей, расползшихся по десяткам сайтов. И этим мне не нравится.

http://softwaremaniacs.org/blog/2009/08/27/scipio/

Ну написано же в начале первой страницы: хотите запостить ссылку, заключите её в двойные квадратные скобки.

Идея комментироавания в копиях блогов выглядит как-то ненадёжно.

1) Что делать с рассинхронизацией комментариев в разных копиях блогов.

Синхронизировать. Собственно, эта задача решена в прошлом веке, в usenet, ещё до полявления TCP/IP. Вариант, оптимизированный на блогосферу, предлагался мной несколько лет назад.

2) Популярные блоги вызовут массовое падение всей системы, если упадёт их родной сервер. Например, в каком-нибудь блоге ЖЖ с 10000 комментариев в сутки появился очередная запись, после чего ЖЖ упал (как обычно). Все эти 10000 комментаторов ведь ломанутся на кэшированные копии во фрэндлентах, и положат их сервера.

У популярных блогов будет много копий. Во-первых, если этот блог читает 10000 человек, более менее распределенных по 1000 серверов, там будет 1000 копий. И 10000 читателей распределятся по 10 человек на сервер. Особенно если мы сумеем придумать вменяемый алгоритм поиска незагруженной копии. И всем будет хорошо. Во-вторых, 10000 комментариев в сутки это сильно меньше 1000 комментаторов. Как правило, в активно идущих дискуссиях каждый активный участник оставляет более 10 комментов.

И вообще, 10000 комментариев в сутки, это один комментарий в 8 секунд. Такое даже этот сайт выдержит.

В-третьих,

А чем плохо требование хранить приватный ключ на стороне пользователя? Кажется, очень скоро всякие Security Token-ы с ключами внутри будут практически принудительно выдавать. Одним больше, одним меньше - без разницы.

10000 комментариев в сутки, это один комментарий в 8 секунд. Такое даже этот сайт выдержит.

Надо сказать он уже как-то сильно нереактивно реагирует - секунд несколько на запрос содержащий cgi

Витус неоднократно и категорично заявлял, что php у него на сервере не будет в принципе

Полагаю, Витус все же читает на PHP.

Тут вопрос: а зачем нам нужна эта авторизация?

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

Понял я это, когда хотел оставить комментарий к блогозаписи "тысячника". Вроде и информация для комментария актуальна, оригинальна и т.п., но тратить время и постить его желания нет. Автора (вероятно, вообще изначально проплаченного) не переубедишь, а заходящие посмотреть пользователи на 4й странице комментариев от [био]ботов уровня "кг ам/пиши ещё" твой комментарий просто не найдут, т.е. и дискуссии не получится. И понял я, что вот было бы здорово, что бы всякий входящий мог при желании не просто посмотреть чужие комментарии, а отфильтровать их, поставить пресловутые плюсики и минусики в карму и т.п. Что бы можно было вынести дискуссию из чужого журнала и продолжить в своём, но так, что бы приходящие в чужой журнал могли об этой внешней дискуссии узнать.

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

Ведь чем принципиально формат блогов отличается от Фидо/юзнета/емайла? Во-первых, полной независимостью автора от сети: автор сам решает где разместить, не нужно бюрократии прокидывать локалку на бон, как это было в фидо. Во-вторых, в инете есть выделенный ресурс, доступный каждому - где есть все ветви дискуссии за считаемый автором актуальным период, а не только за период рескана у босса/хаба (если у него вообще есть эта эха/конфа и её не нужно специально заказывать, и если вообще есть этот аплинк, а не надо ещё как-то подключаться к сети или проходить премодерацию на постороннем узле). Т.е. блог отличается ещё и независимостью читателя от сети. Больше отличий, кроме вытекающих из первой или второй независимости нет. С независимостью ушли мелочи вроде отсутствия стандартизации на фиды ответов/фолловапов, организованная реакция на XAB и т.д.

А ведь в фидо/юзнете принципиально не было системы авторизации пользователей (иначе нельзя было бы вести дискуссию через несколько BBS/хостов, работать директом и заливать заявку на ноду). То есть оставить информацию мог любой (и это нормально). Тогда как авторизация при заходе на борду/ноду вполне была (т.е. пользователи в дискуссиях были узнаваемыми, если они сами были не против этого).

Соотвественно, почему бы не реализовать аналогичную схему авторизации/идентификации с блогами, только на основе реалий того, что и авторы и читатели выбирают независимость от посторонних структур? Человек входит на блог/страницу, идентифицирует себя любым образом, поддерживаемым движком (openid, логин/пароль, email/клик), общается, комментирует. Если его идентификационного провайдера смыло волной - просто заводит новый аккаунт или пишет анонимом, подписываясь в тексте. Но если он хочет участвовать в репутационной сети (для того, что бы вести осмысленные дискуссии, например), то он ставит нужные расширения к браузеру, пируется с несколькими друзьями (не обязательно с созданием PKI - по возможностям). Далее плагин к конкретному блогодвижку в браузерном расширении обрабатывает собственные записи и комментарии пользователя, формируя коллекции метаданных (и, опционально, выделяет сами данные по примеру юзнет-статей). Эти коллекции, а также список логинов участника (его AKA на разных блогохостингах) в индексированном виде кладутся на доверенные сервера (совместимые блогодвижки) друзей и на собственный блог участника. Расширения к браузерам других участников при заходе на ту или иную блогозапись/страницу, получают метаданные, ассоциированные с ней через какую-нибудь kad-сеть, после чего последовательно устанавливают идентичность и доверие к каждому участнику дискуссии (данные на будущее кэшируются), затем на блоге/странице рисуются элементы интерфейса (плюсики-минусики, карма, путь доверия - в зависимости от пользовательских настроек и от версии расширения к браузеру), а также визуально удаляются отфильтрованные данные.

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

В общем, в моей идее ключевым моментом является то, что в общем случае такая системная задача как учёт репутации/контроль идентичности не должна подрывать ни независимость автора блога от сети (а любая зависимость от разных хитрых стандартов-последователей openid эту независимость колеблет) ни независимость простых читателей от сети (в противном случае проект в мировом масштабе "не взлетит"). В то же время в интернете давно назревает необходимость в ресурс-агностичной и децентрализованной сети обмена репутацией в частности и метаданных в общем с интерфейсами для неё (некоторые из них могут администрировать те же Гугл/ФБ/суп, если наберётся критическая масса, но возможность независимых операторов должна быть, если мы не хотим скатиться в цифровые тёмные или белые века).

Недостатки: нужно реализовать не имеющую текущего прототипа (в принципе, раньше были штуки вроде odigo, которые позволяли "общаться на третьих страничках") систему со сложным в проектировании резолвером доверия (которого на первом этапе можно выкинуть, заменив P2P обычным централизованным веб-сайтом или, ещё проще, блогохостингом с тематикой "клуб общесетевой репутации"), а также убедить заинтересованных в принципе пользователей использовать немного больше чем голый браузер.

Тут вопрос: а зачем нам нужна эта авторизация?

Во-первых, не путайте аутентификацию и авторизацию (по английски обе сокращаются как Auth). Аутентификация это "узнать, кто". Авторизация это "вот этому разрешить или не разрешить вот это".

То есть если мы не рассматриваем подзамочные посты, то авторизация в блогосфере сводится к бану. Вот этих зануд мы не хотим здесь видеть и всё.

Что касается аутентификации, то всё-таки восприятие одной и той же фразы сильно зависит от того, кто это сказал. Конечно, если писать большие комментарии, как вы, сейчас, достаточно и самого комментария как независимого текста. Но это неудобно. Обычно пишут абзац-другой текста. А вот этого абзаца-другого уже недостаточно для того, чтобы его рассматривать отдельно от других текстов того же автора.

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

Поэтому использование обязательных программных механизмов аутентификации это не более чем такая защита от собственной забывчивости авторов комментариев. Опять же в юзнете тоже есть такая защита - там клиент автоматически заполняет поле From.

Полагаю, Витус все же читает на PHP.

Кода на любом языке можно найти сколько угодно. Вопрос не в коде, вопрос в социальном взаимодействии. Использование OAuth API требует регистрации своего приложения (в смысле сервера) на сайте провайдера этого самого API. То есть для того чтобы пускать пользователей фейсбука, мне необходимо зарегистрировать свой сайт на фейсбуке. Я считаю, что это противоречит идее распределенной системы.

В распределенной блогосфере возникает гораздо больше аспектов и проблем с аутентификацией.

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

С централизованной блогосферой эти проблемы не стоят так остро, потому что провайдер информации более-менее аутентифицирован у читателя своим URL'ом, весь интернет более-менее борется с MITM, и крупные хостинги не заинтересованы в подделке авторства постов.

Так что, в распределенной блогосфере без ЭЦП никуда. Причем подписывать надо посты, комментарии и т.п. Подписывать на стороне клиента. Тут HTTPS не поможет. А если будет ЭЦП, то достаточным идентифицирующим признаком может быть открытый ключ, либо ссылка на него. Остальное — опционально.

С авторизацией в распределенной сети тоже не всё гладко. Если черные списки еще туда-сюда можно рассылать по кэшам (хоть и тоже не очень хочется), чтобы они могли отсекать нежелательных личностей, то белые списки рассылать совсем не хочется, как многим не хочется светить списки френдов в соц. сетях. А если подумать еще и о серых списках (тех, кто на премодерации), то картина с чисто распределенной сетью окажется совсем печальной. Т.е. все равно без единого центра, который говорит: «это принимаем, а это в мусорку» — никуда. Если этот единый центр падает, то максимум, что можно сделать — оставить блог в режиме «только чтение». Либо сам владелец теряет контроль над своим детищем.

Во-первых, не путайте аутентификацию и авторизацию (по английски обе сокращаются как Auth). Аутентификация это "узнать, кто". Авторизация это "вот этому разрешить или не разрешить вот это".

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

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

Поэтому использование обязательных программных механизмов аутентификации это не более чем такая защита от собственной забывчивости авторов комментариев. Опять же в юзнете тоже есть такая защита - там клиент автоматически заполняет поле From.

Так вот, с учётом определений выше автозаполнение From:/X-Comment-To: в юзнете/фидо - это только идентификация, причём самого базового уровня, а не аутентификация. К примеру, у меня в Фидо, если я верно помню, было около 15 полных тёзок ("Имя Фамилия") даже без учёта вариантов off/ow - и достаточно регулярно в карбонку падали сообщения к ним - и не было способа вычленить только себя.

При этом такой минимальной идентификации авторов/адресатов сообщений вполне хватало. И, например, если бы я написал текущий коммент от dwшного openid, вы бы нормально проассоциировали меня с автором предыдущего комментария, использовавшего ljшный. Также как все нормально ассоциировали комментарии со сбойной openid`-аутентификацией, когда вы были на DW. Вежливые пользователи просто писали кто они в том же или следующем комментарии. В то же время, если кому-то захочется повандалить, то вандал сможет регистрироваться на разных openid-провайдерах и аутентифицироваться с их помощью быстрее, чем автор блога будет их банить. И никак, кроме как введением капчи или вайт-листов такой вандализм не пресечь. И если для использования вайт-листов аутентификация понадобится, то капча - совсем другой механизм.

То есть если мы не рассматриваем подзамочные посты, то авторизация в блогосфере сводится к бану. Вот этих зануд мы не хотим здесь видеть и всё.

Наверное, всё таки, зануд мы хотим банить не постфактум, когда они будут ломиться ботами с использованием 10 openid-провайдеров. А мы хотим присвоить некий рейтинг пользователям сети, так что заранее неизвестные лично нам пользователи с положительным рейтингом будут приниматься как званые гости без всяких сложных капч и предварительных регистраций, а известные в сети зануды будут вынуждены проходить капчи, писать в автоскринящиеся комментарии, проходить предрегистрацию, а особо злобные - отправляться в /dev/null.

Т.е. нужна всё таки не авторизация в вашем смысле (аутентификация пользователя + права доступа), а всего лишь идентификация (+ права доступа). Способ узнать, считает ли сеть его занудой. Причём, как я постулировал в своём комментарии, так, что бы ни автор блога не получил зависимость от сети ("сеть считает, что раз автор А выгнал пользователя Б из своего личного блога и по её мнению это не справедливо, то автор А становится персоной нон-грата/экскоммуницируется во всей сети"), ни читатели блога такую зависимость не получили ("сеть считает, что раз пользователь П является пользователем нон-грата на личных блогах известных фриков Ф1, Ф2, Ф3, то и в блоге А он комментировать не сможет"). По моему мнению, такое условие можно соблюсти только отвязав систему идентификации в сети в целом от системы авторизации на конкретном частном блоге. Т.е. авторизация пользователей на твоей системе не должна однозначно зависеть от их авторизации на каких-то левых хостах.

Авторизация же на конкретном частном блоге нужна всего лишь, что бы пользователи впоследствии могли совершать определённые действия со своими же данными, к примеру, удалять собственные посты, указывать e-mail для ответов. Если автор доверяет каким-то операторам single sign-on, то он может принимать их логины для авторизации у себя, но требовать это в обязательном порядке для всех сисопов распределённой блогосферы, думаю, нельзя.

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

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

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

А зачем читателям знать, с какого сервера получена информация? Собственно потребность в узнавании какой именно сервер, возникает ровно тогда, когда этот сервер начинает подозреваться в нехорошем поведении, не раньше.

Вообще, практика показывает, что создание системы реагирования на инциденты обходится дешевле, чем попытка создания системы, в которой инциденты невозможны.

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

Наверное, всё таки, зануд мы хотим банить не постфактум, когда они будут ломиться ботами с использованием 10 openid-провайдеров.

Нет, именно постфакутм. Но вместе с провайдерами. Мне как раз больше всего нравится в OpenID та идея, что провайдером аутентификации является тот же сайт, что и является провайдером контента, созданного данным пользователем. Соответственно, если человеку дорог свой контент, то он не будет держать свой сайт на хостинге, где есть много пользователей-спаммеров. Поэтому если с какого-то провайдера OpenID пришло много спаммеров, то можно банить весь провайдер по домену.

Принцип коллективной ответственности - каждый пользователь сети отвечает за действия всех клиентов своего хостера. Если ему не хочется отвечать за действия клиентов этого хостера - пусть ищет другой хостинг.

Способ узнать, считает ли сеть его занудой. Причём, как я постулировал в своём комментарии, так, что бы ни автор блога не получил зависимость от сети

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

Нет, именно постфактум.

...

Принцип коллективной ответственности - каждый пользователь сети отвечает за действия всех клиентов своего хостера. Если ему не хочется отвечать за действия клиентов этого хостера - пусть ищет другой хостинг.

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

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

Если же люди смогут уходить от своего блогохостинга/id провайдера вместе с метаданными и социальными связями (как бы я хотел), то никакого эффекта от "бана по openid" не будет. Спамеры будут несколько раз в день перекидывать свои аккаунты между разными площадками и личными хостами.

Так ведь это и есть "предварительно", просто бремя ответственности переносится с владельца блога на сеть.

У вас какая-то путаница в голове. Сеть у нас одна. Интернет называется. А сайтов в ней много.

Но ведь боязнь за данные - это то, что мы хотим избежать, распределяя блогосферу.

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

Не у всех пользователей есть возможность выделять свою личную машину с человеко-читаемым доменным именем.

Ну ерунда же! У всех пользователей есть такая возможность. Не у всех есть желание этой возможностью воспользоваться.

А если любой сосед может лишить тебя социальных связей (как у вас - переподписалось меньше 10% от подписчиков в ЖЖ),

А выбирайте себе соседей.

Вообще проблема лишения социальных связей возникает только потому, что площадок мало, и их владельцы стремятся всячески ограничить кроссплощадочные социальные связи. Распределенная блогосфера как раз для того и нужна, чтобы связи не зависили от того, на одной или на разных площадках ведутся блоги. Чтобы социальные связи были в пределах интернета в целом.

причём не осознанно, а, например, в результате ошибки (компрометации своего логина, к примеру)

А нам ваша неувязочка пофигу. Если хотите участвовать в социальных связях, забудьте слово "постулат". Не бывает в человеческом обществе на сто процентов надежных решений. А под постулатом обычно понимается именно вещь, которая должна быть гарантирована в 100%. Социальные связи состоят из компромиссов, и всегда приходится взвешивать "за" и "против". Так что нет постулатов, есть эвристики, и в любых правилах должны быть предусмотрены исключения. Вплоть до того, что "все юзеры с livejournal.com по умолчанию считаются спаммерами, а вот эти двадцать конкретных - нет. И если кто-нибудь ещё с livejournal.com хочет получить доступ к моему сайту, пусть его порекомендует один из этих 20".

У вас какая-то путаница в голове. Сеть у нас одна. Интернет называется. А сайтов в ней много.

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

Не у всех есть желание этой возможностью воспользоваться.

Ну, не у всех желание превышает сопутствующие сложности. Например, наверняка многие из тех, кто не переподключился на новые ваши rss`ки - на самом деле интересуются вашими топиками, но сперва было неохота находить галочки, потом закрутились, а потом напоминания в ленте пропали и как-то забылось. Вообще, если вспомните времена перетекания Фидо в интернет: что его спровоцировало? И это при том, что Фидо тогда было бесплатным для большинства, а за интернет приходилось платить немалые по тем временам деньги. Причём количество авторов, перешедших в инет было несопоставимо меньше тех, кто перешёл в него просто "читать".

Чтобы социальные связи были в пределах интернета в целом.

Вот здесь, как мне кажется, я начал понимать вашу точку зрения. Т.е. смысл в том, что бы человек и не надеялся, что его тщательно собираемые соцсвязи навечно останутся в его ведении и что бы учился подключаться к rss-фидам, кэшам и т.д?

Если хотите участвовать в социальных связях, забудьте слово "постулат". Не бывает в человеческом обществе на сто процентов надежных решений. А под постулатом обычно понимается именно вещь, которая должна быть гарантирована в 100%.

Понятно, но маленькое замечание. Этот постулат, или, как хотите, эвристика, мной обосновывается тем соображением, что если "новая система блого-устройства мира", которую вы предлагаете, не даст как авторам, так и читателям гарантий независимости, не намного меньших, которые они получили с переходом из контролируемых (страхом экскоммуникации/неудобств) фидо и юзнета в общедоступный (из-за коммерческости) интернет, то система "не взлетит", потому что найдёт только количество авторов и читателей, сопоставимое с таковыми в современном Фидо. Более того, возможно, что экономически целесообразно при таких количествах пользователей не лепить распределённую систему с общими протоколами но разными клиентами, а просто написать один yet another ultimate блогохостинг со всеми нужными темами интерфейса и фичами, создать НКО для его администрирования и разместить его в нескольких датацентрах с полной репликацией для надёжности и форкать этот софт и площадки, когда фич/качества администрирования будет не хватать.

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

Но получается, что выставляя серьёзные требования к сообществу вы можете сильно осложнить доступность участия в такой блогосфере. И, к примеру, тот же lj может превентивно забанить .pp.ru или вообще !.{ru,рф} - хотя бы просто по приколу, злоупотребляя своим положением (наша гипотетическая система же должна учитывать возможность злоупотреблений). И тогда пользователи будут стоять перед дилемой: пользоваться блогохостингом (или локальным клиентом для распределённых блогов) A (например, самим ЖЖ) и иметь возможность возможность доступа к ЖЖ, но не вашему блогу или пользоваться блогохостингом Б (например, вашим), и иметь доступ к вашему блогу, но не к ЖЖ. И практика показывает, что большинство пользователей выбирает тот вариант, при котором сетевая ценность выше, т.е. где получается больше возможных связей к интересующему контенту. К другому блогохостингу обращаются гораздо реже и только когда сильно нужна какая-то информация.

Тогда как можно отделить авторизацию от рейтингования, как предлагаю я. Вы можете объявить "этих 20" доверенных ЖЖ-пользователей своими поставщиками рейтингов и банить/игнорировать пользователей, которых они занесли в свой твит (и/или, наоборот, пропускать только из их вайт-листов). Если пользователи захотят общаться с вами - им не нужно будет искать блогохостинг, который у вас в фаворе, а просто нужно будет найти способ добавиться в рейтинги. А если вы захотите, что бы не только "эти 20" доверенных пользователей участвовали в составления вашего личного рейтинга, но и люди из их вайт листов (скажем, если суммарное доверие к человеку по личной соцсети набирает 51%, то его добавляем в личный вайтлист с доверием макс_доверие/2), то у вас получается своя собственная социальная сеть (по отношению доверия - дерево) и людям нужно будет добавляться не конкретно к вашим друзьям, а просто запироваться с несколькими своими, и если они адекватны, то большая вероятность, что эти люди автоматически попадут в вашу соцсеть.

При таком подходе вам придётся немного больше времени тратить на модерирование, а кроме того, тратить ресурсы своих компьютеров на построение и обновление социального дерева доверия. Но вы ликвидируете препятствия для тех, кто хочет общаться с вами, пусть даже они выбрали не очень правильный блогохостниг/ПО.

Возможно, имеет смысл реализовать оба механизма, что бы можно было выбирать и настраивать их в зависимости от характеристик текущего потока спамеров/троллей.

Вот здесь, как мне кажется, я начал понимать вашу точку зрения. Т.е. смысл в том, что бы человек и не надеялся, что его тщательно собираемые соцсвязи навечно останутся в его ведении и что бы учился подключаться к rss-фидам, кэшам и т.д?

Смысл в том, чтобы он не надеялся, что добрый дядя Фицпатрик будет вечно беречь его социальные связи, а не продаст скопом весь ЖЖ злому дяде Маммуту.

Проблему автоматического поиска живой копии блога, упрощения агрегации и так далее - можно решить. Она техническая. Тем более, что в общем-то все решения уже есть в смежных областях. Автоматический редирект на ближайший миррор есть, например, на сурсфордже. Да и интерфейс у ЖЖ не то чтобы слишком удобный, поэтому добиться того, чтобы было не хуже - не так уж сложно.

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

Потому что хостер юзера обязательно рано или поздно подведёт. Если это коммерческая компания, то у неё изменится ToS, если некоммерческая организация, она рано или поздно не доберет финансирования, если просто хороший человек - у него случатся обстоятельства непреодолимой силы.

и все кому надо об этом узнали.

Так а разве это не означает перенос своих соцсвязей? Понятно, что паре человек нужно будет сообщить свой новый AKA, но если реализовать механизм локальной соцсети, то можно придумать алгоритм, когда ПО всех остальных само заметит факт изменившегося AKA и предложит поменять ссылку на френда/настройку агрегации.

Понятно, что паре человек нужно будет сообщить свой новый AKA,

Непонятно, зачем сообщать его людям. Есть DNS, есть поисковые роботы.

Очевидно, что если какой-нибудь кэш начнет постить спам от имени кого угодно, этот кэш быстро вычислят и экскоммуницируют.

Это было бы хорошо, если бы не было очень похожей системы в качестве примера: SMTP. Спамеров вычисляют недостаточно быстро, не всех, и создали кучу головняка добропорядочным участникам сети.

Вопрос доверия или недоверия определенному кэшу - это несколько более простой социальный механизм.

Так пользователь ведь не знает, каким сервером кэша он пользуется? И технически определение кэша, которому [не]доверять, может быть таким же простым, как определение места жительства е-почтового спамера. Хотя, конечно, смотря как реализованы протоколы взаимодействия.

Вообще, практика показывает, что создание системы реагирования на инциденты обходится дешевле, чем попытка создания системы, в которой инциденты невозможны.

Практика показывает, что чтобы реагирование на инциденты обходилось дешевле, система должна быть создана с хотя бы минимальной защитой, дабы инциденты происходили с какой-то разумной частотой, а не 100 шт/с. На спам, вот, далеко не все реагируют, хотя и по закону можно. Просто потому, что его настолько дофига, что на каждый инцидент не нареагируешься, вот и создают задним числом поверх SMTP систему, хотя бы частично защищенную от таких инцидентов.

P.S. Уведомления на почту не приходят. Так и задумано?

Непонятно, зачем сообщать его людям. Есть DNS, есть поисковые роботы.

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

А вот по поводу DNS я не понял. Если возникла необходимость в переезде, то велика вероятность, что старый домен и старый хостинг пользователь уже не контролирует (более того, возможно, что их захватили злые люди, которые пытаются выглядеть как "правильный" пользователь).

Возможно, конечно, распространять информацию о пользователях в стиле fidonet.net, но это потребует иерархического управления этим доменом, что противоречит нашему неприятию "сеть сказала".

Можно, конечно, развить мою идею о децентрализованном DNS на доверии, которую я озвучил в моём первом комменте, но это слишком сложно и ново, как и гёделевская логика в целом.

http://www.securitylab.ru/news/435887.php

В браузерах появится поддержка криптографии -> на жаваскрипте можно будет генерить подписи -> каждый коммент и пост можно будет соотнести с автором -> распределённый блоггинг станет немного проще.

должна предусматривать работу просто по индивидуальным парам логин/пароль для каждого пира (френда).

... а также вообще без секретов - по отношению "ссылается" (по принципу, который присутствует в том же openid, например).

Оффтопик: редактирование комментов тоже часто нужно, с соответствующими уведомлениями ("комментарий был отредактирован").

А вот по поводу DNS я не понял. Если возникла необходимость в переезде, то велика вероятность, что старый домен и старый хостинг пользователь уже не контролирует

Так совершенно не обязательно же регистрировать домен через хостера. Более того, если вы хотите хранить там хоть что-нибудь ценное, лучше так не делать, чтобы в случае ухода от хостера сохранить контроль над доменом.

angry_elf, а слабо сссылку делать ссылкой?

В браузерах появится поддержка криптографии -

Вообще-то window.crypto.signData() есть с незапамятных времен. Проблема с электронной подписью заключается в необходимости таскать с собой защищенное хранилище для закрытого ключа. Это уже из интернет-кафе, с чужого компьютера и т.д. не поработаешь.

В принципе, если допустить возможность использования закрытых ключей, уже десятиления как реализованных в браузерах возможностей TLS вполне достаточно для аутентификации пользователей.

Так совершенно не обязательно же регистрировать домен через хостера

В нашей стране довольно велика вероятность потерять одновременно и домен в национальной зоне и хостинг. Ну и DNS пока не настолько защищён от подмены злоумышленниками. Мне кажется, что в 21 веке и после решения ITU о DPI для задачи идентификации с большой достоверностью в общесетевом масштабе не нужно уповать на предположения о том, что домен/сеть всегда под контролем того человека, под контролем которого они были несколько раньше. И, возможно, незаметная подмена личности блогера - это более опасно, чем потеря с блогером привычной связи (когда можно передоговориться, узнать о переезде и т.п.).

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

А почему все считают, что к закрытому ключу надо относиться с бОльшим пиитетом, чем к паре логин/пароль? Ведь ценность и того, и другого определяется лишь ценностью ресурсов, доступ к которым они предоставляют.

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

Да, таскать с собой свои закрытые ключи неудобно, но это просто потому, что привычки нет. Лет пять назад таскать бандуру типа современного смартфона было неудобно — ничего, привыкли. А то, что процедуры сложные — так просто никто не пытался сделать их простыми и понятными каждой кухарке, вот и считается до сих пор, что это сложно и только для фриков. По сути же, процедуру можно сделать весьма простой, не сложнее 2-factor authentication a la Google.

А почему все считают, что к закрытому ключу надо относиться с бОльшим пиитетом, чем к паре логин/пароль?

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

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

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

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

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

на одной и той же флешке ключ для использования в смартфоне и в настольных компьютерах - не потаскаешь.

Сейчас, кстати, модно реализовывать механизмы работы с закрытыми ключами на смартфонах (даже биткойн-клиент есть под андроид). Получается такой софтовый e-token/смарткарта (хотя и подверженный малвари). Единственно, что сложно юзабельно реализовать механизм надёжного бэкапа и аварийной смены ключей. А также необходима инфраструктура (например, P2P сеть) для поиска способа связи со смартфоном консумером.

Что касается закрытых ключей, то существует спецификация WebId в общем-то решающая все проблемы аутентификации в блогах. Вы видели хотя бы один сайт, на котором она используется?

Нет, живого сайта ни разу. По следующей ссылке - список реализаций. Негусто, но основные языки и фреймворки покрыты. http://www.w3.org/2005/Incubator/webid/wiki/Implementations

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

В какой-то мере да, но логин-пароль в интернет-кафе тоже не стоит использовать, если это не одноразовый пароль, присланный на отдельное устройство, например, смартфон. Ой, опять у нас есть отдельный токен, которым мы аутентифицируемся.

Вообще, вспоминаются современные развенчания устоявшихся рекомендаций. Старые рекомендации не записывать пароли привели к тому, что самыми популярными являются "12345" и "11111", а >>50% паролей входят в десятку самых популярных. Нынешние рекомендации звучат: «Заводите много сложных паролей, записывайте на здоровье, только не приклеивайте на монитор, а хотя бы в ящик стола убирайте. Ломать все равно будут через сеть».

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

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

С сильной криптографией поле для махинаций ничуть не меньше. Потому что вопрос не в криптографии, а в структуре сети доверия. В том же WebID, где вполне есть сильная криптография, компрометация shared-хостинга дает возможность подменить открытый ключ в foaf. И приехали.

Кроме того, никогда не надо забывать что при работе с информацией всегда есть минимум две угрозы 1. Что информация будет несанкционированно изменена 2. Что к ней не сможет вовремя получить доступ тот, кто имеет право.

Вот вторую угрозу использование криптографии повышает многократно. А в блогосфере она как раз более существенна.

А в блогосфере она как раз более существенна.

1. Это пока вторая проблема встречается несколько чаще, чем первая.
2. Кому как.

Уж сколько людей теряли доступ к своим аккаунтам в разных соц. сетях и на разных хостингах по разным причинам, и ничего — слегка побухтят и живут дальше с другими аккаунтами/на других хостингах. А вот как только первая проблема возникла достаточно массово (рекламные сообщения от имени пользователей на их стенах в Facebook), то ор поднялся просто сумасшедший. Но Facebook это большая, но всего лишь одна компания. А если подобную возможность дать в руки неограниченному неопределенному кругу лиц, то подобная система помрёт немедленно, от спама.

Так что, позволю себе не согласиться.

В том же WebID, где вполне есть сильная криптография, компрометация shared-хостинга дает возможность подменить открытый ключ в foaf. И приехали.

Да, но эта проблема ничуть не больше, чем проблема увода паролей и аккаунтов в прочих сферах и сетях.

Да, но эта проблема ничуть не больше, чем проблема увода паролей и аккаунтов в прочих сферах и сетях.

Если увели пароли/аккаунты в централизованной системе, то часто технически можно откатить (ответив на секретный вопрос, а в крайнем случае через суд).

В распределённой блогосфере, когда одна из фич это переезд блога на другое место, при стопроцентном доверии аутентификации (в частности на основе ЭЦП) откатить будет практически нереально. Именно поэтому я ратую за включение редактируемого отношения доверия в соцсеть и ПО, которое на этой сети работает. Что бы подписчик видел: "вообще-то судя по ЭЦП/WebID этот блог переехал сюда, но вот есть отдельные люди, которые считают что это фейк".

откатить будет практически нереально.

Естественно, система должна быть рассчитана на подчистку последствий взломов и т.п. Т.е. владелец должен иметь возможность объявить "Это не моё". Тогда после обычного восстановления доступа к хостингу, где лежит профиль с открытым ключом, всё можно более-менее восстановить.

при стопроцентном доверии аутентификации

Вообще, тема доверия в распределенных системах — самая острая и требует отдельного большого обсуждения. Собственно, сложностью концепции доверия в распределенных системах и объясняется слабое их распространение. Люди привыкли к простой схеме «верь своему феодалу» и всё.

Вообще, тема доверия в распределенных системах — самая острая и требует отдельного большого обсуждения.

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

Вообще, "Семантическая паутина", из которой вылезли FOAF, RSS и вышеупомянутый WebID, как мне кажется, "не взлетела" из-за того, что предполагает 100% доверие всем ресурсам, предоставляющим RDF. Т.е. если, к примеру, ты используешь в своей работе для описания своих знаний некую онтологию то ты должен доверять поставщику онтологии в том, что он не изменит/дополнит её несовместимым для тебя способом. Более того, принципиально нельзя стандартным способом выразить факт отрицания неких других фактов. В результате по последним новостям по этой теме выходит, что SW доступен/полезен только узкоспециализированным учёным, которые загружают все используемые ресурсы к себе на комп и используют статически (а в локальных тулзах введено нестандартным образом, в частности, отрицание). А в остальных местах SW медленно вымирает, заменяясь стандартами, которые не отсылают к SW.

Люди привыкли к простой схеме «верь своему феодалу» и всё.

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

В принципе, я прикидывал, что если немного проработать вышеописанные вопросы, то можно это свести к "верь своим френдам" (

Принцип «Верь своим френдам» вообще-то уже двадцать лет назад был реализовал Филом Циммерманом в ключевой инфраструктуре PGP. И до сих пор активно применяется.

Наросли разнообразные ритуалы, вроде keysigning party.

В том же WebID, где вполне есть сильная криптография, компрометация shared-хостинга дает возможность подменить открытый ключ в foaf. И приехали.

Да, но эта проблема ничуть не больше, чем проблема увода паролей и аккаунтов в прочих сферах и сетях.

Но и ничуть не меньше. О чем я и талдычу весь тред. В данном случае использование криптографии ничуть не уменьшает проблем. Но создает типичный для критпографии usability hamper. То есть цену за использование криптографии платить приходится, но благ за эту цену получаешь ровно ноль, потому что проблемы с безопасностью лежат в другом месте.

Принцип «Верь своим френдам» вообще-то уже двадцать лет назад был реализовал Филом Циммерманом в ключевой инфраструктуре PGP. И до сих пор активно применяется.

Наросли разнообразные ритуалы, вроде keysigning party.

Что-то подобное я и имел в виду. Единственно, когда я последний раз пользовался виндовым GUI PGP около 10 лет назад, там не было удобного интерфейса для просмотра цепочки доверия (вообще, очень смутно помнится). А интерфейсы к GPG, которые я пробовал, ориентированы на доверие конкретным ключам, с которыми работаешь (если есть какие-то удобные, посоветуйте плз - хочется посмотреть, как там сделано).

Ну и я не знаю, как там с распространением изменений. Википедия упоминает то, что в PGP (а как в OpenPGP/GPG?) уже ввели сроки ключей для планового отзыва и возможность выделения доверенного отзывателя (кстати, поддерживается ли это в GPG?). А вот ввели ли в инфраструктуру ключевых серверов механизм отзыва и недоверия других ключей (что бы сказать: а вот этот ключ, хоть и подписан 100 другими ключами других людей, уже 5 лет как погребён на не функционирующем винчестере - ищите вместо него вот тот ключ, хоть он и подписан пока только двумя)?

Понятное дело, что это криптографически ненадёжно, но в качестве пищи для размышления людьми, мне кажется, очень важно.

В данном случае использование криптографии ничуть не уменьшает проблем.

Я полагаю такое сравнение некорректным. Да, использование сильной криптографии в распределенной среде не уменьшает проблем по сравнению с нынешней централизованной. Но распределенная среда без сильной криптографии — вообще швах.

что бы сказать: а вот этот ключ, хоть и подписан 100 другими ключами других людей, уже 5 лет как погребён на не функционирующем винчестере - ищите вместо него вот тот ключ, хоть он и подписан пока только двумя

Если я правильно понимаю, то изготовление заранее пары revocation certificate + еще один запасной ключ, подписанный первым с уровнем доверия ultimate, более-менее решают эту проблему. Надо только научить пользователей хранить сертификат отзыва и запасной ключ отдельно.

подписанный первым с уровнем доверия ultimate

Ах, черт. В PGP нет уровней доверия при подписывании ключей. А жаль…

Ах, черт. В PGP нет уровней доверия при подписывании ключей. А жаль…

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

Я так понимаю, по оригинальной задумке Циммермана (и тому, что везде написано про web of trust), предполагалось что отправитель будет не просто искать путь к ключу получателя и обратно, а анализировать топологию всех таких путей. Разумеется, с точки зрения юзабилити это утопия. Но, думаю, можно упростить так, что бы необходимый уровень телодвижений пользователя для администрирования своей мировой картины доверия к информации зависел от сложности его задач (а совсем неприхотливые пользователи как и сейчас полностью доверяли бы своим феодалам или набору пиров-феодалов, возможно, с установленными каждому приоритетам).

... "подписанный PGP-ключ", по сути, всего лишь выражает истинность утверждения "владелец этого подписанного ключа в прошлом представлялся имяреком владельцу подписавшего" ...

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

"подписанный PGP-ключ", по сути, всего лишь выражает ... никак не доверие.

В этом и проблема. На самом деле, нужно расширить список подписываемых утверждений. В частности, утверждение "это тоже я".

А с доверием вообще сложно. Например, я могу вполне надежно удостоверить, что некоторый ключ принадлежит моему другу. В то же время, я не могу с такой же уверенностью доверять подобным утверждениям моего друга, хотя и подтвержденным средствами сильной криптографии. Просто потому, что знаю, что этот мой друг — полный профан в IT вообще и в отношении элементарной гигиены безопасности в частности. Именно это я и подразумевал, когда говорил ранее, что тема доверия сложна и требует отдельного большого обсуждения.

нужно расширить список подписываемых утверждений

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

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

Вообще распределенную аутентификацию надо было сразу прорабатывать еще на уровне http протокола в 90е годы. На мой взгляд самым лучшим был бы вариант использования DNS для хранения ключей, причем как открытого, так и закрытого, в TXT записях. Как-то так:

IN TXT "SEC=..........:OPEN=............"

Секретный ключ накрыт паролем пользователя. Для аутентификации сервер дергает открытый ключ и шифрует им большое случайное число, отдает клиенту. Клиента браузер просит его ввести домен и пароль, причем окно отличается от любых javascriptовских так, чтобы это нельзя было подделать, дергает секретный ключ, дешифрует его введенным паролем пользователя, расшифровывает соль, отдает серверу. Все, установлено точно, что человек с паролем, которым зашифрована запись SEC, соответствует этому домену. Домен = идентификатор, а там что угодно можно накручивать, при желании можно из другой TXT foaf дернуть. Минимум работы для браузера, минимум для сервера.

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

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