Tag Archives: Uncategorized

Trojans Embedded in .svg Files

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2025/08/trojans-embedded-in-svg-files.html

Porn sites are hiding code in .svg files:

Unpacking the attack took work because much of the JavaScript in the .svg images was heavily obscured using a custom version of “JSFuck,” a technique that uses only a handful of character types to encode JavaScript into a camouflaged wall of text.

Once decoded, the script causes the browser to download a chain of additional obfuscated JavaScript. The final payload, a known malicious script called Trojan.JS.Likejack, induces the browser to like a specified Facebook post as long as a user has their account open.

“This Trojan, also written in Javascript, silently clicks a ‘Like’ button for a Facebook page without the user’s knowledge or consent, in this case the adult posts we found above,” Malwarebytes researcher Pieter Arntz wrote. “The user will have to be logged in on Facebook for this to work, but we know many people keep Facebook open for easy access.”

This isn’t a new trick. We’ve seen Trojaned .svg files before.

LLM Coding Integrity Breach

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2025/08/llm-coding-integrity-breach.html

Here’s an interesting story about a failure being introduced by LLM-written code. Specifically, the LLM was doing some code refactoring, and when it moved a chunk of code from one file to another it changed a “break” to a “continue.” That turned an error logging statement into an infinite loop, which crashed the system.

This is an integrity failure. Specifically, it’s a failure of processing integrity. And while we can think of particular patches that alleviate this exact failure, the larger problem is much harder to solve.

Davi Ottenheimer comments.

The Compliance Arms Race: What GovRAMP Means for SLED, Cloud Vendors, and the Rest of Us

Post Syndicated from Kari Rivas original https://www.backblaze.com/blog/the-compliance-arms-race-what-govramp-means-for-sled-cloud-vendors-and-the-rest-of-us/

A decorative image showing a server, a NAS, and a computer.

If you’ve spent any time sourcing, evaluating, or speculating about cloud services in the public sector lately, you’ve likely felt it: the arms race happening in compliance. Courting customers from schools to statehouses to national labs, more and more cloud vendors are racing to pin the next security badge to their lapel—GovRAMP (formerly known as StateRAMP), TX-RAMP, FedRAMP, SOC 2, and on and on.

And while it might feel like a compliance bingo card, there’s real strategy and real consequences behind this sprint. At the heart of it all is the SLED market (state and local government, and education)—a sprawling patchwork of institutions tasked with safeguarding citizen data and taxpayer trust, all while operating with limited resources and infrastructure budgets.

Let’s talk about why this compliance arms race exists, what it means for buyers and vendors alike, and how we at Backblaze are choosing to compete not just with checkboxes, but with character.

Why does SLED even need unified standards?

Public sector IT has long been a security quilt. Some agencies stitched up with advanced defenses, others more… threadbare. While some may have advanced security tooling, a K–12 school district might still be running on legacy systems and duct tape. Yet both manage data that’s increasingly digital, distributed, and vulnerable.

The result? Inconsistent practices and rising risks. Enter: GovRAMP.

What is GovRAMP?

Short for Government Risk and Authorization Management Program, GovRAMP was customized to standardize cloud security for state and local agencies. It’s actually based on the same set of controls for FedRAMP—controls derived from the National Institute of Standards and Technology (NIST) SP 800-53, a catalog of controls for organizations to manage cybersecurity and privacy risk. GovRAMP ensures that even the smallest public institutions can procure secure IT solutions without reinventing the wheel every time.

GovRAMP was originally launched as StateRAMP, but has since grown beyond state lines, evolving into a broader framework adopted by local governments and school systems. Today, it’s a rigorous, independent audit program that holds vendors to a high set of security controls. Translation: If a vendor is GovRAMP-authorized, they’re playing in the big leagues of cloud security.

The alphabet soup of compliance: TX-RAMP, GovRAMP, FedRAMP

If you’re in Texas, you’re probably familiar with TX-RAMP, the state’s specific compliance framework. The good news? GovRAMP and TX-RAMP are closely aligned. At Backblaze, our GovRAMP Progressing Snapshot status qualifies us for TX-RAMP Provisional Authorization as well—one less hurdle for Texas agencies seeking secure, scalable cloud storage.

As for FedRAMP, it remains the gold standard for federal data, but for the vast majority of public sector orgs, including most SLED agencies, it’s simply unnecessary.

How GovRAMP streamlines cloud sourcing

Here’s where the compliance arms race actually makes things easier: Once a vendor is authorized through GovRAMP, SLED buyers can trust that the solution meets certain security standards, saving months of one-off vetting, paperwork, and duplicated audits. In a procurement environment plagued by inefficiency, that’s no small thing.

Especially now, as budgets tighten and AI-driven everything drives demand for flexible infrastructure, reducing sourcing friction matters more than ever.

Going beyond checklists: What buyers should really look for

Checkboxes alone don’t guarantee real-world resilience. Compliance can become its own form of security theater. It looks good on paper but falls short in practice. That’s why buyers should dig deeper.

Look for vendors who not only pass audits but live and breathe their controls. That means going beyond annual assessments and embracing security as a continuous, integrated discipline. The best partners are transparent, proactive, and thoughtful about risk—not just checking boxes, but building real-world resilience. Here are a few signs to look for:

  • Continuous monitoring and internal audits: They treat compliance as an ongoing process, not a once-a-year scramble.
  • Clear, accessible documentation: Security policies, certifications, and standardized independent attestations are available (under NDA if needed), not locked in a black box.
  • Transparent data practices: They’re upfront about where your data lives, who can access it, and what happens in the event of an incident. 
  • Responsive support: You can communicate with real people who understand your risk profile—not just surface-level answers or automated replies.
  • Affordable recoveries: They don’t make recovering your data prohibitively expensive. Look at their egress policies and price out what it would actually cost to retrieve your data.

When you’re responsible for protecting sensitive data, it’s not enough to be compliant. You need a partner who’s disciplined, trustworthy, and invested in your resilience.

The Backblaze approach: Rigor, transparency, and trust

Pursuing authorizations like GovRAMP and TX-RAMP isn’t easy, but it’s the right thing to do and we’re committed to the process. We believe public sector buyers deserve cloud partners who understand their constraints, meet them where they are, and still bring best-in-class solutions to the table.

But more than that, we’re not stopping at frameworks. Compliance is a floor, not a ceiling. We’ve built our platform on decades of operational rigor and security discipline—not to impress auditors, but to earn your trust. And we’ve structured our products to enable security best practices, not hinder them, including 3x free egress for disaster recovery.

So yes, we’re proudly in the compliance race. But we’re not just chasing badges. We’re building something secure, sustainable, and ready for whatever comes next.

Want to learn more about our GovRAMP journey or how Backblaze supports public sector cloud transformation? Reach out to our Sales team.

The post The Compliance Arms Race: What GovRAMP Means for SLED, Cloud Vendors, and the Rest of Us appeared first on Backblaze Blog | Cloud Storage & Cloud Backup

SIGINT During World War II

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2025/08/sigint-during-world-war-ii.html

The NSA and GCHQ have jointly published a history of World War II SIGINT: “Secret Messengers: Disseminating SIGINT in the Second World War.” This is the story of the British SLUs (Special Liaison Units) and the American SSOs (Special Security Officers).

The “Incriminating Video” Scam

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2025/08/the-incriminating-video-scam.html

A few years ago, scammers invented a new phishing email. They would claim to have hacked your computer, turned your webcam on, and videoed you watching porn or having sex. BuzzFeed has an article talking about a “shockingly realistic” variant, which includes photos of you and your house—more specific information.

The article contains “steps you can take to figure out if it’s a scam,” but omits the first and most fundamental piece of advice: If the hacker had incriminating video about you, they would show you a clip. Just a taste, not the worst bits so you had to worry about how bad it could be, but something. If the hacker doesn’t show you any video, they don’t have any video. Everything else is window dressing.

I remember when this scam was first invented. I calmed several people who were legitimately worried with that one fact.

Blue/Green Deployments with Amazon Elastic Container Service

Post Syndicated from Nathan Taber original https://aws.amazon.com/blogs/compute/bluegreen-deployments-with-amazon-ecs/

This post and accompanying code was generously contributed by:

Jeremy Cowan
Solutions Architect		 Anuj Sharma
DevOps Cloud Architect		 Peter Dalbhanjan
Solutions Architect

Deploying software updates in traditional non-containerized environments is hard and fraught with risk. When you write your deployment package or script, you have to assume that the target machine is in a particular state. If your staging environment is not an exact mirror image of your production environment, your deployment could fail. These failures frequently cause outages that persist until you re-deploy the last known good version of your application. If you are an Operations Manager, this is what keeps you up at night.

Increasingly, customers want to do testing in production environments without exposing customers to the new version until the release has been vetted. Others want to expose a small percentage of their customers to the new release to gather feedback about a feature before it’s released to the broader population. This is often referred to as canary analysis or canary testing. In this post, I introduce patterns to implement blue/green and canary deployments using Application Load Balancers and target groups.

If you’d like to try this approach to blue/green deployments, we have open sourced the code and AWS CloudFormation templates in the ecs-blue-green-deployment GitHub repo. The workflow builds an automated CI/CD pipeline that deploys your service onto an ECS cluster and offers a controlled process to swap target groups when you’re ready to promote the latest version of your code to production. You can quickly set up the environment in three steps and see the blue/green swap in action. We’d love for you to try it and send us your feedback!

What are blue/green deployments?

Blue/green deployments are a type of immutable deployment used to deploy software updates with less risk by creating two separate environments, blue and green. “Blue” is the current running version of your application and “green” is the new version of your application you will deploy.

This type of deployment gives you an opportunity to test features in the green environment without impacting the current running version of your application. When you’re satisfied that the green version is working properly, you can gradually reroute the traffic from the old blue environment to the new green environment by modifying DNS. By following this method, you can update and roll back features with near zero downtime.

A typical blue/green deployment involves shifting traffic between 2 distinct environments.

This ability to quickly roll traffic back to the still-operating blue environment is one of the key benefits of blue/green deployments. With blue/green, you should be able to roll back to the blue environment at any time during the deployment process. This limits downtime to the time it takes to realize there’s an issue in the green environment and shift the traffic back to the blue environment. Furthermore, the impact of the outage is limited to the portion of traffic going to the green environment, not all traffic. If the blast radius of deployment errors is reduced, so is the overall deployment risk.

Containers make it simpler

Historically, blue/green deployments were not often used to deploy software on-premises because of the cost and complexity associated with provisioning and managing multiple environments. Instead, applications were upgraded in place.

Although this approach worked, it had several flaws, including the ability to roll back quickly from failures. Rollbacks typically involved re-deploying a previous version of the application, which could affect the length of an outage caused by a bad release. Fixing the issue took precedence over the need to debug, so there were fewer opportunities to learn from your mistakes.

Containers can ease the adoption of blue/green deployments because they’re easily packaged and behave consistently as they’re moved between environments. This consistency comes partly from their immutability. To change the configuration of a container, update its Dockerfile and rebuild and re-deploy the container rather than updating the software in place.

Containers also provide process and namespace isolation for your applications, which allows you to run multiple versions of them side by side on the same Docker host without conflicts. Given their small sizes relative to virtual machines, you can binpack more containers per host than VMs. This lets you make more efficient use of your computing resources, reducing the cost of blue/green deployments.

Fully Managed Updates with Amazon ECS

Amazon Elastic Container Service (ECS) performs rolling updates when you update an existing Amazon ECS service. A rolling update involves replacing the current running version of the container with the latest version. The number of containers Amazon ECS adds or removes from service during a rolling update is controlled by adjusting the minimum and maximum number of healthy tasks allowed during service deployments.

When you update your service’s task definition with the latest version of your container image, Amazon ECS automatically starts replacing the old version of your container with the latest version. During a deployment, Amazon ECS drains connections from the current running version and registers your new containers with the Application Load Balancer as they come online.

Target groups

A target group is a logical construct that allows you to run multiple services behind the same Application Load Balancer. This is possible because each target group has its own listener.

When you create an Amazon ECS service that’s fronted by an Application Load Balancer, you have to designate a target group for your service. Ordinarily, you would create a target group for each of your Amazon ECS services. However, the approach we’re going to explore here involves creating two target groups: one for the blue version of your service, and one for the green version of your service. We’re also using a different listener port for each target group so that you can test the green version of your service using the same path as the blue service.

With this configuration, you can run both environments in parallel until you’re ready to cut over to the green version of your service. You can also do things such as restricting access to the green version to testers on your internal network, using security group rules and placement constraints. For example, you can target the green version of your service to only run on instances that are accessible from your corporate network.

Swapping Over

When you’re ready to replace the old blue service with the new green service, call the ModifyListener API operation to swap the listener’s rules for the target group rules. The change happens within a few seconds. Afterward, the green service is running in the target group with the port 80 listener and the blue service is running in the target group with the port 8080 listener. The diagram below is an illustration of the approach described.

Scenario

Two services are defined, each with their own target group registered to the same Application Load Balancer but listening on different ports. Deployment is completed by swapping the listener rules between the two target groups.

The second service is deployed with a new target group listening on a different port but registered to the same Application Load Balancer.

By using 2 listeners, requests to blue services are directed to the target group with the port 80 listener, while requests to the green services are directed to target group with the port 8080 listener.

After automated or manual testing, the deployment can be completed by swapping the listener rules on the Application Load Balancer and sending traffic to the green service.

Caveats

There are a few caveats to be mindful of when using this approach. This method:

  • Assumes that your application code is completely stateless. Store state outside of the container.
  • Doesn’t gracefully drain connections. The swapping of target groups is sudden and abrupt. Therefore, be cautious about using this approach if your service has long-running transactions.
  • Doesn’t allow you to perform canary deployments. While the method gives you the ability to quickly switch between different versions of your service, it does not allow you to divert a portion of the production traffic to a canary or control the rate at which your service is deployed across the cluster.

Canary testing

While this type of deployment automates much of the heavy lifting associated with rolling deployments, it doesn’t allow you to interrupt the deployment if you discover an issue midstream. Rollbacks using the standard Amazon ECS deployment require updating the service’s task definition with the last known good version of the container. Then, you wait for Amazon ECS to schedule and deploy it across the cluster. If the latest version introduces a breaking change that went undiscovered during testing, this might be too slow.

With canary testing, if you discover the green environment is not operating as expected, there is no impact on the blue environment. You can route traffic back to it, minimizing impaired operation or downtime, and limiting the blast radius of impact.

This type of deployment is particularly useful for A/B testing where you want to expose a new feature to a subset of users to get their feedback before making it broadly available.

For canary style deployments, you can use a variation of the blue/green swap that involves deploying the blue and the green service to the same target group. Although this method is not as fast as the swap, it allows you to control the rate at which your containers are replaced by adjusting the task count for each service. Furthermore, it gives you the ability to roll back by adjusting the number of tasks for the blue and green services respectively. Unlike the swap approach described above, connections to your containers are drained gracefully. We plan to address canary style deployments for Amazon ECS in a future post.

Conclusion

With AWS, you can operationalize your blue/green deployments using Amazon ECS, an Application Load Balancer, and target groups. I encourage you to adapt the code published to the ecs-blue-green-deployment GitHub repo for your use cases and look forward to reading your feedback.

If you’re interested in learning more, I encourage you to read the Blue/Green Deployments on AWS and Practicing Continuous Integration and Continuous Delivery on AWS whitepapers.

If you have questions or suggestions, please comment below.

Google Project Zero Changes Its Disclosure Policy

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2025/08/google-project-zero-changes-its-disclosure-policy.html

Google’s vulnerability finding team is again pushing the envelope of responsible disclosure:

Google’s Project Zero team will retain its existing 90+30 policy regarding vulnerability disclosures, in which it provides vendors with 90 days before full disclosure takes place, with a 30-day period allowed for patch adoption if the bug is fixed before the deadline.

However, as of July 29, Project Zero will also release limited details about any discovery they make within one week of vendor disclosure. This information will encompass:

  • The vendor or open-source project that received the report
  • The affected product
  • The date the report was filed and when the 90-day disclosure deadline expires

I have mixed feelings about this. On the one hand, I like that it puts more pressure on vendors to patch quickly. On the other hand, if no indication is provided regarding how severe a vulnerability is, it could easily cause unnecessary panic.

The problem is that Google is not a neutral vulnerability hunting party. To the extent that it finds, publishes, and reduces confidence in competitors’ products, Google benefits as a company.

China Accuses Nvidia of Putting Backdoors into Their Chips

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2025/08/china-accuses-nvidia-of-putting-backdoors-into-their-chips.html

The government of China has accused Nvidia of inserting a backdoor into their H20 chips:

China’s cyber regulator on Thursday said it had held a meeting with Nvidia over what it called “serious security issues” with the company’s artificial intelligence chips. It said US AI experts had “revealed that Nvidia’s computing chips have location tracking and can remotely shut down the technology.”

The Semiconductor Industry and Regulatory Compliance

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2025/08/its-time-for-the-semiconductor-industry-to-step-up.html

Earlier this week, the Trump administration narrowed export controls on advanced semiconductors ahead of US-China trade negotiations. The administration is increasingly relying on export licenses to allow American semiconductor firms to sell their products to Chinese customers, while keeping the most powerful of them out of the hands of our military adversaries. These are the chips that power the artificial intelligence research fueling China’s technological rise, as well as the advanced military equipment underpinning Russia’s invasion of Ukraine.

The US government relies on private-sector firms to implement those export controls. It’s not working. US-manufactured semiconductors have been found in Russian weapons. And China is skirting American export controls to accelerate AI research and development, with the explicit goal of enhancing its military capabilities.

American semiconductor firms are unwilling or unable to restrict the flow of semiconductors. Instead of investing in effective compliance mechanisms, these firms have consistently prioritized their bottom lines—a rational decision, given the fundamentally risky nature of the semiconductor industry.

We can’t afford to wait for semiconductor firms to catch up gradually. To create a robust regulatory environment in the semiconductor industry, both the US government and chip companies must take clear and decisive actions today and consistently over time.

Consider the financial services industry. Those companies are also heavily regulated, implementing US government regulations ranging from international sanctions to anti-money laundering. For decades, these companies have invested heavily in compliance technology. Large banks maintain teams of compliance employees, often numbering in the thousands.

The companies understand that by entering the financial services industry, they assume the responsibility to verify their customers’ identities and activities, refuse services to those engaged in criminal activity, and report certain activities to the authorities. They take these obligations seriously because they know they will face massive fines when they fail. Across the financial sector, the Securities and Exchange Commission imposed a whopping $6.4 billion in penalties in 2022. For example, TD Bank recently paid almost $2 billion in penalties because of its ineffective anti-money laundering efforts

An executive order issued earlier this year applied a similar regulatory model to potential “know your customer” obligations for certain cloud service providers.

If Trump’s new license-focused export controls are to be effective, the administration must increase the penalties for noncompliance. The Commerce Department’s Bureau of Industry and Security (BIS) needs to more aggressively enforce its regulations by sharply increasing penalties for export control violations.

BIS has been working to improve enforcement, as evidenced by this week’s news of a $95 million penalty against Cadence Design Systems for violating export controls on its chip design technology. Unfortunately, BIS lacks the people, technology, and funding to enforce these controls across the board.

The Trump administration should also use its bully pulpit, publicly naming companies that break the rules and encouraging American firms and consumers to do business elsewhere. Regulatory threats and bad publicity are the only ways to force the semiconductor industry to take export control regulations seriously and invest in compliance.

With those threats in place, American semiconductor firms must accept their obligation to comply with regulations and cooperate. They need to invest in strengthening their compliance teams and conduct proactive audits of their subsidiaries, their customers, and their customers’ customers.

Firms should elevate risk and compliance voices onto their executive leadership teams, similar to the chief risk officer role found in banks. Senior leaders need to devote their time to regular progress reviews focused on meaningful, proactive compliance with export controls and other critical regulations, thereby leading their organizations to make compliance a priority.

As the world becomes increasingly dangerous and America’s adversaries become more emboldened, we need to maintain stronger control over our supply of critical semiconductors. If Russia and China are allowed unfettered access to advanced American chips for their AI efforts and military equipment, we risk losing the military advantage and our ability to deter conflicts worldwide. The geopolitical importance of semiconductors will only increase as the world becomes more dangerous and more reliant on advanced technologies—American security depends on limiting their flow.

This essay was written with Andrew Kidd and Celine Lee, and originally appeared in The National Interest.

First Sentencing in Scheme to Help North Koreans Infiltrate US Companies

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2025/08/first-sentencing-in-scheme-to-help-north-koreans-infiltrate-us-companies.html

An Arizona woman was sentenced to eight-and-a-half years in prison for her role helping North Korean workers infiltrate US companies by pretending to be US workers.

From an article:

According to court documents, Chapman hosted the North Korean IT workers’ computers in her own home between October 2020 and October 2023, creating a so-called “laptop farm” which was used to make it appear as though the devices were located in the United States.

The North Koreans were hired as remote software and application developers with multiple Fortune 500 companies, including an aerospace and defense company, a major television network, a Silicon Valley technology company, and a high-profile company.

As a result of this scheme, they collected over $17 million in illicit revenue paid for their work, which was shared with Chapman, who processed their paychecks through her financial accounts.

“Chapman operated a ‘laptop farm’ where she received and hosted computers from the U.S. companies her home, so that the companies would believe the workers were in the United States,” the Justice Department said on Thursday.

“Chapman also shipped 49 laptops and other devices supplied by U.S. companies to locations overseas, including multiple shipments to a city in China on the border with North Korea. More than 90 laptops were seized from Chapman’s home following the execution of a search warrant in October 2023.”

За Аркадий Хайт, леля Миня и…

Post Syndicated from Григор original http://www.gatchev.info/blog/?p=2668

Аркадий Хайт е съветски и руски писател, хуморист, сценарист. Половината от писателското дуо Курляндский и Хайт – автори на сценария за любимия на децата по съветско време „Ну, погоди!“ и купища хумористични разкази.

Днес мярнах в Нета една негова история, която не мога да се сдържа да не открадна и преведа. С уважение към таланта му – и таланта на леля Миня.

—-

Мина Мойсеевна, или просто леля Миня, беше съседка по жилище на мой приятел, режисьор в киностудия „Горки“. Той и ни запозна.

– Мина Мойсеевна, знаете ли кой е това? Това е Хайт!

– Е и какво? – беше отговорът ѝ. – Да застана „мирно“? Или да ходя да си мия врата?

– Не е нужно – казах аз. – Можете да ходите и с мръсен.

– Ой, какъв язвителен младеж! Жалко че не знаех, че ще имам толкова важен гост. Щях да взема нещо специално към чая. Вие как го предпочитате – без вишнево сладко или без ягодово?

– Без малиново, ако може.

– Разбира се? Имам всичко.

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

Като видя днес на сцената Клара Новикова като нейната леля Соня, чиито монолози ги пишат най-добрите хумористи, си мисля – ами леля Миня? На нея никой не ѝ пишеше репликите, тя си ги измисляше сама.

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

– Къде съм попаднал?

– А къде сте се целили? – пита леля Миня.

Макар че беше по душа стопроцентова еврейка, не можеше да търпи разговори какви сме потресаващо умни:

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

(Руският еквивалент на института „Пирогов“ у нас – Григор.)

Специално почвах да я дразня:

– Ние не сме ли избран народ?

– Ние с вас – да! Но някои евреи май са ги избирали с пряко и тайно гласуване, като нашия Върховен съвет на СССР.

Време е да кажем какво работеше леля Миня. Беше професионална сватовница. Днес, в епохата на брачните обяви и електронните комуникации, тази професия изглежда забравена. Но не и за тези, които познаваха Мина Мойсеевна.

– Човек трябва да умее да си хвали стоката – казваше тя. – Рекламата е голяма работа. Погледнете кокошката като снесе яйце как кудкудяка, колко врява вдига. Патицата снася без нито един звук. А резултатът? Кокошите яйца ги купува всеки, а за пачите никой не е и чувал. Нямат звукова реклама!

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

– Ало? Какво? Да, помня ви, Володя. Та, какво търсите?… Млада? Красива? И какво още, богата? Не разбирам, на вас три жени ли ви трябват? Аха, една! Ама да има всичко това. Ясно. Извинете, а вие какъв сте? Каква ви е професията? Учител по зоология? Ми вие сте като лебед бе, скъпи. Един дълъг врат и голо дупе. Добре, звънете, ще ви търсим…

-Ало? Кой се обажда? Роза Григориевна? Буцкес ли ви пращаше? Много ми е приятно. А какво искате?… Жених? За кого, за внучката? Не? А за дъщерята ли? А, за вас! Интересно… Ако не е тайна, на колко години сте? 36? А преди колко години ги навършихте?… Добре, добре, ще търсим. Току-виж изкопаем нещо…

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

Казваше ми понякога:

– Жалко, че не те познавах по-рано. Щях да ти намеря хубава жена.

– Аз и сам съм си намерил.

– Не споря! Ама щях да ти намеря също такава, и плюс това еврейка.

– Ако толкова ви бива, защо не сте си намерили хубав мъж евреин?

– Я стига! Не ми сипвай сол в захарта. С моя Миша отдавна се разделихме.

– И защо, ако не е тайна?

– Хъркаше.

– Какво, за такава дреболия?!

– Да, ама той хъркаше всеки път с различна…

Когато Мина Мойсеевна навърши 75 години, тя взе най-важното решение в живота си – да емигрира в Израел. Всичките ѝ приятелки я убеждаваха да се откаже:

– Миночка, къде сте тръгнала на тия години? Да живеете сред непознати! И плюс това, там всички са ционисти…

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

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

На следващия ден още призори телефонът в стаята ми звънна:

– Ало, това великият руски писател Шолохов-Алейхем ли е?

– Леля Миня! – извиках аз. – Вие ли сте?

– Ами да! Какво се чудиш, все едно ти е звъннал Ясер Арафат?

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

– Всичко си е както преди – каза тя, проследила погледа ми. – Даже професията ми си е същата.

– Как? И тук сте сватовница?!

– Защо не? И тук има женихи и невести за свързване. Да свържем двата края, както се казва…

По-нататък денят продължи под акомпанимента на непрекъснатите телефонни разговори на леля Миня:

– Ало? Слушам? Да, помня ви. Дето искахте невеста с добра зестра. Ами, можете вече да си направите сметка в банка „Хипоалим“, намерих ви невеста. Дават за нея 50 хиляди шекела. Какво искате? Да ѝ видите снимката? Скъпи мой, за такива пари снимка не показвам. Като получите зестрата си купете фотоапарат и я снимайте докато побирате!

– Ало? Бокер тов, геверет! – Тя задърдори на иврит като картечница. След малко остави слушалката и отбеляза: – Ненормална румънска еврейка. Пълна с пари, та не ѝ е останало място за акъл. Не иска блондин, не иска брюнет, задължително да е риж!… Откъде да знам защо? Може да има спалня от червено дърво и да си търси мъж в тон с нея…

– Ало?… Ама какво сте се развикали, кой ви е измамил?… Ама аз ви казах, че тя има дете… Какъв позор? Какво му е позорното?… Е и какво като детето се е родило преди сватбата? То откъде да знае кога ще е сватбата?!…

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

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

– Имам за вас страхотна невяста! Даже не прилича на чукча, по-скоро на японка!… Каква зестра бе, какви елени?!… Ох, този си е изгубил акъла! Аз такава красавица му предлагам, той елени иска! Оженете се за нея и ще ви пораснат повече рога, отколкото на всичките ви елени!

… Леля Миня вече я няма сред нас. По наш обичай не бива на умрелите да се носят цветя. Но никой не е казвал, че не бива да им се подаряват разкази. Написах този в памет на Мина Мойсеевна и ми е жал само че тя няма да го чуе. Щеше да каже:

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

Spying on People Through Airportr Luggage Delivery Service

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2025/08/spying-on-people-through-airportr-luggage-delivery-service.html

Airportr is a service that allows passengers to have their luggage picked up, checked, and delivered to their destinations. As you might expect, it’s used by wealthy or important people. So if the company’s website is insecure, you’d be able to spy on lots of wealthy or important people. And maybe even steal their luggage.

Researchers at the firm CyberX9 found that simple bugs in Airportr’s website allowed them to access virtually all of those users’ personal information, including travel plans, or even gain administrator privileges that would have allowed a hacker to redirect or steal luggage in transit. Among even the small sample of user data that the researchers reviewed and shared with WIRED they found what appear to be the personal information and travel records of multiple government officials and diplomats from the UK, Switzerland, and the US.

“Anyone would have been able to gain or might have gained absolute super-admin access to all the operations and data of this company,” says Himanshu Pathak, CyberX9’s founder and CEO. “The vulnerabilities resulted in complete confidential private information exposure of all airline customers in all countries who used the service of this company, including full control over all the bookings and baggage. Because once you are the super-admin of their most sensitive systems, you have have [sic] the ability to do anything.”

AI-Driven Development Life Cycle: Reimagining Software Engineering

Post Syndicated from Raja SP original https://aws.amazon.com/blogs/devops/ai-driven-development-life-cycle/

Business and technology leaders are constantly striving to improve productivity, increase velocity, foster experimentation, reduce time-to-market (TTM), and enhance the developer experience. These North Star goals drive innovation in software development practices. This innovation is increasingly being powered by artificial intelligence. Particularly, generative AI powered tools such as Amazon Q Developer and Kiro have already begun to revolutionize how software is created. As things stand, organizations employ AI in software development through two primary approaches: AI-assisted development, where AI enhances specific tasks like documentation, code completion, and testing; and AI-autonomous development, where AI generates entire applications with human oversight.

Why do we need a transformative approach to AI in software?

Our existing software development methods, are designed for human-driven, long running processes, with product owners, developers, architects alike spending most of their time on non-core activities such as planning, meetings, and other software development lifecycle (SDLC) rituals. Simply retrofitting AI as an assistant not only constrains its capabilities but also reinforces outdated inefficiencies. To truly harness AI’s power and achieve the productivity North Star goals, we need to reimagine our entire approach to the software development lifecycle.

To achieve transformative results, we need to position AI as a central collaborator and teammate in the development process, and leverage its capabilities throughout the software development lifecycle. This is why we’re introducing the AI-Driven Development Lifecycle (AI-DLC), a new methodology designed to fully ingrain AI capabilities into the very fabric of software development.

What is AI Driven Development Life Cycle (AI-DLC)?

AI-DLC is an AI-centric transformative approach to software development that emphasizes two powerful dimensions:

  • AI Powered Execution with Human Oversight: AI systematically creates detailed work plans, actively seeks clarification and guidance, and defers critical decisions to humans. This is critical since only humans possess the contextual understanding and knowledge of business requirements needed to make informed choices.
  • Dynamic Team Collaboration: As AI handles the routine tasks, teams unite in collaborative spaces for real-time problem solving, creative thinking and rapid-decision-making. This shift from isolated work to high-energy teamwork accelerates innovation and delivery.

Depicts an AI-centric approach to software development, with AI in the center, with cross functional team members around it, working collaboratively with one another.

These two dimensions enable you to deliver software faster without compromising on quality.

How does AI-DLC work?

At its core, AI-DLC operates by having AI initiate and direct workflows through a new mental model:

AI creates plans, seeks clarification, & implements plans, while humans make critical decisions

This pattern, where AI creates a plan, asks clarifying questions to seek context, and implements solutions only after receiving human validation, repeats rapidly for every SDLC activity, to provide a unified vision and approach for all development pathways.

With this mental model at its core, the software development in AI-DLC takes place in three straightforward phases:

  • In the Inception phase, AI transforms business intent into detailed requirements, stories and units through “Mob Elaboration” – where the entire team actively validates AI’s questions and proposals.
  • In the Construction phase, using the validated context from the Inception phase, AI proposes a logical architecture, domain models, code solution and tests through “Mob Construction” – where the team provides clarification on technical decisions and architectural choices in real time.
  • In the Operations phase, AI applies the accumulated context from previous phases to manage infrastructure as code and deployments, with team oversight.

Each phase provides richer context for the next, thus enabling AI to provide increasingly informed suggestions.

The three phases of AI-DLC: Inception, Construction, Operation

AI saves and maintains persistent context across all phases by storing plans, requirements, and design artifacts to your project repository, ensuring seamless continuation of work across multiple sessions.

AI-DLC introduces new terminology and rituals to reflect its AI-driven, highly collaborative approach. Traditional ‘sprints’ are replaced by ‘bolts’ – shorter, more intense work cycles measured in hours or days rather than weeks; Epics are replaced by Units of Work. This shift in terminology underscores the method’s emphasis on speed and continuous delivery. Similarly, other familiar Agile terms are reimagined to align with the AI-centric workflow, creating a vocabulary that better represents the methodology’s innovative approach to software development.

What are the benefits of this methodology?

  • Velocity: The foremost benefit that AI-DLC offers is acceleration in development velocity, as AI rapidly generates and refines artifacts, such as requirements, stories, designs, code, and tests allowing product owners, architects, and developers to complete tasks in hours or days that previously took weeks.
  • Innovation: Consequently, this acceleration and heavy lifting by AI, frees up significant time for innovation, enabling builders to explore creative solutions and push the boundaries of what’s possible.
  • Quality: With continuous clarification, teams build precisely what they have in mind, rather than an abstract AI interpretation of the intent. This results in products that are more closely aligned with business objectives. AI enhances quality by consistently applying organization-specific standards – your coding practices, design patterns, and security requirements – while generating comprehensive test suites. This end-to-end AI integration improves coherence and traceability from requirements to deployment.
  • Market Responsiveness: The rapid development cycles of AI-DLC enable us to quickly respond to market demands and user feedback, and consequently faster adaptation to requirements.
  • Developer Experience: AI-DLC transforms the developer experience by shifting focus from routine coding tasks to critical problem-solving. AI helps reduce cognitive load by handling repetitive tasks, while satisfaction is enhanced as developers gain deeper business context and witness how their work directly impacts business value.

How do I get started with this?

Begin your journey with AI-DLC, through three clear paths: Read the comprehensive AI-DLC white paper, explore how Amazon Q Developer rules and Kiro custom workflows can help you implement AI-DLC in your organization consistently or connect with your AWS account team to discuss how AI-DLC can be tailored to your organization’s specific needs.

The future of software development is here. We are excited to help you leverage AI to not only build systems faster but also maintain fidelity and quality through critical human oversight and collaboration. Start your AI-DLC journey today and join the growing community of organizations transforming their development practices through AI-driven innovation.

Raja SP

Raja is a Principal Solutions Architect at AWS, where he leads Developer Transformation Programs. He has worked with more than 100 large customers, helping them design and deliver mission critical systems built on modern architectures, platform engineering practices, and Amazon inspired operating models. As generative AI reshapes the software development landscape, Raja and his team created the AI Driven Development Lifecycle (AI DLC) — an end to end, AI native methodology that reimagines how large teams collaboratively build production grade software in the AI era.

Cheating on Quantum Computing Benchmarks

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2025/07/cheating-on-quantum-computing-benchmarks.html

Peter Gutmann and Stephan Neuhaus have a new paper—I think it’s new, even though it has a March 2025 date—that makes the argument that we shouldn’t trust any of the quantum factorization benchmarks, because everyone has been cooking the books:

Similarly, quantum factorisation is performed using sleight-of-hand numbers that have been selected to make them very easy to factorise using a physics experiment and, by extension, a VIC-20, an abacus, and a dog. A standard technique is to ensure that the factors differ by only a few bits that can then be found using a simple search-based approach that has nothing to do with factorisation…. Note that such a value would never be encountered in the real world since the RSA key generation process typically requires that |p-q| > 100 or more bits [9]. As one analysis puts it, “Instead of waiting for the hardware to improve by yet further orders of magnitude, researchers began inventing better and better tricks for factoring numbers by exploiting their hidden structure” [10].

A second technique used in quantum factorisation is to use preprocessing on a computer to transform the value being factorised into an entirely different form or even a different problem to solve which is then amenable to being solved via a physics experiment…

Lots more in the paper, which is titled “Replication of Quantum Factorisation Records with an 8-bit Home Computer, an Abacus, and a Dog.” He points out the largest number that has been factored legitimately by a quantum computer is 35.

I hadn’t known these details, but I’m not surprised. I have long said that the engineering problems between now and a useful, working quantum computer are hard. And by “hard,” we don’t know if it’s “land a person on the surface of the moon” hard, or “land a person on the surface of the sun” hard. They’re both hard, but very different. And we’re going to hit those engineering problems one by one, as we continue to develop the technology. While I don’t think quantum computing is “surface of the sun” hard, I don’t expect them to be factoring RSA moduli anytime soon. And—even there—I expect lots of engineering challenges in making Shor’s Algorithm work on an actual quantum computer with large numbers.

Measuring the Attack/Defense Balance

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2025/07/measuring-the-attack-defense-balance.html

“Who’s winning on the internet, the attackers or the defenders?”

I’m asked this all the time, and I can only ever give a qualitative hand-wavy answer. But Jason Healey and Tarang Jain’s latest Lawfare piece has amassed data.

The essay provides the first framework for metrics about how we are all doing collectively—and not just how an individual network is doing. Healey wrote to me in email:

The work rests on three key insights: (1) defenders need a framework (based in threat, vulnerability, and consequence) to categorize the flood of potentially relevant security metrics; (2) trends are what matter, not specifics; and (3) to start, we should avoid getting bogged down in collecting data and just use what’s already being reported by amazing teams at Verizon, Cyentia, Mandiant, IBM, FBI, and so many others.

The surprising conclusion: there’s a long way to go, but we’re doing better than we think. There are substantial improvements across threat operations, threat ecosystem and organizations, and software vulnerabilities. Unfortunately, we’re still not seeing increases in consequence. And since cost imposition is leading to a survival-of-the-fittest contest, we’re stuck with perhaps fewer but fiercer predators.

And this is just the start. From the report:

Our project is proceeding in three phases—­the initial framework presented here is only phase one. In phase two, the goal is to create a more complete catalog of indicators across threat, vulnerability, and consequence; encourage cybersecurity companies (and others with data) to report defensibility-relevant statistics in time-series, mapped to the catalog; and drive improved analysis and reporting.

This is really good, and important, work.