Здравствуйте,
Хочу обсудить с вами концепцию сервиса публикации или передачи данных строго не ранее указанной даты и/или только в определенной геолокации. Из-за обилия общих фраз, этот пост в некотором смысле похож на корованы — это осознанное решение, из-за нежелания делить текст на куски и разбирать каждый подробно на этом этапе. В любом случае, жду любой (кроме очевидной) критики и проэмоционаленных замечаний (страхи, переживания, неожиданные кейсы и т.п.). Это прежде всего — подход, но далее, для простоты, буду называть его сервисом.
Искал инструменты и средства решения, рассматривал отложенную отправку, предварительное шифрование известным ключом, готовые сервисы — но они были или слишком узкоспециалированными, либо чересчур громоздкими, либо не отвечали разумному недоверию человеческому фактору.
Я нащупал подход два года назад, но после обсуждения с друзьями и по причинам политической ангажированности, забросил его — он так и оставался бы в моих черновиках, если бы не события последнего времени и сменившихся взглядах на передачу и интерпретацию знаний между поколениями. Я уверен, что относительно короткая продолжительность жизни — последнее препятствие к действительно впечатляющему прыжку к технологической сингулярности. Поэтому передача знаний, лишенная ненужных эмоциональных переживаний, парадоксальных попыток уберечь через сокрытие и без подмены истинных причин случившегося — необходимый костыль. Или по-другому — еще одна ступень в переходе от пост-индустриального общества к информационному.
Доступ к информации должен быть не вопросом влияния, страха или прихоти. Это должен быть вопрос времени.
В корне архитектуры сервиса, с заложенным недоверием ко всем посредникам — шифрование исходных данных, разбиение на максимально большое количество кусочков (ничего не значащих сами по себе) и последующее их «распыление» по участникам. При достаточно большом количестве участников, разнообразии операционных систем, устройств и юрисдикций — попытки вмешаться будут или бессмысленны или достаточно заметны, чтобы локально принять адекватные меры.
При самых строгих настройках, контроль за отдачей «кусочков» (далее iprates — information particles) архитектурно находится на самих устройствах, проще говоря — «не отдам, ещё рано».
Иллюстрация к подходу:
Перед перечислением сценариев, для ясности отмечу возможные критерии контроля последующей передачи перед уходом данных в сервис — дата, геолокация и список адресатов, в том числе «для всех».
Сценарии использования:
- Дневники, блоги «в стол»
зачем?Интерес для участников в заведомо отсутствующем широковещании и, при первоначальном желании, невозможности редактирования/отзыва. Сколько раз мы переписывали, ограничивались или вообще отправляли в черновики или небытие что-то важное, что хотели сообщить. Судя по количеству рецептов куриной грудки в лентах — есть люди начисто лишенные здравой самокритики. Но я точно такой не один, который непозволительно часто учитывает изменившуюся или чересчур широкую аудиторию, или возможное собственное переосмысление событий самим собой в будущем. Ключевые события, реакции и решения надо фиксировать как есть. Совсем ни на что не оглядываясь, но при этом зная, что это не эксцентричное битье в барабан «смотрите — я живой». Согласитесь, поколение за поколением раз за разом наступает на одни и те же эмоциональные грабли: что-то забывается, а что-то намеренно избегается из-за болезненных выводов или попыток «уберечь». Как бы благозвучно не звучала история — гены, окружение и этапы развития никуда не деваются. Читать захватывающие вымышленные романы или выдающиеся биографии полезно, но читать подлинную историю развития своих родителей без прикрас — в стократ полезней. Следовать или не следовать описанному опыту — дети сами разберутся исходя из нового контекста. Но позволять, не давая выбора, биться лбом в те же стены — по-моему, проявление некоторых пренебрежения и безответственности
- Сообщения конкретным людям, с определенными геокоординатами, в указанный промежуток времени — осмысленное применение в голову не приходит, разве что just for fun для кладов на современный лад
- Цифровое завещание, письма в будущее и т.п. — это в том или ином виде уже представлено в интернете, но представлено бледно. Но распространение официальной цифровой подписи физического лица — вдохнёт во всё это новую жизнь
- Психологическая разрядка — средство максимально анонимного признания или выражения чувств любого оттенка, когда сказать хочется непреодолимо, а нельзя
- Использование свободного пространства на дисках персональных компьютеров в организациях. На рабочих местах пользователей, как правило, очень много неиспользуемого места, но оно простаивает из справедливого недоверия каждому конкретному ПК или их группам. Но части зашифрованных архивов/бэкапов средней и ниже важности вполне можно раскидать без опаски, оставляя на ключевых СХД только отдельные части. Впрочем, этого можно достичь без лишнего шаманства уже сейчас, комбинируя шифрование и средства синхронизации
Очевидные сложности и подходы к их решению:
- Критическая масса пользователей. Способ набора: позиционирование, маркетинг, публичные гарантии / opensource, предусмотренное сарафанное радио «by design»
- Неизменное присутствие компрометирующих агентов, «honeypot-наоборот» и утеря, ротация участников. Способ минимизации влияния:
- математическая модель распределения, допускающая до 50% ненадежных участников
- развитие критериев доверия, в том числе публичная цепочка подписанных рекомендаций
- децентрализованные и анонимные точки ввода: адресная передача iprates через Tor/DHT-p2p
- обезличивание принадлежности iprates — каждый из них знает только соседей (лево/право или, в случае трехмерного представления исходных данных — также вверх-низ)
Пример конечно iprates в определениях Thrift
struct IprateSelfAwareness { 1: optional string leftIprateUuid, 2: optional Checksum leftIprateCS, 3: optional string rightIprateUuid, 4: optional Checksum rightIprateCS, 5: optional i64 position, } struct Iprate { 1: string uuid, 2: EncodedValue encodedValue, 3: optional Date creationDate, 4: optional Date publishDate, 5: optional string lastPingDate, 6: optional i32 publishIfNoPingCntMonths, 7: optional string tomeUuid, 8: optional IprateSelfAwareness selfAwareness, 9: optional auth.User owner, 10: optional IprateExtra extra }
- Атака на ключевые сервера. Имеет смысл только на этапе альфа-тестирования proof-of-concept. Допущение децентрализованной дистрибуции, а также отсутствие препятствий для получения исходных данных «когда можно» кем бы то ни было — нивелирует понятие ключевого сервера, такой сервер может поднять любой
- Устаревание технологий и средств криптографии. Кроме как массой и локальным контролем конечных устройств, способов нивелировать этот риск я не придумал. В том числе и потому, что нельзя не учитывать Самый Главный Риск
Зачем это здесь
Несмотря на то, что есть и мотивация и наработки и опыт в управлении проектами, проект слишком объёмен и чувствителен к способу и времени анонса и публичных обещаний, чтобы ограничиться свободным временем. Кроме того, после непродолжительных размышлений — мне важнее, чтобы он вообще был услышан, понят и востребован. И цель этого поста — прежде всего рассказать об этом подходе и узнать ваше мнение. А если будет интерес и найдутся единомышленники: прикладные математики, разработчики, специалисты по информационной безопасности, то перевести на английский, записать видео и пойти на Бум- или Kickstarter с иллюстрациями и открытым забралом репозиторием — вопрос времени.
Автор: donanykey
