标签：#chrome

In my last post I said that for normal HTML pages, element-based automation ( find / read_page ) beats coordinates every time. This post is about the apps where that advice is useless. Flutter Web apps. Canvas-rendered editors. Every button and panel you can see on screen doesn't exist in the DOM — it's all pixels painted onto a single canvas. find returns nothing. read_page 's accessibility tree is effectively empty. I got Claude to drive the Rive editor (an animation tool built with Flutter) all the way through selecting assets and exporting them. Here's the procedure that survived contact with reality. Step zero: confirm you're actually in this situation Coordinate automation is fragile, so you should only accept it after ruling out the alternative. The test is quick: run read_page . If the visible UI has almost no corresponding nodes, you're looking at a canvas-rendered app, and coordinates are the only interface you have. The four rules 1. Wait for the window size to settle before anything else Same failure mode as my previous post: right after load, the viewport hasn't reached its final width (I measured 1664→1920 over 2–3 seconds), and clicks based on an early screenshot land to the right of the target. Read innerWidth via javascript_tool twice; only proceed when two consecutive reads match. But matching innerWidth alone isn't enough — also confirm devicePixelRatio hasn't changed since the screenshot you're about to act on (a follow-up to my previous post surfaced this: when DPI or scaling changes, the whole coordinate space rescales the same way, but the new values stabilize immediately, so an innerWidth -only check can't catch it). Canvas apps deserve extra paranoia here, because there is no element-based fallback when a click misses. 2. Read text by zooming, not by extracting Text painted on canvas can't be pulled out of the DOM. To read a menu item or panel label, zoom into that region and read the enlarged screenshot as an image. Full-page screenshots ma

Introduction Chrome's Built-In AI APIs allow applications to perform selected AI workloads directly within the browser. Unlike traditional AI integrations, developers do not need to deploy or operate model infrastructure. This guide walks through the major APIs currently available. Getting Started: API Availability and Chrome Flags Chrome's Built-In AI APIs are at different stages of maturity. Some APIs are available in stable Chrome, while others remain experimental. The required setup therefore depends on the API you want to test. Available in Chrome Stable The following APIs are available in stable Chrome on supported desktop devices: Language Detector API Translator API Summarizer API These APIs do not require experimental flags for normal use in supported Chrome versions. The Prompt API has different availability requirements depending on whether it is used from a web page or a Chrome Extension. Check the current Chrome documentation for the environment you are targeting. Experimental APIs The Writer, Rewriter, and Proofreader APIs remain experimental and may require developer trials, origin trials, or Chrome flags for local development. Because these APIs are evolving, refer to the official Chrome documentation for the current setup requirements rather than relying on a static list of flags. Engineering recommendation: Use feature detection and availability() checks at runtime rather than relying on Chrome version numbers or assuming that a particular flag is enabled. Language Detector API Use cases: Dynamic localization Query routing Analytics Content classification Example const detector = await LanguageDetector . create (); const result = await detector . detect ( " Bonjour tout le monde " ); console . log ( result ); Architecture Notes Low latency Task-specific model Suitable for client-side execution Complete runnable example: Language Detector API on GitHub Gist Translator API Use cases: Localization Offline translation International applications Example

Tra performance, piattaforma e toolchain: i temi che contano davvero per chi costruisce frontend oggi. Il frontend nel 2026 è diventato una disciplina sempre più “di prodotto”: non basta far funzionare l’interfaccia, serve che sia veloce, stabile, accessibile e misurabile in produzione. E quando l’ecosistema Chrome parla di “connessione” tra developer e piattaforma, il messaggio utile per chi lavora sul web è semplice: capire dove investire tempo per ottenere impatto reale sugli utenti . Di seguito, una lettura pratica dei temi che continuano a emergere come prioritari per chi costruisce applicazioni e siti moderni. 1) Performance: meno benchmark, più realtà La performance non è più un esercizio di ottimizzazione a fine progetto. È un requisito continuo che va gestito con strumenti, metriche e processi. Cosa significa “misurabile” oggi Metriche di campo (real user monitoring) : le prestazioni che contano sono quelle che arrivano dai dispositivi reali, su reti reali. Metriche di laboratorio : restano utili per regressioni e CI, ma vanno interpretate come “segnali” e non come verità assolute. Implicazione pratica Imposta una pipeline dove: le metriche sintetiche bloccano regressioni evidenti (build/PR), le metriche reali guidano le priorità (release e backlog). 2) DevTools: dal debug al controllo qualità Gli strumenti di sviluppo non servono più solo a “trovare il bug”, ma a ridurre il rischio : regressioni di layout, memory leak, risorse inutili, dipendenze pesanti. Abitudini che fanno differenza Profilare prima di ottimizzare: CPU, rete e rendering hanno colli di bottiglia diversi. Isolare i cambiamenti: una variazione di bundling o di immagini può ribaltare il profilo prestazionale più di una micro-ottimizzazione in JS. 3) La piattaforma web continua a crescere (e chiede scelte più consapevoli) La Web Platform oggi offre API potenti, ma la parte difficile non è “usarle”: è scegliere quando usarle. Un criterio utile Se una feature riduce complessità (meno librerie,

I missed the tiny "x" on a browser tab again today. Meant to close it, switched to it instead. Aiming a one-pixel pointer at an eleven-pixel checkbox is basically microsurgery, and somewhere along the way we all just accepted that. Here's the strange part: HCI research solved this twenty years ago. It just never shipped. The paper In 2005, Grossman and Balakrishnan published The Bubble Cursor at CHI. The whole idea fits in one sentence: Make the cursor's hit area a dynamic circle that always contains exactly one target. That turns out to be the same thing as always selecting the target nearest to the pointer. Picture the screen divided into Voronoi cells, one per clickable thing, and the cursor picking the owner of whatever cell it's currently in. The clever part is what it refuses to do. Naive "gravity" cursors snap to every link on the way to the one you actually want, and they get stuck. The bubble cursor grabs exactly one target by definition. The moment a second target becomes nearer, it switches. So it stays calm on link-dense pages, and the paper showed significant speedups in controlled experiments. Twenty years later our cursors are still naked, so I built it as a Chrome extension. It's called MagPoint . The core is about 30 lines A content script collects clickable elements ( a[href] , button , input , ARIA roles and so on) and, every frame, picks the one with the smallest point-to-rectangle distance: function pointToRect ( x : number , y : number , r : DOMRect ): number { const dx = Math . max ( r . left - x , 0 , x - r . right ); const dy = Math . max ( r . top - y , 0 , y - r . bottom ); return Math . hypot ( dx , dy ); } Clicks that land in the empty space near a captured element get re-routed to it. Past a max radius of 120px the magnet lets go, and empty-space clicks behave like the normal web. It also stands down while you type or select text, because getting yanked toward a link mid-sentence would be infuriating. The rule that kept me sane: the vis

TL;DR: Most extensions block Google's AI Overviews by hiding the panel with a content script after it renders — fragile, flickery, and always a step behind Google's markup changes. A better approach: force udm=14 at the network layer with declarativeNetRequest , so the AI Overview never loads. The content script becomes a backstop, not the main mechanism. One Chrome API mystery — AI Mode being invisible to four different extension APIs — shows why the DOM was never the right layer. Google puts an AI Overview at the top of most search results now, and a lot of people would rather it didn't. So there's a whole shelf of Chrome extensions that remove it. Almost all of them work the same way, and I think that way is a mistake. The obvious approach, and why it's a trap The default move is DOM-hiding: inject a content script, wait for the AI Overview panel to render, find it by class name or attribute, and set display: none . It's the first thing anyone reaches for, and it works — until it doesn't. The problems are all baked into the approach. You're reacting after the render, so there's a flash of AI content before your script catches it. You're matching against Google's markup, which is obfuscated and reshuffled constantly, so every layout change is a silent breakage. And you're paying for DOM churn on a page you don't control. You end up in a permanent game of catch-up against a page that changes whenever Google feels like it. The deeper issue is that you're operating one layer too high. The panel is a symptom . By the time it's in the DOM, the work is already done — the server decided to send it, the page rendered it, and now you're scrambling to un-render it. If you can move the decision earlier, none of that scramble has to happen. The thesis: prevent it at the network layer Google Search takes a parameter, udm , that selects which result vertical you get. udm=14 is the plain "Web" results view — the classic list of links, no AI Overview, no AI Mode. It's Google's ow

Chrome has had scroll restoration support since 2015. You can even control it: history.scrollRestoration = 'manual' . But if you've ever tried to reliably restore a user's position on a React or Next.js app, you know it doesn't work the way you'd expect. Here's what breaks, why it breaks, and how a browser extension can sidestep the entire problem. What the Browser Actually Does The default behavior is history.scrollRestoration = 'auto' . When you navigate back to a page, the browser tries to scroll to where you were. This works fine for static pages. It falls apart for: SPAs where content is injected into the DOM after navigation Infinite scroll pages where the content at a given Y position changes depending on what was previously loaded Lazy-loaded images that push content down after the scroll restore fires The fundamental problem: the browser fires scroll restoration when the page HTML is parsed, not when the page content is fully rendered. A React app that loads a skeleton → fetches data → renders actual content will restore scroll into a partially-rendered DOM. The history.scrollRestoration = 'manual' Trap If you set manual , you own scroll restoration completely. Most Next.js apps do this. The typical approach: // Save position before navigation router . beforeEach (( to , from ) => { savedPositions [ from . path ] = window . scrollY ; }); // Restore after navigation router . afterEach (( to ) => { const position = savedPositions [ to . path ]; if ( position !== undefined ) { nextTick (() => window . scrollTo ( 0 , position )); } }); The nextTick is the problem. It fires after the Vue/React render cycle, but before async data fetching completes. The page renders empty containers, scroll restores to Y=800, then data loads and pushes everything down. User ends up at Y=800 in a now-different page position. The correct fix is to wait until the content that was at Y=800 actually exists. There's no clean hook for this — you'd need to observe the DOM until the expec

Debugging authentication in web apps is painful. You need to test the same flow as five different user types — new visitor, returning user, admin, expired session, logged-out — and the easiest way is to constantly create new accounts or clear all your cookies and start over. There's a faster way. These five techniques use direct cookie manipulation to simulate any auth state without touching your database or creating dummy accounts. I use CookieJar for most of this — a free Chrome extension built natively on MV3 that gives you a proper UI for cookie editing. But I'll show you the underlying Chrome DevTools method too, so you understand what's actually happening. 1. Simulate a Logged-Out State Without Clearing Everything The naive approach: clear all cookies and reload. The problem: you just nuked your dev server session token, your local storage flags, your Stripe test mode cookie, and everything else you carefully set up. The targeted approach : identify and delete only the session/auth cookie. Most session cookies are named session , sid , auth_token , _session_id , or something close. In DevTools: Application → Cookies → [your domain] → find the session cookie → right-click → Delete With CookieJar: open the extension, search session , click the trash icon next to just that cookie. Your dev environment stays intact. The user state resets to logged-out. 2. Test the "Returning User" vs "New User" Path Without a Second Account Session cookies tell the server you're authenticated. But many apps use separate cookies to track whether a user has seen the onboarding flow, completed setup, or visited before. Look for cookies like onboarding_complete , setup_done , first_visit , or custom flags in your app code. To test the new user experience: Export your current cookies (CookieJar → Export → JSON format, or copy from DevTools) Delete the specific onboarding/first-visit flag cookie Reload and test the new user path Re-import or re-set the cookie to restore your state This

I built a Chrome extension called Margin — a news reader that lives in the browser's side panel and shows one bite-sized story at a time, instead of an infinite-scroll feed. This is a build log: the decisions, the constraints that pushed back, and a couple of things I had to solve in slightly unusual ways. Why the side panel Chrome shipped chrome.sidePanel in MV3 a while back and most uses I saw were utility tools — note-taking, translation helpers. Nobody was using it for content consumption. News felt like a good fit: a side panel that stays open next to whatever you're working on, where you tap through headlines in a couple of minutes without leaving the page. The reading model is intentionally narrow: one card, one headline, one short summary, tap to read the full article at the source . No infinite scroll, no algorithmic feed. If you've used InShorts, the shape will be familiar. The stack Preact + Vite + @crxjs/vite-plugin . Preact because the side panel is a small UI surface and I didn't want React's weight for what's essentially a card stack and a settings screen. @crxjs/vite-plugin handles the MV3-specific build wiring (manifest generation, service worker loader, HMR for the extension context) that would otherwise be a lot of manual plumbing. The constraint that shaped onboarding chrome.sidePanel.open() requires a user gesture . You cannot call it from a background service worker on install — Chrome will throw. That one constraint shaped the whole first-run experience. My first instinct was "just auto-open the panel on install so people see it immediately." Doesn't work. The fix ended up being two-pronged: On chrome.runtime.onInstalled with reason === 'install' , open a real browser tab with a short walkthrough (find the icon → pin it → open the panel). The button on that page calls sidePanel.open() — valid, because the click is the gesture. The first time the panel itself is opened, show an in-panel welcome screen before onboarding, nudging the user to pin

Debugging authentication in web apps is painful. You need to test the same flow as five different user types — new visitor, returning user, admin, expired session, logged-out — and the easiest way is to constantly create new accounts or clear all your cookies and start over. There's a faster way. These five techniques use direct cookie manipulation to simulate any auth state without touching your database or creating dummy accounts. I use CookieJar for most of this — a free Chrome extension built natively on MV3 that gives you a proper UI for cookie editing. But I'll show you the underlying Chrome DevTools method too, so you understand what's actually happening. 1. Simulate a Logged-Out State Without Clearing Everything The naive approach: clear all cookies and reload. The problem: you just nuked your dev server session token, your local storage flags, your Stripe test mode cookie, and everything else you carefully set up. The targeted approach : identify and delete only the session/auth cookie. Most session cookies are named session , sid , auth_token , _session_id , or something close. In DevTools: Application → Cookies → [your domain] → find the session cookie → right-click → Delete With CookieJar: open the extension, search session , click the trash icon next to just that cookie. Your dev environment stays intact. The user state resets to logged-out. 2. Test the "Returning User" vs "New User" Path Without a Second Account Session cookies tell the server you're authenticated. But many apps use separate cookies to track whether a user has seen the onboarding flow, completed setup, or visited before. Look for cookies like onboarding_complete , setup_done , first_visit , or custom flags in your app code. To test the new user experience: Export your current cookies (CookieJar → Export → JSON format, or copy from DevTools) Delete the specific onboarding/first-visit flag cookie Reload and test the new user path Re-import or re-set the cookie to restore your state This

There is a class of feature that used to be impossible to ship for free: anything that needed a language model. You wired up an API key, you ate the per-token bill, and every prompt your users typed went off to someone else's server. For a small public tool, that math usually killed the idea before it started. That changed. Recent versions of Chrome ship a language model, Gemini Nano, and expose it to any web page through the Prompt API . The model runs on the user's own machine. No API key. No inference bill. No data leaving the browser. We put this into a real, live tool, a free Mermaid diagram editor where you describe a diagram in plain English and the browser writes the Mermaid code for you. This post is the developer's version of that story: how the API actually works, the code that makes a small on-device model trustworthy, and an honest accounting of what you gain and what you give up. What "AI in the browser" means in 2026 The important word is built-in . This is not WebGPU plus a 4 GB model you download and run yourself. The model ships with Chrome, and you talk to it through a small standard-track JavaScript API. As of Chrome 148, the Prompt API is stable for web pages (it had been available to extensions since Chrome 138). It is the general-purpose member of a growing family of built-in APIs: Prompt API ( LanguageModel ): general natural-language prompting, now multimodal (text, plus image and audio input). Summarizer, Writer, Rewriter, Proofreader : task-specific, text-to-text. Translator and Language Detector : backed by expert models, desktop only. The Prompt API is the one you reach for when you need something the task APIs don't cover, like "turn this description into Mermaid source." So that is the one this post focuses on. The 15-line version Here is the whole happy path. Check availability, create a session, prompt it. // Feature-detect first. Old browsers won't have this at all. if ( ' LanguageModel ' in self ) { const status = await LanguageMod

Debugging authentication in web apps is painful. You need to test the same flow as five different user types — new visitor, returning user, admin, expired session, logged-out — and the easiest way is to constantly create new accounts or clear all your cookies and start over. There's a faster way. These five techniques use direct cookie manipulation to simulate any auth state without touching your database or creating dummy accounts. I use CookieJar for most of this — a free Chrome extension built natively on MV3 that gives you a proper UI for cookie editing. But I'll show you the underlying Chrome DevTools method too, so you understand what's actually happening. 1. Simulate a Logged-Out State Without Clearing Everything The naive approach: clear all cookies and reload. The problem: you just nuked your dev server session token, your local storage flags, your Stripe test mode cookie, and everything else you carefully set up. The targeted approach : identify and delete only the session/auth cookie. Most session cookies are named session , sid , auth_token , _session_id , or something close. In DevTools: Application → Cookies → [your domain] → find the session cookie → right-click → Delete With CookieJar: open the extension, search session , click the trash icon next to just that cookie. Your dev environment stays intact. The user state resets to logged-out. 2. Test the "Returning User" vs "New User" Path Without a Second Account Session cookies tell the server you're authenticated. But many apps use separate cookies to track whether a user has seen the onboarding flow, completed setup, or visited before. Look for cookies like onboarding_complete , setup_done , first_visit , or custom flags in your app code. To test the new user experience: Export your current cookies (CookieJar → Export → JSON format, or copy from DevTools) Delete the specific onboarding/first-visit flag cookie Reload and test the new user path Re-import or re-set the cookie to restore your state This

Google Chrome version 150 and 151, expected in late June and July, respectively, will cut off support for the last remaining workarounds for running older ad blockers, 9to5Google reports. Google phased out support for ad-blocking extensions built for Manifest V2, like uBlock Origin, in 2024. At that point, most Chrome users either switched to newer […]

I've shipped 4 Chrome extensions and 2 VS Code extensions. The advice that always sounds smart — "find a popular extension the dev abandoned, rebuild it better" — is miserable in practice. You open the Web Store, see 100k users and a 4.4 rating, think you found gold, then burn a weekend reading reviews only to realize half the complaints are unfixable traps (sync died, login broke, backend gone). So I built a small pipeline to do the boring part automatically. The method Scrape public Chrome Web Store metadata — users, rating, last-updated date. Filter: 20k–300k users, 18+ months without an update, rating 3.3–4.4 (good enough to prove demand, bad enough to prove pain). Pull up to 50 recent reviews per candidate via public CWS data. Score each one: score = log10(users)10 + months_stale0.5 + feature_request_count2 - trap_count1.5 The key part is trap_count — I subtract points for complaints about sync/login/server issues, because those are unfixable without inheriting someone else's dead backend. High "demand" with high trap count is a mirage. One example Extension Manager — 100k users, 4.4★, last updated ~25 months ago. Looks healthy until you read the 1–2★ reviews: "The site-specific rules feature simply does not work… the core feature advertised is broken." "It won't save any changes made… extensions are re-enabled automatically." A user even posted an RCE report: the dev parses JSON with a Function(str)() fallback — executing arbitrary code from untrusted input. That's not "build a clone." That's "fix the rules engine, kill the eval, add local backup, ship something 100k people already want." The counterintuitive part The highest-scoring extension in my list (200k users, abandoned ~4 years) is actually the worst business opportunity — it's a simple toggle utility whose users will never pay, and the original asks for camera/mic permissions (adware-grade). Raw download counts would put it at the top of your build list. Revenue potential buries it. That gap between "

The Problem Nobody Talks About Picture this: You're trying to find a place to meet up with friends. Someone suggests a coffee shop. It's 8 minutes from their house. It's 45 minutes from yours. You say yes anyway, because suggesting a different place feels awkward. This happens all the time — with friends, with remote teams, with family scattered across a city. And the worst part? Most "meet in the middle" suggestions aren't actually in the middle. They're just the geographic midpoint, which completely ignores traffic, transit options, and the fact that roads don't go in straight lines. I got frustrated enough to build something about it. Meet Meetle Meetle is a free web app that finds the fairest meeting spot for any group of people — based on real travel times , not just distance. A Chrome Extension is coming soon so you'll have it one click away in your toolbar. You add everyone's starting location, choose how each person is traveling (driving, walking, or transit), hit Find Meeting Point , and Meetle does the math across every person simultaneously. It then surfaces the best nearby cafés, restaurants, parks, gyms, or whatever venue type you're looking for — ranked by actual fairness. No more "it's fine, I don't mind the drive." Now you have data. How It Actually Works Under the hood, Meetle uses three Google Maps APIs working together: Distance Matrix API calculates travel time from every person's location to every candidate venue, simultaneously. This is the core of the fairness scoring — you can't rank venues fairly without knowing everyone's actual travel time to each one. Places API finds candidate venues near the calculated center point. You can filter by type (coffee, food, parks, gyms, etc.), price level, minimum rating, and whether they're open right now. Maps JavaScript API renders everything visually — the map, the travel zones (isochrones), and the markers for each suggested venue. The scoring works two ways and you can toggle between them: Fairness mo

It is one of the most frustrating experiences in online learning: you sit down to focus on a Udemy course, but the video player constantly pauses, freezes, or refuses to load. Meanwhile, YouTube, Netflix, and every other app on your Mac run perfectly fine. Because other platforms work without a hitch, it is easy to assume the issue lies with Udemy's servers. However, the root cause is usually a silent conflict between your browser settings, macOS security features, and Udemy’s strict digital rights management (DRM) protections. If you are stuck on a looping loading wheel, here is exactly why it happens and how to fix it in less than two minutes. Quick-Fix Troubleshooting Checklist Save or screenshot this step-by-step breakdown to instantly diagnose and fix your playback issues: Step 1: Open Chrome in Incognito Mode Open a new Incognito window ( Cmd + Shift + N on Mac). Try playing the video again. If it works: Disable ad blockers. Disable VPN privacy shields or browser extensions one at a time. If it still fails: Continue to Step 2. Step 2: Disable Hardware Acceleration Open Chrome. Go to Settings → System . Turn off Use graphics acceleration when available . Relaunch Chrome. Test the video again. Step 3: Check Mac Security and Display Connections Disconnect any external monitors or docking stations. Close applications that may interfere with video playback: Zoom Discord OBS Studio Screen recording tools Test video playback again. Step 4: Clear Temporary Browser Data Open Chrome. Go to Settings → Privacy and Security → Clear Browsing Data . Select: Cookies and other site data Cached images and files Clear the data. Restart Chrome and try again. Still Not Working? If the issue persists after completing all four steps: Update Chrome to the latest version. Update macOS. The Main Culprit: Hardware Acceleration Conflict The most common reason Udemy videos stutter or freeze on a Mac is a feature called Hardware Acceleration inside Google Chrome. What is Hardware Accelerat

Hey tech family! 👋 If you’ve noticed your favorite Chrome extensions acting a bit differently lately or if you're a developer currently sweating over a massive codebase rewrite you are experiencing the era of Manifest V3 (MV3) . 🤖 Google has officially pushed the web ecosystem forward by deprecating Manifest V2, making MV3 the absolute standard for how browser extensions behave. But why is this happening, what actually changed, and why is the internet so divided over it? Let’s break it all down in plain English! 👇 🧐 What Exactly is Manifest V3? Think of a "Manifest" as the blueprint file ( manifest.json ) that tells the browser exactly what an extension is, what files it uses, and what permissions it needs to run. Manifest V3 is Google's major architectural overhaul of this system. Its core mission sounds great on paper: improve user privacy, beef up security, and boost browser performance . However, achieving those goals meant rewriting the core rules of how extensions interact with your browser. 🛠️ The Biggest Changes & New Features MV3 isn't just a small patch; it fundamentally alters the underlying extension engine. Here are the headline shifts: Goodbye Background Pages, Hello Service Workers! 💤 In MV2, extensions used hidden, persistent background pages that ran 24/7, hogging your computer's RAM even when you weren't using them. MV3 replaces these with Service Workers. They are event-driven meaning they wake up, execute a task (like clicking an extension icon), and go right back to sleep. Hello, free RAM! 🐏 The Ad-Blocker Shakeup: webRequest vs. declarativeNetRequest 🛑 This is the most controversial change. In MV2, powerful extensions like uBlock Origin used the webRequest API to intercept, read, and block network requests in real-time using complex code. MV3 replaces the blocking version of this with declarativeNetRequest . Instead of letting the extension intercept the data, the extension must now hand Chrome a pre-defined list of rules, and Chrome does the b

Alternative search engine DuckDuckGo launches 'no AI' web extensions for Chrome and Firefox users.

By Takeshi Yokoyama — Onecarat Labs Hi. I'm Yokoyama, and I build a local-first AI text editor as a side project, along with a few other experimental tools. Working on them, I keep running into the same question about where the web is going. This post is one observation, plus a small experiment I built to test it — including a Chrome extension you can actually try. The short version: I think websites will increasingly be read through AI agents, reshaped per reader, on the fly. And once that happens, there's a clear gap between sites that are easy for an AI to read and sites that aren't. What's starting to happen Until now, people read websites as websites. You open the top page, follow the menu, read the body, click a button — tracing the path the maker designed. As local AI and AI agents become normal, that breaks. People stop opening the page directly. They tell an AI what they want — "Can I try this quickly?" , "I just want to check it's safe" , "Just the gist" — and the AI reads the web and reshapes it into the form that reader wants. What the reader receives is no longer the layout the maker built. This isn't speculation. The idea that AI generates the interface for the reader already has a name — Generative UI — and it's one of the hottest areas in frontend right now, with Google, Vercel and others building toward it. But notice who's holding the pen in almost every version of that story: the site , or an AI embedded in an app — something under the maker's control. What I'm looking at is one step past that: a local AI, in the reader's own hands, reshaping any site into that person's preferred form — with no involvement from the maker at all. The initiative moves from the maker to the reader. The part that nags at me as a builder I build software too. So this shift nags at me. A site carries its maker's intent and rights. The order things appear in, what gets emphasized, the tone. Design, copy, flow — all of it is deliberate. Having an AI quietly reorder, rewri

An insufficient validation input flaw, one of 11 patched in an update this week, could allow for arbitrary code execution and is under active attack.