Cookies

Томас Даннинг говорил: При 300 процентах [прибыли] нет такого преступления, на которое он [капитал] не рискнул бы, хотя бы под страхом виселицы. Эти слова, сказанные в XIX веке, актуальны до сих пор. Компании, которые ведут бизнес в интернете, изобретают все более изощренные способы слежки за пользователями.

История кукисов пережила несколько скандалов, связанных с нарушениями приватности, работа браузеров с ними постепенно менялась и, казалось бы, окончательно вошла в цивилизованное русло. Мы научились защищать свои данные и кушать печеньки стало относительно безопасно.

Но потом появились Supercookies довольно липкая штука, которую буквально не обойти.

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

Как наивность разработчиков создала основы для сбора персональных данных

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

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

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

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

Первая тревога была поднята в 1996 году. Всего через пару лет после внедрения cookie Financial Times опубликовала в своей газете статью об угрозе приватности:


Итогом расследований 1996 и 1997 годов, которые прошли в Федеральной комиссии по торговле США, стала спецификация, регламентирующая работу с куками. Одним из ее положений было то, что сторонние cookie должны или полностью блокироваться, или, как минимум, не работать по умолчанию.

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

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

Как Flash-Supercookie собирали персональные данные

Изначально Supercookie были неприятным и потенциально опасным явлением. В отличии от обычных куков, их источник был не от адреса конкретного сайта, а домена более высокого уровня. Например, вместо привязки к сайту habr.com, файл куки прописывался к доменному имени com и мог контролировать работу пользователя с любыми сайтами в этой доменной зоне. Эта возможность была настолько очевидной, что блокировалась браузерами с самого начала. Но, когда появились способы хранить приватную информацию другими способами, это название вспомнили и оно прижилось.

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

Так как коммерческие компании мало чем отличаются от негодяев в выборе средств, они не гнушались задействовать возможности flash для сбора информации о пользователях. Для этого применялась технология под названием Локальные общие объекты (LSO, Local Shared Objects). Изначально она предназначалась, к примеру, для сохранения прогресса в браузерной flash-игре или настройки громкости в аудио-плеере. LSO доступны из разных браузеров, потому что относятся к флеш-плееру. С их помощью можно восстанавливать обычные http-cookie, если пользователь их удалил, а внутри самих LSO можно хранить много собранной информации о пользователе компьютера.

Довольно долго эта технология не попадала в поле зрение специалистов по безопасности, но в 2009 году Джереми Кирк опубликовал свое исследование, посвященное проблемам приватности: Study: Adobe Flash cookies pose vexing privacy questions. Постепенно начали появляться сторонние расширения, позволяющие контролировать и удалять флеш-куки, но неповоротливые производители браузеров и компания Adobe не торопились обратить внимание на эту проблему. Только в 2011 году распространенные браузеры научились работать с этими печеньками так же, как и с обычными.

Но в конце-концов дырявый и тормозной Flash-player всех окончательно достал, а HTML5 получил достаточно широкое распространение, что позволило полностью избавиться от технологии Флеш. Убивали его долго и мучительно, компания-производитель очень неторопливо отказывалась от своего детища. В 2012 году Adobe пообещала, что прекратит поддержку технологии примерно в течение десятка лет. В 2017 был назван срок удаления флеш-плеера с сайта декабрь 2020 года. Эти три года, по словам компании, были необходимы для того, чтобы разработчики адаптировали свои сайты под HTML5. Месяц назад этот срок подошел к концу, и назойливые предупреждения о том, что плагин, окончательно и бесповоротно, отовсюду удаляется, стали появляться во всех браузерах, хотя непонятно, зачем уведомлять об этом пользователей, которых не особо интересуют тонкости внутреннего устройства сайтов.

На этом можно считать тему флеш-куков окончательно исчерпанной.

Примерно по тому же механизму работали супер-куки на основе ETag, одного из идентификаторов HTTP-заголовка, отвечающего на запрос, отличается ли текущая версия ресурса от загруженного. Подобные куки были обнаружены примерно в одно время с Flash-Supercookie и, после иска в 2011 году, встречались относительно редко.

HTTP-Supercookie: как Verizon и Access втихую продавали данные

Флеш не единственный способ слежки за пользователями через куки.

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

Протокол HTTP без SSL-шифрования прожил очень долго: SSL-сертификаты были платными, порой совсем не дешевыми (некоторые компании продавали их дороже 100 долларов). Вторая причина сложность использования. Это сейчас сертификат ставится и обновляется запуском одного скрипта, а до того как Mozilla раскрутила свою инициативу Lets Encrypt, не каждый админ считал необходимым изучить установку SSL.

Но пока суд да дело, интернет-провайдеры эксплуатировали и продавали рекламщикам возможность отслеживать пользователей через HTTP.

Работало это довольно изощренным образом. Когда пользователь заходил на сайт, его провайдер вставлял в HTTP-заголовок особую информацию: UIDH (Unique Identifier Headers), уникальную для каждого пользователя, что позволяло совершенно однозначно идентифицировать компьютер или смартфон, с которого открывают страницу. Для подобной операции использовалась нашумевшая технология DPI.

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

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

Самый известный скандал с использованием этого способа отслеживания пользователей связан с компанией Verizon, американским провайдером сотовой связи. В Verizon начали использовать UIDH в 2012 году для показа персонализированной рекламы, активно торгуя личными данными своих клиентов. Только в 2014 году компания публично призналась в этом факте, закопав упоминание о нем глубоко в Q&A на своем сайте. Тем не менее это заметили, и на Verizon обрушился шквал критики за такое беспардонное отношение к своим пользователям. В 2015 году компанию вынудили добавить в личный кабинет пользователя настройку, позволяющую отключить использование UIDH для своих устройств, а в 2016 году окончательно добили. Федеральная комиссия по связи США взыскала с компании штраф в 1,35 миллиона долларов.

Увы, Verizon не одни такие хитрые.

Компания Access создала специальный сайт Amibeingtracked.com (актуальный адрес: www.accessnow.org/aibt/) и стала анализировать заголовки HTTP пользователей мобильных телефонов, которые согласились на тестирование. Выяснилось, что 15,3% запросов содержали супер-куки. В участии принимали пользователи со всего земного шара. Оказалось, что почти все крупные мобильные операторы следили за своими пользователи таким образом.

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

Кроме того надо отметить, что не только сайты работающие по протоколу HTTPS способны защитить от подобной слежки, но и серфинг через VPN. В этом случае провайдер тоже не может подставить UIDH. Обы способа защиты актуальны, а недавние ковровые блокировки научили многих компьютерной грамотности, и про VPN узнали очень многие.

HSTS-Supercookie: почему SSL нас не спасет

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

Основан он на том, что для каждого сайта в браузере есть специальная булева переменная, которая хранит состояние того, как пользователь заходил на сайт: через HTTPS или HTTP. Например, последний раз пользователь заходил на сайт habr.com через HTTPS, а на сайт flibusta.is через HTTP (увы, это сейчас актуально из-за нерасторопности админов библиотеки). В браузере будут данные примерно такого вида:

habr.com: 1;

А сайт flibusta.is не будет упомянут в HSTS-базе.

Таким образом можно зарегистрировать несколько доменов вида: 00-hsts-supercookie.net, 01-hsts-supercookie.net, 02-hsts-supercookie.net, 03-hsts-supercookie.net.

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

00-hsts-supercookie.net: 1;02-hsts-supercookie.net: 1;

И потом считывать данные для кукис-сайтов, подставляя 0 на место сайтов, которых нет в базе. В этом примере будет сформировано число 1010. Если зарегистрировать два-три десятка сайтов, то уникальных идентификаторов будет достаточно, чтобы снабдить ими вообще всех абонентов, которые, теоретически, могут зайти на сайт.

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

HTML5-Supercookie

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

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

Если вы посещаете современные сайты, то вы пользуетесь возможностями HTML5, а значит информация про: user-agent, размер canvas, разрешение экрана и глубину цвета, системные шрифты и многое другом, будет передаваться на сайт, для того, чтобы адекватно его отрисовать в браузере. Кроме того стандарт HTML5 позволяет сохранять данные в Localstorage, специальном хранилище, которое недоступно пользователю через обычное меню по чистке кукисов, истории посещения или кеша браузера.

Посмотреть все, что передает браузер на сайт, можно на сайте www.deviceinfo.me. Попробуйте зайти количество информации впечатляет!

Также существуют сайты, которые сопоставляют всю передаваемую информацию и вычисляют то, насколько уникально ваше конкретное устройство среди множества остальных. К примеру, я зашел на coveryourtracks.eff.org, сайт продвигаемый некоммерческой правозащитной организацией Фонд электронных рубежей (Electronic Frontier Foundation, EFF) и выяснил, что:

Your Results

Your browser fingerprint appears to be unique among the 300,802 tested in the past 45 days.

Currently, we estimate that your browser has a fingerprint that conveys at least 18.2 bits of identifying information.

The measurements we used to obtain this result are listed below. You can read more about our methodology, statistical results, and some defenses against fingerprinting here.

В теории, считается, что немного уменьшить уникальность браузера можно с помощью использования прокси или VPN и приватного режим браузера. Увы, это не сильно мне помогло, результаты полученные в приватной вкладке через встроенный в Opera VPN, выдали практически те же самые результаты:

Your Results

Your browser fingerprint appears to be unique among the 300,854 tested in the past 45 days.

Currently, we estimate that your browser has a fingerprint that conveys at least 18.2 bits of identifying information.

The measurements we used to obtain this result are listed below. You can read more about our methodology, statistical results, and some defenses against fingerprinting here.

Хотя одно устройство из трехсот тысяч в море, где плавают сотни миллионов смартфонов и десктопов, есть где спрятаться.

Cache-Supercookie: изощренный способ идентификации пользователя через кэш

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

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

Бороться с такими супер-куками можно с помощью разделения кешей для разных сайтов. Неделю назад команда Firefox сообщила, что они включили этот механизм в 85 версию браузера. Объем кэшируемых данных увеличивается, но зато отследить пользователя становится сложнее.

Какими печеньками нас будут кормить в будущем?

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

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

Поэтому так ли страшно отслеживание рекламными фирмами наших действий в интернете?

Сложно сказать. Дело не только в слежке, но и в назойливой персонализированной торговле. С одной стороны, на моей памяти, я только раз воспользовался рекламным предложением из поисковой выдачи, которое было с пометкой Реклама. За много лет у людей выработалась баннерная слепота, и даже без блокировщика рекламы этот метод уже не особо работает. С другой стороны, высокая релевантность поиска в Google, Amazon или AliExpress работает благодаря хитрым трекерам, отслеживающих нашу активность.

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

Хорошо это или плохо? Наверное, уже ни то и ни другое. Это стало привычным, а приватность иллюзией.

Люди не читают инструкций. Вы почти наверняка не читали лицензионное соглашение Windows, не читали лицензионное соглашение iTunes, не читали условия Linux GPL или любого другого программного обеспечения.

Это нормально. Такова наша природа.

То же самое происходит в интернете. В последнее время благодаря GDPR и другим законам часто приходится видеть всплывающие сообщения, где вас спрашивают разрешения на использование cookies.



Большинство нажимает Согласиться и продолжает жить как ни в чём ни бывало. Никто ведь не читает политику конфиденциальности, верно?

Разработчик Конрад Акунга (Conrad Akunga) решил разобраться, какие конкретно условия предусмотрены соглашением об использовании. Для примера он взял новостной сайт Reuters. Это абсолютно произвольный пример, у большинства других сайтов тоже есть свои правила.

Вот эти правила:

Обратите внимание на полосу прокрутки. Дальше идёт продолжение.


Если вкратце, документ информирует пользователя о нескольких вещах:

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

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

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

И ещё один пункт о партнёрах, которым продаются ваши персональные данные. Список партнёров общий для всех сайтов, которые сотрудничают с IAB.

Кто же эти партнёры?

Если нажать на соответствующую кнопку, то появится следующее окно:

Обратите внимание, насколько маленький ползунок на полосе прокрутки. Наверное, там их сотни. Под названием каждой компании ссылка на политику конфиденциальности.

Это не одна и та же ссылка, а разные! Каждая из них ведёт на уникальную политику конфиденциальности каждого партнёра. Сколько человек на самом деле пойдёт по этим ссылкам вручную, чтобы прочитать условия? Это просто нереально.

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



Скопированный список он вставил в VSCode и получил огромный файл на 3835 строк, который после форматирования (Alt + Shift + F) разбился в чудовище на 54 399 строк.



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

Log.Logger = new LoggerConfiguration().WriteTo.Console().CreateLogger();// Define the regex to extact vendor and urlvar reg = new Regex("\"vendor-title\">(?<company>.*?)<.*?vendor-privacy-notice\".*?href=\"(?<url>.*?)\"",RegexOptions.Compiled);// Load the vendors into a string, and replace all newlines with spaces to mitigate// formatting issues from irregular use of the newlinevar vendors = File.ReadAllText("vendors.html").Replace(Environment.NewLine, " ");// Match against the vendors html filevar matches = reg.Matches(vendors);Log.Information("There were {num} matches", matches.Count);// extract the vendor number, name and their url, ordering by the name first.var vendorInfo = matches.OrderBy(match => match.Groups["company"].Value).Select((match, index) =>new{Index = index + 1,Name = match.Groups["company"].Value,URL = match.Groups["url"].Value});// Create a string builder to progressively build the markdownvar sb = new StringBuilder();// Append headerssb.AppendLine($"Listing As At 30 December 2020 08:10 GMT");sb.AppendLine();sb.AppendLine("|-|Vendor| URL |");sb.AppendLine("|---|---|---|");// Append the vendor detailsforeach (var vendor in vendorInfo)sb.AppendLine($"|{vendor.Index}|{vendor.Name}|[{vendor.URL}]({vendor.URL})|");// Delete existing markdown file, if presentif (File.Exists("vendors.md"))File.Delete("vendors.md");//Write markdown to fileFile.WriteAllText("vendors.md", sb.ToString());

В результате получился список всех партнёров, и у каждой свой уникальный документ c условиями конфиденциальности. Вот этот список: vendors.md.

В нём 647 компаний.

Очевидно, что никто не сможет ознакомиться со всеми этими условиями прежде, чем нажать кнопку Согласиться, делает вывод автор.

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

Код для парсинга из этой статьи опубликован на Github.

8 марта мы рассказали о том, что из соображений безопасности разлогинили всех пользователей GitHub.com из-за редкой уязвимости защиты. Мы считаем, что прозрачность ключевой фактор сохранения доверия со стороны пользователей, поэтому решили рассказать об этом баге подробнее. В этом посте мы изложим технические детали данной уязвимости и объясним, как она возникла, как мы на неё отреагировали и какие мы предприняли шаги для того, чтобы подобное не повторилось.

Отчёты пользователей

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

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

Исследование недавних изменений в инфраструктуре

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

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

Исследование недавних изменений в коде

Благодаря тому, что мы начали расследование с недавних изменений в инфраструктуре, нам удалось выяснить, что запросы, приводившие к возврату неправильной сессии, обрабатывались на одной и той же машине и в одном процессе. Мы используем многопроцессную схему с веб-сервером Unicorn Rack, выполняющим наше основное Rails-приложение. обрабатывающее такие задачи, как отображение issues и пул-реквестов.

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

У нас появилась рабочая теория о том, что нечто каким-то образом приводило к утечке состояния между запросами, которые обрабатывались в одном процессе Ruby. Нам нужно было выяснить, как такое может происходить.

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

Безопасность потоков и отчёты об ошибках

Для понимания проблемы с безопасностью потоков необходим контекст. Основное приложение, обрабатывающее большинство браузерных взаимодействий на GitHub.com это приложение Ruby on Rails, известное тем, что оно имело компоненты, написанные без учёта возможности в нескольких потоках (т.е. они были непотокобезопасны). Обычно в прошлом непотокобезопасное поведение могло приводить к неправильному значению во внутренних отчётах об исключениях системы, но при этом пользователи не сталкивались с изменением поведения системы.

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

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

Многократно используемый объект

Наша команда совершила прорыв, обнаружив, что HTTP-сервер Unicorn Rack, используемый в нашем Rails-приложении, не создаёт новый и отдельный объект env для каждого запроса. Вместо этого он выделяет единственный Ruby Hash, который очищается (с помощью Hash#clear) между запросами, которые он обрабатывает. Благодаря этому мы поняли, что проблема с потокобезопасностью в логгинге исключений может привести не только к неправильности фиксируемых в исключениях данных, но и к передаче данных запросов на GitHub.com.

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

1. В потоке обработки запросов запускается анонимный запрос (назовём его Request #1). Он регистрирует обратный вызов в текущем контексте для внутренней библиотеки отчётности об исключениях. Обратные вызовы содержат ссылки на текущий объект контроллера Rails, имеющий доступ к единому объекту среды запроса Rack, предоставляемого сервером Unicorn.
2. В фоновом потоке возникает исключение. Сообщение об исключении копирует текущий контекст, чтобы включить его в отчёт. Этот контекст содержит обратные вызовы, зарегистрированные запросом Request #1, в том числе и ссылку на единую среду Rack.
3. В основном потоке запускается новый запрос залогиненного пользователя (Request #2).
4. В фоновом потоке система отчётности об исключениях обрабатывает обратные вызовы контекста. Один из обратных вызовов считывает идентификатор сессии пользователя, но поскольку запрос на момент контекста не имеет авторизации, эти данные ещё не считываются, и, следовательно, запускают новый вызов к системе авторизации через контроллер Rails из запроса Request #1. Этот контроллер пытается выполнить авторизацию и получает куки сессии из общей среды Rack. Так как среда Rack это общий объект для всех запросов, контроллер находит куки сессии запроса Request #2.
5. В основном потоке запрос Request #2 завершается.
6. Запускается ещё один запрос залогиненного пользователя (Request #3). В этот момент Request #3 завершает свой этап авторизации.
7. В фоновом потоке контроллер завершает этап авторизации, записывая куки сессии в cookie jar, находящийся в среде Rack. На данном этапе это cookie jar для Request #3!
8. Пользователь получает ответ на запрос Request #3. Но cookie jar был обновлён данными куки сессии Request #2, то есть пользователь теперь авторизован как пользователь из Request #2.

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

Для возникновения этого бага требовались очень конкретные условия: фоновый поток, общий контекст исключения между основным потоком и фоновым потоком, обратные вызовы в контексте исключения, многократное использование объекта env между запросами и наша система авторизации. Подобная сложность является напоминанием о многих из пунктов, представленных в статье How Complex Systems Fail, и демонстрирует, что для возникновения подобного бага требуется множество различных сбоев.

Предпринимаем действия

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

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

Кроме устранения бага мы предприняли действия для определения пользовательских сессий, на которые он повлиял. Мы изучили данные логгинга на предмет паттернов, соответствующих неправильно возвращаемых сессий. Затем мы вручную просмотрели соответствующие паттерну логи, чтобы определить, на самом ли деле сессия была неверно возвращена от одного пользователя другому.

В конце мы решили сделать ещё одно превентивное действие, чтобы гарантировать безопасность данных наших пользователей, и аннулировали все активные сессии пользователей на GitHub.com. Учитывая редкость условий, необходимых для возникновения этого условия гонки, мы знали, что вероятность возникновения бага очень мала. Хотя наш анализ логов, проведённый с 5 по 8 марта, подтвердил, что это была редкая проблема, мы не могли исключить вероятность того, что сессия была неверно возвращена, но никогда не использовалась. Мы не хотели идти на такой риск, учитывая потенциальный ущерб использования даже одной из таких неверно возвращённых сессий.

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

Продолжаем работу

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

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

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

Подведём итог

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

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

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

От обмена данными в чистых помещениях и внутри объединений паблишеров до контекстной рекламы и решений на основе алгоритмов ИИ Тим Конли, директор IPONWEB по обслуживанию клиентов в Европе, рассказывает о том, что нас ждет в мире без cookie-файлов.

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

Итак, каким будет будущее без cookie-файлов?

Решения на основе контекстной рекламы.

На заре цифровой эпохи ключевую роль играл контент наряду с контекстом. Рекламодатели покупали рекламные места, ориентируясь на аудиторию паблишера, которая, в свою очередь, зависела от контента, размещаемого на сайте. То есть реклама была связана с непосредственными интересами пользователя, а не с его прошлой активностью, отслеживаемой с помощью cookie-файлов.
Со временем, благодаря развитию ретаргетинга на базе файлов cookie и его более высокой эффективности, на первый план вышла аудитория. Стало не так важно, где размещать рекламу, главное, чтобы ее видел именно тот пользователь, которого хотел привлечь рекламодатель.
Теперь, когда конец cookie-файлов неизбежен, маятник таргетинга качнулся обратно в сторону контекстной рекламы. Похоже, рекламодатели готовы (вновь) признать, что уместность важна и что есть определенный смысл в том, чтобы размещать свой контент в подходящих местах. Вместо того, чтобы пытаться продать пользователю кроссовки для бега, пока он изучает свою родословную на генеалогическом сайте, гораздо эффективнее показать ему эту же рекламу, когда он просматривает информацию о беговых маршрутах.
Контекстный таргетинг тоже не стоял на месте. Здесь удалось добиться, в частности, более быстрой и детализированной классификации контента. Благодаря этому рекламодатели могут, например, эффективно использовать новостные циклы и популярный контент.
Многое еще предстоит сделать, чтобы научиться дополнять контекст нужными эмоциями и обеспечить более дифференцированный подход, учитывающий различные нюансы. Например, чтобы рекламодатели, которые хотят ассоциироваться с контентом, посвященным баскетбольной тематике, но при этом не появляться в новостях, посвященных недавней трагичной смерти Коби Брайанта, могли настраивать такое размещение автоматически и с возможностью масштабирования.

Инициативы паблишеров и рекламодателей.

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

Обмен данными с помощью чистых помещений.

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

ИИ и алгоритмы машинного обучения.

В этой теме сохраняется обширное пространство для теорий и спекуляций, однако очевидно: постоянно дорабатываемая самообучаемая модель, анализирующая анонимные сигнальные данные, такие как частота посещений сайта или используемые устройства, позволяет узнать о пользователях очень многое. Обработка больших массивов таких данных позволяет формировать когорты пользователей и на базе этого делать общие прогнозы.
Например, для людей, проживающих в конкретном районе города, пользующихся устройствами Apple с iOS версии 13 или выше и посещающих сайт Forbes.com, вероятность оформления и получения кредитных карт в пять раз выше среднего. То есть вместо того, чтобы таргетировать рекламу на конкретных пользователей на основе cookie-файлов, возможно сформировать модели закупок рекламы, нацеленные и оптимизированные для охвата выявленных таким образом аудиторий.
Возникают очевидные вопросы по поводу атрибуции, особенно связанные с тем, как при таком подходе паблишеры будут получать свою прибыль. Но в ожидающем нас мире без cookie-файлов это один из перспективных подходов к таргетированию аудитории. Поэтому, чтобы модель атрибуции по последнему клику не стала нормой, появится новый способ оценки эффективности рекламы.

Будущее на основе идентификаторов.

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

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

Мы обсудили с Вендой Чжоу (Wenda Zhou), руководителем направления продуктов для паблишеров в компании IPONWEB, текущее положение дел в сфере programmatic-рекламы от нестандартных подходов к оптимизации заголовков (headers) во время спада продаж до влияния дедупликации аукционов, шейпинга трафика (traffic shaping) и оптимизации цепочки поставки инвентаря (SPO: supply path optimization).



Гэвин Данауэй: Уровень расходов на рекламу все еще очень далек от того, что было до пандемии. Какие, на ваш взгляд, существуют простые приемы оптимизации заголовков, которые помогут паблишерам получить максимальную отдачу?

Венда Чжоу: Есть простой и эффективный способ, позволяющий паблишеру получить максимальную доходность от заголовка. Нужно добиться оптимальной настройки рекламных слотов: они должны сочетать высокий уровень показов (viewability) с хорошими показателями качества страницы, и при этом участники аукционов должны успевать передать ответ обратно в оболочку (wrapper) в рамках заданного окна времени на ответ (timeout window).
Добиться этого можно, в том числе, разбив отдельные рекламные слоты на группы и сделав отдельные вызовы для рекламных партнеров исходя из положения рекламного слота на странице. Например, вызовы по слотам в верхней части страницы обязательно нужно делать первыми с жестким ограничением на время ответа, потому что у рекламодателей для этого блока очень мало времени до того, как пользователь прокрутит страницу вниз. Для слотов в середине или в нижней части страницы требования к времени отклика не такие жесткие, поэтому для них имеет смысл отправлять отдельный запрос с более длительным таймаутом. Паблишеры, рассылающие один запрос для всех слотов на странице, фактически, упускают часть дохода.

ГД: Действительно ли на отрасль programmatic-рекламы серьезно повлияла дедупликация аукционов, примерно как в ситуации с требованиями The Trade Desk? Последуют ли этому примеру другие DSP (Demand Side Platform платформа на стороне покупателя)?

ВЧ: Если коротко, то нет. Проблема дублирования трафика (и усилия, направленные на ее минимизацию) впервые возникла около трех лет назад, тогда речь шла о дублировании из одного источника. Ее в целом удалось решить с минимальными последствиями для отрасли. В последнее время дублирование трафика оценивается на стороне покупателя с двух сторон: для большого количества источников предложений(предложение одного и того же показа от нескольких SSP [Supply Side Platform платформ на стороне предложения]); для связанных партнерств с одним источником, таких как Google Open Bidding (OB) и Amazon Transparent Ad Marketplace (TAM).
Недавнее объявление The Trade Desk касалось второго случая. Его суть в том, что один источник не должен пытаться одновременно монетизировать одни и те же показы и через прямой канал к DSP, и через другие обменные сети. SSP должен выбрать предпочитаемый канал для каждого источника закупки и предлагать DSP показы только через этот выбранный канал(и это не обязательно самый короткий канал).
Из имеющихся двух видов дублирования этот проще выявить и предотвратить. С учетом того, что два самых ярких примера этого вида дублирования работа через OB и TAM (Google и Amazon), вряд ли другим DSP удастся занять аналогичное место на рынке. Хотя в теории The Trade Desk могла бы выиграть от снижения дублирования за счет меньших издержек на оборудование и прослушивание, нам неизвестно о каких-то заметных изменениях по рынку. Хотя, возможно, на какие-то SSP это повлияло сильнее, чем на другие.
Куда больше на торговлю повлияет решение проблемы дублирования из нескольких источников, если (или когда) DSP найдут способ реально ее решить. Если какой-нибудь DSP решит свести взаимодействие по предложениям показа к одному SSP, это может вызвать серьезные проблемы с масштабированием и исполнением, а выбор источников закупки сократится до нескольких явных победителей.

ГД: Каким образом шейпинг трафика влияет на монетизацию паблишеров (и на деятельность закупщиков)?

ВЧ: Паблишеры стали более избирательно подходить к выбору партнеров на стороне спроса. Многие начали отключать SSP, которые не приносят значимого и растущего дохода. Шейпинг трафика стал для SSP одним из способов закрепить за собой место в заголовке паблишера благодаря приоритетному каналу связи с ним, чтобы потом сконцентрироваться на тех из имеющихся рекламных ресурсов, которые обеспечивают более высокий процент реализованных сделок. На стороне покупателя, DSP стали требовательнее при выборе для своих рекламодателей наиболее выгодных каналов закупки с оптимальным набором рекламных ресурсов и структуры затрат.
Многие DSP добавили в свои алгоритмы закупки фильтрацию трафика или перенесли закупку рекламы на частные торговые площадки (PMP: Private Ad Exchange / Marketplace), чтобы получить более прямой доступ к рекламным ресурсам паблишера. По нашим наблюдениям, шейпинг трафика используется для тех видов рекламных ресурсов, у которых нет ограничений с точки зрения предложения, таких как интернет-ресурсы для ПК и мобильных устройств. При этом никаких изменений для рекламных ресурсов, предназначенных для демонстрации на большом экране, например видео для телевизоров с доступом в интернет (CTV: Connected TV), не произошло. Шейпинг трафика, как и оптимизация цепочки поставки инвентаря (SPO) это способ для паблишеров начать с покупателями, т.е. с агентствами и DSP, диалог относительно углубления партнерства, обещающего обеим сторонам дополнительные выгоды за счет упрощения доступа к премиальным закупкам при максимальной прозрачности и снижении издержек.

ГД: SPO спасение для programmatic-рекламы или разрушение экосистемы?

ВЧ: Мнение о полезности SPO и ее ценности для экосистемы очень сильно зависит от того, кому вы задаете этот вопрос. Те представители стороны-получателя, которых потеснили закупщики агентств или DSP, использующие модели закупок на основе машинного обучения для определения наиболее выгодного канала доступа к рекламным ресурсам, скажут, что без SPO было бы лучше. Однако цель SPO оздоровить экосистему через создание прозрачных и эффективных каналов доступа к качественным медиа-ресурсам. Без рисков мошенничества и ущерба для репутации бренда.
С этой точки зрения SPO кажется выгодной для всех игроков, генерирующих самостоятельную ценность в рамках цепочки поставок. Для агентств это означает тесное сотрудничество с разными DSP, SSP и паблишерами с целью поиска каналов закупки, обеспечивающих прозрачность, эффективность и конфиденциальность, совместимость с ads.txt и требованиями приватности, а также безопасность для репутации бренда и дающих им конкурентное преимущество перед другими покупателями.
А паблишерам стоит рассматривать SPO как возможность проинформировать своих партнеров-покупателей о предпочитаемых каналах закупки, то есть, каналах, позволяющих отбить затраты на работающие медиаресурсы и вместе с тем потенциально несущих минимальные финансовые риски. В этом случае, SPO вряд ли станет мессией для programmatic-рекламы, однако поможет перестроить рынок, сделать его центром создание реальной ценности и вернуть покупателям и продавцам ощущение баланса и контроля.

ГД: Открытая экосистема programmatic-рекламы все больше приобретает черты закрытой. Что можно сделать, чтобы развернуть эту тенденцию? Неужели идея о втором этапе роста это лишь несбыточная мечта?

ВЧ: Хотя programmatic-реклама еще не полностью реализовала свой потенциал, она все равно работает в рамках рынка данных. А данные это кровь закрытых экосистем, и если уж нам нужна эффективная конкуренция в рамках открытого интернета (что стимулирует второй этап роста рынка programmatic-рекламы), то агентства, бренды и паблишеры должны иметь возможность использовать в торговле закрытые данные в рамках системы, обеспечивающей конфиденциальность данных, предусмотренную (справедливо) новыми нормативными ограничениями. Главное здесь решить проблему идентификации (ID), ведь в существующей системе идентификация играет ключевую роль и с точки зрения бизнес-модели независимых паблишеров, и для обеспечения возможности для брендов и агентств независимо отслеживать и оценивать эффективность кампании.
Учитывая, насколько быстро в начале прошлого десятилетия сформировались правила открытой RTB-торговли (RTB: Real-Time Bidding) и как быстро на этих правилах выросли очень сложные системы торговли рекламой, нет никаких сомнений, что проблема идентификации будет решена. Однако на этот раз стремление найти решение, отвечающее потребностям индустрии онлайн-рекламы (а также множащимся призывам обеспечить конфиденциальность потребителей) должно быть коллективным и основываться на убеждении, что открытый Интернет должен оставаться свободным и опираться на рекламу, которую размещают все участники рынка, а не ограниченный круг лиц.

ГД: Сторонние следящие cookie доживают свои последние дни. На какие альтернативные технологии делает ставку компания IPONWEB?

ВЧ: Мы активно изучаем разнообразные решения в рамках всех наших бизнес-проектов, включая BidSwitch и MediaGrid, а также взаимодействуем с отраслевыми ассоциациями, такими как проект Rearc у IAB и Консорциум Всемирной сети (W3C: World Wide Web Consortium). Наша общая задача вместе найти все возможные решения и выявить лучшие из них, которые позволят обеспечить соблюдение требований по охране частной жизни и отчетность на уровне пользователя.
Некоторые из этих решений включают: использование внутренних файлов cookie или уникального идентификатора на уровне паблишера, контекстное таргетирование, таргетирование/отслеживание с согласия пользователя, парсинг торговой информации и информации об отслеживании пользователей в анонимизированном виде без возможности личной привязки и т.д.

Гэвин Данауэй шеф-редактор AdMonsters, он отвечает за весь контент сайта, а также разрабатывает повестку дня таких конференций, таких как Publisher Forum и Ops.

Меня долго печалила ситуация с рекламой в Интернете. Стоит всего однажды зайти на продающий какие-либо товары сайт, как тут же начинаешь видеть соответствующую рекламу в соцсетях, в почте, даже в чёртовом музыкальном плеере на телефоне (да, в Xiaomi докатились и до этого). Причем неважно с какой именно целью ты зашел на сайт быть может просто решил уточнить характеристику устройства, или уточнить модель девайса, о котором рассказал другу. Это совершенно не важно, итог один: несколько недель тебе будут показывать злополучные стиральные машинки, мониторы и так далее. Знакомая ситуация? Я уверен, что да!

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

Для отключения подобной слежки (строго говоря отключения сторонних cookies) нужно поставить всего одну галочку в Chrome. Вот ссылка на настройки браузера (вашего, локального): chrome://settings/cookies?search=Privacy+and+security. Нужно включить опцию Block third-party cookies:

И вуаля, на скриншоте ниже ситуация cookie до и после. Раньше была целая куча "левых" сайтов (это еще не попали yandex, mail и т.д.), а теперь только сам сайт магазина. Можете попрактиковаться в проверке такого подхода.

Теперь Вы можете спокойно искать в сети любые товары, не боясь бессмысленной и бсепощадной рекламы. Как бы ни старались рекламщики, пока "воз и ныне там":

Вы купили диван? Давайте мы подберем Вам еще 50 диванов

Я уже несколько дней тестирую полет нормальный, работоспособность нужных мне сайтов не нарушена!