From the endpoint to the prompt: a unified data security vision in Cloudflare One

Post Syndicated from Alex Dunbrack original https://blog.cloudflare.com/unified-data-security/

Cloudflare One has grown a lot over the years. What started with securing traffic at the network now spans the endpoint and SaaS applications – because that’s where work happens.

But as the market has evolved, the core mission has become clear: data security is enterprise security.

Here’s why. We don’t enforce controls just to enforce controls. We do it because the downstream outcomes are costly: malware, credential theft, session hijacking, and eventually the thing that matters most: sensitive data leaving the organization. What looks like a simple access policy can be the first link in a chain that ends in incident response, customer impact, and reputational damage.

So when you take a step back, most security programs – even the ones that look different on paper – are trying to answer the same questions:

  • Where is sensitive data?

  • Who can access it?

  • What paths exist for it to move somewhere it shouldn’t?

That’s the backbone of our data security vision in Cloudflare One: a single model that follows data across the places it moves, not a pile of siloed controls. That means:

  • Protection in transit (across Internet + SaaS access)

  • Visibility and control at rest (inside SaaS)

  • Enforcement in use (on endpoints)

  • And now, coverage at the prompt (as AI becomes a new interface to enterprise data)

Think of these as one connected system: visibility tells you what’s happening, controls constrain where data can move, and enforcement closes the last-mile gaps when content leaves an app. That’s the endpoint-to-prompt problem: data moves faster than product boundaries, so policy needs to follow the data, not the tool.

In this post, we’ll walk through a set of updates that push that vision forward – from browser-based Remote Desktop Protocol (RDP) controls, to operation-level logging, to endpoint data loss prevention (DLP), to AI security scanning for Microsoft 365 Copilot. 

Remote access without data sprawl: browser-based RDP clipboard controls

Browser-based RDP is a practical way to provide remote access when you can’t assume a managed endpoint or installed client – common for contractors, partners, and occasional access workflows. Cloudflare One’s browser-based RDP adds visibility and policy controls to that access. But once you’re delivering a full RDP experience in the browser, the question becomes simple: how granular are your controls over where data can move, especially via the clipboard?

Today, we’re adding a setting that directly protects data: clipboard controls for browser-based RDP. With this new feature, security and IT administrators will now be able to decide whether their users can copy or paste information between their local device and the browser-based RDP session.

Clipboard restrictions are a perfect example of the productivity-security tradeoff. If users can’t copy and paste in the workflow they rely on, they’ll route around the control, whether it’s by taking screenshots, retyping data, or shifting work to unmanaged tools. Clipboard controls let you be precise: allow the workflow where it’s safe, and block it where it isn’t.

With clipboard controls in browser-based RDP, administrators can enable the copy/paste workflow users expect while enforcing granular control over directionality and context. For example, if users access a customer support portal that contains sensitive customer information, you might allow copy/paste into the session for productivity, but block copy/paste out of the session to prevent data from landing on unmanaged endpoints.

This functionality is now available in Cloudflare One and can be configured as a new setting within Access Application Policies for browser-based RDP apps.

Visibility without guesswork: operation mapping in logs

While remote access controls reduce risk, to tune them well, you also need to understand the specific actions users are taking inside SaaS apps.

We use a process called operation mapping (detailed in a recent blog post) to give visibility to these actions and simplify the way customers write policies for SaaS services. Our mapping process takes various elements of an HTTP request and interprets them as a single operation, e.g. ‘SendPrompt’, in the example of ChatGPT. We collect multiple operations that perform similar actions into an Application Control, e.g., ‘Share’ or ‘Upload’. The [what?] is viewable in our HTTP policy builder, allowing for simple policy authoring. 

Today, we’ve taken that process a step further to enrich logs and provide greater visibility over how SaaS applications are being used in your organization – by extending that mapping into logging. Without any additional configuration, operations and application controls will now appear in log events for traffic that matches our operation maps.

In log details, you’ll now see both the application control group and the specific operation (e.g., SendPrompt for ChatGPT). This makes investigations and policy tuning faster.


The added context helps you understand usage patterns, accelerate forensic analysis, and spot potentially risky behavior, so you can tune policy with less guesswork and disruption to users.

Visibility is step one. To protect data in use, especially what moves through the clipboard, you also need enforcement on the endpoint.

Better endpoint protection: on-device DLP in the Cloudflare One Client

In a modern enterprise, sensitive information routinely moves from managed applications into unmanaged contexts – often via the clipboard. The risk isn’t only a file leaving the organization; it can be a snippet of proprietary code or a customer record pasted into an unauthorized large language model (LLM) or personal tool.

Cloudflare One already helps protect data in transit with Gateway and DLP, and provides visibility and control at rest through CASB and its API integrations. Now we’re extending coverage to data in use by bringing Endpoint DLP enforcement to the Cloudflare One Client, starting with high-signal workflows like clipboard movement, so data protection doesn’t stop the moment content leaves a browser tab.

That means sensitive data copied from a protected SaaS app doesn’t immediately become “policy-free” content the moment it hits the OS clipboard. With Endpoint DLP, teams can extend data protection to users’ fingertips without deploying a second agent or stitching together complex integrations.

For teams already using Cloudflare One for data protection, Endpoint DLP completes the model by adding a consistent enforcement layer for data in use.

This is the endpoint-to-prompt problem: if sensitive data can be copied locally, it can be pasted into an AI assistant just as easily. Once you protect data in use, the next question becomes unavoidable – what happens when that same data is transformed at the prompt?

AI visibility without blind spots: M365 Copilot scanning with API CASB

Last year, Cloudflare One and API CASB became the first to offer API integrations with OpenAI ChatGPT, Anthropic Claude, and Google Gemini offerings – and we’re not done yet. 

Starting today, customers using Cloudflare One’s API Cloud Access Security Broker (CASB) – which scans SaaS apps via API for common, yet risky security issues – can now analyze Microsoft 365 Copilot activity for data security issues, including chats and uploads that match DLP detection profiles.

Copilot findings surface with rich context (file references, profile matches, and interaction metadata) so teams can triage quickly instead of starting from raw audit logs.


A CASB Finding showing detection of a file used in M365 Copilot that matches an enabled DLP Profile

Customers can now see when Copilot activity includes sensitive data. For example, user prompts, Copilot responses, and uploaded files that match DLP detection profiles.

Microsoft 365 Copilot findings are available by default as part of the Microsoft 365 integration. If you already use this integration, go to Integrations in the Cloudflare One dashboard, update your Microsoft 365 connection, and start receiving Copilot findings. If you’re new to the integration, connect your Microsoft 365 tenant to gain visibility into Copilot usage and associated data security findings.

As AI product sprawl continues, we’ll be massively expanding coverage across additional AI assistants and core SaaS platforms throughout 2026 – stay tuned!

What’s next: unified data security in Cloudflare One

Over the last few years, enterprise security has expanded across more surfaces: SaaS, unmanaged endpoints, remote access patterns, and now AI assistants. But the objective – protecting sensitive data – hasn’t changed. The updates in this post reflect a single direction: consistent visibility and enforcement across data in transit, at rest, in use, and at the prompt. So policy follows data, not product boundaries.

Looking forward, our vision is broader than “data security features in data security products.” Over time, every Cloudflare One product will become more data-security-aware, with more data-oriented configurability, visibility, controls, and guardrails, built directly into the workflows teams already use across Access, Gateway, endpoint enforcement, and SaaS integrations. The goal is simple: wherever your users work and wherever data moves, Cloudflare One should be able to explain what’s happening and help you control it.

As the modern perimeter spreads across applications, browsers, endpoints, and AI prompts, patching together point solutions becomes harder to operate and easier to bypass. By building data security directly into Cloudflare One – from access controls to endpoint enforcement to AI visibility – and continuing to unify these layers, we’re helping teams build a clearer, more complete picture of their data risk and their data security posture from the endpoint to the prompt.

To get started, explore Cloudflare One or contact our team to learn more about the platform and these new features.

Поход към прогреса. И още банани

Post Syndicated from Емилия Милчева original https://www.toest.bg/pohod-kum-progresa-i-oshte-banani/

Поход към прогреса. И още банани

Когато политикът Румен Радев обяви, че тръгва на поход за бъдещето на България, слизайки от луксозен SUV BMW X7, значи за избирателите походът е Ком–Емине, а за него – смяна на предавките след Президентството. 

Онова, което мерят социолозите, за да го позиционират като победител във всички проучвания от началото на януари 2026-та досега, е не потенциалът на партия, а президентско-спасителският рейтинг на Румен Радев. Защото партия няма, програми (още) не са обявени и лицата в кандидатдепутатските листи не са известни. Основният политически капитал произтича от един лидер. Така както през 2001 г. дойде от невидимата корона на Царя, през 2009 г. – от мускулите и черната кожена тужурка на Бат’ Бойко, а сега идва от генералските пагони и ореола на „силната президентска ръка“, обещаваща нов ред и държавност.

За какво служат „шаситата“

Коалицията, с която Радев ще се яви на изборите на 19 април – „Прогресивна България“, беше регистрирана тази седмица в Централната избирателна комисия. Тя включва три партии: Политическо движение „Социалдемократи“ на Елена Нонева, Социалдемократическата партия на Тодор Барболов и Движение „Нашият народ“ на кмета на Кричим Атанас Калчев, който управлява 7-хилядната община пети мандат (до момента 19 години). 

Няма законова пречка формациите да са една или две. 

Тези три „шасита“ не носят реална електорална тежест и това е част от избрана стратегия. Така някои кандидати могат да бъдат вкарани през различните партии, без да се забележат (веднага). Формално това става чрез някаква квота, а Румен Радев няма да носи пряка отговорност за подбора им.

Имиджов трик е, че Радев не е начело на коалицията. Нейни съпредседатели са двама негови съветници от Президентството – бившият служебен премиер Гълъб Донев и бившият военен министър Димитър Стоянов. Това е знак за привидна дистанция – един вид, лидерът стои над партийните структури, поради което не се появи и при регистрирането ѝ. Позволява гъвкавост при разпределяне на местата по избирателните райони. Също така поради юридически или стратегически съображения понякога е по-удобно други лица да са формални председатели. 

В допълнение, това е част от изграждането на образа на бившия президент, който се представя като национален лидер, а не като партиен апаратчик – поне докато не покаже свой партиен продукт. Но клиентелистите вече са се наредили на опашка при бъдещия победител, така че бързо ще я сглоби.

Интересни са партиите в тази постпрезидентска сглобка. ПД „Социалдемократи“ беше един от трите мандатоносителя на „Продължаваме промяната“ заедно с ВОЛТ на Настимир Ананиев и „Средна европейска класа“ на Константин Бачийски. През 2022 г. именно ПД „Социалдемократи“ получи 90% от субсидията, въпреки че нямаше нито един депутат.

ПД „Социалдемократи“, което до октомври 2025 г. беше част от БСП – Обединена левица, има любопитна партийна история. Основано е през юни 2000 г. от Николай Камов, който е бил депутат от БСП, а до 1989 г. – виден комсомолски кадър. Един от учредителите ѝ е Ивайло Калфин, който като депутат от БСП в 37-мото Народно събрание по времето на кабинета „Виденов“ се отцепи от групата заедно с още депутати социалисти и всички вкупом напуснаха БСП. Сред тях бяха Филип Боков, Елена Поптодорова, Андрей Бунджулов, Росен Карадимов (днес председател на Комисията за защита на конкуренцията, КЗК) и др., известни като социалдемократи. По-късно те се присъединиха към Александър Томов, който тогава създаде Евролевицата, но го напуснаха през 2000 г.

(Любопитен факт е, че Карадимов беше назначен в Надзорния съвет на Българската банка за развитие през ноември 2022 г. именно от служебен кабинет с премиер Гълъб Донев и така бе върнат в активната политика. При издигането му за шеф на КЗК бе свързван с олигарха Делян Пеевски, санкциониран от САЩ и Великобритания за корупция.)

През 2005 г. ПД „Социалдемократи“ е в коалиция с БСП, която печели изборите и на власт идва Тройната коалиция (БСП, НДСВ, ДПС). Не подкрепят военната помощ за Украйна и са на страната на Радев за референдум за еврото.

Социалдемократическата партия (СДП) също е отломка от славно минало – на СДС. Дори е имала депутати в сините парламентарни групи и заместник-председател на парламента (Иван Куртев), когато е партньор на СДС през 1997 г., но е била отделна партия. През 2023 г. е част от коалиция „Заедно“, издигнала за депутати напусналите „Има такъв народ“ Ива Митева и Любомир Каримански. Сега се спекулира, че Митева ще бъде и в листите на „Прогресивна България“.

Румен Радев използва именно лозунга на СДП – „Свобода, справедливост, солидарност“, в поста си във Facebook в деня на регистрирането на коалицията:

„Прогресивна България“ е отговорът на очакванията на българите за демонтиране на олигархичния корупционен модел. На апела на мълчаливото мнозинство за свобода, солидарност и справедливост. За развитието на България като модерна и демократична европейска държава.

Като изключим този лозунг, СДП е някакъв призрак, а за партиен живот е трудно да се открие каквато и да било следа в последните двайсетина години.

Броени дни преди регистрацията пък кметът на Кричим отрече Радев да е искал формацията му за мандатоносител, каквато информация изтече през февруари. Калчев, който е бивш полицай, е известен с това, че печели всичките си мандати като кмет още на първи тур с добра преднина пред конкуренцията.

Неговата партия Движение „Нашият народ“ е бившата Движение „Нашият град“, появила се на местните избори във Варна преди 20 години и свързвана с икономическата група около „Химимпорт“. Журналистката Невяна Троянска, авторка на книгата „ТИМ. Отборът, който превзе България“, разкри във Facebook тази трансформация.

А освен тези прилики беше хванато, че логото на „Прогресивна България“ е едно към едно с логото на организацията RISE East of England Teaching Exchange. За капак се оказа, че има сдружение „Прогресивна България“ с ЕИК 207561851, регистрирано на 17.10.2023 г. според търговския регистър и регистъра на юридическите лица с нестопанска цел. Основната дейност на сдружението е защита на правата на ЛГБТ+ общността. Интересното в случая е, че Радев винаги се е заявявал като консерватор и защитник на традиционното семейство. 

Как тези негови ценности се вписват в социалдемократическата рамка? Едва ли решилите да гласуват за него 32,6% според последното проучване на „Алфа Рисърч“ се вълнуват от идеологическата мотивация. А и БСП, член на Партията на европейските социалисти, беше сред генераторите на кампанията срещу ратификацията на Истанбулската конвенция, както впрочем и самият Радев.

Какво става с неравенството?

Ако през всичките девет години като президент Румен Радев шикалкавеше със съдебната реформа, то неизменно акцентираше върху темата за неравенството. 

На един държавен глава му е простено да не отива по-далеч от показалеца си. Но един политик, устремил се към изпълнителната власт, е длъжен да продължи с отговорите – как ще намали неравенството, каква комбинация от финансови и социални мерки ще използва.

Първият тест от предстоящия „поход към прогреса“ е данъчната система. Ще настоява ли Румен Радев за замяна на плоския данък с прогресивно данъчно облагане? (Даже си върви с името на коалицията му.) Това предложение беше в арсенала на БСП. Но какво все пак ще предложи срещу неравенството, засега е неясно. Вероятно ще се съсредоточи върху повече държава в икономиката и по-големи социални разходи, така присъщи на БСП.

Остава големият въпрос дали предвожданата от Румен Радев нова политическа сила ще се заеме с някакви смели реформи и дали няма да ги подмени с обичайната смяна на караула в институции и съдебна система.

Намаляването на неравенството е свързано с прекъсване на олигархичните зависимости. Радев често използва банализираната фраза „борба с олигархията“, без да назове нито един олигарх. От трибуната на Софийския икономически форум през януари също се заяви за изгонване на олигархията от властта, за върховенство на правото и за отговорност в държавното управление – все познати лозунги.

ВМРО и БСП декларираха, че са с Радев, очаква се да го направят и от Алианса за права и свободи. ПП–ДБ са готови да си партнират с него за излъчване на парламентарната квота във Висшия съдебен съвет. 

Социологът Андрей Райчев не спира да предрича коалиция на формацията на Радев с ГЕРБ и Бойко Борисов. Не чрез Борисов или други силни говорители на ГЕРБ, а чрез партньора на партията – СДС, се дават знаци, че при определени условия би било възможно.

Най-стабилната конструкция е първият и вторият да управляват заедно, по някои теми бихме могли да работим с Румен Радев, основно темата за ориентацията на България – дали продължаваме по пътя, който избрахме преди години и задълбочаване на евроинтеграцията, или преосмисляме мястото, на което страната ни е днес. Ако вървим в една посока по този въпрос, има неща, за които ще можем да водим разговор.

Румен Христов, председател на СДС

Походът на Радев към властта започна. 
За тези, които не са на ΒΜW, има банани.

Claude Used to Hack Mexican Government

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2026/03/claude-used-to-hack-mexican-government.html

An unknown hacker used Anthropic’s LLM to hack the Mexican government:

The unknown Claude user wrote Spanish-language prompts for the chatbot to act as an elite hacker, finding vulnerabilities in government networks, writing computer scripts to exploit them and determining ways to automate data theft, Israeli cybersecurity startup Gambit Security said in research published Wednesday.

[…]

Claude initially warned the unknown user of malicious intent during their conversation about the Mexican government, but eventually complied with the attacker’s requests and executed thousands of commands on government computer networks, the researchers said.

Anthropic investigated Gambit’s claims, disrupted the activity and banned the accounts involved, a representative said. The company feeds examples of malicious activity back into Claude to learn from it, and one of its latest AI models, Claude Opus 4.6, includes probes that can disrupt misuse, the representative said.

Alternative link here.

Менопаузата и глупавите клишета, които понякога се оказват верни

Post Syndicated from Надежда Цекулова original https://www.toest.bg/menopauzata-i-glupavite-klisheta-koito-ponyakogha-se-okazvat-verni/

Менопаузата и глупавите клишета, които понякога се оказват верни

Периодът на постепенно настъпване на менопаузата (перименопауза) е известен с клишето за топлите вълни и непостоянните настроения. 

Това е най-глупавото клише в историята на глупостите, в историята на клишетата и в историята на жените. 

Преминаването от активна фертилна възраст към менопауза е преди всичко криза на идентичността. Почти същата като пубертета, но ако повечето от нас като деца са мечтали и бързали да пораснат, то преходът към „третата възраст“ е свързан основно със загуби и страхове. И макар зрелостта да има своите неоспорими предимства, „застраховката не покрива пълната щета“. Преходът към менопауза е период, в който всяка жена пренаписва себе си. Този период толкова дълго е неглижиран и стигматизиран, че почти всички клишета за него са грешни. 

Според статистиката в световен мащаб менопаузата настъпва средно около 51-вата година на жената, а симптомите на перименопаузата – между 45 и 50. Актуални данни от САЩ обаче показват, че значителна част от жените се сблъскват с първите симптоми на перименопаузата преди 40 или дори преди 35 години. Поради твърде ранната поява на тези симптоми те остават неразпознати. 

Перименопауза. Менопауза. Това кое беше сега? 

Всички знаем какво е пубертет. Термините, които завършват на -пауза ги бъркаме. 

Пременопаузата е периодът преди настъпването на симптоми, които сигнализират за намаляване на фертилността при жената. 

Перименопаузата е преходният период, в рамките на който хормоналният баланс, поддържащ фертилността, започва да се променя. Това води до широка палитра от физически и психични симптоми, само един от които (и не задължително първият) е нарушение в редовността на менструацията.

Менопауза е понятието, отбелязващо момента, в който в продължение на 12 месеца жената няма менструация.

Постменопаузата е практически целият период след настъпването на менопаузата.

Андропаузата бележи периода, в който намаляването на нивата на тестостерона у мъжа започват да дават симптоми. За мъжкото здраве обаче ще говорим друг път.

Криза на идентичността – не са (просто) хормони

„Жените споделят, че не са себе си“, казва д-р Мери Росър в уебинар, посветен на митовете за менопаузата. Д-р Росър е акушер-гинеколожка, професорка по женско здраве в Колумбийския университет и съавторка на книгата Menopause: What Your Ob-Gyn Wants You to Know. Макар специалността ѝ да предполага грижа основно за репродуктивната система, погледът на Росър като холистична специалистка по женско здраве извежда именно тази характеристика като най-ярък отличителен белег на прехода към менопауза (menopausal transition). 

През последните две десетилетия в психологията нараства интересът към изследването на феномена. Много по-голямо влияние за „отваряне“ на разговора за психичните измерения на този период в живота на жената обаче имат популярните жени, които разказват от първа ръка с какво са се сблъскали. От Мишел Обама до Холи Бери, от Салма Хайек до д-р Мери Клер Хейвър, множество известни личности разказаха собствените си истории, за да провокират обществен дебат за женското здраве и качеството на живот на жените над 40-годишна възраст. 

Актрисата Джилиън Андерсън, известна у нас с ролята си на детектив Скъли от сериала „Досиетата Х“, например разказва в едно от поредица интервюта по темата как веднъж в осем часа сутринта хвърлила палтото си в краката на децата и се разкрещяла, че „този ден е отвратителен“. Тогава актрисата била на 46. „Бях свикнала да балансирам много неща и изведнъж се почувствах, сякаш не мога да се справя с нищо. Чувствах се напълно изтощена“, разказва Андерсън. 

„Стегни се.“ Особености на женското психично здраве
Със „стегни се“ не минава. Пробвано е многократно в годините. Ако минаваше, резултатите за психичното здраве в глобален и в локален мащаб нямаше да са такива. А какви точно са и защо – повече в текста на Надежда Цекулова.
Менопаузата и глупавите клишета, които понякога се оказват верниТоестНадежда Цекулова
Менопаузата и глупавите клишета, които понякога се оказват верни

Колежката ѝ Наоми Уотс преживява прехода още по-драматично, сблъсквайки се с ранни симптоми още на 36. След години на трудности, сред които пристъпи на тревожност, депресия, ярост, паника и скръб, Уотс описва преживяванията си в книгата Dare I Say It: Everything I Wish I’d Known About Menopause. 

Физиологичните симптоми най-често създават допълнителни предпоставки за психическата картина. Палитрата от възможни проявления на перименопаузата е широка и в различни етапи от прехода към менопауза се наблюдават различни симптоми с различна интензивност. Освен това не всички се срещат при всяка жена. 

  • Промени в настроението

4 от 10 жени споделят, че по време на перименопаузата са преживели промени в настроението, които са им познати от предменструалния синдром. Когато нивата на естроген и прогестерон спаднат по време на перименопаузата, серотонинът също спада, което допринася за повишена раздразнителност, нервност и тревожност. По-високите нива на кортизол – „хормона на стреса“, който се увеличава с възрастта, също могат да създадат чувство на тревожност. Ако симптомите са толкова остри, че правят невъзможно изпълнението на дневните задачи или предизвикват суицидни мисли, препоръката е да се консултирате незабавно с лекар. 

Клиничните данни и разкази на пациентки показват, че много жени изпитват промени в оргазма и сексуалната функция по време на перименопаузата и постменопаузата. Често съобщаваните проблеми включват по-дълго време за достигане на оргазъм, намалена интензивност на оргазмите и в някои случаи невъзможност за постигане на оргазъм. Тези промени често са съпроводени от други симптоми, като вагинална сухота, дискомфорт по време на полов акт и променена генитална чувствителност. Намаляването на нивата на естроген по време на менопаузалния преход допринася за промени в кръвния поток, нервната чувствителност и тъканната реакция във вулвата, клитора и вагината. Въпреки разпространението на тези симптоми много жени не получават адекватни насоки или лечение. 

Истинският живот на женското либидо
Жени си говорят за секс, а Надежда Цекулова обобщава техните споделени мисли за либидото и сексуалния опит съвсем прегледно и с обяснение от медицинска гледна точка на някои важни хормонални процеси, протичащи в женския организъм.
Менопаузата и глупавите клишета, които понякога се оказват верниТоестНадежда Цекулова
Менопаузата и глупавите клишета, които понякога се оказват верни

  • Проблеми с концентрацията и/или паметта

Около 60% от жените в менопауза съобщават за проблеми с паметта. Проучване, обхващащо жени в пре-, пери- и постменопауза, открива чрез образна диагностика предимно временни промени в частите на мозъка, отговорни за когнитивните функции. По време на перименопаузата сивото вещество – тъканта, която съдържа повечето нервни клетки на мозъка и е от съществено значение за мисленето, паметта и вземането на решения, временно се свива и ползва повече мазнини и кетони за функционирането си. Образната диагностика показва също промени в областите, които контролират движенията, паметта и емоциите. Окуражаващото е, че след менопаузата обемът на сивото вещество се възстановява и мозъкът се стабилизира и преструктурира за този нов етап от живота.

  • Главоболие

Колебанията в нивата на естрогена и прогестерона по време на перименопаузата увеличават вероятността за мигрена и както много жени са установили – за менструална мигрена. Тези пристъпи са по-дълги, по-голяма е склонността към рецидив, а също така са по-тежки и по-инвалидизиращи в сравнение с пристъпите в други периоди от менструалния цикъл. Със скъсяването на менструалните цикли по време на перименопаузата менструалните пристъпи се появяват по-често. Горещите вълни и нощното изпотяване нарушават съня, действайки като допълнителен спусък за мигрена. С времето менструациите стават редки и в крайна сметка спират завинаги. Но въпреки това яйчниците все още могат да произвеждат естроген на различни нива в продължение на няколко години. Така че, макар мигрената да намалява с навлизането в постменопаузата, това не е незабавно. 

Променящите се хормонални нива по време на перименопаузата и менопаузата пречат на хипоталамуса да регулира телесната температура. Усещането е за внезапен прилив на топлина най-често в областта на лицето, врата и гърдите. В отговор тялото се опитва да се охлади, като се изпотява твърде много.

  • Безсъние

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

  • Ставни и мускулни болки

Наблюдения сочат, че ставните и мускулните болки са сред най-сериозните оплаквания на жените в преход към менопауза. Според данните средно около 71% от жените в перименопауза изпитват такива болки, като за разлика от повечето други симптоми на перименопаузата, този не отшумява с настъпването на менопаузата, а рискът от оплаквания нараства с възрастта.

  • Чести позиви за уриниране

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

Защо се случва всичко това?

Перименопаузата и менопаузата засягат всички системи и функции на жената, но „започват“ от яйчниците: с годините фоликуларният резерв се изчерпва, а с него спадат хормоните, които фоликулите произвеждат и чиято роля е да държат под контрол хипофизната стимулация. Това предизвиква неравномерно покачване на FSH (фоликулостимулиращия хормон) и прояви на дисрегулация на месечния цикъл: в един месец яйчникът реагира добре, в друг – не. 

Пропуснатите овулации водят до липса на прогестеронов пик във втората фаза на цикъла, който пък може да стане причина ендометриумът да нарасне твърде много и следващата менструация да е по-обилна. Клиничният резултат се изразява в непредвидими, по-кратки или по-продължителни цикли. 

Паралелно с това нивата на другия ключов хормон – естрогена – могат да се люшкат от твърде високи до твърде ниски. Ето защо еднократно лабораторно изследване на хормони в този период не дава достатъчно категорична клинична информация, а от друга страна, кара жените често да се чувстват така, сякаш тялото им променя правилата без предупреждение. Хормоналните изменения могат да доведат до всички изброени симптоми, но при всяка жена се проявява различен набор от тях в различен момент и с различна интензивност.

Да запазиш себе си или да намериш ново аз – кой помага по пътя?

Съвременната медицина предлага редица възможности за намаляване на негативните усещания и дългосрочните усложнения, причинени от симптомите на перименопаузата и менопаузата. Много от тях изискват жените да имат достъп до добре подготвен мултидисциплинарен медицински екип. 

Част от решенията обаче са в ръцете на самите жени и са свързани с начина на живот. Отказ от вредните навици (колкото по-рано, толкова по-добре), като тютюнопушене, кафе и алкохол, доказано влияе на облекчаване на част от симптомите. Редовното движение с натоварване на сърдечносъдовата система (кардио) и опорно-двигателния апарат (тренировки с тежести) също е с голямо и дългосрочно значение.

В повечето случаи обаче това не е достатъчнo.

Един от най-хубавите монолози за менопаузата в съвременната популярна култура. Част е от втория сезон на сериала Fleabag.

В зависимост от хода на спада в хормоните, вида и интензивността на симптомите жените могат да получат различни форми на медикаментозна терапия, която да повиши качеството на живота им и да намали дългосрочните негативни ефекти. 

В края на 2025 г. Европейското дружество по ендокринология публикува ново Клинично практическо ръководство за лечение и оценка на менопаузата и перименопаузата. Ръководството е разработено от екип ендокринолози и гинеколози и дава насоки както за общопрактикуващите лекари, които обикновено се сблъскват с първите оплаквания на жените, така и за специалисти, които работят с по-сложни случаи.

Една от важните теми, посочени в клиничното ръководство, е приложението на хормонозаместителна терапия. През последните години отношението към нея е нееднозначно и докато едни специалисти я препоръчват като първа линия на въздействие, други все още я отричат категорично. В момента има научен консенсус за множеството предимства на този метод, но той изисква прецизен индивидуален подход заради възможните рискове. Науката за перименопаузата и менопаузата обаче е много нова – едва на няколко десетилетия – и все още има неясноти и значителни промени в разбирането на процесите, особено при различните групи жени.

При ранна менопауза например системната хормонална терапия се разглежда като заместващо лечение, а не просто като „нещо срещу горещите вълни“. Идеята е, че организмът остава без естроген в години, в които би следвало да го произвежда, затова специалистите от Европейското дружество по ендокринология посочват, че в такива случаи хормоналната терапия по правило се препоръчва (ако няма противопоказания) и често се продължава поне до средната възраст на естествената менопауза (около 51 г.) с периодични преоценки. Това има значение не само за симптомите, а и за дългосрочното здраве, например за костната плътност и сърдечносъдовата система, като режимът за конкретната жена винаги се избира индивидуално от специалист. 

При менопауза около 50-годишна възраст системната терапия най-често се обсъжда, когато симптомите са осезаеми и пречат на нормалния живот. Балансът полза–риск обикновено е най-благоприятен при здрави жени под 60 г. или в рамките на около 10 години от настъпването на менопаузата, ако няма противопоказания. Основните рискове, които се вземат предвид, са редки, но сериозни: повишен риск от образуване на тромби, от инсулт, както и от рак на гърдата. 

Любимият въпрос: къде сме ние?

В България състоянията, свързани с перименопаузата и менопаузата, са лично хоби на тесен кръг специалисти. Лично предизвикателство за жените пък е да открият кои са тези специалисти, и да се доберат до тях, както и да се ориентират, когато моментът настъпи. В актуалните Медицински стандарт по акушерство и гинекология и Фармако-терапевтично ръководство по същата специалност менопаузата се споменава само като период, в рамките на който на жената се случват някакви други неща, представляващи обект на интерес. Самата менопауза обаче не е отделно състояние, изискващо специфични комплексни познания и подход, а перименопаузата изобщо не съществува – дори и като понятие. 

Женското здраве като пазарна ниша – ползи и рискове
Има ли шанс женското здраве да излезе от периферията на медицината, без да потъне в маркетинг лабиринта, в който на милиони жени по света ежесекундно се продават милиони неща, които, освен че са по-скъпи просто защото са „женски“, понякога са и напълно излишни? От Надежда Цекулова.
Менопаузата и глупавите клишета, които понякога се оказват верниТоестНадежда Цекулова
Менопаузата и глупавите клишета, които понякога се оказват верни

В страната ни не се внася нито една трансдермална форма на хормонален препарат, въпреки че тези форми доказано намаляват рисковете от нежелани усложнения. Жени, които имат нужда от подкрепа за справяне със симптомите, споделят, че се сблъскват с неглижиране, защото състоянието им е „нормално за възрастта“ или защото „така ще е“, или пък обратно – защото са „твърде млади“, за да имат симптоми на перименопауза. Липсват мултидисциплинарни екипи, в които специалисти с различни профили (например акушер-гинеколог, ендокринолог и кардиолог) заедно да определят терапията на жена със симптоми, изразяващи се в различни нарушения.

За щастие, световната тенденция не подминава (напълно) страната ни и разговорите за благосъстоянието на жените в преход и в менопауза стават все по-модерни, макар и все още предимно да се опитват да ни продадат нещо и да са далеч от масови, експертни или достъпни за всички заинтересовани и нуждаещи се. 

„Анатомия на пола: Жена“ разглежда здравето на жените като неразривна част от обществото, историята и културата. В поредицата изследваме как са се променяли нагласите към женското здраве, как медицината е възприемала специфичните потребности на жените и какви процеси са повлияли на достъпа им до качествени здравни грижи. Вглеждаме се в научните открития, но и в културните митове; в официалните политики, но и в личните истории на жени, борещи се за правото си на здраве и достойнство.

По буквите: Янакиева, Иванов

Post Syndicated from Зорница Христова original https://www.toest.bg/po-bukvite-yanakieva-ivanov/

Слава Янакиева, „Музеят на моето време”

По буквите: Янакиева, Иванов

Пловдив: изд. „Жанет 45“, 2025

Аз ли развих вкус към мемоаристиката, или съществува обществена тяга към нея? Повече мемоарни книги ли се появиха, или аз остарявам и почвам да ги забелязвам?

Така или иначе, „Музеят на моето време“ на Слава Янакиева ми попадна не само скоро след спомените на Алберт Бенбасат, Жюстин Томс, Людмила Миндова, а и успоредно с куп други книги, опитващи се да съхранят отдавна изгубени времена и светове. Заравяйки се в проучвания, усещам как първо посягам към мемоара и чак после – към стандартната, „голяма“ история. Имам обяснение.

Колкото повече разнопосочни източници на информация ни заливат, колкото повече се усъмняваме в истинността на думи, снимки, кадри, анализи, колкото повече усещаме как думата „факти“ ожълтява и се превръща в тесте от „сензации“, толкова повече ценим личното свидетелство.

Този го познавам. Това ми се случи. Това се е случило в моето семейство. Това се наричаше така и така. Неслучайно горе изброих спомените на автори, които познавам лично, а не, примерно, мемоарите на Бенджамин Франклин. Събрани заедно, те започват да плетат една

лична история на света „отвътре“, история на малкия домашен свят, ризоматична история, която не върви линейно от корена през стъблото към клоните и листата, а се свързва подземно ту в едно, ту в друго разклонение.

По буквите: Янакиева, Иванов

Заглавието на „Музеят на моето време“ е добре подбрано: музеите са държавни институции, които управляват паметта. Домовете обаче също са музеи, в тях също има вещи, които говорят за миналото, и също има памет и разказ. За разлика от официалния, този разказ има много глаголни времена. Има минало, за което не можеш да питаш – като убития от Народния съд дядо Никола. Има бъдеще, което е отказано – като професионалния път на бащата и лелята. Има сегашно премълчано – като роднините от Америка, чиито посещения будят небивали вълнения в домакинството, но са крайно неподходящи адресати за училищни писма по образец.

И тук има два плана на четене: на съпреживяването и гнева, от една страна, и на удивлението каква литература се получава по тези правила, от друга. Защото мемоарите по принцип – а тези още повече – винаги се колебаят между стремежа към максимална истинност и стремежа към увлекателност. Затова между сериозните теми тържествено се мъдри „принцеса“, наричана още „странджанка“, „сакарка“ и дори „людмилка“ (гениално название!); затова в музея важно е изложено „кървавото писмо“ на невръстния още баща и едно друго момченце срещу „двете Мимита“. И в рецитацията на Вапцаров, в която вместо „Майко! Фернандес убит…“ идва името на Фернандел.

Ето нещо, което официалната история никога не си позволява да прави – да се смее.

Не че и тя не се води по правилата на литературата (завръзки, кулминации, развръзки, протагонисти, антагонисти и пр.), но почти задължително се придържа към жанра на трагично-героичния епос. А личната история оцелява в смеха. В личното си естество всички сме трагикомедии. Да живее мемоаристиката!

Мартин Иванов, „Цени и заплати през Възраждането (1750–1878 г.). Том 1. Зърнени храни, фуражи, храни, напитки и живи животни“

София: Университетско издателство „Св. Климент Охридски“, 2025

Другата книга в днешния обзор изглежда диаметрално противоположна. Едната е субективен, личен опит, другата е неутралният глас на статистиката. Страници след страници списъци с цени на основни стоки през Възраждането и само в началото на главите – обзор и анализ. Видимо предназначено за учени, както и подобава на книга на университетско издателство. Защо тогава ви говоря за нея?

Защото е друга стратегия към истината в постистинния свят: този път не през гаранцията на личното свидетелство, а през гаранцията на изчерпателността. Фактите са „факти“, когато единичното е извадено от контекст; когато е избрано сензационното или пък желаното, ласкателното, очакваното, уличаващото – в зависимост от целите на подбиращия.

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

Историческата наука обаче не би трябвало да го прави – и изследването на Мартин Иванов показва как е възможно да се обработят наличните масиви от данни, за да се стигне до доказуема истина по отношение на миналото. В случая разбираме какво е купувал и какво е продавал възрожденският българин, как се е хранил, какво е произвеждал и т.н. Популярността на дадена стока се доказва с броя цени, които са намерени за нея – и може да разкрие например съотношението на отделни храни в менюто или сравнителния престиж, който е носила всяка от тях. Като обикновена любопитна читателка забелязвам сладокусните факти – за многото превъплъщения на захарта, не само познатия ми небетшекер и захар на пръчки, но и примерно, захарното мезе (със сол, захар, оцет и сирене); за ориза като луксозна храна (особено пък пълнен в зеленчук), за странната липса на интерес към плодовете (освен за ракия) и т.н.

Но смисълът на тази книга далеч надхвърля кулинарния куриоз – тя е важна основа за изследване на стопанската дейност, за търсене на отговор на въпроса кога и как се заражда вътрешният български стопански пазар,

какво го мотивира, как му се отразяват различните политически събития и пр. В изследването на проф. Румен Аврамов върху стопанския XX век на България например пише, че Освобождението се отразило пагубно върху занаятите поради прилива на фабрично произведени европейски стоки; в настоящото изследване на цените пък ми направи впечатление например джелепкешанството в Копривщица – събирането и отвеждането на овце за нуждите на османската армия. След Освобождението с тази професия било свършено; в друг източник четем, че Копривщица пообедняла, защото огромните стада нямало къде да зимуват (преди зимували край Бяло море) и половината животни измрели.

Вероятно това обяснява защо прапрабаба ми, родена копривщенка, заминава с мъжа си за Одринско – от освободените територии към неосвободените; придвижване, което идеята за копривщенския просперитет не би могла да обясни. Ето че от общото пак стигнахме до частното.

Но това е неизбежно, защото съм частен читател; по-едрите изводи оставям на кръга историци, чиито изследвания са естественият контекст на тази книга: Стефан Дечев, Райна Гаврилова, Румен Аврамов и пр. И на тези след тях, разбира се.

Личните спомени разкриват друг свят – например такъв, в който има поравно мъже и жени, в който хората пазаруват, работят, сядат на масата, хранят се, вместо само да завоюват и да губят територии, и понякога да сменят системата на управление. Този личен свят е много подобен на нашия – но започва да ни гложди мисълта доколко е представителен. Да речем, знам, че прабаба ми е правила рачел – мога ли смело да кажа, че рачелът е бил популярен десерт преди 100 години в България? А преди 150?

По буквите: Янакиева, Иванов

Изследването на Мартин Иванов събира в едно всички налични цени на стоки по българските земи през Възраждането. То е изключително любопитно в контекста на дългогодишните усилия на българските учени да разкрият и другото лице на историята – историята на човешкото всекидневие от всички социални слоеве. Взети заедно, тези изследвания дават надежда, че познанието за света – такъв, какъвто го преживяваме – може да бъде запазено.

Разбира се, с дългите списъци от цени книгата има функцията повече на справочна, отколкото на прочитна литература. Но аз имам личен наглед как статистиката се превръща обратно в живот: дъщеря ми, бивша студентка на доц. Иванов, имаше за курсова работа да анализира три лични тефтера за приходи и разходи, та чух със собствените си уши как литературата оживява от голите данни, как виждаме богатите братя, канени навсякъде на кръщенета, бедния развейпрах, харчещ каквото няма за напитки и дрехи, и т.н. Тук пък покрай статистиката оживяват пазарът и паницата – и свързаният с тях живот.

В емблематичната си колонка „Ходене по буквите“, започната още през 2008 г. във в-к „Култура“, Марин Бодаков ни представяше нови литературни заглавия и питаше с какво точно тези книги ни променят. В началото на 2020 г. той я пренесе в „Тоест“. Вярваме, че е важно тази рубрика да продължи. От човек до човек, с нова книга в ръка. От края на 2021 г. по буквите тръгна Зорница Христова.

Активните дарители на „Тоест“ получават 20% отстъпка от коричната цена на всички книги на над 15 български издателства. Кои са те – вижте в условията на Читателски клуб „Тоест“.

Т.Е. от Е.Т – епизод 42

Post Syndicated from Тоест original https://www.toest.bg/t-e-ot-e-t-epizod-42/

Т.Е. от Е.Т – епизод 42

Падат бомби, Доналд Тръмп има нова шапка, а ИТН са предсмъртен, пардон, предизборен спазъм. Ето какво още от Е.Т.-то на Републиката.

Следете видеорубриката на Елена Телбис за „Тоест“ и във Facebook, Instagram и TikTok.

Избори 2026 – заявление за гласуване в чужбина

Post Syndicated from Боян Юруков original https://yurukov.net/blog/2026/izbori2026-form/

Тази информация беше изпратена на над 3000 абонирали се за бюлетина на Glasvam.org заедно с новини и полезни съвети за подготовката и провеждането на гласуването в чужбина.

На 19-ти април 2026 ще се проведат избори за Народно събрание. Вече може да подавате заявление за гласуване зад граница. Ще намерите формуляра на страницата на ЦИК. Там може да проверите и дали правилно е записано заявлението ви. Ето няколко важни неща, които трябва да знаете:

  • Крайният срок за подаване е 24-ти март в полунощ българско време
  • Подаването на заявление за гласуване в секцията най-близо до Вас, ще Ви улесни и ще ускори изборния процес, тъй като ще сте вече вписани в списъците
  • Заявление се подава за всеки вот поотделно. Т.е. не се пренасят от предходни избори
  • Дори да подадете заявление, а се окаже, че на 19-ти април сте в България, ще може да гласувате в секцията си по постоянен адрес с попълване на декларация
  • Вече са предварително одобрени 372 места за секции в чужбина, където в последните 5 години е имало поне 100 гласували. Това е наполовина от минали години и причината са промените в Изборния кодекс ограничаващи секции извън Европейския съюз и възможността за автоматично отваряне на база висока активност до сега. Повече за това може да прочетете в тази статия.
  • За отваряне на секции извън Европейския съюз остава единствено възможността да се съберат поне 40 заявления.
  • Предварителното одобрение не означава, че непременно ще има секции на тези места. Това зависи от възможностите на помещенията и дали има комисии и доброволци към тях. Решението е на ЦИК по препоръка на Външно. Могат да се увеличат шансовете като се подават заявления за тези места и повече хора се включат като членове на комисии и доброволци.
  • На някои места като Германия е нужно да се иска разрешение от местните власти. Това вече би трябвало да се случва предвид предварително одобрените места. Очакваме информация от МВнР
  • Подаването на заявления освен, че подпомага изборния процес, показва и повишен интерес на съгражданите ни в чужбина към вота

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

Събирането на заявленията ще може да следите в реално време на картата, както и на подробната таблица. Заради допълнителни бариери на сайта на ЦИК на последните няколко вота не не можех да зареждам автоматично данните за броя подали заявление. Намерих начин, но този път е възможно отново да ме блокират нарочно, което ще спре и данните в таблицата. Повече информация ще намерите на сайта на ЦИК и МВнР.

Reclaiming Terabytes: Optimizing Android image caching with TLRU

Post Syndicated from Grab Tech original https://engineering.grab.com/reclaiming-tetabytes-optimizing-android-image-caching-with-tlru

Introduction

In a previous post, we discussed Project Bonsai, our initiative to reduce the Grab app’s download size. We successfully reduced the Android Application Package (APK) download size by 26%. This reduction offers a substantial advantage: it minimizes download friction, allowing users to download the app, even on slower networks. However, the battle for storage doesn’t end after installation.

The Grab app includes a wide range of features and workflows that heavily depend on image content, particularly in services like transportation and e-commerce. Although some images are packaged within the app binary, a large majority are downloaded from Grab’s server at runtime. To optimize the app’s performance and minimize server expenses, the downloaded images are cached in the app’s storage. This reduces both load times and traffic to Grab’s image server, resulting in better user experience and lower costs. Although we use Least Recently Used (LRU) cache to manage storage, many images can remain in the app storage for extended periods, even if they are no longer relevant.

This blog details how we addressed this challenge in our Grab Android app by evolving our standard LRU cache into a Time-Aware Least Recently Used (TLRU) cache. This evolution allows us to reclaim storage space without compromising user experience or increasing server costs.

Understanding LRU cache limitations

Note: In this article, when “cache” or “image cache” is mentioned, it specifically refers to disk cache, which is the persistent storage on the device’s file system, rather than in-memory cache.

The Grab Android app uses the Glide library as its primary image loading framework. Glide provides excellent features for efficient image loading, caching, and display. At its core, by default, Glide uses a cloned version of Jake Wharton’s DiskLruCache for disk-based caching.

To prevent unlimited cache growth, we configured the LRU cache with a maximum size limit of 100 MB. However, our analytics revealed that the 90th percentile (P90) of users were consistently reaching this 100 MB limit, meaning the cache was constantly at capacity. Conversely, for users whose cache hadn’t yet reached the 100 MB threshold, images were never removed, even if they were outdated by several months and no longer relevant.

Our analysis revealed that image caching was a major contributor to the app’s disk footprint, and without proactive management, this would only worsen as we continued adding features and content to Grab’s superapp.

How DiskLruCache works

The LRU cache algorithm manages storage by maintaining entries in access order and automatically evicting the oldest unused entries when space is needed.

Figure 1 and 2 illustrates how LRU cache trimming works. These diagrams present an LRU cache with a maximum size of 100 MB containing three cache entries totaling 95 MB. When a new 25 MB cache entry is added, it exceeds the cache’s maximum size.

Figure 1. A new cache entry is added to an LRU cache that’s near its 100 MB capacity, exceeding the limit.
Figure 2. The LRU cache automatically trims the least recently used entry to bring the total size back within the 100 MB limit.

The challenge

While DiskLruCache efficiently manages cache size, it has a critical limitation: It does not account for the age of cached content. Due to the lack of time-based eviction rules, the cache does not remove outdated entries until it exceeds the maximum size. This meant that stale promotional images, images from infrequently used features, and outdated content continued occupying disk space indefinitely, as long as the cache remained under the size limit.

What we needed was a cache mechanism that could:

  • Maintain LRU cache benefits: Preserve efficient caching for users who actively use the app features.

  • Remove stale content based on time: Automatically identify and evict outdated entries, not just rely on storage constraints.

  • Protect user experience: Ensure images still load quickly without cache misses.

  • Keep server costs low: Avoid increased server requests from premature cache evictions.

These requirements pointed us toward an enhanced LRU approach. We needed to enhance LRU with time awareness while preserving its proven size-management capabilities.

TLRU cache: The solution

To address these limitations, we developed a new LRU cache variant named TLRU that extends traditional LRU by introducing time-based eviction while maintaining size-based cache management.

Core TLRU attributes

TLRU introduces three core attributes to manage cache entries:

  • Time-To-Live (TTL): A threshold that determines when a cache entry is considered expired. An entry is expired if (current_time - last_accessed) > TTL. Expired entries are automatically removed during cache operations.

  • Minimum cache size threshold: A safety net that ensures a baseline set of essential images always remains cached, even when entries expire. This prevents complete cache deletion when users haven’t used the app for more than the TTL period, maintaining app responsiveness for returning users instead of starting with an empty cache.

  • Maximum cache size: Inherited from LRU cache, this enforces the upper storage limit (100 MB in our case). When exceeded, the least recently used entries are evicted regardless of their age.

Together, these attributes ensure TLRU maintains optimal cache size by managing both storage constraints and temporal relevance, reducing app disk footprint without impacting user experience.

TLRU cache trimming in action

To better understand how TLRU works in practice, let’s walk through a comprehensive example. The following diagrams demonstrate how the TLRU cache evaluates and trims entries based on both time and size constraints.

Our TLRU cache configuration includes:

  • Maximum cache size: 100 MB – the storage limit that triggers size-based eviction.

  • Minimum size threshold: 20 MB – the safety net that protects essential cached content.

  • TTL: 20 days – entries older than this are considered expired.

Each cache entry includes last_accessed metadata containing the timestamp of its most recent access. When an entry is first created, this timestamp is initialized with the creation time. This timestamp determines whether an entry has expired based on the formula:

Entry is expired if: (current_time - last_accessed) > TTL

For this walkthrough, we’ll use current_time = Day 100 as our starting point.

Initial cache state analysis

Our example begins with three existing cache entries totaling 95 MB, approaching the 100 MB limit:

  • Item 1 (8 MB, last accessed Day 82): At 18 days old
  • Item 2 (30 MB, last accessed Day 81): At 19 days old
  • Item 3 (57 MB, last accessed Day 80): At exactly 20 days old, valid at the TTL threshold

When a new 10 MB item is added on Day 100, the cache grows to 105 MB, exceeding our 100 MB limit and triggering size-based eviction.

Figure 3. Initial TLRU cache state and the impact of adding new entries.

Size-based eviction process

When the cache exceeds its 100 MB limit, TLRU applies traditional LRU eviction logic. Item 3 is selected for eviction because:

  • It is the least recently used entry (oldest access time).

  • This demonstrates TLRU maintaining LRU behavior for size enforcement, regardless of expiration status.

Figure 4. Size-based eviction removes the least recently used entry to enforce storage limits.

Time-based eviction process

Five days later (Day 105), Item 1 and Item 2 cross the expiration threshold:

Despite operating well below the size limit (48 MB < 100 MB), TLRU evaluates expired entries for time-based eviction. Item 2 is removed because it’s expired, and the cache remains above the minimum threshold. Item 1, although also expired, is protected by the minimum threshold rule; removing it would leave only 10 MB, which falls below the 20 MB minimum.

Figure 5. Time-based eviction and minimum threshold protection working together.

TLRU behavior summary

This comprehensive example demonstrates TLRU’s three core mechanisms:

  • Size-based eviction: Enforces storage limits using traditional LRU ordering (Item 3 removed despite being valid).

  • Time-based eviction: Proactively removes expired content when safe to do so (Item 2 removed for age).

  • Minimum threshold protection: Preserves essential cache functionality even with expired content (Item 1 protected despite expiration).

Technical implementation

Rather than building an image cache from scratch, we recognized that Glide’s bundled DiskLruCache (originally from Jake Wharton’s implementation) already provided a mature, battle-tested foundation. This implementation is widely adopted across the Android ecosystem and handles complex edge cases like crash recovery, thread safety, and performance optimization that would require substantial effort to replicate.

Our approach was pragmatic, we cloned Glide’s DiskLruCache and extended it to support time-based expiration. This strategy allowed us to inherit the existing reliability while adding the temporal awareness we needed for TLRU.

To understand our implementation, we’ll first explore how the original DiskLruCache works, then dive into the specific modifications we made to transform it into TLRU.

Understanding DiskLruCache

DiskLruCache provides a simple cache solution that stores key-value pairs on disk, while also keeping track of their usage to evict the least recently used items when the cache reaches its maximum size. Here is an overview of how DiskLruCache is implemented:

  • Data storage: DiskLruCache stores its data in a specified directory, creating files for each entry.

  • Key-based access: Each entry has a unique key (typically a hash generated by the image loader) used to create the filename of the cached entry.

  • Atomic writes: When adding an entry, it creates a temporary file and writes the data to it. If successful, it atomically renames the temporary file to the final filename.

  • Cache retrieval: When reading from the cache, it looks up the key, opens the corresponding file on disk, and returns an InputStream to read the data.

  • Size management: It maintains a maximum cache size limit. When exceeded, it removes the least recently used items until it is within the specified limit.

The central component that enables this functionality is the journaling mechanism, detailed in the following section.

The journaling mechanism

The journaling mechanism in DiskLruCache is designed to maintain consistency and prevent data corruption in the cache. The journal file records all cache operations, such as adding, updating, or removing entries. The journaling mechanism is essential in rebuilding the cache metadata during initialization and performing journal compaction to clean up the journal file.

Figure 6. Example of the journaling mechanism in DiskLruCache.

Journal file format:

The journal file is a plain text file that records cache operations line by line.

  • DIRTY: Indicates the start of a write operation to a cache entry.

  • CLEAN: Indicates that a cache entry was successfully written and closed.

  • REMOVE: Indicates that a cache entry was removed from the cache.

  • READ: Indicates that a cache entry was read.

To gain a comprehensive understanding of the journal file format, refer to the following detailed explanation.

  • Key information: Each line includes the key and other relevant information, such as the lengths of the cache entry files.

  • Cache initialization: Upon initialization, DiskLruCache reads the journal file to reconstruct cache metadata in memory, determining file associations, lengths, and access order. If the journal file is corrupted or missing, the cache will be considered invalid, and DiskLruCache will remove all cache files and start fresh.

  • Cache operations and journal updates: When performing cache operations like adding, updating, or removing entries, DiskLruCache appends corresponding lines to the journal file, recording the operation details. For example, when starting to write a new cache entry, it writes a DIRTY line with the key, and when the write is successful, it appends a CLEAN line with the key and lengths.

  • Synchronization and consistency: DiskLruCache uses synchronization to ensure that only one thread can access the cache at a time, preventing race conditions and data corruption. It also uses a journalWriter (java.io.Writer) instance to append operations to the journal file, ensuring that the file is always in a consistent state.

  • Journal compaction: Over time, the journal file may grow with redundant operations. DiskLruCache periodically compacts the journal by creating a new file that contains only the current cache metadata, then atomically replaces the old file. The compaction process usually happens when the journal file size exceeds a certain threshold.

DiskLruCache ensures consistency and prevents data corruption by using this journaling mechanism, making it a reliable solution for disk-based caching.

Modifying DiskLruCache for TLRU

With a solid understanding of DiskLruCache’s architecture, we can now explore how we extended it to implement the TLRU cache attributes defined earlier.

Three primary modifications to DiskLruCache:

Tracking last access time

To support time-based eviction, the cache needs to track when each entry was last accessed. This information m ust persist across app restarts, so it’s stored in the journal file itself.

Modified journal format:

READ [Cache-Key] [Access-Timestamp]
CLEAN [Cache-Key] [File-Size]-[Access-Timestamp]

The timestamps are added to READ and CLEAN operations:

  • READ entries record when a cache entry is accessed, updating its last-access time.

  • CLEAN entries record the creation time when a new entry is successfully added to the cache.

Figure 7. Example of a TLRU journal file.

Time-based eviction logic

The TLRU cache leverages the existing LRU ordering to optimize expiration checking. For each cache operation, it checks if the least recently accessed entry has expired before proceeding with time-based trimming.

The diagram below shows how the TLRU cache makes the decision to remove the cache entries.

Figure 8. TLRU eviction decision flow – evaluating cache entries based on time expiration and size constraints.

The algorithm leverages the sorted nature of the cache: if the least recently accessed entry hasn’t expired, no other entries need checking. If it has expired, the cache trim operation walks through entries from oldest to newest, removing all expired ones.

Backward-compatible migration

With an extensive user base, invalidating existing cached images would cause millions of users to experience poor performance while creating massive server traffic spikes and infrastructure costs.

One of the challenges was retrieving last-access timestamps from existing LRU entries, as file system APIs do not offer reliable access time data. Our solution was to set the last-access time of all existing entries to the migration timestamp. This approach preserves all cached content and establishes a consistent baseline, although it necessitates waiting one TTL period to realize the full benefits of eviction.

We also ensured bidirectional compatibility – the original LRU implementation can read TLRU journal files by ignoring timestamp suffixes, enabling safe rollbacks if needed.

Upon completing our TLRU implementation, we focused on determining optimal values for the three core attributes: TTL duration, minimum threshold, and maximum cache size. These parameters are crucial for balancing storage optimization and cache performance, requiring careful tuning based on real user behavior.

Finding optimal configuration values

Finding optimal configuration values requires systematic experimentation and data-driven decision-making. Controlled experiments to compare the cache hit ratio with baseline LRU performance must be conducted.

Note: Cache hit ratio, our key success metric, gauges efficiency by the percentage of requests served from cache versus requiring server downloads. Lower ratios lead to higher server costs and increased user data consumption.

Our success criteria is for a cache hit ratio decrease of no more than 3 percentage points (pp) during the transition to TLRU. For instance, a decrease from 59% to 56% hit ratio would result in 7% increase in server requests. This threshold balances storage optimization with acceptable performance impact.

To mitigate potential server cost impact from our maximum acceptable 3 pp cache hit ratio drop, we worked with the server team to optimize image delivery infrastructure, enabling a confident TLRU rollout without infrastructure cost concerns.

Impact and results

After fully rolling out TLRU to production, we significantly optimized storage while preserving user experience. Post-implementation stabilization, the P95 total app size reduced by approximately 50 MB. This meant that 95% of our users experienced storage reduction up to 50 MB, with the top 5% seeing even greater savings.

With over 100 million downloads of the Grab Android app, even conservative estimates show terabytes of storage reclaimed across all user devices worldwide. This translates to better device performance, especially on low-end devices, and improved user satisfaction.

Critically, we maintained our success criteria: cache hit ratio stayed within target thresholds (no more than 3 pp decrease), with no increase in infrastructure costs. The seamless migration preserved all existing cache data without disruption.

Conclusion

At Grab, we believe that every byte matters. Our users trust us with their device storage, and we take that responsibility seriously. The TLRU implementation exemplifies our commitment to user experience. We don’t just build features, we optimize them to ensure our app respects our users’ devices. The petabytes of storage reclaimed across millions of devices aren’t just a technical achievement; it’s a reflection of our dedication to creating a lighter, faster, more respectful mobile experience.

The implementation demonstrates that meaningful improvements can be achieved through thoughtful modifications to existing, well-tested libraries. Our focus on backward compatibility and safe migration ensured zero disruption for Grab’s users, proving that user experience and technical innovation can coexist.

Join Us

Grab is Southeast Asia’s leading superapp, serving over 900 cities across eight countries (Cambodia, Indonesia, Malaysia, Myanmar, the Philippines, Singapore, Thailand, and Vietnam). Through a single platform, millions of users access mobility, delivery, and digital financial services, including ride-hailing, food delivery, payments, lending, and digital banking via GXS Bank and GXBank. Founded in 2012, Grab’s mission is to drive Southeast Asia forward by creating economic empowerment for everyone while delivering sustainable financial performance and positive social impact.

Powered by technology and driven by heart, our mission is to drive Southeast Asia forward by creating economic empowerment for everyone. If this mission speaks to you, join our team today!

A GitHub Issue Title Compromised 4,000 Developer Machines (grith.ai)

Post Syndicated from corbet original https://lwn.net/Articles/1061548/

The grith.ai blog reports
on an LLM prompt-injection vulnerability that led to 4,000 installations of
a compromised version of the Cline utility.

For the next eight hours, every developer who installed or updated
Cline got OpenClaw – a separate AI agent with full system access –
installed globally on their machine without consent. Approximately
4,000 downloads occurred before the package was pulled.

The interesting part is not the payload. It is how the attacker got
the npm token in the first place: by injecting a prompt into a
GitHub issue title, which an AI triage bot read, interpreted as an
instruction, and executed.

[$] The relicensing of chardet

Post Syndicated from corbet original https://lwn.net/Articles/1061534/

Chardet
is a Python module that attempts to determine which character set was used
to encode a text string. It was originally written by Mark Pilgrim, who is
also the author of a number of Python books; the 1.0 release happened in
2006. For many years, this module has been under the maintainership of
Dan Blanchard. Chardet has always been licensed under the LGPL, but, with
the 7.0.0
release, Blanchard changed the terms to the permissive MIT license.
That has led to an extensive (and ongoing) discussion on when code can be
relicensed against the wishes of its original author, and whether using a
large language model to rewrite code is a legitimate way to strip copyleft
requirements from code.

Buildroot 2026.02 released

Post Syndicated from jzb original https://lwn.net/Articles/1061543/

Peter Korsgaard has
announced version 2026.02 of Buildroot, a tool for generating
embedded Linux systems through cross-compilation. Notable changes
include added support for HPPA, use of the 6.19.x kernel headers by
default, better SBOM generation, and more.

Again a very active cycle with more than 1500 changes from 97 unique
contributors. I’m once again very happy to see so many “new” people next
to the “oldtimers”.

See the changelog
for full details. Thanks to Julien Olivain for pointing us to the announcement.

Gigabyte AI TOP ATOM NVIDIA GB10 Review A Neat Little Box

Post Syndicated from Ryan Smith original https://www.servethehome.com/gigabyte-ai-top-atom-nvidia-gb10-review-a-neat-little-box/

The Gigabyte AI TOP ATOM is the company’s NVIDIA GB10 platform for local AI with 128GB, a Blackwell GPU, 200GbE networking, and a fast Arm CPU

The post Gigabyte AI TOP ATOM NVIDIA GB10 Review A Neat Little Box appeared first on ServeTheHome.

AWS completes the 2026 annual Dubai Electronic Security Centre (DESC) certification audit

Post Syndicated from Tariro Dongo original https://aws.amazon.com/blogs/security/aws-completes-the-2026-annual-dubai-electronic-security-centre-desc-certification-audit/

We’re excited to announce that Amazon Web Services (AWS) has completed the annual Dubai Electronic Security Centre (DESC) certification audit to operate as a Tier 1 Cloud Service Provider (CSP) for the AWS Middle East (UAE) Region.

This alignment with DESC requirements demonstrates our continued commitment to adhere to the heightened expectations for CSPs. Government customers of AWS can run their applications in AWS Cloud-certified Regions with confidence.

The AWS compliance to the DESC Framework requirements were validated by an independent third-party auditor (BSI) prior to issuance of a renewed certificate by DESC. The updated DESC CSP certificate is available through AWS Artifact, and is valid for one year to January 22, 2027. AWS Artifact is a self-service portal for on-demand access to AWS compliance reports. Sign in to AWS Artifact in the AWS Management Console, or learn more at Getting Started with AWS Artifact.

The certification includes the following 10 additional services in scope, for a total of 108 services:

This is a 10% increase in the number of services in the Middle East (UAE) Region that are in scope of the DESC CSP certification.

AWS strives to continuously bring services into the scope of its compliance programs to help you meet your architectural and regulatory needs. You can view the current list of services in scope on our Services in Scope page. You can also reach out to your AWS account team if you have any questions or feedback about DESC compliance.

To learn more about our compliance and security programs, see AWS Compliance Programs. As always, we value your feedback and questions; reach out to the AWS Compliance team through the Contact Us page.

If you have feedback about this post, submit comments in the Comments section below

Tariro Dongo
Tariro Dongo

Tari is a Security Assurance Program Manager at AWS, based in London. Tari is responsible for third-party and customer audits, attestations, certifications, and assessments across EMEA. Previously, Tari worked in security assurance and technology risk in the big four and financial services industry over the last 15 years.

Standardizing construct properties with AWS CDK Property Injection

Post Syndicated from Marco Frattallone original https://aws.amazon.com/blogs/devops/standardizing-construct-properties-with-aws-cdk-property-injection/

Standardizing CDK construct properties across a large organization requires repetitive manual effort that scales poorly as teams and repositories grow. Development teams working with AWS Cloud Development Kit (AWS CDK) must apply the same configuration properties across similar resources to meet security, compliance, and operational standards but manual configuration leads to drift, maintenance burden, and compliance gaps. In this post, you learn how to use Property Injection, a feature introduced in AWS CDK v2.196.0, to automatically apply default properties to constructs without modifying existing code.

The Challenge of Infrastructure Standardization

Organizations implementing infrastructure as code face a fundamental tension between developer productivity and operational consistency. CDK provides abstractions for defining cloud resources, but ensuring compliance with organizational security policies, compliance requirements, and operational standards requires repetitive manual configuration.
Consider this scenario: an organization’s security policy requires that all SecurityGroups disable outbound traffic by default. Development teams must apply these settings to every SecurityGroup:


new SecurityGroup(stack, 'api-sg', {
  vpc: myVpc,
  allowAllOutbound: false,        // Required by security policy
  allowAllIpv6Outbound: false     // Required by security policy
});

new SecurityGroup(stack, 'db-sg', {
  vpc: myVpc,
  allowAllOutbound: false,        // Same configuration repeated
  allowAllIpv6Outbound: false     // Same configuration repeated
});

This manual approach creates four specific problems:

  • Configuration drift: Teams omit required properties or apply them inconsistently
  • Maintenance burden: Policy updates require coordinated changes across multiple repositories and teams
  • Developer friction: Repetitive configuration tasks slow development velocity and increase cognitive load
  • Compliance gaps: Manual processes introduce human error, creating security or compliance violations

Custom construct libraries address these challenges but require refactoring every construct instantiation in existing code and create learning curves for development teams already familiar with standard CDK patterns.

Introducing Property Injection

AWS CDK Property Injection addresses these challenges by automatically applying default properties to constructs without requiring changes to existing code.

Property Injection is a feature introduced in AWS CDK v2.196.0 that intercepts construct creation and automatically applies organizational defaults. With this approach, you can enforce standards consistently while preserving existing development workflows and code patterns.

After implementing Property Injection, the same SecurityGroup creation requires only the vpc parameter, security defaults are applied automatically:

// Your existing code remains unchanged
new SecurityGroup(stack, 'my-sg', {
  vpc: myVpc
  // Security defaults applied automatically by Property Injection
});

The key benefits of this approach include:

  • Zero-impact adoption: Existing CDK code continues to work without modification
  • Centralized policy management: Standards are defined once and applied automatically
  • Consistent enforcement: Policies are applied uniformly across all applications and teams
  • Reduced maintenance overhead: Policy updates require changes in only one location
This diagram shows the five-step Property Injection process in a clear two-column format. The left column outlines each process step, while the right column shows the corresponding implementation details with properly formatted TypeScript code. The flow demonstrates how CDK intercepts SecurityGroup creation, applies organizational security defaults through property injectors, merges them with developer-specified properties, and creates a fully configured SecurityGroup that meets both developer requirements and organizational standards.

Figure 1: CDK Property Injection Mechanism

Property Injection operates transparently within CDK, intercepting construct creation to apply predefined defaults before merging them with any properties explicitly provided by developers. This ensures that organizational standards are consistently applied while maintaining the flexibility for developers to override defaults when specific use cases require it.

Understanding the Implementation Approach

Property Injection works by implementing the IPropertyInjector interface, which allows you to define default properties for specific construct types. These injectors are registered with CDK stacks and automatically apply their defaults during construct instantiation.
The implementation follows three steps: define the defaults you want to apply, register the injector with your stack, and let CDK handle the automatic application of these defaults to matching constructs.

Implementation Guide

This section shows you how to implement Property Injection for SecurityGroup constructs.

Step 1: Create a Property Injector

Create a class that implements the IPropertyInjector interface:

import { IPropertyInjector, InjectionContext } from 'aws-cdk-lib';
import { SecurityGroup, SecurityGroupProps } from 'aws-cdk-lib/aws-ec2';

export class SecurityGroupDefaults implements IPropertyInjector {
  readonly constructUniqueId: string;

  constructor() {
    this.constructUniqueId = SecurityGroup.PROPERTY_INJECTION_ID;
  }

  inject(originalProps: SecurityGroupProps, context: InjectionContext): SecurityGroupProps {
    return {
      // Apply organizational defaults
      allowAllIpv6Outbound: false,
      allowAllOutbound: false,
      // Original properties override defaults when specified
      ...originalProps,
    };
  }
}

Step 2: Add the Injector to Your Stack

Apply the injector to your CDK stack:

import { Stack } from 'aws-cdk-lib';
import { SecurityGroupDefaults } from './security-defaults';

const stack = new Stack(app, 'MyStack', {
  propertyInjectors: [
    new SecurityGroupDefaults()
  ]
});

Step 3: Use Constructs Normally

Create constructs as usual. The injector applies defaults automatically:

// This SecurityGroup receives the injected defaults:
// - allowAllOutbound: false
// - allowAllIpv6Outbound: false
new SecurityGroup(stack, 'my-sg', {
  vpc: myVpc
});

// You can override defaults when necessary
new SecurityGroup(stack, 'special-sg', {
  vpc: myVpc,
  allowAllOutbound: true  // Overrides the injected default
});
This side-by-side comparison shows the difference between manual configuration and Property Injection. The left side (Before) shows three SecurityGroup definitions, each requiring manual specification of allowAllOutbound: false and allowAllIpv6Outbound: false, leading to repetitive code, inconsistency risk, and maintenance burden. The right side (After) shows the same SecurityGroups created with the VPC parameter alone after a one-time Property Injection setup, demonstrating the DRY principle, consistent defaults, and reduced maintenance.

Figure 2: CDK Code Before vs After Property Injection

Property Injection vs L2 Constructs

You can achieve the same enforcement of default properties by creating custom L2 constructs with built-in defaults. However, Property Injection is better suited for standardizing existing codebases without refactoring, while L2 Constructs are better suited for new projects where you want custom APIs and multi-resource abstractions.

This decision tree guides the selection between Property Injection and L2 Constructs for CDK standardization. Starting with existing CDK applications, it evaluates willingness to accept potential breaking changes from new defaults. If breaking changes are acceptable or no existing code exists, it assesses whether custom APIs, naming improvements, or multi-resource patterns are needed beyond simple defaults. The tree leads to three outcomes: Property Injection (blue) for transparent defaults with existing code compatibility, L2 Constructs (orange) for custom APIs and purpose-built abstractions, or a Hybrid approach (green) combining both techniques for maximum flexibility.

Figure 3: Decision Tree – Property Injection vs L2 Constructs

Implementation Comparison

Consider an application with multiple SecurityGroup instantiations that need standardized security defaults.

L2 Construct approach requires creating a custom construct and updating each instantiation:

// Step 1: Create custom L2 construct
export class SecureSecurityGroup extends SecurityGroup {
  constructor(scope: Construct, id: string, props: SecurityGroupProps) {
    super(scope, id, {
      allowAllOutbound: false,
      allowAllIpv6Outbound: false,
      ...props
    });
  }
}

// Step 2: Update each instantiation throughout your codebase
// Change from:
new SecurityGroup(stack, 'sg1', { vpc: myVpc })
new SecurityGroup(stack, 'sg2', { vpc: myVpc })
new SecurityGroup(stack, 'sg3', { vpc: myVpc })

// To:
new SecureSecurityGroup(stack, 'sg1', { vpc: myVpc })
new SecureSecurityGroup(stack, 'sg2', { vpc: myVpc })
new SecureSecurityGroup(stack, 'sg3', { vpc: myVpc })

Property Injection approach requires one-time stack configuration:

// Step 1: Add injector to stack configuration
stack.propertyInjectors = [new SecurityGroupDefaults()];

// Step 2: Existing SecurityGroup calls receive defaults automatically
new SecurityGroup(stack, 'sg1', { vpc: myVpc })  // Gets defaults
new SecurityGroup(stack, 'sg2', { vpc: myVpc })  // Gets defaults  
new SecurityGroup(stack, 'sg3', { vpc: myVpc })  // Gets defaults

Key Differences

Property Injection works with existing construct calls, requiring no changes to how developers instantiate SecurityGroups or other constructs. This approach overrides constructs from external libraries and can be implemented without modifying existing code. Developers continue using familiar CDK APIs without learning new interfaces.

L2 Constructs require updating all constructor calls throughout your codebase. This approach cannot modify third-party construct creation since you must change each instantiation to use your custom construct. Implementation requires refactoring existing code and developers must learn your custom construct APIs instead of standard CDK interfaces. L2 constructs serve multiple purposes beyond complex business logic – simple L2 constructs provide domain-specific naming conventions and cleaner APIs, while complex L2 constructs orchestrate three or more resources and implement business rules.

When to Choose Each Approach

Choose Property Injection when you need to standardize existing infrastructure. Property Injection excels in scenarios where you already have CDK applications deployed and need to apply consistent defaults retroactively. Property Injection works transparently with existing code, requiring no changes to how developers instantiate constructs. This makes it useful when you have existing CDK applications that you want to standardize without disrupting current development workflows.

Property Injection also solves the challenge of applying defaults to constructs from third-party libraries. Since you cannot modify external library code, Property Injection enforces organizational standards on any construct type, regardless of its source. Additionally, when you want to implement standards without changing existing code, Property Injection operates at the framework level, automatically applying defaults during construct instantiation without requiring developers to modify their existing implementations.

Choose L2 Constructs when you need custom APIs or multi-resource patterns. L2 Constructs provide the right abstraction when you want to create purpose-built interfaces that differ from standard CDK APIs. This includes simple wrappers with domain-specific naming, complex business logic, validation rules, or multi-resource orchestration patterns. L2 Constructs excel when you want to create opinionated APIs that simplify common patterns by hiding complexity behind intuitive interfaces.

L2 Constructs suit new application development where you can design the API from the start. This approach creates purpose-built abstractions that match your organization’s specific use cases and terminology. Unlike Property Injection, which applies defaults to existing construct APIs, with L2 Constructs you can design entirely new APIs that directly represent your business domain and operational patterns.

Implementation Patterns

Stack Integration Methods

The CDK provides two methods for adding Property Injectors to stacks:

This diagram demonstrates two methods for adding Property Injectors to CDK stacks. Method 1 (blue) shows adding injectors directly in the Stack constructor’s propertyInjectors array. Method 2 (orange) shows using PropertyInjectors.of(stack).add() after stack creation. Both methods produce identical results with green checkmarks indicating success. The diagram includes usage examples showing normal SecurityGroup instantiation (blue) that inherits defaults automatically, and override scenarios (orange) where developers explicitly override injected defaults. The bottom section shows the resulting CloudFormation output: default SecurityGroups have empty egress rules (green), while overridden ones include outbound traffic rules (orange).

Figure 4: CDK Stack Integration Methods

Method 1: Stack Constructor

const stack = new Stack(app, 'MyStack', {
  propertyInjectors: [new SecurityGroupDefaults()]
});

Method 2: PropertyInjectors.of()

const stack = new Stack(app, 'MyStack');
PropertyInjectors.of(stack).add(new SecurityGroupDefaults());

Both methods produce the same result. Choose the method that best fits your existing code structure. For more details, see the PropertyInjectors API documentation.

Organization-Wide Implementation

For organization-wide standardization, create a shared library of injectors:

// @myorg/cdk-injectors package
export const ORGANIZATION_INJECTORS: IPropertyInjector[] = [
  new SecurityGroupDefaults(),
  new LambdaFunctionDefaults(),
  new S3BucketDefaults(),
];

// Teams import and use the shared injectors
import { ORGANIZATION_INJECTORS } from '@myorg/cdk-injectors';

const stack = new Stack(app, 'TeamStack', {
  propertyInjectors: ORGANIZATION_INJECTORS
});

Scope Hierarchy

Property Injectors can be applied at different levels in the CDK construct tree:

This diagram illustrates the three-level hierarchy of Property Injector scopes in CDK with integrated resolution examples. The App level (blue) shows a BucketInjector ‘b1’ that applies globally, with an example showing how Stack2 buckets use this injector. The Stage level (green) demonstrates a FunctionInjector ‘f1’ that applies to all stacks within the stage, including an example of Stack1 functions using this injector. The Stack level (orange) shows two stacks: Stack1 with its own BucketInjector ‘b2’ that overrides the app-level injector, and Stack2 with no injectors that inherits from parent scopes. The Resolution Rules box (green) explains that CDK searches from most specific (stack) to most general (app), with the first match winning per construct type. Arrows show the hierarchical relationship between scopes.

    Figure 5: CDK Scope Hierarchy & Injector Resolution
  • App level: Applies to all stacks in the application
  • Stage level: Applies to all stacks within a specific stage
  • Stack level: Applies only to constructs within a specific stack

CDK searches for applicable injectors starting from the construct’s immediate parent scope and moving upward. The first matching injector for each construct type is used.

Best Practices

When implementing Property Injection, begin with high-impact constructs like SecurityGroups, VPCs, and Lambda functions that require repetitive configuration.

These constructs have the highest frequency of misconfiguration and the most direct compliance impact, making them the most valuable targets for early adoption.

Document your defaults by explaining what properties your injectors provide and why. Include examples and link to relevant policies that drive the requirements. With this documentation, developers can understand standards and make informed override decisions.

Write automated tests using CDK testing utilities to verify that injectors apply expected defaults. Test both standard scenarios and cases where developers override properties to prevent regressions when updating injector logic.

Version injectors carefully using semantic versioning principles because changes affect all applications. Coordinate updates across teams and provide migration guides for breaking changes or changes to default values.

Design override mechanisms so that developers can handle edge cases while benefiting from organizational standards. Property Injection operates as defaults, not restrictions, so design injectors to merge gracefully with developer-specified properties.

Limitations and Considerations

Property Injection operates as a default mechanism rather than a compliance enforcement system. Developers retain the ability to override injected properties, which means organizations cannot rely solely on Property Injection for strict compliance requirements. For teams that need mandatory compliance, combine Property Injection with CDK Aspects or AWS Config rules to validate and enforce standards.

The feature works exclusively with L2 constructs, as documented in the official AWS CDK guidance. The IPropertyInjector interface targets specific L2 construct types, and L1 (CloudFormation) constructs use different instantiation patterns that bypass the property injection mechanism entirely. Organizations with L1 construct usage need alternative standardization approaches.

Property Injection introduces debugging complexity because injected properties do not appear directly in application code. Developers troubleshooting construct behavior must understand which injectors apply to specific construct types and how those injectors modify properties. This hidden behavior requires documentation that lists each injector, the properties it sets, and the policy it enforces, along with clear naming conventions to maintain code clarity.

The feature requires CDK v2.196.0 or later, which affects adoption timelines for organizations using older CDK versions. Teams must plan upgrade paths and test compatibility before implementing Property Injection across their applications.

Conclusion

Property Injection provides a mechanism for applying consistent default properties to CDK constructs without requiring changes to existing code. This approach reduces repetitive configuration, improves consistency, and simplifies maintenance of CDK applications.
Property Injection is the right choice for organizations that need to standardize construct configurations across existing codebases while preserving developer workflows. When combined with proper testing and documentation, Property Injection becomes a reliable foundation for infrastructure governance across your organization.

About the authors:

Put Cheung

Put Cheung is a Senior Software Development Engineer at AWS Security. He is a part of a team that is making it easier for builders to configure AWS Resources securely. AWS CDK Property Injection is an important step toward this goal.

Rico Huijbers

Rico Huijbers is a Software Engineer at Amazon Web Services. He is extremely lazy and is therefore on a quest to eradicate the need for repetitive manual work from software engineering. Rico loves working on AWS CDK—it’s the tool he wishes he had 5 years earlier.

Marco Frattallone

Marco Frattallone is a Senior Technical Account Manager at AWS focused on supporting Partners. He works closely with Partners to help them build, deploy, and optimize their solutions on AWS, providing guidance and leveraging best practices. Marco focuses on helping Partners adopt emerging AWS services and translate technical capabilities into business outcomes. Outside work, he enjoys outdoor cycling, sailing, and exploring new cultures.

Israel Hacked Traffic Cameras in Iran

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2026/03/israel-hacked-traffic-cameras-in-iran.html

Multiple news outlets are reporting on Israel’s hacking of Iranian traffic cameras and how they assisted with the killing of that country’s leadership.

The New York Times has an on the intelligence operation more generally.

The collective thoughts of the interwebz