DEV Community: Beto Muniz

The Quiet AI War Inside Your Browser

Beto Muniz — Mon, 25 May 2026 22:09:47 +0000

Google shipped the Prompt API in Chrome 148 on May 5, 2026. Mozilla objected. Apple's WebKit team objected. The W3C TAG objected. Microsoft Edge disabled the feature entirely despite running on the same Chromium engine. It was, by any measure, one of the most contested browser feature launches in recent memory.

And it doesn't matter. Google has already won this one.

What Actually Happened

Chrome 148 quietly gave every website on earth the ability to run AI inference locally (text generation, summarization, classification, image captioning) by talking to Gemini Nano, a 4GB model that Chrome now ships to users' devices without asking. The API is dead simple:

const session = await self.ai.languageModel.create({ systemPrompt });
const result = await session.prompt("Your prompt here");

That's it. No API key. No latency. No server cost. No data leaving the device.

The opposition's core argument is a legitimate one: unlike fetch() or addEventListener(), an AI model isn't a deterministic spec. Two browsers implementing the "same API" with different underlying models could produce wildly different outputs, breaking the foundational promise of web standards: write once, run identically everywhere.

It's a real concern. It's also, in practice, irrelevant.

The Web Has Never Guaranteed Identical Outputs

Font rendering differs across browsers. Canvas pixels vary by GPU driver. Audio processing behaves differently on macOS versus Windows. Math.random() is, by definition, non-deterministic. None of these killed the web. Developers adapted, and they'll adapt here too.

The "we can't standardize non-deterministic output" argument proves too much. If it were applied consistently, half the modern web platform wouldn't exist.

Cloud Is the Real Baseline: Not Firefox's Future Model

Here's the thing critics seem to be missing: developers building serious AI features today aren't choosing between Chrome's Prompt API and Firefox's theoretical equivalent. They're calling cloud APIs: OpenAI, Anthropic, Gemini Cloud. Those are where the quality is, where the context windows are, where the capable models live.

Gemini Nano is a small model. It's good at lightweight, well-scoped tasks: summarizing a paragraph, classifying sentiment, extracting a date from a string. It's not replacing GPT-4o or Claude Sonnet for anything that actually matters.

So the Prompt API isn't competing with cloud AI. It's filling a specific niche:

Zero latency tasks that need to feel instant
Offline-capable features in PWAs
Privacy-sensitive processing where data must stay on device
Cost-sensitive at-scale operations (spell check, auto-tagging, content filtering)

Developers will reach for it as a progressive enhancement layer: use the Prompt API when available, fall back to a cloud call when not. The non-determinism objection collapses entirely in this framing: nobody is relying on Chrome and Firefox producing the same tokens. They're relying on "good enough local inference" vs "cloud inference." That gap is fine.

We Have Seen This Movie Before

PWAs. Web Components. Service Workers. WebRTC. Each time, the pattern is the same:

Google ships something useful but contested
Mozilla and Apple raise principled standards objections (sometimes valid, sometimes a proxy for business interests)
Developers adopt it anyway, because Chrome is 65% of global browser traffic
The holdouts implement their own version 2–5 years later
It retroactively becomes a "web standard"

PWAs are the sharpest example. Apple resisted for years: not primarily because of standards purity, but because native apps and the App Store are a multi-billion dollar business. They eventually shipped, incompletely at first, then more fully as the pressure became undeniable. Web Components took a similarly winding road: Google and Mozilla aligned early, Apple dragged its feet, and today Custom Elements and Shadow DOM are universally supported.

The Prompt API will follow the same arc. The only open question is how long the lag is and what compromises get made along the way. (My guess: Firefox and Safari eventually ship something with a compatible API surface but their own models underneath. Mozilla with something open-source, Apple with something Core ML-optimized. The outputs will differ. Nobody will care.)

The Real Concern Nobody Is Saying Out Loud

Apple's strategic worry isn't about spec compliance. It's about this: Google just normalized the browser as an AI delivery vehicle and installed its model on over 4 billion devices. That's not a web standards problem. That's an ecosystem control problem.

Whoever controls the model layer of the browser controls a significant surface area of how users interact with the web: what gets summarized, how content gets classified, what gets surfaced and what doesn't. Apple understands this better than anyone; it's exactly the kind of leverage they've built with the App Store for 15 years.

That's a legitimate concern worth having a serious conversation about. But dressing it up as a standards integrity argument dilutes it and, frankly, makes the objectors look like they're arguing in bad faith. That weakens their position when the real fight (model governance, content policies, on-device data access) eventually arrives.

What This Means for You

If you're building web products today:

Developers: Start experimenting with the Prompt API now for lightweight, latency-sensitive tasks. Design with graceful degradation: the API isn't available in Firefox or Safari yet, so treat it as enhancement, not baseline. WebGPU-based bring-your-own-model approaches (via transformers.js, ONNX Runtime Web) remain the cross-browser story for anything more demanding. If you want a unified abstraction over both, check out web-ai-sdk.dev.

Product and business: The interesting unlock here isn't replacing your cloud AI pipeline. It's enabling AI features that previously couldn't exist on the web: instant, offline, private, zero marginal cost. Think client-side content moderation, on-device personalization, local draft assistance. The economics and privacy story are genuinely new.

The browser is becoming an AI runtime. Google didn't ask for permission. That ship has sailed.

The Prompt API is available in Chrome 148+. WebGPU-based inference works cross-browser today via libraries like Transformers.js. WebNN remains experimental across all browsers.

How to improve the Critical Path CSS on web using the “Above-The-Fold" strategy?

Beto Muniz — Mon, 31 May 2021 15:28:04 +0000

In this brief content, I am sharing about the Above-The-Fold strategy to load CSS and why it matters to improve the page loading of our web pages.

📁 Above-The-Fold strategy on the web is a practice that extracts critical CSS declaration to render the layout displayed during the initial page load.

⏬ Non-critical CSS is added to another context (usually a dedicated .css file) to use async loading.

⌛️ Above-The-Fold enhances the loading experience while browsing since the browser will have the necessary CSS to scaffold the layout.

⏱ Also, this technique is an essential strategy to improve First Content Paint metrics in our web pages.

👉 Have you already heard about this web optimization opportunity strategy?

How to avoid Meltdown, Spectre and CSRF Attacks on Web with CORP, CORB, and CORS?

Beto Muniz — Mon, 24 May 2021 21:33:26 +0000

A brief and useful content about the mechanics on Cross-Origin Read Blocking, Cross-Origin Resource Policy and Cross-Origin Resource Sharing against Meltdown, Spectre and CSRF Attacks.

CORB

By design, Cross-Origin Read Blocking validates browser requests before they even reach the server using their MIME type as a validation rule.

To enable it, send the HTTP header X-Content-Type-Options: nosniff from the server.

CORP

Cross-Origin Resource Policy is a complementary CORB mechanism for validation applied to requests flagged with no-cors to invalidate them if they came from different domains or origin.

Send the header Cross-Origin-Resource-Policy from the server with values same-origin or same-site to invalidate no-cors requests from different domains or origin.

CORS

Cross-Origin Resource Sharing is a logical context mechanism that ensures minimal security in the way that users consume web content using browsers instructing how the browser will validate the origin of the requests.

To define rules about how the origin of the request will be identified, send the HTTP header Access-Control-Allow-Origin using values like <exact_request_origin> and even a more generic approaches using *.

Conclusion

Hope that now you understand a bit better why to use these Cross-Origin Resource features

Try don't disable or ignore them in your web applications. Spectre, CSRF, and Meltdown attacks are really dangerous.

How to Protect Cookies Against Common XSS Attacks on the Web?

Beto Muniz — Mon, 17 May 2021 21:58:30 +0000

We can ignore Cookies danger by just not recommending its usage, but the fact is that at least 55% of all the websites use Cookies RIGHT NOW even with lots of existing cookieless strategies.

So how to protect Cookies against Common XSS Attacks?

Well, if your app really needs to use Cookies, configure each one through Set-Cookie HTTP Header with at least the following flags:

🍪 Secure: To allow the Cookie only through HTTPS

🍪 HttpOnly: To remove the Cookie from the document.cookie

🍪 SameSite: To limit the Cookie context usage

Set-Cookie: Secure;HttpOnly;SameSite=Strict;...

Hope that with these tips, your app now has a few more chances against XSS Attackers that use Cookies breaches. Anyway, keep in mind that complex attacks can easily bypass these tips. So try to migrate ASAP to cookieless strategies.

XSS Attacks Types on Web

Beto Muniz — Mon, 10 May 2021 21:03:19 +0000

Know how each Cross-Site Scripting Attack behaves is crucial to start to think about how vulnerabilities in our web apps allow malicious codes to be executed using the browser to take sensible data from users.

That's what this article is about.

🔓 Reflected XSS

📌 This attack XSS use URL parameters or data submitted via POST in forms to inject malicious code on that server request that persists some data for later execution in the browser. Third-party Browser extensions could even be an access point to inject such a malicious code.

🔓 Stored XSS

📌 This attack XSS happens when malicious code is persisted by the attacker directly in the server-side of the web app and is executed by the user (victim) when she accesses the infected application.

🔓 DOM XSS

📌 This attack XSS happens when the application manipulates the DOM incorrectly, opening breaches to malicious scripts sent by URL parameters to inject malicious code.

🔓 The question is... How to defend against attacks XSS?

📌 There's no formula - A system security is always dependent on that system context, keep this in mind, but there are practices against well-known XSS attacks to stay updated about XSS attacks.

👉 Start reading about Content Security Policy, Mozilla Observatory, OWASP recommendations, and signing up my newsletter. As a web security lover, I always talk about it.

Proxy Pattern in JavaScript

Beto Muniz — Mon, 03 May 2021 21:03:24 +0000

Just a catch up about how the Proxy object works on JavaScript to allow us to implement Proxy patterns.

📌 JavaScript's Proxy object allows us to intercept and modifies any JavaScript object.

📌 JavaScript's Proxy object is an elegant and safe way for creating or extending libraries, caching, error handling, and complex data manipulation on JavaScript.

const obj = {a: 1, b: 2};

const arrProxy = new Proxy(obj, {
  get: function (item, property) {
    if (item.hasOwnProperty(property)) return item[property];

    return "default value";
  },
});

arrProxy.z; // "default value"
arrProxy.a; // 1

💡 What are the use cases that you most liked to use such a JavaScript feature?

📚 Still, for a detailed API spec of Proxy's object in JavaScript, take a look in the MDN docs.

Earn money using the Web Monetization API

Beto Muniz — Mon, 26 Apr 2021 16:03:05 +0000

Content inspired after I receive my first payment using Web Monetization API

🧑‍🔬 The How

Sign up to wallet.uphold.com/signup and verify yourself
Find the Interledger Payment Pointer in the Transact panel

And pick a currency target. It could be USD, BTC, etc

The Web Monetization API needs a Payment Pointer to address micropayments for you.

🏗 The Where

You could now use your already created Uphold's Payment Pointer on your website using this declaration:

<meta name="monetization" content="$ilp.your.payment/pointer" />

Also, dozens of services offer support:

Even YouTube, when connected in a creator account on Coil.

💰 The Web Monetization API

The Web Monetization API is a W3C Standard that uses a neutral payment protocol called Interledger (ILP) for transferring money for anyone by anyone.

The proposal help web creators avoid systems that slow down the web and creates annoying UX

📚 More about Web Monetization Standards

Map and Set in JavaScript for Humans

Beto Muniz — Mon, 19 Apr 2021 21:37:35 +0000

Would you like to hear more about Set and Map objects in JavaScript?

Let's catch up with them on this thread 🧵

Set in JavaScript 👇

📌 It's not key/value like the Object type. Keys are just values exposed

📌 Don't accept duplicated values

📌 It's iterable with forEarch method and for...of

📌 Conceptually is similar to []

💡 Set is useful to remove duplicates on [].

Map in JavaScript 👇

📌 Allow/preserve any key type. Even objects

📌 Don't expose insecure data properties

📌 Iterate with forEarch method and for...of

📌 Stay the insertion order doesn't matter the type

💡 Prefer Map instead of {} for client-side data manipulation.

Thoughts on Map, Set, {}, and [] in JavaScript 👇

📌 Each has a specific usage in JS

📌 Use {} for data traffic from the server.

📌 Set helps apply omit, diff, etc. on []

📌 Map return size. {} don't return size

🗣 There's not a silver bullet. Use them carefully.

😉 Hope that you now understand better such useful objects on JavaScript, they are highly valuable, and master them will make you a better JavaScript Developer.

Using "noopener" and ”noreferrer” against Phishing Attacks

Beto Muniz — Mon, 12 Apr 2021 19:24:45 +0000

Want to help users to avoid some Phishing Attacks with HTML?

👉 Use rel="noopener noreferrer" while adding external links to your website to improve user navigation security.

<a rel="noopener noreferrer" href="https://...">
 External Link
</a>

🐿 noopener: tells the browser to remove sensitive data from window.opener object when the user arrives at the destination website.

🤓 noreferrer: protect sensitive data of the origin website removing it from the Referrer header while the user navigates between origin website and destination website.

😋 Super easy security strategy to implement. Adopt this recommendation without moderation.

CSS Custom Properties with @property

Beto Muniz — Mon, 05 Apr 2021 14:19:38 +0000

Have you heard about the CSS @property statement?

📣 @property is a CSS Houdini at-rule that allows us to configure CSS custom properties by data type using the syntax field, default values using the initial-value field, and set if it allows inheritance.

@property --colorPrimary {
  syntax: "<color>";
  initial-value: magenta;
  inherits: false;
}

body {
  /* Fallback for browsers without @property support. */
  --colorPrimary: magenta;
}

.text {
  color: var(--colorPrimary);
}

🪄 The nicest aspect about @property is the capability to enhance CSS dynamics through high-level declarations with simplicity and certain performance enhancements.

🔬 Some use cases for @property statement are data type validation on CSS and animations.

@property --status {
  inherits: false;
  initial-value: 0%;
  syntax: '<percentage>';
}

.progress-bar {
  width: var(--status);

  height: 5px;
  background: gold;
  animation: progress 2s forwards;
}

@keyframes progress {
  to {
    --status: 100%;
  }
}

😋 Really cool, right?

CSS Property: content-visibility

Beto Muniz — Mon, 29 Mar 2021 19:19:01 +0000

👉 The CSS property content-visibility allows the web developer inform to the browser rendering engine which parts of the page are out of the user view.

😍 With this info, the browser can optimize the render flow time to focus on where really matters for the user.

content-visibility: visible;
content-visibility: hidden;
content-visibility: auto;

🪔 content-visibility using visible or hidden values show or hide respectively the content on a rendering engine level.

⚡️ content-visibility with value auto tells the browser rendering engine to render the elements based on user needs.

globalThis in a nutshell

Beto Muniz — Wed, 24 Mar 2021 17:25:20 +0000

globalThis is a global object reference for client and server applications using JavaScript.

👉 It’s helpful to create cross-platform apps and libraries.

🔒 Due to security, globalThis is a Proxy reference of the global object on the browser.

globalThis.fetch("https://...");