В Telegram Ads добавили Banner in Bot

В Telegram Ads появился формат Banner in Bot для показа рекламы внутри ботов с аудиторией от 1000 человек. Инструмент таргетируется не на площадки, а на пользователей — по интересам, номерам телефонов и подпискам. Пока доступны только текстовые креативы по ставкам Target Users. Новинка позволяет напрямую через стандартный кабинет охватывать целевую аудиторию прямо в их диалогах с ботами.

➡️ Читайте на сайте: https://aff.top/blog/v-telegram-ads-dobavili-banner-in-bot

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

Anthropic готовит к запуску Claude Money

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

➡️ Читайте на сайте: https://aff.top/blog/anthropic-gotovit-k-zapusku-claude-money

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

Meta ограничивает расходы на токены для сотрудников

Meta ввела внутренние лимиты на использование ИИ из-за резкого роста расходов: в 2026 году только на сотрудников заложены миллиарды долларов, а общий бюджет на ИИ-инфраструктуру оценивается в 130–145 млрд. Вывод простой: даже у Big Tech ИИ перестал быть бесплатной игрушкой и требует жёсткого контроля затрат.

➡️ Читайте на сайте: https://aff.top/blog/meta-ogranichivaet-raskhody-na-tokeny-dlia-sotrudnikov

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

upgrade-insecure-requests or block-all-mixed-content: which CSP directive fits a migration?

When you move a site to HTTPS but legacy resources still reference http://, which Content Security Policy tool should you reach for? They solve adjacent but distinct problems.

upgrade-insecure-requests rewrites in-document HTTP subresource URLs to HTTPS before the request is made. It is forgiving: if the resource exists over TLS, it loads; the user sees no breakage. This is the migration aid — it papers over hardcoded http:// references during transition.

block-all-mixed-content does the opposite: it refuses to load any mixed content, optionally including the passive kind browsers normally allow. It is the enforcement tool — useful once you believe the site is clean and want a hard guarantee against regression.

Note that browsers now auto-upgrade many mixed requests regardless, and block passive mixed content in stricter modes, so these directives increasingly codify behavior the browser trends toward anyway.

— Use upgrade-insecure-requests during and shortly after migration.
— Switch to block-all-mixed-content once you want regression protection.
— Audit with the browser console's mixed-content warnings before flipping to block mode.

Further reading: W3C Mixed Content specification; CSP Level 3.

Bottom line: upgrade is the gentle migration crutch; block is the strict post-migration guardrail — sequence them, do not pick one forever.

Is SHA-1 still acceptable for internal or non-critical certificates?

The rationalization "SHA-1 is fine for internal certs, no one's attacking those" misjudges both the cost of the attack and the role of the signature. SHA-1 is the hash over which a CA computes a certificate's signature. A collision — two different inputs hashing to the same digest — lets an attacker craft a benign certificate signed by a CA and a malicious one sharing that signature, transplanting the trust.

This stopped being theoretical in 2017 when Stevens et al. produced SHACK/SHAttered, the first practical SHA-1 collision, and in 2020 Leurent and Peyrin demonstrated a chosen-prefix collision for roughly $45,000 of compute — directly applicable to certificate forgery. "Internal" does not change the math; it only changes who you imagine the attacker to be, and chosen-prefix collisions are now within reach of well-resourced adversaries and falling in price.

Browsers stopped accepting publicly-trusted SHA-1 certificates in 2017. The mandated baseline is SHA-256 or stronger (the SHA-2 family). There is no security argument for SHA-1 signatures on any new certificate.

— Chosen-prefix SHA-1 collisions are practical and cheap
— Forged certificates are the direct threat
— SHA-256 is the floor everywhere

Further reading: Leurent & Peyrin, "SHA-1 is a Shambles" (2020).
Bottom line: SHA-1 certificate signatures are forgeable today. "Internal" is not an exemption; use SHA-256.

Claude Cowork, Claude Design объединили в один Claude

➡️ Читайте на сайте: https://aff.top/blog/claude-cowork-claude-design-obedinili-v-odin-claude

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

Microsoft планирует вставлять рекламу в игры

➡️ Читайте на сайте: https://aff.top/blog/microsoft-planiruet-vstavliat-reklamu-v-igry

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

Name Constraints or separate sub-CAs: how should you scope an intermediate's authority?

When you delegate issuance to an intermediate CA, how do you stop it from issuing for domains it should never touch? Two approaches bound the authority differently.

The Name Constraints extension (RFC 5280 §4.2.1.10) embeds permitted and excluded name subtrees directly into the intermediate certificate. A constrained sub-CA limited to .corp.example.com cryptographically cannot issue a trusted certificate outside that namespace — the path-validation algorithm rejects it. One intermediate, hard-scoped, enforced by every conforming client.

Issuing multiple separate sub-CAs instead relies on policy and operational discipline to keep each in its lane, with no cryptographic enforcement of scope. It offers flexibility but trusts process where Name Constraints trusts math.

The historical caveat: Name Constraints enforcement was patchy in older clients, which is why public CAs were slow to rely on it. In controlled internal environments where you know the clients, it is far more dependable.

— Use Name Constraints to cryptographically cage an internal sub-CA.
— Verify your client stack actually enforces the extension before relying on it.
— Reserve multiple sub-CAs for genuinely independent trust domains.

Further reading: RFC 5280 §4.2.1.10; RFC 9618 on constraint clarifications.

Bottom line: Name Constraints enforce scope in cryptography rather than policy — superior where clients honor it, which is most controlled internal fleets.

Is HTTP Public Key Pinning a strong defense you should deploy?

Older hardening guides still recommend "pin your public keys with HPKP for maximum security." Follow that advice and you will deploy a feature browsers removed. HPKP (HTTP Public Key Pinning, RFC 7469) let a site send a header committing browsers to accept only specific public keys for a set period. The intent was to stop misissued certificates from being usable against your domain.

In practice HPKP was a footgun with two failure modes. Hostage attacks: an attacker who briefly compromised a server could pin a key they controlled, locking out the legitimate owner for the pin's lifetime. Suicide: an operator who lost the pinned key, or failed to maintain a backup pin, bricked their own domain for every returning visitor — no recovery, no override. Chrome deprecated HPKP in 2018 and removed it; the broader ecosystem followed.

The properties HPKP aimed for are now served better by Certificate Transparency (detection of misissuance) and, for native apps where you control the client, application-level pinning with a managed update path.

— HPKP enabled hostage and suicide failures
— Browsers removed it in 2018
— CT plus app-level pinning replaced it

Further reading: RFC 7469; Chrome HPKP deprecation notice (2018).
Bottom line: Do not deploy HPKP — it no longer exists in browsers and was dangerous when it did. Rely on CT instead.