You don’t need to memorize 200 services to start your AWS journey. But you do need to understand the foundations. Here’s everything I wish someone had explained to me before I started studying for my AWS certification.

1. What Even Is Cloud Computing?

Let’s start from the very beginning. Cloud computing sounds fancy, but the core idea is simple: there’s a physical server somewhere, and you’re renting it over the internet.

Instead of buying your own hardware, setting up a server room, and hiring people to maintain it — you use someone else’s infrastructure (like AWS) and pay only for what you use.

Here’s the official NIST definition:

“A model for enabling ubiquitous, convenient, on-demand network access to a shared pool of **configurable computing resources* that can be rapidly provisioned and released with minimal management effort or service provider interaction.”*

Let’s break that down into human language:

• On-demand → You get resources whenever you want them
• Shared pool → Multiple customers share the same physical infrastructure
• Configurable → You choose how much CPU, RAM, storage you need
• Rapidly provisioned and released → Spin up a server in minutes, shut it down when you’re done
• Minimal management effort → No need to physically touch any hardware

2. What’s Actually Behind the “Cloud”?

Behind the cloud, there are real, physical server racks sitting in massive data centers around the world. AWS has these data centers spread across the globe, and the infrastructure is organized in a clear hierarchy:

Region

A large geographic area (e.g., eu-west-1 for Ireland, us-east-1 for N. Virginia). You choose a region based on where your users are, compliance requirements, or pricing.

Availability Zone (AZ)

Each Region contains multiple AZs (e.g., eu-west-1a, eu-west-1b, eu-west-1c). An AZ is one or more data centers with independent power, networking, and connectivity. Multiple AZs exist for redundancy — if one goes down, the others keep running.

Edge Locations / Points of Presence (PoP)

These are smaller, lightweight locations spread even more widely than Regions. They’re used primarily for caching content closer to end users.

3. Edge Networks and CDN — Speed Matters

Imagine your origin server is in the US, but a user in Southeast Asia wants to load your website. Without any optimization, every single request travels across the Pacific Ocean and back. That’s slow.

This is where Edge Networks and CDN (Content Delivery Network) come in.

How it works:

1. Your original content lives on the Origin Server (e.g., in us-east-1)
2. AWS caches copies of your static content (images, CSS, JS, videos) at PoP / Edge Locations around the world
3. When a user in Singapore requests your site, they get the cached version from the nearest PoP — not from the US
4. Result: dramatically lower latency

CDN vs Edge Network — are they the same thing?

Not exactly. The Edge Network is the infrastructure — the distributed network of servers worldwide. CDN is the most well-known use case of that infrastructure. In practice, people use the terms interchangeably, and that’s mostly fine.

AWS’s CDN service is called CloudFront, and it leverages these Edge Locations.

4. Virtualization and the Hypervisor

Here’s where it gets interesting. When you launch an EC2 instance, you’re not getting a dedicated physical server. Here’s what’s actually happening:

1. Host Computer → The physical AWS server rack in a data center
2. Host OS → The operating system running on that physical machine
3. Hypervisor → Software that sits on top of the Host OS and splits the physical machine into multiple virtual machines
4. Your EC2 Instance → One of those virtual machines

So if a physical server has 64 CPUs and 256 GB RAM, the hypervisor might split it into four isolated instances of 16 CPUs / 64 GB RAM each. Different customers can be using the same physical hardware without ever knowing about each other — completely isolated.

AWS built their own hypervisor called Nitro, which operates at the hardware level for minimal performance overhead.

Key takeaway: EC2 instances are virtual slices of physical servers, managed by a hypervisor. Multiple instances from different customers can live on the same physical machine, fully isolated from each other.

5. The Shared Responsibility Model — Who’s Responsible for What?

This is probably the most important concept for your certification exam. AWS and the customer share security responsibilities, but the line between them is very clear.

Security OF the Cloud → AWS’s Job

AWS is responsible for protecting the infrastructure that runs all the services:

• Physical security — data center access, cameras, biometric entry
• Hardware — servers, storage, networking equipment
• Software — compute, storage, database, networking services
• Global infrastructure — Regions, Availability Zones, Edge Locations
• Host OS & Hypervisor — you can’t even access these

Security IN the Cloud → Your Job

You are responsible for everything you put in and configure on the cloud:

• Customer data — whatever you upload, store, or process
• Platform, applications & IAM — who has access to what, roles, permissions, secret keys
• OS & firewall configuration — if you launched an EC2 with Ubuntu, patching it is on you
• Encryption — client-side, server-side, in-transit, at-rest decisions
• Network traffic protection — security groups, NACLs, VPN configurations

The Three Control Categories

Quick Quiz — Test Yourself

Simple rule of thumb: If you can configure it in the AWS Console or CLI → it’s your responsibility. If you can’t even touch it → it’s AWS’s responsibility. If both sides need to do their part → it’s shared.

Think of it like renting an apartment: AWS gives you a secure building (locked doors, fire alarms, security guards). But whether you lock your own door, put your valuables in a safe, or leave your windows open — that’s entirely on you.

6. AWS Support Plans — Developer vs Business

When you create an AWS account, you’ll need to choose a support plan. Here’s the practical difference between the two most common ones:

Which one should you pick?

• Developer → Great for learning, experimenting, and building prototypes. Start here if you’re just getting started.
• Business → Essential when you’re running production workloads with real users. The 1-hour critical response time alone is worth it when something goes down.

Good news: You can start with Developer and upgrade to Business anytime from the AWS Console (Support Center > Change Plan). Billing is prorated, so you only pay for what you use. You can also downgrade later if needed.

Wrapping Up

Before diving into specific services like S3, Lambda, or DynamoDB, make sure these foundational concepts are solid:

1. Cloud = renting virtual resources from physical infrastructure over the internet
2. Regions → AZs → Edge Locations form the backbone of AWS’s global presence
3. CDN / Edge Networks cache content close to users for speed
4. Hypervisors split physical servers into isolated virtual machines (EC2 instances)
5. Shared Responsibility Model — know what’s yours vs what’s AWS’s (this will be on the exam)
6. Support Plans can be upgraded/downgraded as your needs evolve

These aren’t glamorous topics, but they’re the bedrock everything else is built on. Nail these, and the rest of your certification journey will make a lot more sense.

Happy cloud learning! If you found this helpful, drop a reaction or follow for more AWS certification notes.

AI agents are moving from research demos to production systems. But most tutorials still show toy examples. Here are 5 battle-tested patterns that actually work at scale.

1. ReAct (Reasoning + Acting)

The most versatile pattern. The agent thinks about what to do, takes an action, observes the result, and repeats.

def run_react_agent(task, tools, max_steps=10):
    messages = [{"role": "user", "content": task}]

    for step in range(max_steps):
        response = client.messages.create(
            model="claude-sonnet-4-20250514",
            tools=tools,
            messages=messages
        )

        if response.stop_reason == "tool_use":
            tool_results = execute_tools(response)
            messages.extend([
                {"role": "assistant", "content": response.content},
                {"role": "user", "content": tool_results}
            ])
        else:
            return response.content[0].text

When to use: General-purpose tasks — research, data analysis, customer support.

2. Router Pattern

Instead of one agent doing everything, use a lightweight router to dispatch to specialized agents.

class RouterAgent:
    def __init__(self):
        self.agents = {
            "code": CodeAgent(),
            "research": ResearchAgent(),
            "writing": WritingAgent(),
        }

    def route(self, task):
        category = classify_task(task)  # haiku-level model
        return self.agents[category].run(task)

Why it works: Specialized agents with focused system prompts outperform generalist agents by 30-40% on benchmarks. And routing with a small model costs <$0.001 per request.

3. Tool-Use with Fallback Chain

Production agents need graceful degradation. If Tool A fails, try Tool B. If both fail, fall back to the LLM’s knowledge.

class FallbackToolAgent:
    def execute_with_fallback(self, tool_name, params):
        try:
            return self.tools[tool_name](**params)
        except Exception:
            pass

        fallback = self.fallbacks.get(tool_name)
        if fallback:
            try:
                return fallback(**params)
            except Exception:
                pass

        return self.llm_fallback(tool_name, params)

Key insight: In production, tools fail 5-15% of the time (API timeouts, rate limits, data issues). Without fallbacks, your agent fails 5-15% of the time too.

4. Multi-Agent with Shared Memory

When tasks are complex enough to need multiple agents, they need to share context efficiently.

class SharedMemory:
    def __init__(self):
        self.facts = {}
        self.history = []

    def add_fact(self, agent, key, value):
        self.facts[key] = {"value": value, "source": agent}
        self.history.append({"agent": agent, "action": "added", "key": key})

    def get_context_for(self, agent):
        return {k: v for k, v in self.facts.items()
                if self._is_relevant(k, agent)}

The mistake everyone makes: Sharing the entire conversation history between agents. This explodes token usage. Instead, share structured facts.

5. Human-in-the-Loop Checkpoints

The most important pattern for production: let the agent work autonomously, but pause for human approval at critical points.

class CheckpointAgent:
    def __init__(self, checkpoints):
        self.checkpoints = checkpoints

    async def run(self, task):
        plan = self.create_plan(task)

        for step in plan:
            if step.name in self.checkpoints:
                approved = await self.request_human_approval(step)
                if not approved:
                    return self.handle_rejection(step)

            result = await self.execute_step(step)

        return result

Rule of thumb: Any action that’s hard to reverse (sending emails, making payments, modifying production data) should have a checkpoint.

Framework Comparison (Quick Reference)

Next Steps

• Free: Download our AI Agent Starter Kit (5 templates + security checklist)
• Free: Subscribe to AI Agents Weekly for curated AI agent news 3x/week
• $29: Get The AI Agent Playbook — 80+ pages, 15 industry templates

Originally published on paxrel.com

A few days ago I was designing a GitHub Actions pipeline with security scanning tools. Choosing what to integrate, how to structure it, what permissions to give it — especially for the context of the project I was building it for. The kind of work that feels productive — you’re building something that will improve the team’s security posture.

That’s when I found out what had happened to Trivy.

On March 19, 2026, TeamPCP compromised the most widely used open-source vulnerability scanner in the cloud-native ecosystem. They didn’t hack a business application. They didn’t exploit a vulnerability in production code. They compromised the tool that thousands of organizations use to find vulnerabilities in their own applications. The security scanner became the weapon.

That made me stop. Not to throw the pipeline away — but to rethink from what principles I was building it.

This post is not a threat intelligence analysis. I’m a practitioner who is learning more and more about building security pipelines and who reflected on this case. What I found along the way changed how I think about trust in external dependencies.

What exactly happened?

The attack wasn’t a single event — it was a multi-phase campaign that lasted several days and started earlier than most people think.

Three weeks before March 19, an automated bot called hackerbot-claw exploited a misconfigured workflow in the Trivy repository and stole a Personal Access Token. Aqua Security detected the incident and rotated credentials — but the rotation was incomplete. TeamPCP retained access to the credentials that survived. That’s what made everything that followed possible. [Palo Alto Networks]

On March 19 at 17:43 UTC, using those retained credentials, TeamPCP compromised three components simultaneously:

The Trivy binary. A malicious version — v0.69.4 — was published across all official distribution channels: GitHub Releases, Docker Hub, GHCR, ECR Public, deb/rpm repositories, and get.trivy.dev. The scanning logic lives in this binary. The other two components are wrappers that invoke it. [Wiz Research]

trivy-action. The GitHub Action most teams use to integrate Trivy into their pipelines. TeamPCP force-pushed 76 of 77 version tags to point at malicious commits. Pipelines referencing these actions by tag began executing the attacker’s code on their next run — with no visible change to the tag name or the releases page. [Microsoft Security Blog]

setup-trivy. The Action that installs the binary. All 7 existing tags were compromised in the same way.

The payload was an infostealer that harvested SSH keys, cloud tokens, Kubernetes credentials, and pipeline environment variables — all while Trivy ran normally and produced the expected output. To an engineer reviewing the logs, the step appeared successful. [SANS Institute]

Exposure windows ranged from 3 to 12 hours depending on the component. Three days later, on March 22, TeamPCP published additional malicious images on Docker Hub — v0.69.5 and v0.69.6 — using separately compromised Docker Hub credentials, extending exposure by another ~10 hours. [Legit Security]

According to SANS Institute, more than 10,000 CI/CD workflows are reported to have been affected.

They didn’t exploit code — they exploited trust

When most teams think about an attack, they picture someone finding a buffer overflow, an SQL injection, an RCE. A technical vulnerability in the code that needs to be patched.

TeamPCP did none of that.

They didn’t find a bug in Trivy. They didn’t break any cryptographic algorithm. They exploited something much harder to patch: the implicit trust logic that organizations place in their dependencies. The premise that if a tool comes from the official vendor, through the official channel, with the official tag — it’s safe.

That premise is what failed.

There’s a brutal irony in how the impact was distributed. The most diligent teams — the ones who had integrated Trivy into every PR, every merge, every deploy — were the most exposed. The more disciplined the team was about running their security pipeline, the more times the infostealer ran. The good practice became the attack vector. [SANS Institute]

This is not an argument to stop scanning. It’s an argument to understand that trusting an external tool without verifying its integrity is exactly the same as trusting a user without verifying their identity. In IAM, nobody accepts that. In dependencies, we accept it all the time.

The expansion of the attack confirms it. TeamPCP didn’t stop at Trivy. On March 23 they compromised Checkmarx KICS — the infrastructure-as-code scanner. On March 24 they reached LiteLLM on PyPI, using credentials stolen from BerriAI’s Trivy pipeline. According to SANS Institute, one stolen token propagated across five distinct ecosystems: CI/CD, npm, Docker, PyPI, and AI infrastructure. [Arctic Wolf]

TeamPCP isn’t targeting business applications. It’s targeting the security tooling ecosystem — exactly the tools that the most security-conscious teams have integrated into their pipelines.

Mutable tags: not the vector, but the multiplier

When the attack was reported, much of the media focus fell on mutable tags. That makes sense — it’s the most striking technical detail. But it’s worth understanding exactly what role they played, because they weren’t the entry vector — they were what turned a single point of access into a massive problem.

To understand the difference, three concepts need to be separated.

The attack vector was the retained credential — the Personal Access Token that survived an incomplete rotation from a prior incident. That credential with write permissions over Aqua Security’s repositories is what gave TeamPCP initial access. Without it, nothing that followed would have been possible. [Palo Alto Networks]

The attack surface was the CI/CD pipelines of thousands of organizations referencing Trivy and its GitHub Actions by tag. Every pipeline running uses: aquasecurity/[email protected] was an exposed surface — not because it had a vulnerability, but because its trust model depended on the immutability of a tag that wasn’t immutable. According to SANS Institute, more than 10,000 CI/CD workflows were part of that surface.

Mutable tags were the multiplier. Once TeamPCP had access, tag mutability allowed them to silently redirect 76 of 77 tags in trivy-action and all 7 tags in setup-trivy to malicious commits — with no visible change in names, dates, or release pages. [Microsoft Security Blog]

Now, the fundamental difference between a tag and a digest.

A tag is a named pointer — v0.35.0, latest, v0.69.4. In Git and container registries, that name can be redirected to any commit or image without the name changing. No notification. No alert. No visible change on the releases page.

A digest is the SHA256 of the actual content — sha256:a3f8d2c1.... It’s immutable by definition. If the content changes, the digest changes. It can’t be forged, it can’t be redirected. Referencing a dependency by digest anchors it to a specific verified piece of content.

Any pipeline referencing those actions by tag began executing malicious code on its next run. Without any visible change. Without any alert. If those same pipelines had referenced the actions by digest, the force-push would have had no effect. The digest would still point to the original commit. The blast radius would have been dramatically smaller. [Legit Security]

Supply chain security = least privilege applied to dependencies

There’s a principle any engineer working with AWS knows by heart: least privilege. You don’t give a role more permissions than it needs. You don’t create access keys when you can use temporary roles. You don’t leave a * in a Resource when you can specify the exact ARN.

It’s the most repeated principle in cloud security. And yet, when it comes to external dependencies, we systematically ignore it.

When a pipeline runs uses: aquasecurity/[email protected], it’s placing full trust in that tag — without verifying its integrity, without anchoring to specific content, without questioning whether the pointer still points to what it pointed to yesterday. It’s the equivalent of giving AdministratorAccess to a role because “it’s easier.” It works. Until it doesn’t.

Supply chain security isn’t a separate domain from the security you already practice. It’s the same least privilege principle applied to a different level: your dependencies. The question isn’t “do I trust this tool?” — it’s “what verification do I have that what I’m executing is exactly what I think it is?”

The expansion of the attack illustrates why this matters at scale. TeamPCP didn’t need to compromise each organization individually. It compromised a central tool in the ecosystem and let implicit trust do the rest. LiteLLM was compromised because its pipeline used Trivy — the infostealer stole the PyPI publishing token, and from there TeamPCP published malicious versions with 3.6 million daily downloads. [SANS Institute]

One token. Five compromised ecosystems. That’s the geometry of a well-executed supply chain attack.

What makes this case especially uncomfortable is that the victims weren’t careless teams. They were teams that had invested in security, that scanned their pipelines, that used cloud-native tooling. Diligence didn’t protect them — because the diligence was applied inside the trust perimeter, not at the perimeter itself.

The solution is not to stop using external tools

The wrong conclusion from this incident would be to stop using Trivy, to distrust all open-source tools, or to build everything in-house. That’s neither viable nor the right lesson.

The lesson is that trust in external dependencies needs to be explicit and verifiable — not implicit and assumed.

Digest pinning

The most concrete and immediate change is to reference GitHub Actions by digest instead of by tag.

Instead of this:

- uses: aquasecurity/[email protected]

This:

- uses: aquasecurity/trivy-action@sha256:57a97c7...

The digest anchors the pipeline to a specific verified piece of content. If someone force-pushes the tag, the pipeline keeps executing the original commit. Tag mutability stops being a problem because the pipeline doesn’t depend on the tag. [Legit Security]

The obvious objection is that this makes updates harder — and it’s valid. A fixed digest doesn’t update itself. That’s where the second part comes in.

Dependabot and Renovate

Dependabot and Renovate can manage GitHub Actions updates automatically, including digest pinning. When a new verified version is released, they open a PR with the updated digest. The team reviews, approves, and the pipeline updates in a controlled and auditable way.

The combination closes the loop: digest pinning eliminates exposure to mutable tags, and Dependabot/Renovate eliminates the friction of maintaining digests manually.

Confirmed safe versions

For those using Trivy at the time of the incident, confirmed safe versions are: Trivy binary v0.69.3 or earlier, trivy-action v0.35.0 at commit 57a97c7, setup-trivy v0.2.6 at commit 3fb12ec. Any reference to v0.70.0 in logs should be treated as suspicious — the attacker attempted to publish that version but was stopped before the tag was pushed. [Legit Security]

Secrets: less is more

One thing this incident makes clear is the problem of pipelines that inherit more secrets than they need. If a scanning job doesn’t need production credentials, it shouldn’t have them — regardless of whether they’re temporary or static. Applying least privilege to what secrets get passed to each job reduces the blast radius when a tool is compromised.

Immediately rotate any credential that was exposed to a pipeline that ran compromised versions of Trivy between March 19 and March 22. That includes GitHub tokens, cloud credentials, registry tokens, SSH keys, and database passwords. [Legit Security]

Closing — what happened in LATAM

All of the above reflection could remain theoretical if it weren’t for someone in our community who lived this in real time.

Alejandro Castañeda, AWS Community Builder and Cloud Engineer from Colombia, shared on LinkedIn what happened to his team. His pipeline was compromised. The infostealer ran on a self-hosted runner inside his EKS cluster and sent approximately 80KB to the attacker’s server. To put that in perspective: 80KB is enough to carry away all the secrets from a complete pipeline.

And yet, they reviewed CloudTrail top to bottom and the result was zero lateral movement. No API calls from the attacker’s IP. No IAM user creation, no policy changes, no resource access.

Why?

Because Alejandro’s team had made an architecture decision ahead of time, when they were defining the foundations of their infrastructure: OIDC with IAM Roles instead of static access keys. Their pipelines assumed temporary roles that expired in minutes. By the time the attacker had the credentials in hand, they were already worthless. And the role’s trust policy only allowed use from GitHub — so even if they hadn’t expired, they couldn’t be used from anywhere else.

If they had had static access keys stored as GitHub secrets, the story would be completely different. The attacker would have had access to ECR to inject malicious images into production containers, and to Secrets Manager to read database credentials and financial service tokens.

The difference between “our secrets were stolen and nothing happened” and a real disaster was an architecture decision that nobody made thinking about this specific attack. They made it because it was the right way to build.

That’s what I take from this incident. Not the list of affected versions — that changes. Not the name of the threat actor — that changes too. What doesn’t change is the principle: design so that when someone compromises a dependency, they don’t find anything useful on the other side.

Security isn’t about building a perfect wall. It’s about making sure that when someone jumps it, there’s nothing useful on the other side.

About the author

Gerardo Castro is an AWS Security Hero and Cloud Security Engineer focused on LATAM. Founder and Lead Organizer of the AWS Security Users Group LatAm. He believes the best way to learn cloud security is by building real things — not memorizing frameworks. He writes about what he builds, what he finds, and what he learns along the way.

🔗 GitHub: gerardokaztro
🔗 LinkedIn: gerardokaztro

“You’ve reached 75% of your usage limit for this week.” must be familiar to quite a few people now.

The promise vs. the reality, especially when subscriptions start at $20/month is frustrating, to say the least.

Now don’t get me wrong, i still do think that Claude is a great tool, and it has helped me a lot in building a website. But the message limits make me hesitant about renewing my subscription at this point.

The “just switch to another model” argument doesn’t hold up.
“Hit the limit? No problem — here’s a lighter model to keep you going.”

Sure. Except that the lighter model doesn’t have the context of the last 40 messages you just built up ?

It doesn’t know you already ruled out Solution B or that you’re on Node 18, not 20. So you either start over, re-paste everything, or accept dramatically degraded output quality.

The limit doesn’t hit the casual user who fires off five prompts a week. It hits the person who has made AI a core part of their production workflow — the exact user these subscriptions were designed to attract.

Moreover, you never really know exactly where you stand until you’re blocked.
No progress bar. No “you’ve used 30% of your weekly allowance” warning. Just a hard stop at the worst possible moment. For anyone managing a deadline, this is genuinely disruptive.
Basic usage transparency shouldn’t be a premium feature.

“Just upgrade to the enterprise tier”

Some will say: pay more, get more. Fair enough in principle.
But the jump from individual to enterprise pricing isn’t a gradual scale — it’s a cliff.

The pricing architecture seems deliberately designed to push anyone with serious usage needs into an enterprise contract, rather than offering a middle tier that actually fits solo builders and small teams.
For developers bootstrapping products on their own, that’s a non-starter.

I’m not arguing that AI companies should run at a loss to serve unlimited queries. Compute costs are real. But i just think there’s a reasonable middle ground that needs to be found:
∙ Visible usage tracking — show me how much I’ve consumed in real time
∙ Rollover credits — unused capacity this week shouldn’t just evaporate
∙ Graceful degradation warnings — tell me I’m approaching the limit before I’m cut off mid-session
∙ Session continuity: if I do hit a cap, preserve context so I can resume without starting from scratch
None of these are technically impossible. They’re product decisions.

We’re paying for infrastructure. We deserve more clarity about what we’re actually buying.

Why another PDF tool? Because privacy shouldn’t be a premium feature.

We’ve all been there. You have a 40-page PDF report, your client needs pages 12–18, and the only tools you can find either slap a watermark on the output, cap your file size, or — most troublingly — upload your document to some server you’ve never heard of before “processing” it.
That last part should bother you more than it does.
I built iHatePDF’s Split PDF tool to solve exactly this problem. It’s fast, it’s free, it has no file size limit, and — most importantly — your files never leave your device. Not a single byte.
Here’s the full story.

The Problem with Most Online PDF Tools
Online PDF utilities are everywhere. But most of them share an uncomfortable architecture: you upload your file, it travels to a remote server, gets processed, and then gets sent back to you. Along the way, your document — which might contain contracts, medical records, financial data, or intellectual property — passes through infrastructure you don’t control and likely don’t understand.
Some tools are upfront about this. Many are not. And even the honest ones that promise to “delete your file after 1 hour” are asking you to take their word for it.
There’s a better way.

The Core Idea: Keep Everything in the Browser
Modern browsers are incredibly capable. Thanks to APIs like the File API, Web Workers, and libraries like pdf-lib, you can do serious PDF manipulation entirely on the client side — no server required.
This is exactly what the Split PDF tool does. When you upload a PDF:

It’s read into memory using the browser’s FileReader API as an ArrayBuffer.
pdf-lib parses the document and counts the pages.
When you hit “Split PDF,” the library creates new PDF documents, copies the relevant pages over, and generates downloadable byte arrays.
Those byte arrays are handed directly to your browser’s download mechanism.

At no point does the file travel over a network. The “server” is your own CPU.
javascriptconst buffer = await readFileAsArrayBuffer(file);
const { PDFDocument } = window.PDFLib;
const sourcePdf = await PDFDocument.load(buffer);
Three lines. That’s the entire “upload” step — and it never left your machine.

Two Ways to Split
The tool offers two splitting modes, designed to cover the most common real-world scenarios.

1. By Page Ranges
   This is the power-user mode. You type something like 1-5, 10-15, 20 and the tool produces three separate PDF files — one for each range. It’s perfect for:

Breaking a book into chapters
Extracting a specific section of a report to share with stakeholders
Separating a combined invoice document into individual invoices

The range parser handles both ranges (1-5) and single pages (20) in the same input string, separated by commas. Clean and flexible.
javascriptconst parseRanges = (rangeStr) => {
const result = [];
for (const part of rangeStr.split(“,”).map((s) => s.trim())) {
if (part.includes(“-“)) {
const [start, end] = part.split(“-“).map((n) => parseInt(n.trim()));
if (!isNaN(start) && !isNaN(end) && start <= end)
result.push({ start: start – 1, end: end – 1 });
} else {
const num = parseInt(part);
if (!isNaN(num)) result.push({ start: num – 1, end: num – 1 });
}
}
return result;
};
Notice the – 1 offsets — PDF page indices are zero-based internally, but humans count from 1. Small detail, big UX impact.

1. Individual Pages
   One click, and every page becomes its own PDF file. A 20-page document turns into 20 separate downloads. This is ideal for distributing slides, archiving scanned documents page by page, or just giving someone exactly the one page they asked for.
   To avoid overwhelming the browser’s download manager, individual page downloads are staggered with a 100ms delay between each one — a tiny but important UX consideration.

Handling Downloads Across Every Browser
Cross-browser file downloads sound trivial until you try to support Safari on iOS. The tool uses a layered download helper that tries progressively more compatible approaches:

A custom window.download function if available
The legacy msSaveOrOpenBlob for old Edge/IE
A programmatically clicked tag (the standard modern approach)
As a last resort, window.open() with a blob URL, with a prompt to allow pop-ups

iOS Safari gets a special callout UI element that reminds users to check their Files app → Downloads folder, since the native Safari download behavior differs from desktop browsers.
javascriptconst isIOSSafari = () => {
const ua = window.navigator.userAgent;
return (
(!!ua.match(/iPad/i) || !!ua.match(/iPhone/i)) &&
!!ua.match(/WebKit/i) &&
!ua.match(/CriOS/i)
);
};
Small touches like this are what separate a tool people actually use from a tool people abandon in frustration.

Local History Without a Backend
The tool tracks your recent splits using a hybrid storage strategy:

Metadata (filename, tool used, timestamp, size) goes into localStorage — lightweight and fast.
The actual PDF bytes go into IndexedDB — the browser’s structured data store, capable of handling large binary blobs.

This means you can revisit recent files without re-uploading anything, and it all works offline. No accounts. No sync. No data leaving your device.
javascriptconst addToHistory = async (pdfData) => {
const history = JSON.parse(localStorage.getItem(HISTORY_KEY) || “[]”);
const newEntry = { id: Date.now(), name: pdfData.name, tool: pdfData.tool, … };
if (pdfData.bytes) {
await dbSet(pdf_${newEntry.id}, pdfData.bytes); // IndexedDB
}
history.unshift(newEntry);
localStorage.setItem(HISTORY_KEY, JSON.stringify(history.slice(0, 50)));
};
The history is capped at 50 entries to keep storage usage reasonable. Pragmatic, not precious.

Quality Is Never Compromised
One concern people often have with PDF tools is quality degradation. This tool sidesteps the issue entirely — because there is no re-rendering happening.
pdf-lib doesn’t rasterize your pages into images and repack them. It copies the raw PDF page objects from the source document into the new document. The text stays as text. The vector graphics stay as vectors. The embedded fonts stay embedded. You get a byte-perfect extraction, not a screenshot of a page.

The Bigger Picture
This tool is part of a broader philosophy: your files are yours. The browser has become powerful enough that the reflexive “upload to server → process → download” pipeline is often unnecessary, and increasingly, it’s irresponsible.
Client-side PDF processing is just one example. The same principle applies to image compression, document conversion, data parsing, and dozens of other utility tasks that millions of people outsource to servers every day when they don’t have to.
As developers, we have a responsibility to ask: does this actually need to leave the user’s device? More often than the current ecosystem suggests, the answer is no.

Try It
If you’ve ever needed to split a PDF — and who hasn’t — give it a try. Upload a file, split it, and notice what doesn’t happen: no spinner while a server “processes” it, no email confirmation, no account wall, no watermark on the output.
Just your PDF, split the way you want it, in seconds, entirely on your machine.
That’s what PDF tools should have been all along.

Built with React, pdf-lib, and a deep distrust of unnecessary server round-trips. All processing happens locally in your browser — always.

https://github.com/shrec/UltrafastSecp256k1
A detailed look at what sets this library apart — not just in speed, but in engineering discipline, audit culture, and verified correctness.

1. Audit-First Engineering Culture

Most high-performance cryptographic libraries ship fast code and trust that it is correct.
UltrafastSecp256k1 ships fast code and then systematically tries to break it.

The internal self-audit system is not a layer of unit tests bolted on after the fact —
it was designed in parallel with the cryptographic implementation, as a first-class engineering artifact.

The underlying philosophy is Bitcoin-style: don’t trust, verify. The project does
not center its trust model on a one-time PDF artifact written by someone else at a
fixed moment in the past. Instead, it tries to make assurance continuously rerunnable:
every important claim should be tied to code, tests, CI artifacts, benchmark logs, or
traceable documentation that another engineer can reproduce on demand.

This is why the audit framework keeps expanding with the codebase. The repository ships
not only tests, but also reviewer-facing infrastructure: structured audit artifacts,
threat-model docs, adversarial exploit tests, differential checks, and a repo-local
SQLite source graph that makes the codebase searchable as an audit surface rather than
just a pile of files.

These top-level differentiators are claim-keyed in the ledger: exploit-audit surface A-005, graph-assisted review A-006, self-audit transparency A-007, and benchmark reproducibility A-004 in docs/ASSURANCE_LEDGER.md.

What the Audit Infrastructure Covers

All 55 audit modules across all tested platforms return AUDIT-READY. Zero failures.
All 86 exploit PoC tests pass. Zero failures across all 14 coverage areas.

Self-Audit Documents

2. CI/CD Pipeline — 24 Automated Workflows

The continuous integration pipeline is not a basic build-and-test gate.
It is a multi-layer quality enforcement system with 24 GitHub Actions workflows
covering security, correctness, performance, supply chain, and formal analysis.

It is also only one part of the assurance model. The repository is routinely reviewed
through external-style passes as if by auditors, attackers, and bug bounty hunters,
including LLM-assisted review loops that help surface edge cases, exploit ideas, and
documentation gaps. Those passes are not treated as magic or as a replacement for
deterministic tests; they are useful because they feed new cases back into the same
reproducible audit framework.

Workflow Index (selected)

Build Matrix Scale

3. Static Analysis & Sanitizer Stack

Every commit is checked by multiple independent static and dynamic analysis layers:

The -Werror flag is enforced — warnings are build failures.

4. Supply Chain Security

Cryptographic libraries are high-value supply chain targets.
UltrafastSecp256k1 applies the OpenSSF supply-chain hardening model:

• OpenSSF Scorecard — automated weekly supply-chain health score
• OpenSSF Best Practices badge — verified against the CII/OpenSSF criteria
• Pinned GitHub Actions — all third-party actions pinned to commit SHA, not floating tags
• Dependency Review — automated PR-level scan for vulnerable dependencies
• Harden-runner — runtime monitoring of CI runner behaviour
• Reproducible builds — Dockerfile.reproducible for bit-for-bit build verification
• SBOM — software bill of materials generated on release
• Artifact attestation — GitHub Artifact Attestation on release builds

5. Formal Verification Layers

6. Performance — Verified, Not Just Claimed

Every benchmark number in this project is:

• Produced by a pinned compiler version with exact flags documented
• Reproducible via a published command in docs/BENCHMARKS.md
• Gated by an automated performance regression check in CI (bench-regression.yml)
• Published to a live dashboard on pushes to dev/main

Sample verified numbers (RTX 5060 Ti, CUDA 12):

Sample verified numbers (x86-64 rerun, i5-14400F, Clang 19):

7. What “Not Paid-Externally Audited” Actually Means Here

UltrafastSecp256k1 has not yet undergone a paid third-party professional audit.
That is a factual status note, not the center of the project’s security philosophy.
The project is open to external audit and continuously prepares evidence so outside reviewers can audit it at any time.
At the same time, it does not wait for a third party to begin strengthening correctness and security, and it does not outsource trust to a single PDF milestone.

However, “not externally audited” does not mean “unverified.” The internal quality infrastructure described in this document represents a systematic, multi-layer correctness assurance program that most open-source cryptographic libraries do not have:

• Over 1,000,000 internal audit assertions executed on every build
• 24 CI/CD workflows enforcing correctness, security, and performance on every push/PR plus scheduled assurance runs
• Formal constant-time verification on two independent platforms
• Supply-chain hardening at the OpenSSF standard
• Nightly differential testing at 1.3M+ additional random checks per night

The honest summary:

This library does not rely on a paid-audit badge as its primary trust story.
It does rely on open self-audit, reproducible evidence, graph-assisted review, and reviewer-friendly verification so anyone can inspect and challenge the implementation.
External audit is welcomed, but assurance work already happens continuously through internal audit on every build, every push/PR gate, and every nightly extended run.

Summary Table

https://github.com/shrec/UltrafastSecp256k1

Video Friday is your weekly selection of awesome robotics videos, collected by your friends at IEEE Spectrum robotics. We also post a weekly calendar of upcoming robotics events for the next few months. Please send us your events for inclusion.

ICRA 2026: 1–5 June 2026, VIENNA

RSS 2026: 13–17 July 2026, SYDNEY

Summer School on Multi-Robot Systems: 29 July–4 August 2026, PRAGUE

Enjoy today’s videos!

“Roadrunner” is a new bipedal wheeled robot prototype designed for multi-modal locomotion. It weighs around 15 kg (33 lb) and can seamlessly switch between its side-by-side and in-line wheel modes and stepping configurations depending on what is required for navigating its environment. The robot’s legs are entirely symmetric, allowing it to point its knees forward or backward, which can be used to avoid obstacles or manage specific movements. A single control policy was trained to handle both side-by-side and in-line driving. Several behaviors, including standing up from various ground configurations and balancing on one wheel, were successfully deployed zero-shot on the hardware.

[ Robotics and AI Institute ]

Incredibly (INCREDIBLY!) NASA says that this is actually happening.

NASA’s SkyFall mission will build on the success of the Ingenuity Mars helicopter, which achieved the first powered, controlled flight on another planet. Using a daring mid-air deployment, SkyFall will deliver a team of next-gen Mars helicopters to scout human landing sites and map subsurface water ice.

[ NASA ]

NASA’s MoonFall mission will blaze a path for future Artemis missions by sending four highly mobile drones to survey the lunar surface around the Moon’s South Pole ahead of astronauts’ arrival there. MoonFall is built on the legacy of NASA’s Ingenuity Mars Helicopter. The drones will be launched together and released during descent to the surface. They will land and operate independently over the course of a lunar day (14 Earth days) and will be able to explore hard-to-reach areas, including permanently shadowed regions (PSRs), surveying terrain with high-definition optical cameras and other potential instruments.

For what it’s worth, Moon landings have a success rate well under 50%. So let’s send some robots there to land over and over!

[ NASA ]

In Science Robotics, researchers from the Tangible Media group led by Professor Hiroshi Ishii, together with colleagues from Politecnico di Bari, present Electrofluidic Fiber Muscles: a new class of artificial muscle fibers for robots and wearables. Unlike the rigid servo motors used in most robots, these fiber-shaped muscles are soft and flexible. They combine electrohydrodynamic (EHD) fiber pumps — slender tubes that move liquid using electric fields to generate pressure silently, with no moving parts — with fluid-filled fiber actuators. These artificial muscles could enable more agile untethered robots, as well as wearable assistive systems with compact actuation integrated directly into textiles.

[ MIT Media Lab ]

In this study, we developed MEVIUS2, an open-source quadruped robot. It is comparable in size to Boston Dynamics Spot, equipped with two LiDARs and a C1 camera, and can freely climb stairs and steep slopes! All hardware, software, and learning environments are released as open source.

[ MEVIUS2 ]

Thanks, Kento!

What goes into preparing for a live performance? Arun highlights the reliability testing that goes into trying a new behavior for Spot.

[ Boston Dynamics ]

In this work, a multi-robot planning and control framework is presented and demonstrated with a team of 40 indoor robots, including both ground and aerial robots.

That soundtrack though.

[ GitHub ]

Thanks, Keisuke!

Quadrupedal robots can navigate cluttered environments like their animal counterparts, but their floating-base configuration makes them vulnerable to real-world uncertainties. Controllers that rely only on proprioception (body sensing) must physically collide with obstacles to detect them. Those that add exteroception (vision) need precisely modeled terrain maps that are hard to maintain in the wild. DreamWaQ++ bridges this gap by fusing both modalities through a resilient multi-modal reinforcement learning framework. The result: a single controller that handles rough terrains, steep slopes, and high-rise stairs—while gracefully recovering from sensor failures and situations it has never seen before.

That cliff behavior is slightly uncanny.

[ DreamWaQ++ ]

I take issue with this from iRobot:

While the pyramid exploration that iRobot did was very cool, they did it with a custom made robot designed for a very specific environment. Cleaning your floors is way, way harder. Here’s a bit more detail on the pyramids thing:

[ iRobot ]

More robots in circus please!

[ Daniel Simu ]

MIT engineers have designed a wristband that lets wearers control a robotic hand with their own movements. By moving their hands and fingers, users can direct a robot to perform specific tasks, or they can manipulate objects in a virtual environment with high-dexterity control.

[ MIT ]

At NVIDIA GTC 2026, we showcased how AI is moving into the physical world. Visitors interacted with robots using voice commands, watching them interpret intent and act in real time — powered by our KinetIQ AI brain.

[ Humanoid ]

Props to Sony for their continued support and updates for Aibo!

[ Aibo ]

This robot looks like it could be a little curvier than normal?

[ LimX Dynamics ]

Developed by Zhejiang Humanoid Robot Innovation Center Co., Ltd., the Naviai Robot is an intelligent cooking device. It can autonomously process ingredients, perform cooking tasks with high accuracy, adjust smart kitchen equipment in real time, and complete post-cooking cleaning. Equipped with multi-modal perception technology, it adapts to daily kitchen environments and ensures safe and stable operation.

That 7x is doing some heavy lifting.

[ Zhejiang Lab ]

This CMU RI Seminar is by Hadas Kress-Gazit from Cornell, on “Formal Methods for Robotics in the Age of Big Data.”

Formal methods – mathematical techniques for describing systems, capturing requirements, and providing guarantees – have been used to synthesize robot control from high-level specification, and to verify robot behavior. Given the recent advances in robot learning and data-driven models, what role can, and should, formal methods play in advancing robotics? In this talk I will give a few examples for what we can do with formal methods, discuss their promise and challenges, and describe the synergies I see with data-driven approaches.

[ Carnegie Mellon University Robotics Institute ]