Архивы: по дате | по разделам | по авторам

Cookies, и с чем их едят

Архив
автор : Игорь Гордиенко   26.05.1997

Кулинарные основы

Неважно, являетесь ли вы поклонником Microsoft Internet Explorer или же Netscape Navigator (Communicator), при работе с браузерами вы то и дело наталкиваетесь на некие небольшие штуковинки, которые, кроме того, что занимаются какими-то своими таинственным делами, к тому же имеют непонятное название "cookies", имеющее во всех англо-русских словарях однозначный перевод: "печенье".

Никто не знает достоверно, откуда произошел термин "cookie". Это фольклор. Его истоки прослеживаются в уже давние легендарные времена "до улицы Сезам", в дни царствования первых Unix-систем. А речь идет о неких "волшебных пряниках" (magic cookies), съев которые, сказочные герои мультсериалов обретали способности к мыслеобмену. Став хакерским термином, cookies используются уже не один десяток лет для обозначения жетона (token) или билета (ticket), которыми обмениваются программы или процедуры при определении взаимных прав. "Новый словарь хакера" ("New Hacker's Dictionary") сравнивает cookie с квитанцией из химчистки. Когда вы возвратитесь за своими вещами, то работник на выдаче проверит вашу квитанцию и выдаст вещи - именно те, которые вы сдавали. Полезно также сравнение cookie с иностранным паспортом, в котором ставятся отметки о пересечении границ и посещении разных территорий.

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

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

Браузеры и серверы нуждаются в применении cookies из-за безличной сути HTTP - формы языка не хранят информацию о рабочих состояниях среды. Любое соединение HTTP (Hyper Text Transfer Protocol) включает четыре существенных действия:

  1. браузер входит в контакт с сервером по указанному URL (Universal Resource Locator);
  2. браузер обращается к службам сервера, пытаясь сообщить ему свои возможности и потребности;
  3. сервер отправляет состояние транзакции обратно к браузеру, вместе с затребованными данными или сообщением об ошибках;
  4. соединение закрывается, и сервер более не помнит о транзакции.

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

Вообще говоря, спецификации пряников, именуемые "The Magic Cookie", первоначально были сформулированы компанией Netscape Communications, а к настоящему времени продуктивно восприняты производителями других браузеров, например, Internet Explorer, Mosaic. С 5 мая 1997 года версия 2.54 документа RFC2109 (Request For Comment), озаглавленного "Механизм управления состояниями HTTP" ("HTTP State Management Mechanism") и находящегося на доработке в Bell Labs, является предметом внимания группы по техническим проблемам Internet (IETF - Internet Engineering Task Force). Статус документа как проекта истекает 5 ноября этого года. После этого, вероятно, он станет действующим стандартом еще одного протокола Internet.

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

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

 

Спецификации пряников

Рассмотренный ниже синтаксис записи заголовков приведен в изначальных спецификациях Netscape Communications "The Magic Cookies". В разработке документа RFC2109 правила, как и положено, приобрели гораздо более строгое, но и более обширное представление. Не будем их обсуждать, поскольку проект может остаться на бумаге.

Заголовок установки пряника, определяемый сервером и направляемый на браузер, выглядит в общем виде так:

Set-Cookie: name=<значение>; expires=<дата>; path=<путь>; domain=<имя домена>; secure

name=<значение>

Это определение имени и содержания данных. Не допускается использование двоеточия, запятой и пробела. Например, некоторой странице можно дать имя "Count" и присвоить содержание, равное 1, значение которого сервер будет увеличивать на 1 всякий раз при посещении страницы. Вот так, для начала: "Count=1". Единственный необходимый параметр заголовка.

expires=<дата>

Срок годности - момент истечения действия пряника по гринвичскому меридиональному времени. Если этот параметр не установлен, то пряник утратит годность сразу же по окончании сеанса. Задавать этот параметр надо в довольно неудобном формате: "Monday, 19-May-1997 23:45:00 GMT". Некоторые браузеры воспринимают сокращенную запись года, например, 97, а некоторые даже допускают указание других отсчетов времени, например, поясных.

path=<путь>

В случае задания этого параметра браузер будет возвращать пряник серверу, только если будет запрошен URL с указанным путем. Например, если задано "path=monkey", то возврат пряника произойдет в случаях затребования страниц, размещенных в каталоге /monkey/ или глубже, скажем, /monkey/chimp/. Если путь не задан вообще, то он будет устанавливаться автоматически как путь первого запроса URL от браузера. Если нужно, чтобы пряники отсылались с каждым запросом к серверу, то следует указывать корневой каталог сервера, то есть "path=/".

domain=<имя домена>

Здесь определено имя домена, куда будут возвращаться пряники. Для доменов com, edu, net, org, gov, mil, int нужно задавать по меньшей мере два периода, то есть, к примеру, "cterra.com", что будет означать все что угодно вида *.cterra.com, в том числе и www.cterra.com. Для других доменов - не менее трех. По умолчанию имя домена есть имя сервера, сгенерировавшего пряник.

secure

Если пряник маркирован меткой безопасности, то он будет отсылаться только на сервер, обеспечивающий сертифицированный уровень безопасности (в настоящее время это означает наличие средств HTTPS (HTTP-SSL - Secure Socket Level). Конечно, можно и не задавать этот параметр.

Таким образом, полный заголовок пряника для страницы может выглядеть так:

Set-Cookie: Count=1; expires=Monday, 26-May-1997 23:45:00 GMT; path=monkey/; domain=cterra.com; secure

После задания этих стандартно определенных параметров сервер может вставлять в тело пряника служебную информацию по собственному усмотрению. Он же будет отвечать за ее правильную интерпретацию. Сама запись установки пряника, поступающая от сервера, как правило, не кэшируется в браузере. Можно, однако, посмотреть готовые пряники. Например, в браузерах Netscape они находятся в файлах cookies.txt. Понять их глубокий смысл непосвященным не так то просто, да и не нужно. А вот соответствующий сервер легко разберется с ними.

То, что было в файле cookies.txt у автора статьи:

www.sna.com FALSE /mmatteo/Java FALSE 922953600 Counter_Cookie 2

.yahoo.com TRUE / FALSE 915145198 Y v=1&n=4vg62g9bam3m6&l=6eh38/o& p=m1lvvru4010q

.techweb.com TRUE / FALSE 942189161 TechWeb 194.67.14.81.863343964

.netscape.com TRUE/FALSE 946684575 NETSCAPE_ID 10010408,149fd281

.nrsite.com TRUE / FALSE 946598481 Nrid oO3pe9EntnvOdd+9hPLT1a www.minds.com TRUE / FALSE 926596817 MUBSTAMP_EUS 1966466 .focalink.com TRUE / FALSE 946641596 SB_ID green.02750863583381488124

.illuminatus.com TRUE / FALSE 945734399 Count 2

Просим к столу!

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

Например, на страницах сайтов таких известных онлайновых торговцев, как Netscape Communications и Amazone Books временные пряники используются для сохранения потребительской информации. Благодаря такому приему, информация о продуктах может распространяться на многие страницы, а пользователь, просматривая их, получает возможность отметить нужные покупки и сделать окончательный заказ через единственный вход, размещенный на отдельной странице. И когда заказ будет сделан, сервер проиндексирует все выборы в специальную ключевую запись данного сеанса и сохранит ее как пряник в браузере пользователя.

На сайтах многих компаний используется несложный, почти стандартный пряник для того, чтобы по предпочтению клиента задать режим формирования и просмотра страниц сайта: скроллинг или фреймы. Практически все поисковые машины (например, AltaVista, Excite, Search.com) используют пряники для настройки поисковых профилей пользователей.

Пряники часто служат средством хранения входной регистрационной информации, например, имени для подключения (login) и пароля. Таким образом, посетитель избавляется от утомительной необходимости, заходя на данный сайт, всякий раз указывать свои неудобовыразимые атрибуты. Примеры такого рода применений пряников можно найти практически на всех персонализированных информационных сайтах: на My Yahoo!, Hot Wired и многих других. Если пользователь потерял или испортил свой пряник, например, стер файл-хранилище пряников из браузера, то потребуется просто еще раз пройти процедуру ручного подключения к сайту, чтобы завести новый пряник в серверной базе данных и в собственном браузере.

А калифорнийская компания Electric Mind использует достаточно отработанные структуры на основе пряников для достижения более экзотической цели - построения онлайнового сообщества. Сайт был создан в августе прошлого году на основе идеологических посылок Говарда Рейнгольда (Howard Rheingold), автора книги "Виртуальная реальность", изданной в 1994 году. Инфраструктуру сообщества спроектировала компания Leverage Information Systems. Система управления онлайновым сообществом включает регистрационную базу, базу данных пользователей, динамическую базу управления содержанием. Совместное использование этих информационных хранилищ регулирует доступ читателей к избранным работам 25 ведущих обозревателей (columnist). Первичный прикладной сервер построен с помощью технологии Java. Информационные массивы реализованы в базе данных Oracle.

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

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

Не менее изощренное применение механизмам пряников нашла компания Data Transmittion Network (DTN). Она предоставляет информацию по сельхозпродуктам, их поставщикам, дает ссылки на другие источники по данной тематике. Компания снабжает информацией более чем 150 тыс. подписчиков через традиционные каналы связи, а недавно начала распространять свои аналогичные услуги через WWW. В зависимости от профиля услуг плата составляет от 10 до 60 долларов в месяц. Являясь реселлером лицензированной информации, DTN сама приобретает исходные материалы у многочисленных поставщиков содержания. Лицензионные соглашения между DTN и поставщиками могут несколько варьироваться, но в их основе простое условие отчисления гонораров исходя из числа обслуженных клиентов. И поэтому компании приходится заботиться о том, чтобы ее клиенты не могли предоставлять свою подписку третьим лицам. Эту задачу DTN решает совместным использованием пряников и обычной учетной системы на основе входных параметров "имя-пароль".

Система действует таким образом. Всякий раз, когда зарегистрированные пользователи подключаются к DTN, Web-сервер проводит сопоставление их пряников, возвращенных браузерами, с данными из базы, построенной на основе Microsoft SQL Server. Каждая попытка соединения фиксируется в журнале с указанием множества различных сопутствующих данных, включая тип браузера, IP-адрес, операционную систему и т. п. Если значения всех этих параметров при очередной попытке доступа совпадают с хранящимися в базе данных, то предоставляется право доступа, а старый пряник замещается новым. Таким образом, всякий раз при подключении к серверу DTN помимо имени и пароля сообщается последний вариант пряника. И если даже некто передал свой пряник третьему лицу, то сам он точно лишится доступа, поскольку не узнает результатов сеанса этого третьего лица. Эти меры делают маловероятным совместное использование входных данных: координация общего информационного обмена становится слишком сложной и дорогостоящей задачей, чтобы решать ее самому.

С помощью пряников DTN также отслеживает все подозрительные ситуации. К примеру, всегда можно обратиться к записи в базе данных, фиксирующей случай, когда пользователь X подключился к системе через провайдера Y с браузера Netscape. А оказалось, что в данном случае подключение выполняется через провайдера Z, и используемый браузер - Internet Explorer. Очевидно, что либо клиент поменял провайдера, либо кто-то пытается подключиться через известные входные параметры.

Компания Doubleclick помогает вести рекламу на WWW таким корпорациям, как IBM, Microsoft, AT&T, и другим. И пряники играют решающую роль в способностях Doubleclick подавать целевую рекламу, управлять частотой ее подачи, обеспечивать детальный анализ результатов этой деятельности. Doubleclick вставляет рекламу со своих серверов в страницы Web на более чем 60 подопечных корпоративных сайтов. Когда пользователь обращается к одному из них, то браузер на короткое время вступает в контакт с сервером Doubleclick, который и передает рекламную вставку. В этом процессе уникальный компактный идентификатор - пряник - обрабатывается, и одновременно делается запись в базе данных, созданной на основе системы Oracle на сервере Doubleclick. Впоследствии информация о вставленной рекламе и о пользователе, которому она была подана, будет проанализирована.

В Doubleclick отмечают, что еще год назад реклама на WWW была весьма новым и необычным делом и владельцы сайтов хотели поэкспериментировать. Сейчас рекламодатели требуют разумных систем, которые дают эффективное управление и подробные отчеты. Рекламодатели хотят учитывать в своей целевой рекламе такие критерии как географическое нахождение клиентов, используемая операционная система, имя домена, время суток, частота заходов на сайт и т. п. Используя пряники как индексы в базе данных, Doubleclick как раз и проводит сечения по всем перечисленным параметрам. А предположения относительно интересов пользователей делаются, исходя из характера связанного посещенного сайта. Более того, Doubleclick ведет учет того, сколько раз реклама была показана конкретному пользователю и затребовал ли он дополнительную информацию о предмете рекламы, "кликнув" на ее картинку.

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

Создавать и тем более сопровождать систему управления рекламой - очень сложная задача, и написание кодов обработки пряников - только незначительная часть ее. Для Doubleclick самое важное - конечная производительность системы. А механизмы пряников обеспечивают время определения рекламы, которую нужно вставить данному пользователю, - всего лишь 20 мс. Каждый месяц отслеживается до 10 млн. посетителей упомянутых 60 сайтов.

Вредны ли пряники?

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

В январе этого года Федеральная комиссия по торговле (FTC - Federal Trade Commission) США опубликовала доклад с результатами анализа коммерческой деятельности в WWW. Приведенные в докладе данные были столь значимы, что вскоре последовали рабочие совещания и ведомственные слушания. В результате всех этих мероприятий был сделан вывод о том, что рост коммерческой деятельности в WWW неизбежно влечет накопление глобальных массивов персональных данных. А поэтому совершенно необходима разработка политики защиты информации о потребителе. Технические средства должны обеспечить пользователям должные предупреждения, выбор объема сообщаемых персональных данных и гарантии их неразглашения.

Потребители США чрезвычайно озабочены вопросами защиты частной информации в свете угрозы, растущей на стыке бизнеса и новейших коммуникационных технологий. Еще в 1995 году доклад службы Харриса (Harris) отмечал, что 82% американцев опасались за свою личную безопасность в связи с посещениями Сети, а 78% были уверены, что у них нет средств контроля бизнеса, который пользуется их персональными данными.

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

Разработчики браузеров предлагают пользователям все более мощные средства контроля пряников. К примеру, начиная с версии 3.0 Netscape Navigator, можно задать режим полного отказа от приема "опасных подарочков". В последних бета-версиях Netscape Communicator предоставляются уже весьма гибкие средства. Можно принимать все пряники, можно принимать только те из них, которые нужно будет отправить обратно на сервер, а можно полностью отказаться от приема. Как дополнительную опцию можно установить режим оповещения перед приемом пряника.

Имеется также немало утилит, которые автоматически удаляют файлы пряников в конце каждого сеанса присутствия в Сети. Это позволяет получить все преимущества от использования сеансовых ключей. А постоянные пряники, могущие нести некоторую персонализированную составляющую, будут искореняться. В марте этого года известная компания PGP предложила свой подключаемый (plug-in) модуль, который блокирует все пряники. В Сети можно найти немало и бесплатных программ, блокирующих механизмы пряников. Если проведете поиск в WWW по ключевому слову "cookies", то через пару ссылок все найдете.

И тем не менее… Когда компания DTN включила в сферу своей онлайновой деятельности небольшую ранее существовавшую систему с 55 клиентами и при этом попыталась запустить для них механизм постоянных пряников, то в ответ было получено 15 возмущенных отповедей.

Интересно, что многие тысячи других клиентов, которые давно обслуживаются с помощью пряников, даже не задумываются о том, насколько это хорошо или плохо. Вопрос возникает единственный раз - при первичной регистрации. Тем не менее столь высокий процент недоверчивых заставляет задуматься: а что бы было, если бы сразу подписались тысячи неграмотных клиентов? Выход один: учить и еще раз учить! И в подтверждение этому представители Netscape Communications заявляют, что массовый пользователь уже сейчас куда более толерантен к пряникам, чем, например, год или полгода назад.

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

© ООО "Компьютерра-Онлайн", 1997-2024
При цитировании и использовании любых материалов ссылка на "Компьютерру" обязательна.