Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2025/11/more-promptgtfo.html
The next three in this series on online events highlighting interesting uses of AI in cybersecurity are online: #4, #5, and #6. Well worth watching.
Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2025/11/friday-squid-blogging-pilot-whales-eat-a-lot-of-squid.html
Short-finned pilot wales (Globicephala macrorhynchus) eat at lot of squid:
To figure out a short-finned pilot whale’s caloric intake, Gough says, the team had to combine data from a variety of sources, including movement data from short-lasting tags, daily feeding rates from satellite tags, body measurements collected via aerial drones, and sifting through the stomachs of unfortunate whales that ended up stranded on land.
Once the team pulled all this data together, they estimated that a typical whale will eat between 82 and 202 squid a day. To meet their energy needs, a whale will have to consume an average of 140 squid a day. Annually, that’s about 74,000 squid per whale. For all the whales in the area, that amounts to about 88,000 tons of squid eaten every year.
Research paper.
As usual, you can also use this squid post to talk about the security stories in the news that I haven’t covered.
Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2025/11/upcoming-speaking-engagements-50.html
This is a current list of where and when I am scheduled to speak:
The list is maintained on this page.
Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2025/11/the-role-of-humans-in-an-ai-powered-world.html
As AI capabilities grow, we must delineate the roles that should remain exclusively human. The line seems to be between fact-based decisions and judgment-based decisions.
For example, in a medical context, if an AI was demonstrably better at reading a test result and diagnosing cancer than a human, you would take the AI in a second. You want the more accurate tool. But justice is harder because justice is inherently a human quality in a way that “Is this tumor cancerous?” is not. That’s a fact-based question. “What’s the right thing to do here?” is a human-based question.
Chess provides a useful analogy for this evolution. For most of history, humans were best. Then, in the 1990s, Deep Blue beat the best human. For a while after that, a good human paired with a good computer could beat either one alone. But a few years ago, that changed again, and now the best computer simply wins. There will be an intermediate period for many applications where the human-AI combination is optimal, but eventually, for fact-based tasks, the best AI will likely surpass both.
The enduring role for humans lies in making judgments, especially when values come into conflict. What is the proper immigration policy? There is no single “right” answer; it’s a matter of feelings, values, and what we as a society hold dear. A lot of societal governance is about resolving conflicts between people’s rights—my right to play my music versus your right to have quiet. There’s no factual answer there. We can imagine machines will help; perhaps once we humans figure out the rules, the machines can do the implementing and kick the hard cases back to us. But the fundamental value judgments will likely remain our domain.
This essay originally appeared in IVY.
Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2025/11/book-review-the-business-of-secrets.html
The Business of Secrets: Adventures in Selling Encryption Around the World by Fred Kinch (May 24, 2024)
From the vantage point of today, it’s surreal reading about the commercial cryptography business in the 1970s. Nobody knew anything. The manufacturers didn’t know whether the cryptography they sold was any good. The customers didn’t know whether the crypto they bought was any good. Everyone pretended to know, thought they knew, or knew better than to even try to know.
The Business of Secrets is the self-published memoirs of Fred Kinch. He was founder and vice president of—mostly sales—at a US cryptographic hardware company called Datotek, from company’s founding in 1969 until 1982. It’s mostly a disjointed collection of stories about the difficulties of selling to governments worldwide, along with descriptions of the highs and (mostly) lows of foreign airlines, foreign hotels, and foreign travel in general. But it’s also about encryption.
Datotek sold cryptographic equipment in the era after rotor machines and before modern academic cryptography. The company initially marketed computer-file encryption, but pivoted to link encryption—low-speed data, voice, fax—because that’s what the market wanted.
These were the years where the NSA hired anyone promising in the field, and routinely classified—and thereby blocked—publication of academic mathematics papers of those they didn’t hire. They controlled the fielding of strong cryptography by aggressively using the International Traffic in Arms regulation. Kinch talks about the difficulties in getting an expert license for Datotek’s products; he didn’t know that the only reason he ever got that license was because the NSA was able to break his company’s stuff. He had no idea that his largest competitor, the Swiss company Crypto AG, was owned and controlled by the CIA and its West German equivalent. “Wouldn’t that have made our life easier if we had known that back in the 1970s?” Yes, it would. But no one knew.
Glimmers of the clandestine world peek out of the book. Countries like France ask detailed tech questions, borrow or buy a couple of units for “evaluation,” and then disappear again. Did they break the encryption? Did they just want to see what their adversaries were using? No one at Datotek knew.
Kinch “carried the key generator logic diagrams and schematics” with him—even today, it’s good practice not to rely on their secrecy for security—but the details seem laughably insecure: four linear shift registers of 29, 23, 13, and 7 bits, variable stepping, and a small nonlinear final transformation. The NSA probably used this as a challenge to its new hires. But Datotek didn’t know that, at the time.
Kinch writes: “The strength of the cryptography had to be accepted on trust and only on trust.” Yes, but it’s so, so weird to read about it in practice. Kinch demonstrated the security of his telephone encryptors by hooking a pair of them up and having people listen to the encrypted voice. It’s rather like demonstrating the safety of a food additive by showing that someone doesn’t immediately fall over dead after eating it. (In one absolutely bizarre anecdote, an Argentine sergeant with a “hearing defect” could understand the scrambled analog voice. Datotek fixed its security, but only offered the upgrade to the Argentines, because no one else complained. As I said, no one knew anything.)
In his postscript, he writes that even if the NSA could break Datotek’s products, they were “vastly superior to what [his customers] had used previously.” Given that the previous devices were electromechanical rotor machines, and that his primary competition was a CIA-run operation, he’s probably right. But even today, we know nothing about any other country’s cryptanalytic capabilities during those decades.
A lot of this book has a “you had to be there” vibe. And it’s mostly tone-deaf. There is no real acknowledgment of the human-rights-abusing countries on Datotek’s customer list, and how their products might have assisted those governments. But it’s a fascinating artifact of an era before commercial cryptography went mainstream, before academic cryptography became approved for US classified data, before those of us outside the triple fences of the NSA understood the mathematics of cryptography.
This book review originally appeared in AFIO.
Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2025/11/on-hacking-back.html
Former DoJ attorney John Carlin writes about hackback, which he defines thus: “A hack back is a type of cyber response that incorporates a counterattack designed to proactively engage with, disable, or collect evidence about an attacker. Although hack backs can take on various forms, they are—by definition—not passive defensive measures.”
His conclusion:
As the law currently stands, specific forms of purely defense measures are authorized so long as they affect only the victim’s system or data.
At the other end of the spectrum, offensive measures that involve accessing or otherwise causing damage or loss to the hacker’s systems are likely prohibited, absent government oversight or authorization. And even then parties should proceed with caution in light of the heightened risks of misattribution, collateral damage, and retaliation.
As for the broad range of other hack back tactics that fall in the middle of active defense and offensive measures, private parties should continue to engage in these tactics only with government oversight or authorization. These measures exist within a legal gray area and would likely benefit from amendments to the CFAA and CISA that clarify and carve out the parameters of authorization for specific self-defense measures. But in the absence of amendments or clarification on the scope of those laws, private actors can seek governmental authorization through an array of channels, whether they be partnering with law enforcement or seeking authorization to engage in more offensive tactics from the courts in connection with private litigation.
Post Syndicated from Григор original http://www.gatchev.info/blog/?p=2672
Ето ви сериозно съкратен разказ за една от многото руски групи за пропагандни лъжи, кръстена от изследователите на Майкрософт “Storm-1516”. (Числото е пореден номер.)
—-
Започнала е като клон на Агенцията за Интернет проучвания – руска пропагандна група, създадена от Евгений Пригожин и регистрирана като „частна фирма“, за да се прикрие фактът, че е управлявана от отдела за активни мероприятия в чужбина на КГБ. Отделното съществуване на Storm-1516 е забелязано за пръв път от група изследователи на дезинформацията в медиите в университета Клемсън.
Основният им канал за разпространение са създавани в YouTube и X акаунти, представящи се за разследващи журналисти или уисълблоуъри. След това разпространява чрез тях пропагандни лъжи на английски, руски, финландски, арабски и френски езици. Често една и съща лъжа се пуска през няколко акаунта, за да оставя впечатление за достоверност.
Основният ѝ метод е заснемане на фалшиви видеота с участие на актьори или генерирането им с AI (по-рано – с дийпфейкване). Вероятната локация на екипа, който заснема видеотата с актьори, е Санкт Петербург. Те често се позовават на източници, които всъщност не съществуват. Пуснатите от тях видеота, както и другите пропагандни лъжи, след това биват споделяни от контролирани от ГРУ ботмрежи за ехо-акаунти.
В командването на групата вероятно взимат участие, или се намират под общо командване с нея, антилибералният „Центр геополитических экспертиз“ и друга пропагандна група, известна като „Фондация для борьбы с несправедливости“. Тясно свързани с нея са:
– групата Storm-1099, специализирана в създаване на фалшиви или имитационни пропагандни уебсайтове
– групата Storm-1679, специализирана в създаване на фалшиви документи и новинарски рапорти от името на достоверно изглеждащи, но фалшиви организации
– Ruza Flood, Volga Flood и Rybar – организации, които също разпространяват фалшива информация, често под името на реална личност (напр. Rybar – Михаил Звинчук) или фалшива персона, изпълнявана от актьор (напр. „Саня от Флорида“).
Свързана с нея изглежда и руската медийна компания Tenet Media, затворена през 2024 г. Основната ѝ дейност е била да плаща на десни блогъри в САЩ да снимат видеота с поръчано от нея съдържание.
Някои от основните теми, по които Storm-1516 генерират фалшиво съдържание, са:
– Намаляване на подкрепата за западна помощ за Украйна срещу руската агресия
През май 2024 г. те пускат фалшиво видео, което показва как украински войници горят чучело на Доналд Тръмп.
Много от фалшивките им лъжат, че украинските лидери злоупотребяват със западната помощ – купуват си яхти, имения, луксозни коли, наркотици и т.н. Имало е случаи, когато американски политици са се хващали на тези лъжи.
– Подкрепа за Доналд Тръмп
Честа тяхна теза е че украински тролски ферми работят срещу избирането на Доналд Тръмп. Целта ѝ е да прикрие отлично доказания факт, че всички руски тролски ферми бяха ангажирани в подкрепа на Доналд Тръмп. Едно от фалшивите видеота показва „служител на украинска тролска ферма“, който „си признава“, че ЦРУ изпълнява заговор, за да попречи на Тръмп да стане президент.
– Свързване на Украйна с Хамас
През октомври 2023 г. те пускат фалшиво видео, в което „ръководител на Хамас“ (лицето му е скрито) „благодари на Зеленски за доставките на оръжие и муниции“. В реалността между Украйна и Хамас няма връзки. Същият актьор в друго видео, пуснато преди Олимпийските игри в Париж, предупреждава, че „Хамас ще атакуват Олимпийските игри“. Видеото е широко разпространено чрез руските тролски мрежи. Френските и израелските служби потвърждават, че е фалшиво.
– Подкрепа за Доналд Тръмп
От началото на лятото на 2024 г. до самите избори за президент в САЩ групата, както и всички други тролски ресурси на ГРУ, е съсредоточена върху подкрепа за Доналд Тръмп. Storm-1516 основно произвеждат фалшиви видеота и новини, обвиняващи кандидатите на демократите в престъпления и разпространяващи конспиративни теории спрямо тях. През това време групата оперира над 100 фалшиви уебсайта, които очернят демократите и хвалят Тръмп и Русия. Частта от групата, която се грижи за тези сайтове, е ръководена от Джон Марк Дугън – бивш полицай от Флорида, конспиративен теорист, уличен в платена проруска пропаганда и потърсил политическо убежище в Русия.
Един от разпространяваните от групата фалшификати е, че Сикрет Сървис са открили в имението на Тръмп подслушвателни устройства, монтирани там от ФБР. Тръмп и Ванс също споделят тази лъжа в социалните мрежи.
Друг гласи, че при посещение в Замбия Камала Харис е застреляла нелегално Касуба – популярен женски черен носорог (видът е застрашен от изчезване). Фалшификатът е споделен от над милион фалшиви акаунта в Х, както и от работещи за Русия западни пропагандисти (Chay Bowes и т.н.)
Друго тяхно фалшиво видео, разпространено от Джон Дугън, „показва“ как поддръжници на Камала Харис атакуват сбирка на поддръжници на Тръмп и пребиват един от посетителите. Към това са прикрепени обичайните опорки за „агресивните леви екстремисти“, и коментари, целящи да засилят междурасови напрежения в САЩ.
На друго тяхно фалшиво видео „нелегален имигрант от Хаити“ разказва „как му е било платено да гласува за Харис многократно с различни шофьорски книжки“.
На друго тяхно фалшиво видео, пуснато в деня на изборите, „американски гласоподавател“ разказва как двама поддръжници на Харис нападнали и пребили поддръжник на Тръмп, за да му попречат да гласува.
В много агресивно разпространявано тяхно видео, видяно от почти 3 милиона души, жена твърди че е била блъсната като тинейджърка през 2011 г. от Камала Харис с кола и оставена да умре. Била цялата изпотрошена, претърпяла 11 операции преди да проходи отново, била и до момента в постоянни болки и т.н… Жената, посочена в различни източници като „Алисия Браун“, „Алиша Браун“ и т.н., е платена актриса. Рентгеновата снимка, показана във видеото за нейна, е взета от медицинско списание. Снимката на катастрофата от видеото е от катастрофа в Гуам през 2018 г. Новинарската агенция, посочена във видеото като източник на материала, не съществува (с изключение на фалшив уебсайт, създаден и поддържан от Storm-1516). Частта от видеото, на която Камала Харис напуска мястото на катастрофата, е дийпфейк… Видеото е споделено от много конгресмени-републиканци, включително Дж. Д. Ванс.
През октомври 2024 г., точно преди изборите, Storm-1516 прави съвместна кампания с QAnon за изкарване на Тим Валц (кандидат за вицепрезидент на демократите) педофил. Близко до QAnon радио излъчва „интервюта“ с „родител“ (в ролята – Джон Дугън) на „ученик“ на Валц, и със „студент на Валц от Казахстан“. (Проверката показва, че в училището, където преподава Валц, за последните 20 години не е имало студенти от Казахстан.) Части от излъчването са споделени масово от руски тролски ботмрежи и са видени от над 800 000 души в САЩ.
Един от акаунтите, споделили излъчването, е “BlackInsurrectionist” – създаден и управляван от Storm-1516. Има го във всички големи социални мрежи, следван е от водещи републикански политици (вкл. Тръмп-младши и Роджър Стоун). С тяхна помощ излъчването стига до около 33 милиона души.
В средата на октомври 2024 г. този акаунт пуска видео с е-майл, за който твърди, че е от малолетен, сексуално преследван от Валц. Многобройни признаци, че видеото е фалшификат, са моментално посочени от много негови зрители, но търсенията в Гугъл за „Tim Waltz pedophile“ скачат стократно. Няколко дни по-късно друг акаунт за конспиративни теории, също управляван от Storm-1516, пуска друго видео с подобни твърдения. Трето подобно видео, очевидно дело на същата група, е пуснато от акаунт на QAnon. Анализ на експерти от Wired показва, че всичките тези видеота са дийпфейкове.
На 19 октомври почти всички сайтове, управлявани от Джон Дугън, пускат голям репортаж, който цитира тези видеота (и ги представя за истински). Репортажът е цитиран от десни инфлуенсъри, между тях Кендис Оуенс и Джак Пособиец. На 21 октомври експерти на Wired успяват да докажат, че видеотата са дело на Storm-1516.
Друго фалшиво видео, създадено от същата група и пуснато през акаунт на QAnon 2 дни преди изборите, показва как член на изборна комисия проверява пратени по пощата бюлетини и къса тези, които са за Доналд Тръмп. Експертите веднага забелязват, че материалите и бюлетините, показани във видеото, не са истински – очевидно реквизиторът на групата се е изложил.
… Мога да напиша още няколко пъти по толкова за тях. А като погледнете поредния им номер, се досещайте колко още са като тях.
Правете си изводите.
Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2025/11/prompt-injection-in-ai-browsers.html
This is why AIs are not ready to be personal assistants:
A new attack called ‘CometJacking’ exploits URL parameters to pass to Perplexity’s Comet AI browser hidden instructions that allow access to sensitive data from connected services, like email and calendar.
In a realistic scenario, no credentials or user interaction are required and a threat actor can leverage the attack by simply exposing a maliciously crafted URL to targeted users.
[…]
CometJacking is a prompt-injection attack where the query string processed by the Comet AI browser contains malicious instructions added using the ‘collection’ parameter of the URL.
LayerX researchers say that the prompt tells the agent to consult its memory and connected services instead of searching the web. As the AI tool is connected to various services, an attacker leveraging the CometJacking method could exfiltrate available data.
In their tests, the connected services and accessible data include Google Calendar invites and Gmail messages and the malicious prompt included instructions to encode the sensitive data in base64 and then exfiltrate them to an external endpoint.
According to the researchers, Comet followed the instructions and delivered the information to an external system controlled by the attacker, evading Perplexity’s checks.
I wrote previously:
Prompt injection isn’t just a minor security problem we need to deal with. It’s a fundamental property of current LLM technology. The systems have no ability to separate trusted commands from untrusted data, and there are an infinite number of prompt injection attacks with no way to block them as a class. We need some new fundamental science of LLMs before we can solve this.
Post Syndicated from Veliswa Boya original https://aws.amazon.com/blogs/aws/secure-eks-clusters-with-the-new-support-for-amazon-eks-in-aws-backup/
Today, we’re announcing support for Amazon EKS in AWS Backup to provide the capability to secure Kubernetes applications using the same centralized platform you trust for your other Amazon Web Services (AWS) services. This integration eliminates the complexity of protecting containerized applications while providing enterprise-grade backup capabilities for both cluster configurations and application data. AWS Backup is a fully managed service to centralize and automate data protection across AWS and on-premises workloads. Amazon Elastic Kubernetes Service (Amazon EKS) is a fully managed Kubernetes service to manage availability and scalability of the Kubernetes clusters. With this new capability, you can centrally manage and automate data protection across your Amazon EKS environments alongside other AWS services.
Until now, for backups, customers relied on custom solutions or third-party tools to back up their EKS clusters, requiring complex scripting and maintenance for each cluster. The support for Amazon EKS in AWS Backup eliminates this overhead by providing a single, centralized, and policy-driven solution that protects both EKS clusters (Kubernetes deployments and resources) and stateful data (stored in Amazon Elastic Block Store (Amazon EBS), Amazon Elastic File System (Amazon EFS), and Amazon Simple Storage Service (Amazon S3) only) without the need to manage custom scripts across clusters. For restores, customers were previously required to restore their EKS backups to a target EKS cluster which was either the source EKS cluster, or a new EKS cluster, requiring that an EKS cluster infrastructure is provisioned ahead of time prior to the restore. With this new capability, during a restore of EKS cluster backups, customers also have the option to create a new EKS cluster based on previous EKS cluster configuration settings and restore to this new EKS cluster, with AWS Backup managing the provisioning of the EKS cluster on the customer’s behalf.
This support includes policy-based automation for protecting single or multiple EKS clusters. This single data protection policy provides a consistent experience across all services AWS Backup supports. It allows creation of immutable backups to prevent malicious or inadvertent changes, helping customers meet their regulatory compliance needs. In case there is a customer data loss or cluster downtime event, customers can easily recover their EKS cluster data from encrypted, immutable backups using an easy-to-use interface and maintain business continuity of running their EKS clusters at scale.
How it works
Here’s how I set up support for on-demand backup of my EKS cluster in AWS Backup. First, I’ll show a walkthrough of the backup process, then demonstrate a restore of the EKS cluster.
Backup
In the AWS Backup console, in the left navigation pane, I choose Settings and then Configure resources to opt in to enable protection of EKS clusters in AWS Backup.
Now that I’ve enabled Amazon EKS, in Protected resources I choose Create on-demand backup to create a backup for my already existing EKS cluster floral-electro-unicorn.
Enabling EKS in Settings ensures that it shows up as a Resource type when I create on-demand backup for the EKS cluster. I proceed to select the EKS resource type and the cluster.
I leave the rest of the information as default, then select Choose an IAM role to select a role (test-eks-backup) that I’ve created and customized with the necessary permissions for AWS Backup to assume when creating and managing backups on my behalf. I choose Create on-demand backup to finalize the process.
The job is initiated, and it will start running to back up both the EKS cluster state and the persistent volumes. If Amazon S3 buckets are attached to the backup, you’ll need to add the additional Amazon S3 backup permissions AWSBackupServiceRolePolicyForS3Backup to your role. This policy contains the permissions necessary for AWS Backup to back up any Amazon S3 bucket, including access to all objects in a bucket and any associated AWS KMS key.
The job is completed successfully and now EKS clusterfloral-electro-unicorn is backed up by AWS Backup.
Restore
Using the AWS Backup Console, I choose the EKS backup composite recovery point to start the process of restoring the EKS cluster backups, then choose Restore.
I choose Restore full EKS cluster to restore the full EKS backup. To restore to an existing cluster, I Choose an existing cluster then select the cluster from the drop-down list. I choose the Default order as the order in which individual Kubernetes resources will be restored.
I then configure the restore for the persistent storage resources, that will be restored alongside my EKS clusters.
Next, I Choose an IAM role to execute the restore action. The Protected resource tags checkbox is selected by default and I’ll leave it as is, then choose Next.
I review all the information before I finalize the process by choosing Restore, to start the job.
Selecting the drop-down arrow gives details of the restore status for both the EKS cluster state and persistent volumes attached. In this walkthrough, all the individual recovery points are restored successfully. If portions of the backup fail, it’s possible to restore the successfully backed up persistent stores (for example, Amazon EBS volumes) and cluster configuration settings individually. However, it’s not possible to restore full EKS backup. The successfully backed up resources will be available for restore, listed as nested recovery points under the EKS cluster recovery point. If there’s a partial failure, there will be a notification of the portion(s) that failed.
Benefits
Here are some of the benefits provided by the support for Amazon EKS in AWS Backup:
Good to know
The following are some helpful facts to know:
Voice of the customer
Srikanth Rajan, Sr. Director of Engineering at Salesforce said “Losing a Kubernetes control plane because of software bugs or unintended cluster deletion can be catastrophic without a solid backup and restore plan. That’s why it’s exciting to see AWS rolling out the new EKS Backup and Restore feature, it’s a big step forward in closing a critical resiliency gap for Kubernetes platforms.”
Now available
Support for Amazon EKS in AWS Backup is available today in all AWS commercial Regions (except China) and in the AWS GovCloud (US) where AWS Backup and Amazon EKS are available. Check the full Region list for future updates.
To learn more, check out the AWS Backup product page and the AWS Backup pricing page.
Try out this capability for protecting your EKS clusters in AWS Backup and let us know what you think by sending feedback to AWS re:Post for AWS Backup or through your usual AWS Support contacts.
– Veliswa.
Post Syndicated from Brent Nowak original https://www.backblaze.com/blog/network-stats-for-q3-2025-the-magnitude-of-ai-workflows/
The way data moves is changing in the age of AI. As AI training, model tuning, and inferencing accelerate massive, unpredictable flows of data across clouds, our network telemetry here at Backblaze offers a real-world view into the AI data gravity shift: where data lives, how it moves, and what it takes to keep it accessible and affordable.
Over the past couple of years, we’ve shared Network Stats snapshots that shed light on how data moves across Backblaze’s storage cloud. This quarter, we’re taking that foundation further, and evolving this series into a full-fledged transparency report that stands alongside Drive Stats with regular quarterly reporting and stats you can analyze for yourself.
This report isn’t just about traffic patterns. It’s a look at how data movement is changing in the age of AI and what those shifts reveal about performance, cost, and resilience at scale.
Drive Stats was the beginning. Want to see the evolution? Check out the Backblaze Stats Lab webinar, bringing together content from all of our Stats articles. We’re going to chat about all things Backblaze and beyond—by the numbers.
In this first report, we’re going to outline the fundamentals of our dataset, highlight standout examples for AI related traffic, and lay the foundation to start sharing our quarter-over-quarter metrics.
Our internal tools allow us to capture network flow data, meaning transmission control protocol (TCP) conversations between parties on our network. Along with basic information such as who is talking and how many bits are being exchanged, we have the ability to record additional pieces of anonymized information like what country, what ISP, or if we’ve seen a particular IP address before. And for each of these metrics, we have numbers for the average, 95th percentile, and maximum values.
Let’s talk about the three elements that make up our dataset: time, values, and metadata.
For every month, for every region, and for each direction (egress and ingress), we are data warehousing the following metrics. We plan on either using month-by-month numbers, or rolling up into a quarterly value for Network Stats reports going forward.
| Item | Detail |
|---|---|
| Date range | Every month |
| Location scope | Every region (eg US-West, EU-Central) |
| Network traffic direction | Ingress, egress |
For each monthly snapshot, we’re recording the following details in our data warehouse. Capturing the average, 95th weighted value, and the maximum allows us enough information to profile our traffic.
The 95th value (discarding the highest 5% bursts) gives us a good profile for daily operations and the maximum helps profile bust traffic.
The most interesting metrics that I’m excited to explore are the “bits per IP” values. This combination of “amount of traffic” transferred with “how many actors are involved” per network is a good proxy for what I’m calling the “magnitude” of the network flow. We’re exploring the first insight into this metric below in our chart section.
| Item | Field(s) | Detail |
|---|---|---|
| Name | name asn |
Common name and BGP ASN of the network |
| Bits | bits_avg bits_95th bits_max |
Number of bits/second |
| Packets | packets_avg packets_95th packets_max |
Number of packets/second |
| Flows | flow_avg flow_95th flow_max |
Number of TCP flows |
| IPs | ip_unique_avg ip_unique_95th ip_unique_max |
Number of unique IP addresses |
| Bits per IP | bits_ip_avg bits_ip_95th bits_ip_max |
Number of bits per IP address |
| Protocol | v4 v6 |
Amount of traffic using IPv4 vs IPv6 |
One of the first custom additions to our dataset is a category field. This helps us define the BGP ASNs (Autonomous System Number), basically the organizations common name associated with a range of IP addresses, that we talk to and group them into categories such as neocloud, hyperscaler, CDN, or general ISP.
| Item | Field | Detail |
|---|---|---|
| category | group | The class of network carrying the traffic (Cloud, PNI, traditional Internet Transit, or Internal Backblaze-Backblaze) |
| category | type | The type of network receiving the traffic (Neocloud, Hosting/Compute provider, Hyperscaler, CDN, Regional ISP, more localised ISP, etc) |
We started capturing this dataset in August of 2025, so we don’t yet have a good amount of data to pull out quarter over quarter trends. But what we can do for now is take a look into some standout metrics for the month of August that we’re interested in tracking over time.
First let’s take a look at where all our traffic goes from a global perspective.
When we look at the data, one pattern stands out immediately: traffic associated with neocloud networks—cloud providers offering compute, GPU, or other AI-related services—already represents nearly a quarter of total ingress and egress across Backblaze’s network. That’s a meaningful signal. Historically CDN traffic has been the majority of our traffic as our B2 Object Storage has been growing. Now, we’re seeing clear evidence of a new class of workload emerging, and it’s AI-shaped.
Let’s look at the magnitude of our network traffic based on the category of the traffic destination. To help quantify our data set, we interact with around 123,000 unique IP addresses every month.
CDN, hyperscaler, isp-regional, and isp-tier one traffic cluster in the same general range of bits per IP, but neoclouds have a couple outliers—the two purple data points in the upper right corner of the log scale graph.
If we change the scale to linear (chart below), now we can see how much of an outlier the AI related traffic is in our sample range.
The “magnitude” (as we’re calling it) of the transfers we’re servicing for AI related flows to neoclouds is an order of magnitude greater than all our traffic patterns. This means that there are only a few unique IP addresses that we’re interacting with transferring large amounts of data in their flows.
Over the past year, AI training and inference have transformed global data flows. Where traditional workloads move steadily, AI workloads move in bursts—rapid retrievals of massive datasets, short high-volume transfers for model training or tuning, and sustained outbound throughput for inferencing pipelines. The magnitude metric we’re introducing (bits per IP address) captures this shift.
As shown in the charts above, AI-related traffic to neoclouds isn’t just heavier, it’s denser. Those purple data points represent a small number of IPs exchanging a disproportionate amount of data. That concentration of flow is a hallmark of AI compute pipelines, where a few high-bandwidth endpoints (often GPU clusters) interact with object storage to repeatedly feed and retrieve training data.
In other words:
This pattern reflects a broader macro trend in the cloud ecosystem: AI data gravity is pulling more storage and compute closer together. As AI models grow larger and datasets become more complex, organizations are rethinking where data “lives.” Instead of centralizing everything in one hyperscaler like AWS or Google Cloud Platform, they’re increasingly using cost-efficient, high-throughput storage clouds like Backblaze connected to specialized GPU clouds for compute (case in point: Why CoreWeave’s Object Storage Launch is Good for AI—and Everyone Building It).
This architectural shift explains the outlier traffic patterns we’re seeing on our network. Data isn’t just moving more—it’s moving smarter, following cost, performance, and regional availability cues.
Tracking this kind of data movement and magnitude helps us, and more importantly our customers, understand a few key things:
This is just the first glimpse of that industry evolution. As our dataset matures, we’ll be able to watch these AI-linked flows change quarter over quarter, offering not just transparency, but a longitudinal view of how the data backbone of the AI economy takes shape.
We’re planning to look at quarter over quarter number tracking for network types, IPv4 traffic vs IPv6 traffic, AI related workflows, cross-cloud connectivity trends, and more. We’re also planning to release the raw data quarterly going forward.
Anything specific you want to see? Let us know in the comments or reach out to our Evangelism team.
We’re excited to share these insights from our network telemetry, the patterns we’re seeing, and what they mean for the broader data economy. This is the stuff we stay up at night studying, and sharing it publicly means we can all better understand the forces shaping digital infrastructure and build with greater confidence and foresight.
The post Network Stats for Q3 2025: The Magnitude of AI Workflows appeared first on Backblaze Blog | Cloud Storage & Cloud Backup
Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2025/11/new-attacks-against-secure-enclaves.html
Encryption can protect data at rest and data in transit, but does nothing for data in use. What we have are secure enclaves. I’ve written about this before:
Almost all cloud services have to perform some computation on our data. Even the simplest storage provider has code to copy bytes from an internal storage system and deliver them to the user. End-to-end encryption is sufficient in such a narrow context. But often we want our cloud providers to be able to perform computation on our raw data: search, analysis, AI model training or fine-tuning, and more. Without expensive, esoteric techniques, such as secure multiparty computation protocols or homomorphic encryption techniques that can perform calculations on encrypted data, cloud servers require access to the unencrypted data to do anything useful.
Fortunately, the last few years have seen the advent of general-purpose, hardware-enabled secure computation. This is powered by special functionality on processors known as trusted execution environments (TEEs) or secure enclaves. TEEs decouple who runs the chip (a cloud provider, such as Microsoft Azure) from who secures the chip (a processor vendor, such as Intel) and from who controls the data being used in the computation (the customer or user). A TEE can keep the cloud provider from seeing what is being computed. The results of a computation are sent via a secure tunnel out of the enclave or encrypted and stored. A TEE can also generate a signed attestation that it actually ran the code that the customer wanted to run.
Secure enclaves are critical in our modern cloud-based computing architectures. And, of course, they have vulnerabilities:
The most recent attack, released Tuesday, is known as TEE.fail. It defeats the latest TEE protections from all three chipmakers. The low-cost, low-complexity attack works by placing a small piece of hardware between a single physical memory chip and the motherboard slot it plugs into. It also requires the attacker to compromise the operating system kernel. Once this three-minute attack is completed, Confidential Compute, SEV-SNP, and TDX/SDX can no longer be trusted. Unlike the Battering RAM and Wiretap attacks from last month—which worked only against CPUs using DDR4 memory—TEE.fail works against DDR5, allowing them to work against the latest TEEs.
Yes, these attacks require physical access. But that’s exactly the threat model secure enclaves are supposed to secure against.
Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2025/11/friday-squid-blogging-squid-game-the-challenge-season-two.html
The second season of the Netflix reality competition show Squid Game: The Challenge has dropped. (Too many links to pick a few—search for it.)
As usual, you can also use this squid post to talk about the security stories in the news that I haven’t covered.
Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2025/11/faking-receipts-with-ai.html
Over the past few decades, it’s become easier and easier to create fake receipts. Decades ago, it required special paper and printers—I remember a company in the UK advertising its services to people trying to cover up their affairs. Then, receipts became computerized, and faking them required some artistic skills to make the page look realistic.
Now, AI can do it all:
Several receipts shown to the FT by expense management platforms demonstrated the realistic nature of the images, which included wrinkles in paper, detailed itemization that matched real-life menus, and signatures.
[…]
The rise in these more realistic copies has led companies to turn to AI to help detect fake receipts, as most are too convincing to be found by human reviewers.
The software works by scanning receipts to check the metadata of the image to discover whether an AI platform created it. However, this can be easily removed by users taking a photo or a screenshot of the picture.
To combat this, it also considers other contextual information by examining details such as repetition in server names and times and broader information about the employee’s trip.
Yet another AI-powered security arms race.
Post Syndicated from Diana Kirby original https://www.raspberrypi.org/blog/how-ai-shapes-your-feed-an-explainable-social-media-simulator-for-the-classroom/
Social media can have a powerful impact on the way we see and experience the world. What we see in our feeds is not random: it is determined by AI-driven systems that collect vast amounts of data, build user profiles, analyse engagement, and generate recommendations. But while young people are prolific users of social media, studies show that many have little understanding of what is happening ‘under the hood’
In our September research seminar, we welcomed back Henriikka Vartiainen and Matti Tedre from the University of Eastern Finland. They introduced Somekone, a social media simulator that is designed to help learners understand some of the fundamental processes behind social media platforms. Their team has been developing AI education materials and tools since 2019, including GenAI Teachable Machine, which they presented at our May research seminar.
Henriikka explained that the development of the Somekone tool emerged from the team’s long-term collaboration with teachers and schools in Finland. They co-developed the tool with the aim of making concepts like data collection, engagement, profiling, recommendations, filter bubbles, and polarisation visible and explainable for students aged 11 to 13 years old.
Henriikka described the pedagogical model that the team follows in all of their AI education interventions. Their goal is not only to support students to develop their understanding of AI concepts, but also to foster ethical awareness and a sense of agency.
Matti then gave a live demonstration of Somekone. Nothing compares to seeing the tool in action, so do check out the video of his demo here!
Students log on to the tool and are presented with an Instagram-style feed of images. They scroll through the feed and like, share, or comment on images that catch their attention or match their interests. For many students this is a very familiar type of environment, and they really enjoy playing with the app!
However, the unique value of Somekone is that it provides students with a real-time view of the way data is collected from every single user interaction, and demonstrates what is done with that data. It also allows students to experiment with a social media tool in the classroom without any data protection issues, as all of the data is stored locally.
Learners explore:
The simulator creates clusters of users with similar interests, which update in real time as students interact with posts on their feeds
The tool provides an explanation for why each post is recommended
Two users’ heatmaps presented side by side, showing their respective filter bubbles
For teachers, the tool has a simple guided interface to make it easy to use in class. There is also a button that teachers can use to pause the app, stopping students from scrolling (much to their dismay!) in order to focus their attention on the teacher when they are explaining concepts.
The research team used pre- and post-tests to evaluate what impact the intervention had on students’ understanding of social media mechanisms and on their sense of agency in relation to data. They conducted the post-test a week after the intervention, and then also did a delayed post-test six months later to see whether any changes were sustained. They found:
The Somekone tool is freely available online — in Finnish, English, German, and French — at somekone.gen-ai.fi. The developer Nick Pope has also made the source code available on GitHub at github.com/knicos/genai-somekone.
However, the supporting materials and teacher resources are currently only available in Finnish and the underpinning pedagogies relate to the Finnish context.
Join us at our next seminar on Tuesday, 11 November from 17:00 to 18:30 GMT to hear Karl-Emil Bilstrup (Copenhagen University) speak about using the micro:bit to explore machine learning practices. We hope to see you there!
To sign up and take part in our research seminars, click below:
You can also view the schedule of our upcoming seminars, and catch up on past seminars on our previous seminars page.
The post How AI shapes your feed: An explainable social media simulator for the classroom appeared first on Raspberry Pi Foundation.
Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2025/11/rigged-poker-games.html
The Department of Justice has indicted thirty-one people over the high-tech rigging of high-stakes poker games.
In a typical legitimate poker game, a dealer uses a shuffling machine to shuffle the cards randomly before dealing them to all the players in a particular order. As set forth in the indictment, the rigged games used altered shuffling machines that contained hidden technology allowing the machines to read all the cards in the deck. Because the cards were always dealt in a particular order to the players at the table, the machines could determine which player would have the winning hand. This information was transmitted to an off-site member of the conspiracy, who then transmitted that information via cellphone back to a member of the conspiracy who was playing at the table, referred to as the “Quarterback” or “Driver.” The Quarterback then secretly signaled this information (usually by prearranged signals like touching certain chips or other items on the table) to other co-conspirators playing at the table, who were also participants in the scheme. Collectively, the Quarterback and other players in on the scheme (i.e., the cheating team) used this information to win poker games against unwitting victims, who sometimes lost tens or hundreds of thousands of dollars at a time. The defendants used other cheating technology as well, such as a chip tray analyzer (essentially, a poker chip tray that also secretly read all cards using hidden cameras), an x-ray table that could read cards face down on the table, and special contact lenses or eyeglasses that could read pre-marked cards.
Post Syndicated from Bruno Giorgini original https://aws.amazon.com/blogs/messaging-and-targeting/como-enviar-sms-internacionales-con-numeros-gratuitos-de-ee-uu-usando-aws-end-user-messaging/
AWS End User Messaging ahora admite capacidades de SMS internacional para Números Gratuitos de EE.UU. (TFN). Esta nueva función permite a las empresas usar un solo TFN de EE.UU. para enviar mensajes SMS a más de 150 países, simplificando el alcance global. Beneficia principalmente a clientes que necesitan enviar alertas transaccionales unidireccionales—como contraseñas de un solo uso (OTP) o notificaciones de envío—y empresas que quieren crear prototipos rápidamente y probar su estrategia de mensajería en nuevos mercados internacionales sin la complejidad de adquirir números específicos por país.
Esta guía te mostrará los pros y contras de esta función y cómo habilitarla y cuándo usarla versus métodos tradicionales de envío específicos por país.
Un número gratuito internacional de EE.UU. es un TFN (toll-free number) estándar de EE.UU. que ha sido habilitado con la capacidad de enviar mensajes SMS a destinos fuera de Estados Unidos. Esta función es compatible con versiones anteriores, lo que significa que puedes habilitarla en cualquier TFN de EE.UU. nuevo o existente en tu cuenta.
Hay tres formas principales de habilitar esta función para tus Números Gratuitos de EE.UU.:
Para más información, consulta Solicitar un número de teléfono en AWS End User Messaging SMS
Si ya has adquirido un TFN, puedes habilitar la función de envío internacional en cualquier momento.
El comando update-phone-number te permite modificar las capacidades de un número de teléfono, mientras que el comando describe-phone-numbers te permite verificar su estado.
Usa el parámetro --international-sending-enabled
aws pinpoint-sms-voice-v2 update-phone-number \
--phone-number-id "phone-a1b2c3d4e5f67890" \
--international-sending-enabled \
--region us-east-1
Nota: Reemplaza "phone-a1b2c3d4e5f67890" con el ID real de tu número de teléfono
Usa el parámetro --no-international-sending-enabled
aws pinpoint-sms-voice-v2 update-phone-number \
--phone-number-id "phone-a1b2c3d4e5f67890" \
--no-international-sending-enabled \
--region us-east-1Respuesta Esperada (para update-phone-number):
Un comando exitoso devuelve el objeto JSON completo para el número de teléfono. Confirma el cambio verificando que el valor InternationalSendingEnabled sea true
{
"PhoneNumberArn": "arn:aws:sms-voice:us-east-1:111122223333:phone-number/phone-a1b2c3d4e5f67890",
"PhoneNumberId": "phone-a1b2c3d4e5f67890",
"PhoneNumber": "+18005550199",
"Status": "ACTIVE",
"IsoCountryCode": "US",
"MessageType": "TRANSACTIONAL",
"NumberCapabilities": [
"SMS"
],
"NumberType": "TOLL_FREE",
"MonthlyLeasingPrice": "2.00",
"TwoWayEnabled": true,
"InternationalSendingEnabled": true,
"CreatedTimestamp": "2025-08-15T10:30:00.123Z"
}
Usa el comando describe-phone-numbers con tu ID de Número de Teléfono para verificar su configuración actual en cualquier momento.
aws pinpoint-sms-voice-v2 describe-phone-numbers \
--phone-number-ids "phone-a1b2c3d4e5f67890" \
--region us-east-1Esta función ofrece una nueva forma poderosa de llegar a una audiencia global, pero es importante entender dónde destaca y cuáles son sus limitaciones.
El precio para esta función es directo:
Para una lista completa y actualizada de precios por país, visita la página de Precios de AWS End User Messaging.
Cuándo Usar TFN Internacional vs. Números Específicos por País
Elegir la herramienta correcta depende de tu caso de uso. Aquí hay una comparación simple:
| Caso de Uso | ¿Usar TFN Internacional? | ¿Usar Número Específico por País (Mejor Práctica)? |
|---|---|---|
| Probar rápidamente un nuevo mercado | Sí. Es la forma más rápida de comenzar. | No, este enfoque toma más tiempo para configurar. |
| Enviar alertas unidireccionales (OTP, notificaciones) | Sí. Es una solución simple y rentable. | Sí, pero es más complejo si necesitas enviar a muchos países. |
| Requerir conversaciones bidireccionales | Solo para EE.UU. y Canadá. | Sí. Este es el enfoque requerido para SMS bidireccional confiable en un país específico. |
| Garantizar que tu marca/número aparezca consistentemente | No, planifica que el ID del Remitente no se preserve, ya que esto no está garantizado internacionalmente. | Sí. Esta es la razón principal para usar un número dedicado en el país. |
| Maximizar la entregabilidad para campañas críticas | No, la entrega es “con máximo esfuerzo”. | Sí. Un número local proporciona la mayor probabilidad de entrega exitosa. |
Una vez que hayas habilitado tu envío internacional sobre Números Gratuitos de EE.UU., puedes mejorar tu estrategia de mensajería considerando resistencia, monitoreo y escalabilidad. Los siguientes recursos proporcionan mejores prácticas para mejorar tu envío.
DELIVERED o FAILED) a servicios como Amazon CloudWatch o Amazon Data Firehose para análisis.El SMS Internacional para Números Gratuitos de EE.UU. es una herramienta estratégica poderosa para empresas que buscan simplificar su mensajería global. Destaca en permitir pruebas rápidas en nuevos mercados y entregar eficientemente alertas transaccionales unidireccionales en todo el mundo desde un solo número.
Sin embargo, no es un reemplazo para la mejor práctica de usar números de teléfono dedicados en el país cuando conversaciones bidireccionales confiables y marca garantizada son críticas para el éxito de tu campaña. Al entender sus beneficios y limitaciones, puedes usar estratégicamente esta función para comenzar rápidamente mientras planificas un movimiento a largo plazo hacia códigos específicos por país para tus mercados más importantes.
Post Syndicated from Brent Nowak original https://www.backblaze.com/blog/making-the-backblaze-network-ai-ready/
AI isn’t just reshaping how data is processed—it’s rewriting how data moves. Behind every training run or inference pipeline is a torrent of data, and how efficiently (or not) that data travels through networks (and whether it’s an AI-ready network) can make or break performance.
Data workloads have massively evolved over the 18 years we’ve been in business from computer backups to exabyte-scale storage to AI data pipelines. And that has implications for not just our storage hardware, but our network.
What started as a single ISP serving a few racks in the early days has grown into a global, multi-terabit backbone connecting customers, compute, and storage in real time via multiple Tier 1 carriers, Internet Exchanges, and PNI links.
So why talk about it now? Because AI is testing the limits of every part of the infrastructure stack—and the network is where those limits are most visible. Running an AI-ready network means rethinking how you design, route, and scale traffic to handle not just more data, but faster, more synchronized, and more resilient data movement than ever before.
In this post, I’m talking about how our network has evolved to support AI workflows, including what’s changed under the hood, how we’re adapting our hardware and architecture, and what that means for the way data moves through Backblaze today.
The Network Engineering (NetEng) group at Backblaze is responsible for the design, implementation, and support of our physical network—everything from the physical copper and fiber cables inside our datacenters to the routers and switches that connect our storage to the world.
When we talk about network traffic, we often refer to a “flow”—a stream of information sent between two or more parties. Downloading a file? That’s a flow between your computer and the server offering the file. Multiple small requests loading a website (text, formatting code, animation code, etc.)? Those are known as “mouse” flows. Massive dataset transfers that sustain hundreds of gigabits per second? Those are “elephant” flows.
AI workloads are the largest “elephant” flows our network has ever sustained. These aren’t just big files, they’re ecosystems of data: multi-petabyte datasets, hundreds of thousands of objects ranging from a single megabyte to hundreds of megabytes per object, and thousands of simultaneous connections working in parallel.
Moving these data sets around is no small task. It means engineering for sustained, lossless throughput. It’s cutting edge, using many machines to perform parallel operations, all at large transfer rates. Let’s say we’re the source of a dataset that is being transferred to a neocloud for processing, the processing layers (often GPUs) want a continuous stream of high bandwidth with no loss. And a single dropped packet in a training pipeline can trigger expensive re-requests, idle GPUs, and cascading slowdowns.
With that in mind, we’ve evolved our infrastructure from traditional cloud networking—designed for smaller flows—to handle the relentless firehose of AI data.
AI changes everything about traffic behavior. It doesn’t just mean that our total capacity is bigger, but also that our considerations for how we design, support, and scale our infrastructure morphed along with our capacity upgrades.
Here’s a quick overview of the former challenges and the new ones we’re engineering to serve our AI workflows.
| Traditional Cloud Network | AI Cloud Network |
|---|---|
| Small to large flow sizes (megabits to, gigabits) | Very large flows (multi-gigabit to terabit) |
| High entropy flows (many sources and destinations) | Low entropy flows (consistent source/destination pairs) |
| Predictable usage patterns | Burst traffic patterns |
| Tolerant to failures | Sensitive to faults, buffering, congestion |
In short: AI traffic is heavier, stickier, and far less forgiving. So the goal is to design networks that can transfer 100Gbps, 200Gbps, and up to 1,000 Gbps (1 Terabit) a second with a low latency, low jitter, and a zero loss profile. Simple right?
To meet these new demands of AI workflows, we’ve upgraded nearly every layer of our physical infrastructure. We needed to increase the density of our networking hardware, deploy denser fiber optic solutions, and upgrade the capacity of our edge network.
The fiber optic modules that are used to connect all our infrastructure hardware (servers, switches, routers) have been transitioned to modules that support a denser encoding method. Both NRZ and PAM4 are technologies used to modulate signals. Think of NRZ as a one-lane highway with one passenger per car. PAM4 adds three more passengers per car, doubling the rate without doubling lanes and with controllable cons such as increased noise sensitivity. By using four voltage levels instead of two, PAM4 transmits twice the information per signal change, effectively doubling bandwidth per fiber strand.
MTP is a fiber connector type and the number after denotes the number of fiber optic strands contained within the cable. The higher the number, the more fiber pairs in the cable. We’ve used MTP-8 for years (four pairs of fiber), but to handle AI-scale traffic, we’re now deploying MTP-16 for higher-density connections. That means where we once ran 100G links, we now run 400G—and can scale up to multiple 100G paths as workloads grow (4x100G, 8x100G, etc).
We’ve refreshed routers and switches to handle higher port speeds and density—moving from 100G to 400G interfaces across our interconnects. The result: higher aggregate throughput and better fault isolation for massive parallel transfers.
Our monitoring tools track network flows (TCP conversations) in real time, giving us visibility into how large AI workflows move across the infrastructure. We use this type of information to monitor and make sure that large workflows are distributed across our physical infrastructure to allow for traffic balancing.
So, what does a large “AI workflow” look like? It’s not one device talking to one device at a high rate, but rather a collection of actors all working together.
On our side, our API layer speaks to our storage layer, requesting the files. Once the files are retrieved from our storage layer, they flow through our API servers and are then sent to a destination. In order to achieve a high throughput, many API servers talk to many destination servers.
A typical 200+ Gbps transfer (diagrammed below) might involve four API virtual IPs (VIPs), each hosted on multiple backend servers sending 5–7 Gbps to ten destination nodes for a total output of 52Gbps from each API server. On the receiving side, each destination server might be ingesting 20Gbps across multiple streams.
The key insight: AI data transfer isn’t one big pipe—it’s a distributed mesh of many coordinated streams. Our design scales linearly—add more API servers, add more destination nodes, and the flow grows predictably without congestion or packet loss.
AI workflows have redefined what “fast” means on the network. At Backblaze, we’ve evolved from a single-ISP startup to an AI-scale infrastructure provider by continuously pushing the boundaries of connectivity, throughput, and reliability.
As our customers push the frontiers of AI, we’ll keep tuning the invisible layer that makes it possible: the AI-ready network.
The post Making the Backblaze Network AI Ready appeared first on Backblaze Blog | Cloud Storage & Cloud Backup
Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2025/11/scientists-need-a-positive-vision-for-ai.html
For many in the research community, it’s gotten harder to be optimistic about the impacts of artificial intelligence.
As authoritarianism is rising around the world, AI-generated “slop” is overwhelming legitimate media, while AI-generated deepfakes are spreading misinformation and parroting extremist messages. AI is making warfare more precise and deadly amidst intransigent conflicts. AI companies are exploiting people in the global South who work as data labelers, and profiting from content creators worldwide by using their work without license or compensation. The industry is also affecting an already-roiling climate with its enormous energy demands.
Meanwhile, particularly in the United States, public investment in science seems to be redirected and concentrated on AI at the expense of other disciplines. And Big Tech companies are consolidating their control over the AI ecosystem. In these ways and others, AI seems to be making everything worse.
This is not the whole story. We should not resign ourselves to AI being harmful to humanity. None of us should accept this as inevitable, especially those in a position to influence science, government, and society. Scientists and engineers can push AI towards a beneficial path. Here’s how.
A Pew study in April found that 56 percent of AI experts (authors and presenters of AI-related conference papers) predict that AI will have positive effects on society. But that optimism doesn’t extend to the scientific community at large. A 2023 survey of 232 scientists by the Center for Science, Technology and Environmental Policy Studies at Arizona State University found more concern than excitement about the use of generative AI in daily life—by nearly a three to one ratio.
We have encountered this sentiment repeatedly. Our careers of diverse applied work have brought us in contact with many research communities: privacy, cybersecurity, physical sciences, drug discovery, public health, public interest technology, and democratic innovation. In all of these fields, we’ve found strong negative sentiment about the impacts of AI. The feeling is so palpable that we’ve often been asked to represent the voice of the AI optimist, even though we spend most of our time writing about the need to reform the structures of AI development.
We understand why these audiences see AI as a destructive force, but this negativity engenders a different concern: that those with the potential to guide the development of AI and steer its influence on society will view it as a lost cause and sit out that process.
Many have argued that turning the tide of climate action requires clearly articulating a path towards positive outcomes. In the same way, while scientists and technologists should anticipate, warn against, and help mitigate the potential harms of AI, they should also highlight the ways the technology can be harnessed for good, galvanizing public action towards those ends.
There are myriad ways to leverage and reshape AI to improve peoples’ lives, distribute rather than concentrate power, and even strengthen democratic processes. Many examples have arisen from the scientific community and deserve to be celebrated.
Some examples: AI is eliminating communication barriers across languages, including under-resourced contexts like marginalized sign languages and indigenous African languages. It is helping policymakers incorporate the viewpoints of many constituents through AI-assisted deliberations and legislative engagement. Large language models can scale individual dialogs to address climate–change skepticism, spreading accurate information at a critical moment. National labs are building AI foundation models to accelerate scientific research. And throughout the fields of medicine and biology, machine learning is solving scientific problems like the prediction of protein structure in aid of drug discovery, which was recognized with a Nobel Prize in 2024.
While each of these applications is nascent and surely imperfect, they all demonstrate that AI can be wielded to advance the public interest. Scientists should embrace, champion, and expand on such efforts.
In our new book, Rewiring Democracy: How AI Will Transform Our Politics, Government, and Citizenship, we describe four key actions for policymakers committed to steering AI toward the public good.
These apply to scientists as well. Researchers should work to reform the AI industry to be more ethical, equitable, and trustworthy. We must collectively develop ethical norms for research that advance and applies AI, and should use and draw attention to AI developers who adhere to those norms.
Second, we should resist harmful uses of AI by documenting the negative applications of AI and casting a light on inappropriate uses.
Third, we should responsibly use AI to make society and peoples’ lives better, exploiting its capabilities to help the communities they serve.
And finally, we must advocate for the renovation of institutions to prepare them for the impacts of AI; universities, professional societies, and democratic organizations are all vulnerable to disruption.
Scientists have a special privilege and responsibility: We are close to the technology itself and therefore well positioned to influence its trajectory. We must work to create an AI-infused world that we want to live in. Technology, as the historian Melvin Kranzberg observed, “is neither good nor bad; nor is it neutral.” Whether the AI we build is detrimental or beneficial to society depends on the choices we make today. But we cannot create a positive future without a vision of what it looks like.
This essay was written with Nathan E. Sanders, and originally appeared in IEEE Spectrum.
Post Syndicated from Brett Ezell original https://aws.amazon.com/blogs/messaging-and-targeting/a-guide-to-sending-international-sms-with-us-toll-free-numbers-and-aws-end-user-messaging/
AWS End User Messaging now supports international SMS capabilities for US Toll-Free Numbers (TFNs). This new feature allows businesses to use a single US TFN to send SMS messages to over 150 countries, simplifying global outreach. It primarily benefits customers who need to send one-way transactional alerts—like one-time passwords (OTPs) or shipping notifications—and businesses that want to rapidly prototype and test their messaging strategy in new international markets without the overhead of procuring country-specific numbers.
This guide will walk you through the pros and cons of this feature and show you how to enable it and when to use it versus traditional, country-specific sending methods.
An International US Toll-Free Number is a standard US TFN that has been enabled with the capability to send SMS messages to destinations outside of the United States. This feature is backward compatible, meaning you can enable it on any new or existing US TFNs in your account.
There are three primary ways to enable this feature for your US Toll-Free Numbers:
For more information, see Request a phone number in AWS End User Messaging SMS
If you have already acquired a TFN, you can enable the international sending feature at any time.
The update-phone-number command allows you to modify a phone number’s capabilities, while the describe-phone-numbers command allows you to verify its status.
Use the --international-sending-enabled flag
aws pinpoint-sms-voice-v2 update-phone-number \
--phone-number-id "phone-a1b2c3d4e5f67890" \
--international-sending-enabled \
--region us-east-1
Note: Replace "phone-a1b2c3d4e5f67890" with your actual phone number’s ID
Use the --no-international-sending-enabled flag
aws pinpoint-sms-voice-v2 update-phone-number \
--phone-number-id "phone-a1b2c3d4e5f67890" \
--no-international-sending-enabled \
--region us-east-1Expected Response (for update-phone-number):
A successful command returns the full JSON object for the phone number. Confirm the change by checking that the InternationalSendingEnabled value is true
{
"PhoneNumberArn": "arn:aws:sms-voice:us-east-1:111122223333:phone-number/phone-a1b2c3d4e5f67890",
"PhoneNumberId": "phone-a1b2c3d4e5f67890",
"PhoneNumber": "+18005550199",
"Status": "ACTIVE",
"IsoCountryCode": "US",
"MessageType": "TRANSACTIONAL",
"NumberCapabilities": [
"SMS"
],
"NumberType": "TOLL_FREE",
"MonthlyLeasingPrice": "2.00",
"TwoWayEnabled": true,
"InternationalSendingEnabled": true,
"CreatedTimestamp": "2025-08-15T10:30:00.123Z"
}
Use the describe-phone-numbers command with your Phone Number ID to check its current configuration at any time.
aws pinpoint-sms-voice-v2 describe-phone-numbers \
--phone-number-ids "phone-a1b2c3d4e5f67890" \
--region us-east-1This feature offers a powerful new way to reach a global audience, but it’s important to understand where it shines and what its limitations are.
The pricing for this feature is straightforward:
For a complete and up-to-date list of prices by country, please visit the AWS End User Messaging Pricing page.
Choosing the right tool depends on your use case. Here’s a simple comparison:
Once you have enabled your international sending over US Toll-Free Numbers, you can enhance your messaging strategy by considering resilience, monitoring, and scalability. The following resources provide best practices for enhancing your sending.
DELIVERED or FAILED) to services like Amazon CloudWatch or Amazon Data Firehose for analysis.International SMS for US Toll-Free Numbers is a powerful strategic tool for businesses looking to simplify their global messaging. It excels at enabling rapid testing in new markets and efficiently delivering one-way transactional alerts across the globe from a single number.
However, it is not a replacement for the best practice of using dedicated, in-country phone numbers when reliable two-way conversations and guaranteed branding are critical to your campaign’s success. By understanding its benefits and limitations, you can strategically use this feature to get going quickly while planning a long-term move towards country-specific codes for your most important markets.
Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2025/11/cybercriminals-targeting-payroll-sites.html
Microsoft is warning of a scam involving online payroll systems. Criminals use social engineering to steal people’s credentials, and then divert direct deposits into accounts that they control. Sometimes they do other things to make it harder for the victim to realize what is happening.
I feel like this kind of thing is happening everywhere, with everything. As we move more of our personal and professional lives online, we enable criminals to subvert the very systems we rely on.