Techlist.io - Korean Tech Blog Curator

cloudflare·Jul 30, 2026·4 min readCurated summary

Dogfooding at scale: migrating cdnjs to Cloudflare’s Developer Platform

cdnjs now runs entirely on Cloudflare’s Developer Platform after a migration intended to improve maintainability rather than performance. Despite the rise of bundlers and modern JavaScript tooling, cdnjs still serves about 9 billion requests per day because it is free, familiar, immutable, auditable, and widely used by both developers and AI coding assistants. The migration replaces a fragmented GCP, GitHub, VM, and Cloudflare setup with a unified architecture built around Workers, R2, Workflows, Queues, D1, KV, Cache, and Containers. ## cdnjs’s Scale and Continued Relevance - cdnjs serves roughly: - 108,000 requests per second - 9 billion requests per day - Traffic across more than 330 Cloudflare data centers - A 98.6% cache-hit rate - It is used by approximately 12% of websites and holds a 48.3% share of the JavaScript CDN market. - Its simple `<script>`-tag model remains popular because: - URLs and versions are consistent and immutable. - Libraries are available without accounts, API keys, or rate limits. - Files include Subresource Integrity hashes. - The project is open source and community-driven. - AI assistants frequently generate cdnjs URLs because they appear throughout years of tutorials, documentation, GitHub repositories, and Stack Overflow answers. ## Why the Existing Architecture Became a Problem - Cloudflare moved cdnjs file serving to Workers and KV in 2020, improving resilience and enabling pre-compressed Brotli and gzip assets. - The publishing pipeline remained on GCP because Cloudflare previously lacked suitable tools for: - Fetching large package archives - Running CPU-intensive processing - Coordinating multi-step jobs over hours - The old pipeline combined GCP Functions, Google Cloud Storage, Pub/Sub, a git-sync VM, GitHub, Workers KV, and a bare-metal origin. - New features and bug fixes required coordinating deployments across multiple platforms, while observability required manually stitching together unrelated logs. ## Problems with the Legacy Pipeline - **No shared tracing** - Package updates could pass through several systems without a common correlation ID. - Partial failures could leave KV updated while GitHub remained stale, with no alert indicating the divergence. - **Split-brain storage** - File content existed both in Workers KV and a GitHub repository. - Neither system was cleanly authoritative, making reconciliation difficult. - **Storage-driven orchestration** - GCP Cloud Functions triggered one another through object-created events. - Storage effectively acted as a message queue without dead-letter handling, backlog visibility, or reliable replay. - **Operational fragmentation** - npm polling required 26 separately deployed Cloud Functions, one for each alphabetic shard. - Health monitoring required checking all 26 deployments and their logs. - **An oversized GitHub repository** - The repository exceeded 1.1 TB of packed storage. - GitHub could no longer generate archive downloads reliably. - Cloning and forking became impractical. - A 274-entry `.gitignore` accumulated to exclude releases the pipeline could not reject properly. - **Security overhead** - Cloud Functions, a VM, container images, storage buckets, and service-account credentials all required patching, auditing, and protection. - Retiring these components reduced the attack surface and eliminated recently exposed vulnerabilities. ## The New Cloudflare-Based Architecture - The rebuilt system uses Cloudflare’s Developer Platform end to end. - **R2** becomes the single source of truth for file content. - It can store large assets that previously did not fit comfortably in KV, including source maps, large bundles, and font packages. - Its S3-compatible API makes the catalog accessible to external tools and mirrors. - The broader platform combines: - Workers for request handling - Workflows for orchestration - Queues for reliable asynchronous processing - R2 for durable object storage - D1, KV, Workers Cache, and Containers for supporting services - Centralizing the pipeline should make processing state observable, reduce deployment complexity, and eliminate inconsistencies between edge storage and the GitHub repository. ## Practical Conclusion The cdnjs migration demonstrates that a globally critical, high-volume open-source service can evolve from a collection of legacy systems into a unified serverless platform. Its continued value comes not only from speed, but from being free, predictable, immutable, and easy for both humans and automated tools to consume.

Read original(opens in new tab)

Cloudflare WorkersServerlessContent Delivery NetworkCloudflare R2+3

line·Jul 30, 2026·4 min readCurated summary

Android CLI for AI Agents: Applying It to Large-Scale Mobile Development Environments

LINE’s Android app is a large monorepo with hundreds of Gradle modules and developers, making unrestricted AI-agent searches expensive and unreliable. Generic tools such as `grep` and `glob` often return excessive, semantically weak results, causing agents to waste tokens and retry. The team therefore built thin wrappers, skills, and prompts around Android CLI to provide efficient documentation lookup and Android Studio’s semantic capabilities across multiple agents. ## Why Generic Search Breaks Down at Scale - Large repositories can return huge numbers of search results from a single request. - Search output consumes agent context and increases costs. - Text search cannot reliably answer semantic questions such as: - Where a symbol is declared or used - Whether a file contains IDE-detectable problems - Whether code is unused - As the number of modules grows, agents are more likely to rely on irrelevant results and repeat searches. ## Replacing MCP Documentation Search with Android CLI - The team first adopted Android CLI for official documentation search. - It provides current documentation for Android, Jetpack Compose, AndroidX, Firebase, and related technologies. - This helps reduce hallucinations caused by outdated pretrained knowledge. - Android CLI’s `docs` commands are exposed through the `get-android-dev-knowledge` skill: - `docs search` finds relevant documentation. - `docs fetch` retrieves the document body from its Knowledge Base URL. - Compared with the previous Google Cloud Knowledge MCP setup, Android CLI eliminates: - Per-developer Google Cloud authentication - An authentication proxy - Quota-management and workaround logic - The result is fresher documentation with fewer tokens and less supporting infrastructure. ## Bundling the Android CLI Binary The team stores the Android CLI binary in the repository and invokes it from a fixed path such as `.agents/tools/android-cli/android`. - **Consistent environments** - Developers, CI systems, and agent hosts use the same pinned version. - Installation differences in version, path, and platform are reduced. - **Security enforcement** - The wrapper automatically adds `--no-metrics`. - This prevents agents from accidentally omitting the company-required telemetry setting. - A fixed binary location makes reliable wrapper enforcement possible. - **Manageable repository cost** - Existing use of Git LFS makes storing the binary relatively inexpensive. ## Handling the Android CLI Metrics Bug - Android CLI 1.0 initializes metrics tracking before honoring `--no-metrics`. - It may still attempt to write under `~/.android/cli`. - In restricted sandboxes, this causes a multi-page Java stack trace, wasting agent context. - The wrapper now probes write access before invoking the CLI: - It creates `~/.android/cli`. - It attempts to create a temporary probe file. - If writing is blocked, it emits a concise, parseable error explaining the required permission. - This converts a noisy failure into an actionable one-line message. ## Android Studio Integration Android CLI 1.0 added integration with running Android Studio instances, enabling IDE-level semantic operations from the command line. - `studio check` - Verifies that Android Studio is running. - Confirms that the target project is open and indexing is complete. - `analyze-file` - Runs IDE inspections on a single file without a build. - Detects semantic issues such as unused code. - `find-declaration` - Locates symbol declarations in the project and inside `.aar` or `.jar` dependencies. - `find-usages` - Finds references to a symbol. - `render-compose-preview` - Renders Compose `@Preview` functions as PNG images. ## Wrapping Studio Features as Skills - The team does not expose raw Android CLI behavior directly to agents. - Each capability is wrapped in a lightweight script and presented as an agent skill. - The first skill created was `studio-check`. - This follows the same design used for documentation search and ensures failures are concise, predictable, and easier for agents to interpret. ## Practical Recommendation For large Android repositories, use Android CLI behind repository-pinned wrappers and agent skills rather than exposing generic search or raw CLI commands directly. Enforce security flags, validate filesystem prerequisites early, and prefer IDE-backed semantic operations when agents need declarations, usages, inspections, or Compose previews.

Read original(opens in new tab)

Model Context ProtocolAndroidGradleAi Coding Agents+3

google·Jul 30, 2026·3 min readCurated summary

Science One Framework: A verifiable autonomous research framework via Chain-of-Evidence

The Science One Framework addresses a central weakness in autonomous AI research: polished papers can contain fabricated citations, unreproducible results, or methods that do not match the underlying code. Its Chain-of-Evidence (CoE) framework requires every claim to be linked to concrete evidence and introduces CoE Audit to test those links automatically. In evaluations, Science One produced fully verifiable papers while matching or exceeding baseline research agents and human performance on several benchmarks. ## Chain-of-Evidence for Verifiable Research - CoE defines trustworthy research artifacts through two requirements: - **Completeness:** Every claim has a recorded evidence chain. - **Correctness:** The evidence genuinely supports the claim. - Claims may include: - Bibliographic references - Reported scores - Method descriptions - Conclusions - Evidence can include peer-reviewed papers, experiment logs, executed code, or result tables. - Hallucinated citations, unreproducible scores, and discrepancies between described and implemented methods are treated as broken evidence chains. ## The Science One Framework The framework builds evidence into the research process instead of attempting to verify a paper after it has been written. - **Problem Investigator** - Uses the Semantic Scholar API to construct a citation graph. - Reads up to 100 full-text PDFs per topic. - Produces a structured research brief. - Restricts final-paper references to sources retrieved through the grounded API, avoiding citations generated from model memory. - **Discovery Engine** - Explores ideas through parallel explore-exploit branches. - Each isolated cycle includes a Solver agent and a task-specific evaluator. - High-performing solutions are iteratively refined. - Raw evaluator outputs are preserved in strict, read-only records. - **Paper Writer and Claim Verifier** - Creates a structured inventory of factual claims. - Attaches inline evidence tags linking claims to workspace artifacts. - Checks each claim against its declared source. - Rewrites unsupported claims conservatively rather than allowing them to exceed the evidence. ## CoE Audit Integrity Checks CoE Audit is an automated, post-hoc forensic review of a paper, solution, code, and references. - **Score verification:** Re-runs the submitted code independently and compares the result with the paper’s reported score. - **Specification violation:** Checks whether the code solves the intended task without exploiting the evaluator or accessing ground-truth answers. - **Reference verification:** Validates every bibliography entry against academic APIs. - **Method-code alignment:** Compares the paper’s method description with the actual implementation using LLM-based judges. ## Evaluation Results - The audit evaluated 75 papers across five systems-optimization tasks: Prism, Cloudcast, EPLB, LLM-SQL, and transaction scheduling. - Science One led the evaluated systems on all four integrity checks. - It had: - Zero phantom references - Perfect score verification - The strongest method-code alignment - Baseline systems hallucinated up to 21% of references and sometimes described advanced algorithms that were implemented as simple deterministic heuristics. - Strong verification did not reduce performance: - Science One matched or exceeded human experts on all five ADRS tasks. - It achieved the best overall result on Cloudcast and EPLB. - On additional MLE-Bench and Parameter Golf evaluations, the framework also demonstrated competitive performance, including two Gold Medals across five difficult Kaggle competitions. The main recommendation is to design autonomous research systems around evidence generation from the beginning. Grounded retrieval, immutable experiment records, claim-level verification, and independent auditing can substantially improve reliability without necessarily sacrificing research performance.

Read original(opens in new tab)

Large Language ModelsMachine LearningAutonomous AgentsSemantic Scholar Api+3

figma·Jul 30, 2026·2 min readCurated summary

A Properties Panel and Annotations, Now in Figma Make | Figma Blog

Figma Make now combines visual editing with code-aware prompting through a properties panel and annotations. The properties panel handles precise visual changes, while annotations let users describe interactions and animations in context. Together, these tools reduce prompting guesswork, use fewer credits, and help ensure visual edits are reflected in the underlying code. ## Visual Editing with the Properties Panel - Users can select elements and adjust spacing, typography, layout, opacity, z-index, borders, corner radii, and other properties. - A DOM tree acts like a layers panel, making it easier to find and select elements in the code. - Multiple instances of an element can be updated simultaneously. - Edits use existing color and typography tokens from the codebase. - Each change is staged in the prompt box for review or disposal before being applied. - Applying the changes updates the underlying code and creates a new file version. - Future Code Connect integration will link Make elements to Figma Design components. ## Contextual Changes with Annotations - Users can mark one or more areas directly on the canvas and describe the desired change. - Annotations support behavior beyond basic styling, such as: - Hover zoom effects - Delayed button fades - Press effects - Full-screen navigation overlays - The agent receives the exact location and context of the selected elements, making prompts more specific. - This approach supports flexible natural-language instructions while avoiding the ambiguity of describing element locations manually. ## Credit Savings and Workflow - Direct manipulation gives the agent a precise target and requires fewer tokens than a text-only prompt. - Edits are staged without consuming credits. - Credits are used only when the user applies the changes. - The workflow keeps design experimentation, review, prompting, and code updates in one continuous process. Figma’s broader goal is to make code editing feel more like visual design. The same properties-and-annotation workflow is planned for code layers on the Figma canvas, further connecting design exploration with production code.

Read original(opens in new tab)

FigmaFigma MakeDesign To CodeCode Connect+2

toss·Jul 30, 2026·4 min readCurated summary

LLMs Are Smart, So Why Don’t They Know How Our Company Works?

LLMs handle public knowledge well but struggle with company-specific questions because relevant evidence is scattered across documents, code, meetings, and chat—and may be outdated or contradictory. The post argues that this is not merely a search problem: organizations need a shared layer for managing trustworthy context. Topic addresses this by extracting source-aware units, linking concepts and relationships, and verifying their freshness, consistency, and evidentiary support. ## Why Search Alone Is Not Enough - Search retrieves relevant text but cannot determine whether it is current, authoritative, or consistent with other sources. - A retry-policy example might contain: - Documentation saying requests fail immediately - A meeting discussion proposing three retries - Code currently implementing two retries - Agents must still determine: - Whether the meeting produced a final decision - Which source is newer - Whether the code reflects an intentional change or an unfinished implementation - Whether different sources describe the same behavior - Topic provides a shared context layer so humans and LLMs use the same sources, relationships, freshness information, and conflict states. ## Six Dimensions of Trust Rather than compressing trust into one score, Topic evaluates six separate dimensions: - **Granularity:** Whether the context is a meaningful, independently manageable unit - **Faithfulness:** Whether the source actually supports the claim - **Staleness:** Whether the evidence remains valid - **Canonicality:** Whether different names refer to the same entity - **Consistency:** Whether sources are compatible - **Coverage:** Whether important evidence or perspectives are missing Different checks use different methods: rules and hashes for deterministic validation, LLMs for semantic interpretation, and humans for ambiguous or high-impact decisions. ## Ingesting Documents, Chat, and Code Topic normalizes information into a common `ContentUnit` containing source type, unit type, original URI, content, hashes, timestamps, and source-specific metadata. It uses different boundaries for each source rather than splitting everything into fixed-size text chunks. ### Structured Document Sections - Markdown documents are divided by heading hierarchy. - Parent headings are preserved to retain context. - Long sections are split only when necessary. - URLs, document paths, and creation or modification times remain attached to the unit. ### Conversation Threads - Entire messenger threads are treated as the semantic unit, not individual messages. - Summaries preserve: - Technical identifiers such as function names and file paths - Questions, alternatives, and final outcomes - Decisions versus unresolved issues - The system avoids inventing consensus and ignores threads containing only casual conversation. ### Code Symbols and Semantic Cards - Parsers extract functions, classes, file paths, line ranges, imports, and other symbols without using an LLM. - Multiple symbols are then grouped into **code semantic cards** describing business behavior. - Cards retain domain terms, code identifiers, source spans, and the relevant commit SHA. - LLM-generated cards are checked against actual files, line ranges, supporting spans, and duplicate-card patterns. - Cards are an intermediate layer for connecting code to business concepts, not a replacement for the code itself. ## Extracting Concepts and Relationships - Topic extracts concept candidates and supporting evidence from each content unit. - It preserves the relationship between every concept and its original evidence. - Similar names are not automatically merged merely because they appear close in meaning. - Concepts can be consolidated into canonical entities only when sufficient evidence exists. ### Human Review for Ambiguous Terminology - Normalization and embeddings can identify obvious duplicates. - Internal abbreviations and aliases may require organizational knowledge. - Topic creates synonym proposals with their supporting context. - Humans approve or reject ambiguous aliases; rejected proposals are remembered to prevent repeated suggestions. ### Typed Document–Code Relationships Topic distinguishes among: - `supported_by`: code behavior supports the document’s claim - `contradicted_by`: code behavior conflicts with the document - `mentions`: both refer to the same area, but support or contradiction is unconfirmed Embedding search first narrows possible matches, after which semantic verification is performed. Low-confidence or failed checks do not create relationships; an absent relationship means “not yet verified,” not necessarily “unrelated.” ## Incremental Verification and Change Detection - Stable identifiers and content hashes allow unchanged units to reuse previous extraction and relationship results. - Deleted sources trigger cleanup of dependent relationships. - Code anchors store the validating commit and span hash. - If an anchor disappears, it is marked orphaned. - If the span remains unchanged, semantic verification can be skipped. - If the span changes, faithfulness must be checked again. - Rule-based checks happen before LLM calls, reducing cost and limiting nondeterministic reasoning to cases that require it. Topic’s practical recommendation is to treat trustworthy internal context as a managed system rather than a search result. Preserve source structure, keep evidence attached to every claim, use automation for deterministic work, and route ambiguous organizational judgments to people.

Read original(opens in new tab)

Large Language ModelsHuman In The LoopSemantic SearchKnowledge Graph+4

toss·Jul 30, 2026·5 min readCurated summary

Building Toss’s Device Farm

Nebula is Toss’s centralized device farm, turning real-device testing into a simple API call instead of a team-specific infrastructure project. It grew from 15 devices and one developer into a 24/7 platform with more than 100 devices, shared across the company. The team replaced Appium with a faster, stateless custom driver and invested heavily in real-time streaming, reliability, security, and compliance. ## From Team-Owned Farms to a Central Platform - Before Nebula, teams managed their own small farms using MacBooks or Mac minis. - Each team repeatedly solved the same problems: - Appium setup and maintenance - Device detection and recovery - OS-version compatibility - USB and hardware failures - Security and compliance - Most teams could manage only five to ten devices, and resources remained isolated. - Nebula centralized device operations so product teams could focus on testing rather than infrastructure. ## One API for Real Devices Nebula’s core goal is to let anyone control a physical device from anywhere through a single API. - Clients reserve a device and invoke actions such as clicks or text input. - Users do not need to know which host owns the device or configure ADB, Xcode, cables, or test servers. - The same API supports frontend tools, SDKs, CLIs, direct API clients, and automated systems. ## Four-Layer Architecture - **Clients:** Web interfaces, SDKs, CLIs, and direct API calls. - **Server:** Orchestrates device discovery, allocation, and test execution. - Kafka distributes execution requests. - Multiple runners consume work horizontally as demand grows. - `occupy`, `assign`, and `release` provide distributed locking so tests cannot interfere with one another. - **Agents:** Run on Android/Linux and iOS/Mac hosts, discover local devices, and forward server requests. - **Devices:** Each device has a controller server and runner that execute actions on the physical phone. ## Why Nebula Replaced Appium ### Faster execution - Nebula’s click and input operations were more than ten times faster than Appium in common cases. - Much of Appium’s latency comes from `waitForIdle`, which waits for the screen to stabilize before acting. - Disabling that wait narrows the difference to roughly two or three times. - Appium prioritizes robustness against changing screens, while Nebula prioritizes immediate interaction for live remote control. ### Stateless operation - Appium requires sessions that can take 15–40 seconds to initialize. - Session startup becomes increasingly fragile and difficult to manage at scale. - Nebula keeps device controllers pre-warmed and accepts stateless HTTP requests, eliminating session setup and reducing failure points. ### Company-specific customization Because Nebula owns its driver specification, it can provide: - A custom IME that preserves Korean and emoji input. - Toss-specific signal triggers. - App Center integration for installing pre-release builds. - Built-in enforcement of internal security policies. The driver uses Android ADB and UiAutomation, and Swift/XCTest on iOS. Its OpenAPI specification generates Go and TypeScript interfaces. ## Real-Time Interaction and Screen Mirroring Nebula needed users to watch and control remote devices simultaneously, not merely replay predefined test steps. ### Android - Instead of using `scrcpy` directly, the team adapted its encoding approach. - Android’s `SurfaceControl` creates a virtual display. - `MediaCodec` encodes the output as H.264. - A broadcaster distributes the stream to multiple browser viewers. ### iOS - iOS screen capture is constrained by USB access and cannot expose the display as freely as Android. - Existing approaches such as QVH and Appium MJPEG did not support simultaneous viewing and interaction. - Nebula developed a capture path inspired by QuickTime’s iOS capture mechanism without exclusively claiming the USB connection. - Both platforms now use H.264 streaming and broadcasting, allowing the entire device farm to be viewed in a browser. ## Security and Compliance - Centralization made it possible to apply consistent security requirements across every device. - The team worked with Toss’s security organization to define mobile-device compliance standards. - Policies are enforced at the platform and driver levels rather than relying on individual developers. - Teams can therefore test on devices that already meet the company’s security requirements. ## Operating Hundreds of Devices Nebula must keep hardware and software running continuously. - **Hardware operations** - USB cables, hubs, and power delivery had to be tested and designed for large-scale use. - Physical failures still require human intervention. - Redundancy is being introduced to reduce service interruptions. - **Software operations** - Controllers and mirroring processes are orchestrated across Mac mini and Linux hosts. - Dead processes are automatically recovered. - Server, agent, controller, and mirroring deployments are performed without interrupting user tests. - Monitoring and observability cover devices, processes, and server performance. ## An Internal Ecosystem Built on the API Nebula has evolved from a device provider into shared testing infrastructure. - Web console for no-code interaction and test-step creation. - SDKs for writing E2E tests. - CLI support for terminals, CI/CD, and local AI agents. - Automated log verification during device interaction. - AI agents that plan and execute tests dynamically. - Direct API access for teams with specialized needs. Reported benefits include faster Appium migration, lower barriers to regression testing, and reducing manual verification from 30–40 minutes to under 10 minutes. Nebula’s main lesson is that a stable, simple API can become the foundation for a much broader testing ecosystem. Centralizing device infrastructure, replacing unsuitable abstractions, and treating real-time operation, compliance, and reliability as first-class requirements enabled Toss to scale physical-device testing across the company.

Read original(opens in new tab)

AndroidiOSApache KafkaOpenapi+4

github·Jul 29, 2026·2 min readCurated summary

Tame Dependabot: Group your updates, slow the cadence, keep security fast

Dependabot can generate unnecessary noise when it opens a separate pull request for every dependency update, especially on active repositories. Using dependency groups, a slower schedule, and coverage for all relevant ecosystems turns that stream into predictable maintenance batches. The recommended approach preserves the speed of security updates while reducing routine review and CI overhead. ## The Problem: Frequent, Un grouped Updates - Microsoft’s GCToolkit had 92 Dependabot commits out of 578—about one in six—with 61 arriving in the previous year. - Its original configuration: - Checked GitHub Actions dependencies daily. - Opened a separate pull request for every dependency. - Limited open Dependabot pull requests to 10. - The pull-request limit capped the visible backlog but did not reduce the underlying noise. ## Grouping Dependencies into Batches - Dependabot’s `groups` configuration combines multiple updates into one pull request. - A wildcard pattern such as `"*"` includes all dependencies in that ecosystem. - Instead of 10 pull requests and 10 CI runs, maintainers receive one reviewable batch. - Larger projects can define separate groups for categories such as testing and production dependencies. - In monorepos, Dependabot can group the same dependency across multiple directories using `directories` and `group-by: dependency-name`. ## Moving from Daily to Monthly Updates - Changing `schedule.interval` from `daily` to `monthly` creates a predictable maintenance cycle. - Combined with grouping, this produces one batch per ecosystem each month rather than a continuous stream. - `weekly` is an alternative for projects needing a faster cadence. - Specific days and times can be configured with `schedule.day` and `schedule.time`. ## Covering All Dependency Ecosystems - The original configuration monitored only GitHub Actions. - The revised configuration also monitors Maven, which is essential for a Java project like GCToolkit. - Each ecosystem receives its own schedule and grouped pull request, keeping Actions and Maven updates separate and manageable. ## Keeping Security Updates Fast - The grouping and scheduling changes primarily affect routine version updates, not Dependabot security fixes. - Maintainers can therefore slow ordinary dependency maintenance without delaying urgent vulnerability patches. A practical configuration is to group all routine updates by ecosystem, run them monthly—or weekly when appropriate—and explicitly configure every package ecosystem used by the repository. This reduces maintenance noise while keeping security response timely.

Read original(opens in new tab)

CI/CDGitHub ActionsDependency ManagementMaven+2

cloudflare·Jul 29, 2026·3 min readCurated summary

Post-quantum authentication to origins is now supported

Cloudflare has added post-quantum authentication to Authenticated Origin Pulls (AOP) and Custom Origin Trust Store (COTS), enabling fully post-quantum-secure mutual TLS between Cloudflare and customer origins. The implementation uses ML-DSA signatures, with ML-DSA-44 recommended for most deployments. This marks the first milestone in Cloudflare’s roadmap toward full post-quantum security by 2029. ## Why Cloudflare-to-Origin Authentication Is Different - A proxied request typically involves: - Visitor to Cloudflare - Cloudflare to the customer’s origin - Post-quantum encryption already protects both connections. - Authentication requirements differ for the origin connection because: - Cloudflare controls the client side and can use connection pooling to amortize signature costs. - Cloudflare and customers already have an account-based trust relationship. - Custom PKIs can be used without relying on public WebPKI constraints such as intermediate certificates and Certificate Transparency. - Cloudflare is pursuing Merkle Tree Certificates for visitor-to-Cloudflare authentication, but ML-DSA can be deployed sooner for origin connections. ## ML-DSA Support - Cloudflare supports all FIPS 204 ML-DSA parameter sets: - ML-DSA-44 - ML-DSA-65 - ML-DSA-87 - ML-DSA-44 is recommended for most applications because it offers the best performance while providing NIST category 2 security strength. ## Custom Origin Trust Store - In Full (strict) SSL mode, Cloudflare validates origin certificates against trusted public CAs and Cloudflare’s Origin CA. - COTS lets customers replace that default trust store with a set of customer-controlled CAs. - Customers can now upload ML-DSA CAs. - Cloudflare will trust origin certificates that chain to those ML-DSA CAs. - COTS requires Advanced Certificate Manager. ## Authenticated Origin Pulls - AOP enables mutual TLS, allowing origins to require requests to come from Cloudflare. - It is available on all Cloudflare plan levels. - Per-zone and per-hostname AOP configurations now support ML-DSA certificates and private keys. - Private keys must be uploaded in FIPS 204 seed format. - The global AOP configuration does not yet support this capability and will require additional work. ## Preventing Downgrade Attacks - Simply supporting post-quantum algorithms is not enough if classical authentication methods remain trusted. - An attacker with the ability to forge classical credentials could force a connection to downgrade to a quantum-vulnerable mechanism. - Origins must therefore remove trust in classical authentication mechanisms where appropriate. - Cloudflare’s AOP and COTS configuration guidance explains how to prevent these downgrades. ## Configuration Requirements - Certificate generation requires OpenSSL 3.5.0 or later. - ML-DSA private keys must use the FIPS 204 seed-only encoding. - Customers configure: - An ML-DSA CA and origin certificate chain for COTS - An ML-DSA client certificate and private key for AOP - Configuration can be performed through the Cloudflare API, with dashboard instructions available in the developer documentation. Cloudflare customers needing post-quantum protection for origin connections should combine ML-DSA-based COTS and AOP, explicitly remove trust in classical alternatives, and use ML-DSA-44 unless their security requirements justify a larger parameter set.

Read original(opens in new tab)

CloudflarePost Quantum CryptographyMl DsaOpenssl+4

discord·Jul 29, 2026·1 min readCurated summary

Introducing Profile Frames: Decorative Borders to Make Your Discord Profile Museum-Worthy

Discord has introduced Profile Frames, decorative borders that surround users’ profiles and add another layer of personalization. Frames are available for purchase in the Shop alongside other profile cosmetics, can be added to a Wishlist, and can be changed whenever desired. Nitro members receive discounts and can assign different Frames to individual servers. ## Profile Frames in the Discord Shop - Frames are now sold through Discord’s Shop on desktop and mobile. - They join existing customization items such as: - Avatar Decorations - Nameplates - Profile Effects - Display Name Styles - Color gradients - Purchased Frames remain available for users to equip or remove at any time. - Users can add desired Frames to their Wishlist for potential gifts. ## Nitro Benefits - Nitro subscribers receive discounts on Profile Frames. - Nitro users who own multiple Frames can assign a unique Frame to each server. ## Ongoing Customization - Discord positions Frames as a finishing touch that complements other profile customization options. - New Frames will be released regularly, giving users more designs to choose from. Users interested in expanding their Discord profile’s visual style can browse the Shop and combine Frames with other decorations for a more personalized look.

Read original(opens in new tab)

DiscordNitroProfile CustomizationAvatar Decorations+2

gitlab·Jul 29, 2026·3 min readCurated summary

GitLab Patch Release: 19.2.1, 19.1.3, 19.0.5 | GitLab Docs

GitLab released patch versions 19.2.1, 19.1.3, and 19.0.5 on July 29, 2026, addressing important security and bug fixes in CE and EE. Self-managed installations should upgrade immediately; GitLab.com is already patched, and GitLab Dedicated customers need no action. The release fixes vulnerabilities ranging from unauthorized data access and configuration changes to denial of service and AI-related security issues. ## Release Scope and Upgrade Guidance - Applies to GitLab Community Edition and Enterprise Edition. - Affected self-managed installations should upgrade to: - 19.2.1 - 19.1.3 - 19.0.5 - GitLab issues security patches through scheduled releases twice monthly or through urgent ad-hoc releases. - Vulnerability details are generally made public 90 days after the release containing the fix. ## High-Severity Access and Configuration Vulnerabilities - **CVE-2026-6267 — Workhorse information exposure (CVSS 8.5)** - An authenticated Developer could access unauthorized information because of insufficient access controls in internal request handling. - Affected CE/EE versions extend back to 10.1.0. - **CVE-2026-12436 — Pipeline Schedule API mass assignment (CVSS 8.4)** - An authenticated user could modify another user’s CI/CD configuration through improperly validated pipeline schedule attributes. - Affects versions beginning with GitLab 18.0. - **CVE-2026-13113 — Merge request approval race condition (CVSS 6.5)** - In GitLab EE, an authenticated user could merge code into a protected branch without the required approvals. - The issue resulted from a race condition in approval rule processing. - **CVE-2026-14341 — Project import authorization flaw (CVSS 4.9)** - A Maintainer could modify protected branch configuration through a projects API endpoint. - The vulnerability affected CE and EE. ## Availability, Import, and Credential Protection Fixes - **CVE-2026-15975 — Merge request discussion denial of service (CVSS 7.5)** - An unauthenticated attacker could exhaust resources and cause a denial of service. - The issue involved insufficient throttling when processing discussions. - **CVE-2026-6336 — Project import status access control (CVSS 5.3)** - An unauthorized user could view project import source information because of a missing authorization check. - **CVE-2026-16553 — Virtual Registry credential exposure (CVSS 5.4)** - Improper upstream request handling could disclose sensitive information to an unintended host. - This issue affects GitLab EE virtual registries. ## Web and AI-Assisted Feature Fixes - **CVE-2026-3093 — Cross-site scripting in paginated views (CVSS 4.7)** - A crafted URL could execute attacker-controlled JavaScript in another user’s browser. - The root cause was inadequate sanitization of user-controlled input. - **CVE-2026-15077 — Prompt injection in Duo Code Review (CVSS 4.3)** - Untrusted content processed by AI-assisted code review could allow access to information from unauthorized projects. - This affects GitLab EE versions 19.1 and 19.2 before the patched releases. - **CVE-2026-15831 — Duo Workflows token generation flaw (CVSS 4.3)** - An authenticated user could bypass administrator-configured tool governance policies through improper authorization during token generation. - The issue affects GitLab EE. ## Recommended Action Administrators should upgrade affected self-managed GitLab installations to the latest supported patch release immediately, regardless of deployment method, including Omnibus, source installations, and Helm charts. Regularly applying the newest patch release is GitLab’s recommended security practice.

Read original(opens in new tab)

CI/CDGitlabApi SecurityPrompt Injection+3

gitlab·Jul 29, 2026·2 min readCurated summary

Why GitLab signed the Open Weights and American AI Leadership letter

GitLab signed the Open Weights and American AI Leadership letter to support an open, competitive AI ecosystem. The company argues that open-weight models improve innovation, customer control, security, and flexibility while reducing dependence on a single cloud or model provider. This aligns with GitLab’s goal of enabling agentic software engineering through cloud-neutral and AI-model-neutral tooling. ## Customer Choice and Model Flexibility - Organizations increasingly need governed access to both proprietary foundation models and open-weight models. - Foundation models may offer stronger general-purpose capabilities, while open-weight models can provide: - Greater cost control - Flexible deployment options - Data-residency advantages - Operation in air-gapped environments - GitLab supports combining different models across development workflows rather than locking teams into one provider. ## Security, Privacy, and Independence - Companies must protect source code, intellectual property, and strategic data from security, privacy, and competitive risks. - GitLab argues that model and cloud neutrality are essential to avoiding dependence on a single vendor. - Open weights allow teams to decide where models run while retaining control over their code and data. ## GitLab’s Policy Position - GitLab supports policies that allow open-weight models to be developed, distributed, and used. - It favors focused, risk-based safeguards aimed at genuine misuse rather than broad restrictions. - A mix of open and proprietary providers can compete on capability, security, and value, benefiting innovation and customer choice. GitLab’s recommendation is to preserve an open AI model market with targeted safeguards. This gives organizations the flexibility to choose models based on capability, cost, privacy, deployment requirements, and security.

Read original(opens in new tab)

AIDevSecOpsFoundation ModelsData Privacy+3

figma·Jul 29, 2026·2 min readCurated summary

How We Secure Figma’s Internal Systems With Agents | Figma Blog

Figma built an AI-powered security agent to reduce the manual work involved in investigating SIEM alerts. What began as a retrieval system for finding similar past incidents evolved into an agent that investigates alerts, queries security data, writes fixes, opens pull requests, and retains useful knowledge. The system reportedly reduced alert time-to-resolution by 71% and changed how security engineers handle on-call work. ## The Challenge of Internal Security Operations - Figma’s infrastructure, SaaS tools, identity systems, and employee devices change constantly. - Panther, Figma’s SIEM, monitors these systems and sends alerts to Slack while creating Asana tickets. - On-call engineers previously spent significant time gathering context: - Comparing alerts with incidents from the previous week - Checking whether an existing pull request addressed the issue - Searching Slack discussions for related investigations - Determining whether an alert was new, recurring, or already understood - Existing agent work focused on securing Figma’s codebase, but the team needed a broader system for the many issues detected by its SIEM. ## The RAG Layer: Giving Alerts Historical Context - Figma first created a retrieval-augmented generation system using: - AWS Bedrock Knowledge Bases - Amazon Kendra - Lambda handlers connected to Panther - Each Panther alert is converted into a standardized searchable document. - The system extracts structured information such as: - IP addresses - Usernames and actors - AWS account IDs from ARNs - Alert type, severity, tags, status, and timestamps - Similar alerts are retrieved semantically using the alert title, typically containing the detection name and actor username. - Searches prioritize: - Recent alerts, since investigation procedures evolve - Alerts containing actual investigation context - Comments from engineers rather than merely closed alerts ## Turning Engineer Comments into Institutional Memory - When an on-call engineer comments in a Slack alert thread, Figma captures that text and attaches it to the original alert. - Asana tickets follow a similar process. - The updated alert document is reindexed with: - The accumulated investigation comments - A `has_investigation_context` flag - Future alerts can retrieve these previous explanations and recommendations. - Engineers do not need to adopt a separate annotation workflow; their normal Slack and Asana comments become reusable knowledge. - Each useful investigation effectively makes subsequent similar alerts faster and less expensive to triage. Figma’s approach demonstrates how security agents can build on existing workflows rather than requiring entirely new ones. Starting with searchable historical context allowed the team to progressively develop a broader agentic system while turning everyday investigative work into persistent operational knowledge.

Read original(opens in new tab)

AI AgentsTypeScriptRAGAws Lambda+4

github·Jul 28, 2026·3 min readCurated summary

Disrupting supply chain attacks on npm and GitHub Actions

GitHub describes a layered approach to disrupting npm and GitHub Actions supply-chain attacks, which typically compromise one project, steal credentials, and spread malware across many others. Rather than relying on one defensive feature, GitHub is targeting several links in the attack chain—from initial compromise through credential theft and malicious publishing. Recent protections add account recovery delays, safer workflow defaults, credentialless publishing, network monitoring, and stronger publishing approvals. ## Anatomy of Supply-Chain Attacks - Attacks commonly: - Compromise a maintainer account or CI/CD workflow. - Escalate access by stealing credentials. - Use those credentials to infect additional packages and projects. - GitHub says effective defense requires multiple mitigations that disrupt the most damaging steps in the chain. ## Preventing Initial Compromise - **High-impact npm account protection** - Accounts enter read-only mode for 72 hours after an email change or use of a 2FA recovery code. - The delay gives maintainers time to detect phishing-related account takeover and recover access. - **Safer `pull_request_target` checkout defaults** - `actions/checkout` now prevents commonly exploited workflows from checking out untrusted code from forks by default. - This reduces exposure to “pwn requests,” where fork-provided code executes with workflow privileges. - **Workflow execution policies** - Enterprise, organization, and repository administrators can control who may trigger workflows and which trigger types are permitted. - These policies provide configurable least-privilege controls for Actions. - **Read-only Actions cache for untrusted triggers** - Less-trusted workflows can no longer modify caches shared with more privileged workflows. - This blocks cache poisoning attacks intended to escalate access to release and publishing credentials. ## Limiting Credential Exfiltration - **npm trusted publishing for CircleCI** - CircleCI can now use trusted publishing, allowing packages to be published without long-lived credentials stored in CI/CD. - Removing persistent tokens reduces the value of compromised workflows. - **Actions network firewall** - The technical preview logs outbound network traffic from workflow runs. - This can expose suspicious downloads or credential exfiltration to unfamiliar domains. - Planned restrictions will allow organizations to block unauthorized network destinations. ## Slowing Attack Propagation - **Staged npm publishing** - Publishing credentials alone are insufficient to immediately release a new package version. - Packages remain staged until an additional approval and 2FA authentication occur through npm’s CLI or website. - This opt-in control separates automated publishing credentials from final authorization, giving maintainers a chance to detect malicious releases. Together, these measures reduce the opportunities for attackers to enter projects, obtain powerful credentials, and rapidly publish malware. GitHub’s recommendation is effectively to combine safer workflow configuration, short-lived or trusted authentication, network visibility, and additional publishing approval rather than depending on any single control.

Read original(opens in new tab)

CI/CDGitHub ActionsNpmSupply Chain Security+3

cloudflare·Jul 28, 2026·3 min readCurated summary

Natural disasters and government interference: examining Q2 2026’s major Internet disruption event

Cloudflare’s Q2 2026 outage review shows how dependent Internet connectivity remains on physical infrastructure, government policy, and complex technical systems. Disruptions ranged from typhoons, earthquakes, and power failures to shutdowns, war-related data-center damage, DNSSEC errors, and submarine cable cuts. Despite these failures, regional networks generally remained resilient, with Cloudflare Radar revealing both the scale and distinctive patterns of each outage. ### Natural Disasters and Power Failures - Super Typhoon Sinlaku passed north of Guam in April, causing power and water disruptions. - Internet traffic fell as much as 80% below expected levels on April 13–14. - Two earthquakes in northern Venezuela on June 24 produced an immediate drop in HTTP traffic. - The decline was especially visible at Fibex Telecom, CANTV, and VNET. - A nationwide power outage in Tanzania on June 27 caused Internet traffic to collapse for at least five hours. - These events demonstrate that storms, earthquakes, and electricity failures can produce similar connectivity impacts, reinforcing the need for redundancy in power, routing, and physical network paths. ### Government Shutdowns and Geopolitical Conflict - Iran began restoring Internet access on May 26 after an 88-day near-total blackout. - Traffic initially recovered to about 40% of pre-outage levels, later reaching 90% before settling near 59%. - Connectivity returned closer to the country’s recent pre-shutdown baseline, rather than fully normal levels. - AWS’s `me-central-1` region in the UAE continued to experience reduced traffic after drone strikes damaged infrastructure in the UAE and Bahrain. - The disruption affected applications hosted in the region even when those applications themselves remained operational. - Iraq imposed three exam-related shutdowns, while Sudan imposed ten. - Sudan’s outages generally lasted about 3.5 hours. - Iraq’s shutdowns lasted roughly 90 minutes. - These incidents illustrate how governments can deliberately switch off, throttle, or selectively restore national connectivity. ### DNSSEC Failure in Germany - On May 5, a DNSSEC key rollover at DENIC caused invalid signatures for Germany’s `.de` domain. - DNS resolvers validating DNSSEC rejected `.de` responses and returned `SERVFAIL`, making affected websites unreachable worldwide until service was restored at 23:15 UTC on May 5. - Cloudflare observed an increase in `.de` queries because failed responses could not be effectively cached, forcing repeated lookups and retries. - Users experienced the incident as widespread website unavailability rather than as an obvious cryptographic or DNS problem. ### Cable and Infrastructure Vulnerabilities - A submarine cable cut in Saint Lucia further demonstrated how regional connectivity can depend on a small number of physical links. - Together with the German DNSSEC failure, the incident shows that routine infrastructure maintenance and single physical-path failures can have effects far beyond the location where the fault occurs. Cloudflare’s findings underline the importance of network redundancy, careful operational procedures, and continuous monitoring. Internet outages may have very different causes, but their effects on users can look remarkably similar: sudden loss of access to communication, applications, and essential information.

Read original(opens in new tab)

AWSCloudflare RadarDnssecInternet Infrastructure+3

github·Jul 27, 2026·3 min readCurated summary

The harness is all you need (mostly)

The post argues that effective AI-assisted development depends less on discovering elaborate prompts, tools, or configurations and more on learning the underlying agent harness. A simple workflow—choose a consistent tool, grant agents autonomy in a safe environment, and prototype before implementing—can produce major productivity gains. The author concludes that the harness is “all you need,” with only a few practical habits required. ## Choose a Tool and Learn the Harness - GitHub Copilot is available through the CLI, Copilot app, VS Code, Visual Studio, JetBrains, and other environments. - Although interfaces differ, these tools increasingly share the same underlying harness and workflow. - Beginners may benefit from starting with the CLI because its text-based interface exposes the agent’s behavior directly. - Learning the harness once makes it easier to work across different Copilot environments. ## Enable Autonomous Agent Operation Safely - “YOLO mode,” also called `/allow-all` or “Allow All,” lets the agent execute commands without requesting approval each time. - Repeated approval prompts slow development and encourage users to approve actions without reading them. - Agents should be given autonomy, but unrestricted execution is risky on local or production systems. - Use isolated environments such as GitHub Codespaces or development containers, especially when working with private organizational data. ## Prototype Before Implementing - AI makes it inexpensive to explore multiple designs before committing to an implementation. - For a date picker, the author recommends generating many HTML mockups at once—for example, 20 variations—to compare layouts and interaction models. - Reviewing prototypes can reveal ideas that are difficult to anticipate from text alone, such as navigating from year to month to day. - Visual and tangible representations help people understand complex concepts faster than dense descriptions. ## Use Visual Models for Non-Visual Work - Prototyping is also useful for backend tasks and API design. - For an analytics-download endpoint, the author suggests asking the agent to create several visual implementation options. - Mermaid diagrams can map out alternatives directly in Markdown. - Exploring these options early exposes requirements and trade-offs, reducing rework and wasted tokens. ## Keep the Model and Reasoning Settings Consistent - The author recommends using a medium-sized model with medium reasoning for most tasks. - Keep the same model and reasoning level throughout a feature, bug fix, or enhancement. - Consistency allows previous conversations to remain cached, reducing token costs on later requests. The practical recommendation is to focus less on collecting AI tools and clever prompts and more on mastering the agent workflow: give it controlled autonomy, prototype alternatives early, and maintain a consistent working context.

Read original(opens in new tab)

AI AgentsGithub CopilotGithub CodespacesDevelopment Containers+2