LINUX.ORG.RU

Откуда берет данные контекстная реклама?

 , ,


0

1

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

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

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

anonymous ()
Ответ на: комментарий от anonymous

Но тогда эти скрипты должны иметь возможность писать куда то эту информацию. По умолчанию кросдоменные запросы запрещены. Они используют инъекции типа <img src="wrong.com" data="all_they_need">?

yetanother2018 ()

Но как она узнает, чем интересовался юзер до этого?

На большинстве сайтов сегодня есть счётчики ГуглоАналитики и ЯндексМетрики. Они и позволяют отследить путь юзера между сайтами.

KRoN73 ★★★★★ ()
Ответ на: комментарий от yetanother2018

Но тогда эти скрипты должны иметь возможность писать куда то эту информацию.

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

KRoN73 ★★★★★ ()
Ответ на: комментарий от yetanother2018

Меня интересует техническая сторона дела

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

KRoN73 ★★★★★ ()
Ответ на: комментарий от KRoN73

Вот я и думаю, почему это не запрещено по-дефолту в целях безопасности? То есть, запрет кроссдоменных запросов получается, чистая фикция, коль скоро браузер имеет запрет только на обратное получение данных, а слив информации, то бишь отправка не запрещены

yetanother2018 ()
Ответ на: комментарий от yetanother2018

Что вы хотите запретить? Есть гугл, его метрика присутствует на множестве сайтов. Гугл у себя информацию сохраняет, куда вы ходите. И Гугл же вам контекстную рекламу и показывает. Все четко ) Или вы хотите чтобы на сайте site.com грузились данные только с домена site.com/... ?

keir ()
Ответ на: комментарий от yetanother2018

Но тогда эти скрипты должны иметь возможность писать куда то эту информацию.

Самый-самый примитивный вариант:

1. Ты идёшь на сайт A с лолями, в который вставлен счётчик CoolCounter в виде картинки. При запросе этого счётчика тебе проставляется кука с домена картинки - coolcounter.com

2. Ты идёшь на сайт B, в который тоже вставлен счётчик CoolCounter в виде картинки. При запросе счётчика, браузер также отсылает все куки, принадлежащий домену, с которого тянется эта картинка - coolcounter.com.

3. Сайт coolcounter.com видит, что ты был на сайте лолей и, если на сайте B ещё вставлены рекламные блоки от coolcounter, то он может вставить туда релевантную рекламу, например, дилдо.

4. Как вариант, CoolCounter может вообще не палиться, а просто собирать информацию и продавать её потом поисковику BigTroubles.com, который уже и продаёт контекстную рекламу, анализируя весь твой пройденный путь за последнее время.

anonymous ()
Ответ на: комментарий от yetanother2018

То есть, запрет кроссдоменных запросов получается, чистая фикция

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

anonymous ()
Ответ на: комментарий от yetanother2018

Запретить отправлять данные из скриптов на сторонние домены. Почему этого до сих пор не сделано?

Так данные передаёт браузер при get запросе картинки, например. Никакие скрипты тут даже не нужны.

anonymous ()
Ответ на: комментарий от anonymous

Нет, просто ввести ограничения. Если идет запрос на сторонний ресурс, должно быть явное разрешения домена-отправителя. Какой толк без этого вообще имеет запрет на кросдоменные запросы, если запрос все равно отправляется, а блокируется только получение ответа?

yetanother2018 ()
Ответ на: комментарий от anonymous

Вот смотри, я отправляю кроссдоменный запрос на своем локалхосте, и браузер мне пишет

Failed to load http://localhost:9000/: No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://127.0.0.1:8000' is therefore not allowed access.

При этом сервер, слушающий порт 9000 на локалхосте прекрасно получил запрос и распечатал мне его в консоли.

yetanother2018 ()
Ответ на: комментарий от yetanother2018

Если идет запрос на сторонний ресурс, должно быть явное разрешения домена-отправителя

Так домен отправитель уже и так явно разрешил, когда поставил картинку со счётчиком.

ls-h ★★★ ()
Ответ на: комментарий от yetanother2018

Что значит «явно разрешил» в данном случае? Каким образом?

Есть сайт А. На нём используется картинка (скрипт, css, не важно) с сайта Б. Когда ты открываешь сайт А, открывается и картинка с сайта Б и сайт Б узнаёт (через referer), что ты был на сайте А. Если что-то с сайта Б есть на очень большом количестве сайтов, то можно отслеживать перемещение пользователя.

Как я понял, ты предлагаешь некий механизм, который бы запрещал/разрешал передачу referer при подгрузке сторонних ресурсов. Я правильно понимаю, ты хочешь это сделать, например, как некую опцию тега, вроде <img src=«siteB.com/img.jpg» referer=«yes» /> (по дефолту - no), чтобы referer не передавался без явного указания? Но тогда владелец сайта A будет явно прописывать такое разрешение.

Или ты хочешь это запретить на уровне браузера для всех сайтов?

ls-h ★★★ ()
Ответ на: комментарий от yetanother2018

Что значит «явно разрешил» в данном случае? Каким образом?

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

Ну и посетитель тоже - и он должен сам решать, можно ли его отслеживать. Для этого есть соответствующие настройки веб-обозревателя (типа, «Принимать куки со сторонних веб-сайтов» и пр.).

vinvlad ()
Ответ на: комментарий от yetanother2018

Что значит «явно разрешил» в данном случае? Каким образом?

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

Sawatari ()
Ответ на: комментарий от Sawatari

Явно разрешил - значит разместил у себя на странице элементы со сторонних ресурсов.

А это предполагает, что сторонний элемент передает данные с места своей установки на сторонние ресурсы? Я должен где то с этим согласится? В письменном виде?

yetanother2018 ()
Ответ на: комментарий от ls-h

Но тогда владелец сайта A будет явно прописывать такое разрешение.

Пусть прописывает, в чем проблема?

Или ты хочешь это запретить на уровне браузера для всех сайтов?

По умолчанию — да, как это и декларируется но не выполняется в CORS

yetanother2018 ()
Ответ на: комментарий от yetanother2018

А это предполагает, что сторонний элемент передает данные с места своей установки на сторонние ресурсы? Я должен где то с этим согласится? В письменном виде?

Ты (посетитель сайта) соглашаешься с этим или нет путем соответствующей настройки своего веб-обозревателя.

А CORS - это вообще про другое...

vinvlad ()
Ответ на: комментарий от yetanother2018

Читаю

по умолчанию запрещает междоменные запросы.

Но на самом то деле, по-умолчанию запросы отправляются, только ответы блокируются

Ты неправильно понял прочитанное или не там читал. Решает, принимать запросы с какого-то другого домена или нет, сторона получателя. И современные веб-обозреватели «уважают» это решение.

CORS - вот про это...

vinvlad ()
Ответ на: комментарий от yetanother2018

lol, а почему получатель должен это делать заголовками для браузера, если он может просто отдать ошибку?

К примеру, чтобы «вредоносный» Javascript-код не ломился постоянно на твой домен с чужого веб-обозревателя, который разглядывает в это время какой-то сайт с уязвимостью. Разок его отфутболил в ответ на OPTIONS-запрос - и все.

vinvlad ()
Ответ на: комментарий от vinvlad

К примеру, чтобы «вредоносный» Javascript-код не ломился постоянно на твой домен с чужого веб-обозревателя,

Не понял. В каком смысле «на домен»? На сервер что-ли? А как он может «ломится» туда, и какое это отношение к кроссдоменным запросам имеет? Запрос то все равно на сервер поступает

yetanother2018 ()
Ответ на: комментарий от yetanother2018

Не понял. В каком смысле «на домен»? На сервер что-ли?

Да на сервер.

Cross-Origin Resource Sharing (CORS) — механизм, использующий дополнительные HTTP-заголовки, чтобы дать возможность агенту пользователя (веб-обозревателю) получать разрешения на доступ к выбранным ресурсам с сервера на источнике (домене), отличном от того, что сайт использует в данный момент.

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

vinvlad ()
Ответ на: комментарий от vinvlad

Да на сервер.

И что может сделать ««вредоносный» Javascript-код» серверу?

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

Мы опять тут возвращаемся к вопросу, почему сервер их вообще отдает если не хочет, и при чем тут браузер и его «милости»?

yetanother2018 ()
Ответ на: комментарий от yetanother2018

... хотя насчет картиночек - это я загнул (пока вроде разрешают воровать). Но точно - такое «согласование» осуществляется при выполнении Javascript-ом AJAX-запросов (XMLHttpRequest) и при использовании Fetch API.

vinvlad ()
Ответ на: комментарий от yetanother2018

Мы опять тут возвращаемся к вопросу, почему сервер их вообще отдает если не хочет, и при чем тут браузер и его «милости»?

https://developer.mozilla.org/ru/docs/Web/HTTP/CORS

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

vinvlad ()
Ответ на: комментарий от yetanother2018

Все что Вы говорите не имеет отношения к сабжу

Это CORS не имеет отношение к сабжу! ))))))))

Читать надо было более внимательно мои посты (про настройки веб-обозревателя). Ты просто зациклился на CORS-е )

vinvlad ()
Ответ на: комментарий от yetanother2018

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

vinvlad ()
Ответ на: комментарий от keir

Или вы хотите чтобы на сайте site.com грузились данные только с домена site.com

Почему какие-то там «данные», исключительно явно запрошенная страница. HTTP для гипертекста!

t184256 ★★★★★ ()

вайфаем делают энцефалограмму мозга и в зависимости от того что на экране вызывает определенную реакцию, то и суют

anonymous ()
Ответ на: комментарий от t184256

Или вы хотите чтобы на сайте site.com грузились данные только с домена site.com

Почему какие-то там «данные», исключительно явно запрошенная страница. HTTP для гипертекста!

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

vinvlad ()
Ответ на: комментарий от vinvlad

Бери выше, от раздачи картинок, видео и CSS по HTTP. Веб скатился тогда, когда кто-то раздал по HTTP первую картинку.

И вообще, зачем городить CDN, если все, что ты делаешь - - отдаёшь гипертекст?

t184256 ★★★★★ ()