Разработчик игры слил $220 в Google ads на установки ботами

Статья описывает кейс разработчика, потерявшего бюджет в Google Ads из-за фрода и специфики атрибуции. Платформа засчитала конверсии, которые не подтвердились в Google Play Console, так как алгоритм учитывает установки без прямой связи с кликом. Главный вывод: Google Ads может наливать ботов не меньше пуш-сетей. При работе за инсталы важно жестко контролировать качество трафика и сверять аналитику с бэкендом, в то время как Facebook на данный мо…

➡️ Читайте на сайте: https://aff.top/blog/razrabotchik-igry-slil-220-v-google-ads-na-ustanovki-botami

🧠 Ещё больше инсайтов → в канале AFF.top

Google расширил Data Manager

Google интегрировал инструмент Data Manager в GA и DV360 для удобной передачи first-party данных, что дает рост ROAS до 26%. Для арбитража трафика прямого применения у офлайн-данных нет, однако инструмент можно использовать для манипуляции алгоритмами: отправка синтетических конверсий через API поможет скорректировать оптимизацию и направить автостратегии на поиск нужной аудитории.

➡️ Читайте на сайте: https://aff.top/blog/google-rasshiril-data-manager

🧠 Ещё больше инсайтов → в канале AFF.top

Can you drop the HTTP-to-HTTPS redirect once HSTS is set?

The optimization "HSTS handles the upgrade, so I can remove my 301 redirect" contains a fatal first-visit gap. HSTS (HTTP Strict Transport Security, RFC 6797) is a Trust On First Use mechanism. The browser only learns your HSTS policy by receiving the Strict-Transport-Security header — and it can only receive that header over a successful HTTPS response. A browser that has never visited you, or whose cached policy expired, has no instruction yet.

So the very first request a new client makes to http://yoursite must still be answered. If you removed the redirect, that plaintext request either fails or is served over HTTP, exactly the window an on-path attacker uses for SSL-stripping. The redirect is what gets that first connection onto HTTPS so the HSTS header can ever be delivered.

The only way to close the first-visit gap entirely is the preload list (compiled into the browser), and even that requires you to keep serving HTTPS correctly. The redirect stays either way.

— HSTS is Trust On First Use over HTTPS
— First plaintext request still needs answering
— Removing the redirect reopens SSL-stripping

Further reading: RFC 6797, §8.3 and §14.6.
Bottom line: Keep the HTTP-to-HTTPS redirect. HSTS protects return visits; the redirect protects the first one.

Why can an HSTS header with the wrong directive be worse than no header at all?

HSTS (RFC 6797) is usually framed as pure upside: force HTTPS, prevent downgrades. But the header is a binding, browser-enforced commitment with a state that outlives the response, and two directives turn it into a foot-gun: includeSubDomains and a long max-age.

Consider the failure mode. You set Strict-Transport-Security: max-age=63072000; includeSubDomains on example.com. Every browser that has seen this header will now refuse plain HTTP — and refuse to bypass certificate errors — for two years, across every subdomain, including ones you do not control today and any you create tomorrow. If a subdomain later needs to serve HTTP (a legacy device, a third-party tool, an acquired property with a broken certificate), it is unreachable for returning visitors. There is no server-side undo for browsers that already cached the policy; you can only serve max-age=0 and hope each affected client revisits the apex over HTTPS to clear it.

The sharper trap is asymmetric reach. The policy is keyed to the host that sent it, but includeSubDomains projects it downward onto hosts that never sent any header and may not be ready. The commitment is made by the parent, paid by the children.

Evidence vs. speculation: the clearing mechanism (max-age=0 on a successful HTTPS response) is normative in RFC 6797 §6.1.1; the operational pain of subdomain lockout is a recurring, documented incident pattern.

Further reading: RFC 6797 §6.1, §8.1, §11.

Bottom line: HSTS state is sticky and client-side — add includeSubDomains only after auditing every present and future subdomain's TLS readiness, because the only rollback is max-age=0 plus a hope that each browser revisits to clear the cached commitment.

Xchat удалён из App Store и Google play

Google Play и App Store удалили мессенджер XChat, продвигавшийся Илоном Маском как сервис с шифрованием без рекламы. Несмотря на трафик из X.com, приложение исключили из сторов. Причиной мог стать отказ от трекинга, что мешает монетизации и антифрод-системам площадок. Кейс доказывает: отсутствие рекламных инструментов делает софт уязвимым, а медийная поддержка не спасает продукт, если его политика нарушает правила маркетплейсов.

➡️ Читайте на сайте: https://aff.top/blog/xchat-udalen-iz-app-store-i-google-play

🧠 Ещё больше инсайтов → в канале AFF.top

В Facebook Ads Manager появилась метрика Creative Diversity

Meta представила метрику Creative Diversity для оценки разнообразия креативов. Алгоритм Generative Recommender анализирует стиль, тему, тип хука и формат объявлений. Простое изменение цвета или ракурса теперь не работает: система пессимизирует похожие подходы. Для эффективного залива арбитражникам придется тестировать принципиально разный контент, чтобы алгоритмы лучше находили аудиторию. Инструмент выйдет из беты до конца года.

➡️ Читайте на сайте: https://aff.top/blog/v-facebook-ads-manager-poiavilas-metrika-creative-diversity

🧠 Ещё больше инсайтов → в канале AFF.top

Твои переписки с ChatGPT читают люди

OpenAI привлекает подрядчиков для ручного анализа диалогов с ChatGPT, чтобы повысить качество модели. В ходе проверки конфиденциальная информация пользователей попадает к третьим лицам. Для сферы CPA это несет прямые риски: уникальные связки, креативы и структуры лендингов, созданные нейросетью, перестают быть приватными. Главный вывод — любая информация, переданная ИИ, может быть изучена извне, что ведет к быстрому выгоранию профитных подходов …

➡️ Читайте на сайте: https://aff.top/blog/tvoi-perepiski-s-chatgpt-chitaiut-liudi

🧠 Ещё больше инсайтов → в канале AFF.top

Does your browser actually reject a revoked certificate?

The assumption "if a certificate is revoked, my browser will block it" describes how revocation is supposed to work, not how it does. Two legacy mechanisms — CRLs (Certificate Revocation Lists, RFC 5280) and OCSP (Online Certificate Status Protocol, RFC 6960) — both fail open. CRLs grew too large to download routinely. OCSP checks add latency and leak browsing to the CA, so browsers adopted soft-fail: if the responder is slow or unreachable, the browser proceeds as if the certificate were valid.

Adam Langley's well-known critique called soft-fail revocation "useless," because any attacker capable of using a stolen certificate can also block the revocation check — the same network position enables both. Chrome largely disabled live OCSP years ago in favor of CRLSets, a curated push of high-priority revocations; Firefox built CRLite, a compressed Bloom-filter structure pushed to the browser.

These push-based systems work because the browser already has the answer before the handshake, so there is nothing for an attacker to block. But they cover a subset of revocations, not all.

— CRL/OCSP fail open by default
— Soft-fail is defeatable by the same attacker
— CRLSets/CRLite push a curated subset

Further reading: Langley, "Revocation checking and Chrome's CRL" (2012); Firefox CRLite.
Bottom line: Live revocation checking is mostly theater. Browser-pushed lists and short certificate lifetimes are what actually protect you.

What actually lets Firefox check revocation for the entire Web Public Key Infrastructure in a few megabytes?

The answer is CRLite, and the mechanism is a worked example of probabilistic data structures meeting a real security need.

Revocation at web scale is a data problem. Certificate Revocation Lists (CRLs, RFC 5280) are large and stale; OCSP (RFC 6960) is per-query and privacy-leaking. CRLite, from a 2017 IEEE S&P paper by Larisch et al. and now shipping in Firefox, asks: can we push the full revocation state of every publicly-trusted certificate to the client?

The enabling insight is Certificate Transparency. Because CT logs (RFC 6962) enumerate essentially all issued certificates, the universe of certificates is knowable. CRLite encodes the revoked subset against that known universe using a cascade of Bloom filters. A single Bloom filter has false positives; a cascade layers additional filters trained only on the items the previous layer got wrong, driving the aggregate false-positive rate to zero over the known set.

The result compresses hundreds of millions of certificates' revocation status into roughly 1–10 MB, with daily delta updates. Lookups are local, instant, and leak nothing to the CA.

The constraint: it only works for certificates the client's filter knows about, so it depends on comprehensive CT coverage and timely updates.

Further reading: Larisch et al., "CRLite" (IEEE S&P 2017); RFC 6962; Mozilla's CRLite rollout posts.

Bottom line: CRLite turns revocation into a local lookup by exploiting CT's complete certificate census plus a zero-false-positive Bloom filter cascade.