Раз уж мне сегодня у меня есть настроение что-то писать, то напишу о своих мыслях насчет развития интернета.
Последнее время наблюдается тенденция к персонализации поиска в интернете. Т.е. скоро повсеместно будет персональная настройка сайтов и их контента. Простейшим примером могут быть новости- система ведет статистику просмотров и фильтрует интересные вам новости. Т.е. если я читаю новости про новинки технологии, то мне не будут показывать новости про Диму Билана и наоборот. Одним из лидеров в разработке этой концепции является гугл.
Собственно, идея мне очень нравится, кроме одной маленькой вещи: это заставляет пользователя хранить все больше информации о себе в сети. Например про меня еще пару лет назад информации практически не было, сейчас же к сожалению есть. Радует только тот факт, что я как тот "Неуловимый Джо", который никому нафиг не нужен.
Но сам факт мне не нравится, я не хочу чтобы кто-то мог узнать, что я качаю порнографию или учебник юного террориста, слишком попахивает тотальным контролем.
Поэтому я стал обдумывать варианты сохранения преимуществ пресонализации сайтов с отсутствующим побочным эффектом гипотетической возможности контроля.
Суть заключается в комбинации локального и глобального механизмов:
1. Создается универсальное локальное хранилище данных, которое позволяет сохранять различные данные. Примерный список особенностей и функций:
- Хранение данных в зашифрованном виде
- Данные хранятся в древовидном виде. Неважно, будет ли это xml или лисповые списки, сделать конвертацию будет нетрудно.
- Данные каждого сайта хранятся отдельно друг от друга для предотвращения кражи информации. При этом должна быть возможность создавать доверенные группы, которые будут иметь доступ друг к другу, т.к. в том же гугле есть множество сервисов. Я еще не сильно задумывался на эту тему.
- Необходимо некое api для управления хранилищем: простейшие операции добавления/удаления/редактирования и чтения+некий набор операций для группировки, обход дерева и т.д. Это api и будет использоваться для общения сайта с хранилищем.
- Генерация закрытых и открытых ключей для идентификации сессии и шифрования траффика
2. На веб-серверах должна быть поддержка этой технологии в том смысле, что опционально должен быть отказ от логинов, поддержка шифрования траффика и установки связи при запросе клиента. Так же сервер должен знать, как обращаться с хранилищем на стороне клиента. Т.е. вместо собственной базы статистики будет использоваться клиентская через соответсвующий высокоуровневый(?) api.
Таким образом, работа системы будет выглядеть примерно следующим образом:
- Клиент обращается к серверу в первый раз. Сервер дает обычный ответ+информацию о том, что он поддерживает технологию анонимной персонализации. Клиентская часть (вероятнее всего интегрированная с браузером) выдает пользователю сообщение, что данный сайт поддеживает такую возможность.
- В случае подтверждения пользователем, клиентская часть создает хранилище для данного сайта.
- Также клиентская часть генерирует пару ключей, одна из них будет отослана серверу, а вторая будет использоваться для шифрования исходящего траффика
- Клиент отсылает открытый ключ серверу, сервер генерирует свою пару ключей и отсылает открытый клиенту. С этого момента начинается обычная работа системы по зашифрованным каналам, клиентская программа переходит в пассивыный режим. Эти ключи используются как аналог временного логина, через некоторое время они устаревают и процедуру нужно повторить.
- В случае возникновения необходимости у сервера для сохраненияили чтения какой-либо информации, он будет просто возвращать страницу с необходимыми данными или командами в блоке страницы. Простой парсер на клиенте будет выполнять эти команды в api клиента и вернуть данные серверу в запросе. Структуру данных определяет софт на сервере, так что это будет похоже на обычную работу с СУБД.
Это первоначальный набросок, который описывает всю систему, есть еще некоторые белые пятна, над которыми надо думать дальше.