Пользователи и интернет-проекты

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

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

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

Этот подход, правильный для большинства e-commerce сайтов конца 90-х (каждой фирме важно нарабатывать знания по своей клиентуре и хранить их у себя), в настоящее время выглядит как чем-то само собой разумеющимся, включен по умолчанию во все вэб-системы и вполне очевиден всем пользователям сети. Более того, современные браузеры, как правило, имеют встроенный механизм для упрощения работы с подобными вещами в виде автозаполнения форм регистрации или запоминания паролей (служба безопасности должна уже начинать паниковать на этот счет). Но если присмотреться повнимательней, этот архаичный принцип кажется уже не таким оптимальным как для разработчика, так и для пользователя. Продолжающееся употребление подобного приема — суть явление инертности большинства, как если бы мы спрашивали на перекрестке в центре города «Что нужно взять, чтобы вырыть яму?» — большинство не задумываясь бы ответили «Лопата!», особо дотошные зануды (которых никто не слушает) стали бы выяснять «какую яму?» после чего безаппеляционно бы заявили про экскаватор, а настоящие инженеры сказали бы «бумажку и карандаш». Но настоящих инженеров мало, а автору сих строк просто не о чем больше думать во время принятия утреннего душа, кроме как о всякой ерунде.

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

• регистрация — это лишнее усложнение для пользователя, которому приходится каждый раз запоминать данные, которые вводятся в форму. Даже в нашем простом случае, когда в качестве авторизационных данных используется пара «почтовый адрес — пароль» это уже непросто, с учетом того, что у посетителя большинство сайтов лежит в пределах одного клика по ссылке, а сайтов, который активный серфер посещает в день, может набираться сотня, а то и две. Браузерные функции по сохранению паролей помогают, но ровно до того момента, когда пользователь сидит за свои традиционным рабочим местом и очередное обновление ПО не грохает базу паролей целиком. В противном случае — приходится судорожно вспоминать регистрационные данные, восстанавливать пароли. Хуже того, если у вас несколько почтовых ящиков и вы просто не помните, на который из них регистрировались — вам грозит долгий и мучительный перебор с вводом цифр, изображенных на картинках, в качеств доказательства, что вы не злобный хакер и не ищете уязвимость в системе. Современный пользователь, избалованный маркетингом и призывами «сделайте посетителям удобно», вряд ли будет этим обрадован.
• безопасность данных и персональной информации. Доверять свой адрес электронной почты сайту, который видите в первый раз и насчет которого есть серьезные сомнения — это, конечно, паранойя, но вот поручится за то, что завтра администратор сайта не уволится, прихватив с собой базу пользователей, которую потом благополучна может быть продана спамерам, не может никто. Другое дело — пароли. Пользователи редко используют более двух-трех паролей в общем случае. Да что там говорить, у меня самого их не больше пяти. Т.е. вероятность, что сообщенный ресурсу пароль будет совпадать с паролем от почтового ящика, равна примерно 40%, а на практике — еще больше. Т.е. вы уже можете себе представить, что будет, если база с пользователями утечет на сторону? Сколько людей могут потерять свои аккаунты на бесценных однокласниках, вконтакте и ICQ, не говоря о деловой переписке, которую многие вели в ожидании починки основного конторского почтового сервера, которой занимается приходящий паренек-студент? Страшно? Мне тоже. «Чушь!» — скажете вы. — «На правильных ресурсах пароль шифруется на стороне клиента, а на сервер попадает только хэш от него.» И будете правы, я уже почти перестал трястись за свой твиттер. Но у нас есть еще такое явление как фишинг (я усиленно промолчу про атаки «человек посредине» — все же они еще далеко не самые тривиальные). И сколько наивных посетителей выскажут свои пароли прежде чем вам удастся прикрыть вашего клона, расставленного «злыми друзьями». В общем, с безопасностью как всегда все плохо, как ни крути
• регистрация — головная боль для разработчика приложений. Во-первых, надо все функции распределять по категориям «этих пускать-этих не пускать», выдавать в зависимости от этого различные страницы, писать анализаторы активности и защиты от роботов, переписывать их, потому что примененные устарели и злобные хакеры их щелкают на раз ради генерации тысячи бесполезных аккаунтов для своих подлых целей и ради чего? Ради тех, кто в 80% случаев не зайдет на сайт второй раз, а зарегистрируется исключительно из любопытства? Нет, я не спорю — есть готовые и удобные решения, которые отработаны годами и было бы глупо их игнорировать. Но если мы пытаемся пофантазировать на предмет того, что в день на наш сайт заходит не жалкие 100 посетителей вместе с поисковиками, а так пара сотен тысяч (с соответствующим парком серверов) — расклад резко меняется. Потому что уже будет недостаточно просто авторизовать пользователя, записав ему в сессию «свой человек», надо уже выделять сервера под memcached или альтернативный механизм, переводить сессии на него и зорко следить за тем, что при смене сервера в кластере оная сессия не была потеряна. В некоторых Гугловых сервисах, насколько я знаю, подошли еще кардинальнее — никаких сессий на серверах (а, следовательно, головной боли с их миграцией), все данные в cookie пользователя, в зашифрованном виде. Да, нагрузку с серверов убрали, а вот то, что хранить данные у пользователя — это затея еще менее надежная, говорить, думаю, не приходится. В общем, и тут — головняк.

Вот так и получается, что все эти регистрации — зло и головная боль по обе стороны баррикад. «Ну и ладно» — скажете вы. «Известное зло лучше анархии и беспорядков. Хоть какая-то видимость контроля.» С одной стороны — это правда, да и посетители, люди, в общем случае далекие от разработки, уже кое-как приноровились и формы заполнять, и пароли менять по первому подземному стуку. Т.е. это как-то живет, хотя бы потому, что альтернативы есть, но они сложные. Сложные как для пользователя, так и для разработчиков.

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

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

Ну и третья альтернатива — плюнуть на все регистрации и делегировать все динамические вещи требующие оной сторонним сервисам, например JS-Kit. Или вообще отказаться от регистрации как таковой. Если есть резон.

А в целом — вопрос так и остается открытым. Единственное что знаю точно — собственной системы авторизации в моем следующем интернет-проекте не будет. Если сам проект состоится.