Pull to refresh

Comments 87

Настоящий детектив! Читал на одном дыхании.
если пост удалят — там этот Rees оправдывается, его кормят говном, в итоге дочкисыночки ставят точку:

https://monosnap.com/file/lsVKG15Q6LMQIb0xZYbf7etrDFcW1J
Это ещё не конец! Они там объясняют, что этим пикселем они, оказывается, борются с недобросовестными конкурентами.

Ну там типа: мы взломали вашу сеть и засунули к вас в c:\windows\system32 нашу программу, но это не троян, нет-нет — это наш защитник, он вам помогает с вирусами бороться.

То есть теоретически, конечно, можно себе представить мир, в котором подобные «Робин Губы» существуют, но практически… Нет — ну кем нужно быть, чтобы в такое поверить? Шестилетним мальчиком?
Технически, есть трояны, которые выпиливают конкурентов. Вероятно, чтобы у пользователя было меньше поводов заподозрить неладное (тормоза и вот это вот всё).
допустим Rees тоже привел аргументы. Но они никак не оправдались и не прокомментировали достоверность этой статьи. Т.е. лучшая защита — это нападение. Фактически они признали, что сделали подлог, потому что решили, что конкурент делает то же самое. Обвинение не снимается.
Интересно что всё таки легче написать нормальный алгоритм рекомендаций или вот этот хитрый хак?
Вопрос некорректен. «Нормальность» алгоритма — вещь не абсолютная, а относительная. Если кто-то потратил на разработку, условно, 100500 денег — то вам нужно потратить сравнимое количество, чтобы сделать так же хорошо. А если такого нет, то, может и за 100 сойдёт.

А написание же хака — от стоимости алгоритма не зависит. Пока кто-то не проведёт исследование и не обнаружит его — можно поступать достаточно грубо.
Какого только говна не напихают в код, чтобы отжать вкусного клиента.
так они и клиента в итоге имеют, не только конкурентов. мерзкие людишки
по факту да; меня ещё очень разозлил прикол увода потенциального покупателя в RTB сети
Уважаемое сообщество Хабра, поделитесь вашим способом борьбы с такими вещами. Такие «подлые» тесты довольно тяжело выявить, особенно имея в руках только Google Analytics. Нам пришлось очень детально анализировать логи на Scala/Spark/Hadoop чтобы раскрыть преступление.

Как можно это сделать проще?
Смотреть на запросы в консоли отладки и анализировать всё, что непонятно?
В консоли не было видно, скрипт блокировал вызовы, когда открыта консоль :-(
если остановиться на доверии к магазину, то загружать js код только той рекомендательной системы которая будет использоваться для конкретно этого юзера

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

Как я понимаю, при этом сразу образуется перекос в размерах сегментов.

Ну да, но и в данном случае он был.

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

Согласен, но все равно это решение не обеспечиает 100% чистоту и беспристрастность.

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

Этого не достаточно. Нужно сегментировать аудиторию для АБ тестов на сервере, включать функциональность тоже на сервере, а куку для сегментации делать недоступной из js.
Ещё неплохо все внешние скрипты 1) запускать во фрейме 2) грузить со своего домена, чтобы исключить подмену скрипта не добросовестным партнером

Кажется, следующая статья RR будет называться «Как обнаружить атаку, анализируя логи через Scala/Hadoop» ;)
приходит в голову механизм подписи значения кукисов

Как вариант — разносить по разным доменам (суб-доменам)… + SOP + не юзать кросс-доменные куки ...

Может быть может помочь правильная настройка Content-Security-Policy со стороны магазина
Предлагаю написать блокиратор хаков от Rees и подговорить магазины разводить эту компанию на 100 000 рублей за проваленные тесты.
UFO just landed and posted this here
Добавьте тег «классический детектив».
Отличное расследование и шикарная подача материала.
Какая милота.
Вспомнилась война читов в тестах для видеокарт.
Утопить бы репутацию этих нехороших людей поглубже, чтобы урок был для других.
А вот мне интересно — какими качествами надо обладать, чтобы на такое пойти. Я не про моральные, тут всё понятно, я про интеллектуальные. Ну ведь вскрывается же, как оказалось, довольно просто.
Анализом статистики поймали необъяснимые девиации.
Код доступен — довольно простой реверсинжениринг. Я про картинку правда не понял.

Теперь просто в порошок растёрли свою репутацию.
Не так уж и просто. Это просто глядя на рекомендации видно что такого не может быть. А если бы рекомендации были в целом похожие (примерно равные соперники), то и не полезли бы так глубоко изучать.

Плюс, судя по комментариям, там было противодействие отладке (скрипт отключался при открытой консоли браузера).

Да и еще если выбран регион Москва(у нас он по умолчанию), то тоже код не работал.
Я не разработчик, но я так понял, что защита от дебага и проверка региона срабатывала только в плане запросов. То есть из москвы и под дебагом запросов не видно. Но код доступен.
Там 2 части кода: первая запрашивает и исполняет код в картинке, вторая часть кода в картинке и меняет куку. Первая часть видна и видно что она не будет запрашивать картинку с открытой консолью и для склада 464, а вот вторую вообще не видно и нам очень повезло что удалось ее поймать.
Да найти такой код не сложно, все-таки там явные признаки сокрытия логики которые бросаются в глаза. Но сам факт, что приходится вычитывать чужой яваскрипт в поисках закладок вводит в уныние.

Вот ставишь себе код фейсбука, и что, искать там ошибки? Почему мы ему должны доверять теперь?
UFO just landed and posted this here
Скажите, очевидно ли что они пытаются уйти от ответа?

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

Их вина абсолютно очевидна, ради интереса проверил картинку — там действительно при дешифровке получается код, меняющий в куке сегмент для домена dochkisinochki.ru. В их опровержении они говорят что url с картинкой отдаёт 403, но это не так — сторонний сервис подтверждает что по крайней мере 5 дней назад они отдавали код смены сегмента.
По всей видимости автор того поста в мордокниге не знает слова «хабро-эффект».
Ну и считает окружающих идиотами заодно.
Автор делает хорошую мину при плохой игре и очевидно пытается спасти репутацию.

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

Похоже, что сейчас у них любой запрос на поддомен "api." возвращает 403.

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

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

Они пытаются придраться к деталям интеграции на магазине, при этом весь код интеграции все еще на сайте в том виде, в котором он был на момент теста и любой может проверить как он работает. Все, к чему они апеллируют, что есть конфликт имен модулей между магазином и кодом Retail Rocket и якобы это позволяет нам менять куку. Во-первых, нет: JavaScript исполняется последовательно, а код Retail Rocket подключен значительно ниже кода деления трафика магазина (сегментатор магазина – ~65 строка, код Retail Rocket – ~2500 строка) и момент его срабатывания уже поздно что-то там подменять, так как сегмент пользователя уже определен в куке (наш код ни к каким кукам теста не обращается). Это легко проверить в дебаггере (наш код там работает и не зашифрован). Во-вторых, мы все знаем — чтобы сменить куку никакие “конфликты” не требуются, берешь и меняешь, вот прямо как они сделали:
document.cookie="rr-VisitorSegment_Rec=3:2; domain=.dochkisinochki.ru; path=/; expires=Mon, 25 Sep 2017 10:15:20 
+0000";document.cookie="DS_SM_rrSegmentRecommendedABC=B; domain=.dochkisinochki.ru; path=/

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

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

И стоило оно того?
тут есть проблема, всё прахом идёт только в кино и мультике. Реальность изобрела ребрендинг и другие способы по 100 раз впаривать унылую херню.

Какая ещё репутация прахом. Менеджмент большинства клиентов не поймет всех этих объяснений. Rees легко смогут заболтать этот случай.

Вот только ничего особенного у них в этот движок не вложено.

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

Имеет ли смысл? Помните «дизелгейт» VW в США?
Получается, что для любого сегмента пользователя отрабатывали оба кода?

и могли таскать друг у друга сессии
но это же дыра, блин,

если сейчас этой дырой воспользовался REES, то в другие разы ей мог пользоваться RR
как я понял, сегментатор авторства RR — тогда вообще все не так однозначно (ц)

Ежу понятно, что только один код для одного сегмента должен отрабатывать — тогда таскать сессии будет невозможно
Еду, может, и понятно, а веб-разработчикам — нет. Что мешает выдавать при первом входе Куку, отправляющая пользователя в нужный сегмент и грузящую затем только скрипты одного из двух конкурентов — неясно абсолютно.
а если обратная ситуация — скрипт меняет куку и отправляет бесперспективного юзера к конкуренту?
Для этого он должен её как-минимум увидеть. Понятно, что скрипт-сегментатор должен жить на отдельном домене, выставлять куку только для этого домена и шифровать её. Название куки можно тоже сделать псевдослучайным… К счастью — это всё стандартные вещи, которые никаких новых стандартов 2020 года не требуют…

Мы увидим юридические последствия этой аферы? Или все спустится на тормозах?

Да, мы намерены идти как минимум в ФАС.
Честно говоря, я бы на месте владельцев магазина, после такой истории выкинул бы из сайта обе указанных конторы, потому что как покупатель, я ни за что не буду делать покупки и светить платежные данные на взломанном сайте.

О чем вы? При чем тут взлом сайта?

Я глупый испуганный покупатель, я не знаю, что такое куки и ява-скрипт, из всей статьи я вижу ключевые фразы: название магазина + атака + афера + подмена чего-то. И вы хотите, чтобы я после этого указывал вам номер своей карты ?? Боюсь, что если скандал будет дальше разгораться в публичной сфере, то больше всего потерь может понести сам магазин. Рокет должен был предъявить это все владельцам магазина, а если хотелось публичного обсуждения — то убрать ссылки на магазин.
В первую очередь мы при личной встрече с представителями интернет-магазина еще более детально, чем в статье, изложили все известные нам факты и наши наблюдения. Вместе с техническим специалистом магазина воспроизвели, как меняется сегмент любого пользователя на сегмент REES. Получили разрешение на использование имени магазина в статье. Затем мы тоже самое проделали с 4 разными сервисными компаниями (дружественными нам и не очень), и только после этого опубликовали нашу статью.
зря минусуете, посмотрите на эту ситуацию глазами простого покупателя, а не технического специалиста.
У простого покупателя память — не работает от слова «вообще». Бояться чего-либо он будет ровно пять минут. Потом всё забудет и ему всё будет пофигу. Ну хорошо, пусть не пять минут, а пять дней — в любом случае это потери — ничто на фоне того, что можно было бы потерять…
Абсолютно неправы. Зло должно быть наказано, а доброе дело поощрено. Это очень важно
АБ-тесты нужны там, где людям пытаются продать хлам. Я огорчен теми, кто этим до сих пор занимается.

Решение — просто делать клевые проекты.
АБ-тесты нужны там, где людям пытаются продать хлам. Я огорчен теми, кто этим до сих пор занимается.
Ок, принято. Выкидываем всё, что разработано Гуглом и Майкрософтом, Каноникалом и Эпплом, перестаём пользоваться Яндексом и Файрфоксом… слушайте — а как вы тут комментарий написали, если ни Хром, ни Оперу не пользуете и ни с МакОС, ни с Windows, ни с Linux не общаетесь?

Решение — просто делать клевые проекты.
Осталось понять как вы узнаете, что ваш проект — клёвый, если ни с чем его не будете сравнивать…
Так ознакомьте же нас со своими клёвыми проектами.
Интересно, насколько сложно такое до суда довести? Обвинения и доказательства очень серьезные.
Для нас это будет новый и увлекательный опыт, обязательно расскажем о нем сообществу.
очень интересная история

как бороться?
все скрипты должны быть под контролем магазина?
валидация скриптов всеми участниками?
контроль качества сегментации арбитром?
все скрипты должны быть под контролем магазина?

Функциональность скриптов должна быть прозрачной, любое сокрытие того, что делает код, должно быть исключено.

контроль качества сегментации арбитром?

Пока нам кажется достаточным, чтобы трафик делился ровно, а пользователи не меняли сегмент. Это можно отследить через google analytics.

валидация скриптов всеми участниками?

Боюсь, что такое недоверие сильно замедлит разработку всех проектов. Думаю, будет достаточно, чтобы сервис всегда рисковал своей головой, если он будет замечен хотя бы в сокрытии функционала кода, не говоря уже о действиях которые несут вред магазину: отправка пользователей в другие системы без ведома магазина или атаки на тесты магазина. Да и вообще всего, что намерено наносит вред.
Увы, это не первый случай отсутствия какой-либо корпоративной этики. Проигрывать тоже надо уметь. А ещё у Rees46 название идиотское. Ну правда, как-то можно это объяснить? Что значит цифра 46? Почему Rees? Почему не «Абырвалг65»? Это они надписи на футболках придумывают?
достаточно интересная ситуация, молодцы все: и те, кто умудрился внедрить такой обман (молодцы — в хорошем смысле, т.к. такое еще надо было придумать и более того, смочь реализовать) и тем более вы, т.к. смогли это расследовать, т.к. это явно было очень не просто…
ну а если конструктивно: проблема в том, что заинтересованным лицам доступен контроль над данными, влияющими на ход тестирования, а именно идентификатор сегмента, это и есть узкое место и в корне не правильно.
моя мысль следующая: если мы допускаем, что сегментатор — это неподвластная истина, то назначать сегменты может только он, решается это следующим образом: у пользователя при первом заходе (если в куках еще нет) генерируется guid, обычный такой случайный гуид, далее, например, суммируется со счетчиком из GA и отправляется на сервер. если по этой паре не назначен сегмент — сервер его назначает и хранит у себя, никому не говоря, а по этому сегменту уже сам направляет на обработку в необходимый экзепляр…
в случае умышленной подмены guid-а мы просто получаем нового пользователя со снова рандомным сегментом, подтасовать в этом случае (опять-таки я учитываю «честный» сегментатор) невозможно.
дополню свою мысль маленьким отступлением. моя парадигма проста: категорически нельзя хранить на клиенте те данные, которые могут повлиять на то, что, чем не предназначено управлять клиенту. и тем более на эти данные ориентироваться серверу. это я понял еще со времен лицея, где мне повезло и в лицее (как части ВУЗа) была сеть на Novell Netware, было одно приложение (еще под DOS), которое использовалось для публикации свои работ по информатике (маленький невзрачный прототип GitHub'а). я тогда любил и изучал ассемблер и это приложение мне было интересно. выяснилось, что флаг доступа «IsRoot» устанавливался внутри приложения и сервер после подключения ему «верил», нетрудно догадаться, чего можно добиться, если, например, в приложении «Сбербанк онлайн» будет подобное))
Вы их просто уничтожили. Есть шанс их засудить? Ну там мошенничество…
Sign up to leave a comment.