# Browser Extension Browser extensions are software add-ons that modify and enhance browser capabilities, commonly built with extension APIs. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Inertia DevTools Now Available for Firefox DevFeed: [Inertia DevTools Now Available for Firefox]() Original publisher: [Read original article]() Author: Paul Redmond Published: 2026-09-17T02:28:55Z Content type: release Language: en Sources: [Laravel]() Topics: [Firefox](), [Browser Extension](), [developer tooling](), [Chrome](), [vs-code](), [phpstorm]() Tags: [chrome-extension](), [devtools](), [editor](), [extension](), [features](), [firefox](), [news](), [panel](), [phpstorm](), [vs-code]() ### AI overview Inertia DevTools is now available as an official Firefox extension with feature parity with the Chrome extension. It records Inertia visits and exposes props, request and response details, routes, controller actions, and page state in a Firefox DevTools panel. Sensitive fields are redacted, and recorded data remains on the local machine. ### Source excerpt Inertia DevTools, the panel for inspecting Inertia.js visits and props, is now on Firefox with the same features as the Chrome extension. The post Inertia DevTools Now Available for Firefox appeared first on Laravel News. Join the Laravel Newsletter to get Laravel articles like this directly in your inbox. ## How to Monetize a Browser Extension with a Freemium Model DevFeed: [How to Monetize a Browser Extension with a Freemium Model]() Original publisher: [Read original article]() Author: Ayush Agarwal Published: 2026-03-28T00:00:00Z Content type: tutorial Language: en Sources: [Dodo Payments Blog]() Topics: [Extension](), [Browser Extension](), [Chrome extension](), [Firefox extension]() Tags: [chrome](), [chrome-extension](), [extension](), [firefox](), [how-to](), [license-keys](), [payments](), [subscription-billing]() ### AI overview A guide to monetizing browser extensions with a freemium model. It covers keeping core functionality free, gating advanced features and usage limits, validating license keys on a server, and using subscription billing and customer self-service portals. ### Source excerpt Build a profitable freemium browser extension. Implement free vs paid feature gating, license key activation, and subscription billing for Chrome and Firefox extensions. ## How to Monetize a Chrome Extension in 2026 (4 Models + Step-By-Step Setup) DevFeed: [How to Monetize a Chrome Extension in 2026 (4 Models + Step-By-Step Setup)]() Original publisher: [Read original article]() Author: Ayush Agarwal Published: 2026-03-23T00:00:00Z Content type: tutorial Language: en Sources: [Dodo Payments Blog]() Topics: [Chrome extension](), [Extension](), [Browser Extension](), [Code]() Tags: [2026](), [billing](), [business](), [chrome](), [chrome-extension](), [code](), [extension](), [global-payments](), [how-to](), [license-keys](), [monetization](), [payments](), [saas](), [subscriptions]() ### AI overview A practical guide to monetizing Chrome extensions in 2026. It explains freemium, subscriptions, license keys, one-time purchases, and usage-based models, and covers payment, tax compliance, license management, and implementation considerations. ### Source excerpt Chrome extension monetization models: freemium, subscriptions, license keys, one-time, usage-based. Code samples plus a license delivery walkthrough. ## Hacking Displate (For Fun!) DevFeed: [Hacking Displate (For Fun!)]() Original publisher: [Read original article]() Author: Dan Lew Published: 2025-11-18T15:00:46Z Content type: opinion Language: en Sources: [Dan Lew Blog]() Topics: [Hacking](), [Website](), [API](), [Browser Extension](), [browser](), [data]() Tags: [api](), [browser](), [extension](), [hacking](), [order](), [scraping](), [tracking](), [website]() ### AI overview A developer documents experiments with Displate's website, including tracking Limited Edition resale prices and using its API to discover early-access links. The article also describes ordering a Limited Edition before its public release and competing with another person using a browser extension to find links and monitor inventory. ### Source excerpt During the pandemic my weird vice/obsession became Displates (metal wall art hung up by magnets): Some of my Displates (along with other tchotchkes in my office) For me, part of the hobby was poking holes in their website. I've long stopped trying to give their devs heartburn, ## Introducing: Local Browser AI DevFeed: [Introducing: Local Browser AI]() Original publisher: [Read original article]() Author: Alex Ewerlöf Published: 2025-10-13T07:51:29Z Content type: article Language: en Sources: [Alex Ewerlof Notes]() Topics: [browser](), [Artificial Intelligence](), [Browser Extension](), [JavaScript](), [On-device AI]() Tags: [ai](), [browser](), [extension](), [interface](), [javascript](), [on-device-ai](), [open-source]() ### AI overview This technical post explains how the Prompt API enables local language-model chat in the browser and examines the Local Browser AI extension, which is built with plain JavaScript and native browser APIs. It also describes the extension's permissions, privacy properties, open-source MIT license, and supported platforms. ### Source excerpt Using the new Prompt API for local chat in the browser ## Vibe-engineering a Firefox add-on: Container Traffic Control DevFeed: [Vibe-engineering a Firefox add-on: Container Traffic Control]() Original publisher: [Read original article]() Author: Kaushik Gopal Published: 2025-09-29T02:31:35Z Content type: opinion Language: en Sources: [Kaushik Gopal's Site]() Topics: [Browser Extension](), [Firefox](), [JavaScript](), [Code review](), [GitHub](), [Software]() Tags: [code-review](), [extension](), [firefox](), [github](), [javascript](), [software]() ### AI overview An experiment in building the Container Traffic Control Firefox add-on entirely through agent-assisted development, without manually editing JavaScript. The author argues that careful instructions, prompting, pruning, testing, organization, logging, comments, and code review can produce a readable and maintainable small codebase. ### Source excerpt I wanted to test a simple claim: you can ship maintainable software by vibe-engineering end to end. I set strict constraints: New platform (I haven't built a browser extension/add-on) Language I'm no longer proficient in (JavaScript) Zero manual code editing In about a day1 I had a working Firefox add-on I could submit for review. The code meets my bar for readability and long-term change. Even the icon came from an image model.2 Introducing Container Traffic Control. Install and source - Install: Firefox add-on listing - Code: github.com/kaushikgopal/ff-container-traffic-control On the vibe-engineering process ## It's in vogue to share horror stories of decimated vibe-coded repos.3 But I'm convinced that with the right fundamentals, you can vibe-engineer4 a codebase you'd comfortably hand to another engineer. This was my experiment to vet my feelings on the subject. Granted, this was a small and arguably very simple repository, but I've also seen success with moderately larger codebases personally. It comes down to scrupulous pruning: updating system instructions, diligent prompting, and code review. I plan to write much more about this later, but let's talk about some of the mechanics of how it went: I didn't write a single line of JavaScript by hand. When I needed changes, better structure, reusable patterns, small refactors -- I asked the agent. The goal throughout was simple: keep the codebase readable and maintainable. It now has a lot of the things we consider important for a decent codebase: Tests (for the important parts) Well-organized code Clear, useful logging Code comments (uses a style called space-shuttle style programming, which I think is increasingly valuable with vibe-engineering) The best part: most of this came together over two days.5 Some example pull requests from the repository with the exact prompt I used and the plan that was generated: Here's the very first prompt I used to generate the guts of the code: # Role/Persona: - you are an expert ## Captionary Browser Extension Provides Subtitle Word Definitions on Netflix DevFeed: [Captionary Browser Extension Provides Subtitle Word Definitions on Netflix]() Original publisher: [Read original article]() Author: Furkan Kolcu Published: 2025-09-07T13:31:21Z Content type: release Language: en Sources: [Furkan Kolcu - Software Engineer Blog]() Topics: [Browser Extension](), [Extension](), [browser](), [Learning](), [Netflix](), [GitHub]() Tags: [browser](), [chrome-addon](), [english-learning](), [english-vocabulary](), [extension](), [firefox-addon](), [github](), [language-learning](), [language-learning-addon](), [learning](), [netflix](), [netflix-addon](), [technology]() ### AI overview Captionary is a browser extension for learning English through shows. It lets users click words in English Netflix subtitles to see definitions without leaving the screen. Support for other platforms and languages is planned. ### Source excerpt If you're watching movies or series to improve your English, you're not alone -- and you're doing it right. Subtitles can be a great way to pick up new words in context, especially when you hear how they're used in real conversations. ## Tailor-made browser extensions for increased testing efficiency DevFeed: [Tailor-made browser extensions for increased testing efficiency]() Original publisher: [Read original article]() Author: Raymond Saba I'm an SDET who enjoys building test automation; Finding Ways Published: 2025-04-23T00:00:00Z Content type: article Language: en Sources: [Trivago]() Topics: [Testing](), [Browser Extension](), [Extension](), [Development]() Tags: [browser](), [development](), [extensions](), [quality-assurance](), [reverse-engineering](), [test-automation](), [testing]() ### AI overview The article describes how trivago's QA team used custom browser extensions to support exploratory testing, reduce cumbersome testing processes, and save time. It discusses an extension created through reverse engineering to inspect Google Tag Manager data-layer values and another that identified the version of the trivago website being viewed. ### Source excerpt When doing exploratory testing on a web application, the nature of activities involves discovering things and not repeating the same patterns. However, there might be aspects that could be impro... ## The article criticizes Google's moderation of malicious Chrome Web Store extensions DevFeed: [The article criticizes Google's moderation of malicious Chrome Web Store extensions]() Original publisher: [Read original article]() Author: Wladimir Palant Published: 2025-01-13T13:12:43Z Content type: opinion Language: en Sources: [Almost Secure]() Topics: [Google Chrome](), [Browser Extension](), [Google](), [trust]() Tags: [extension](), [google-chrome](), [reports](), [transparency](), [trust]() ### AI overview This opinion article argues that Google's moderation of malicious and problematic Chrome Web Store extensions is ineffective and inconsistent. It describes automated moderation as inadequate, says legitimate add-on authors also face problems, and cites the author's experience reporting harmful extensions. ### Source excerpt Let's make one thing clear first: I'm not singling out Google's handling of problematic and malicious browser extensions because it is worse than Microsoft's for example. No, Microsoft is probably even worse but I never bothered finding out. That's because Microsoft Edge doesn't matter, its market share is too small. Google Chrome on the other hand is used by around 90% of the users world-wide, and one would expect Google to take their responsibility to protect its users very seriously, right? After all, browser extensions are one selling point of Google Chrome, so certainly Google would make sure they are safe? Unfortunately, my experience reporting numerous malicious or otherwise problematic browser extensions speaks otherwise. Google appears to take the "least effort required" approach towards moderating Chrome Web Store. Their attempts to automate all things moderation do little to deter malicious actors, all while creating considerable issues for authors of legitimate add-ons. Even when reports reach Google's human moderation team, the actions taken are inconsistent, and Google generally shies away from taking decisive actions against established businesses. As a result, for a decade my recommendation for Chrome users has been to stay away from Chrome Web Store if possible. Whenever extensions are absolutely necessary, it should be known who is developing them, why, and how the development is being funded. Just installing some extension from Chrome Web Store, including those recommended by Google or "featured," is very likely to result in your browsing data being sold or worse. Google employees will certainly disagree with me. Sadly, much of it is organizational blindness. I am certain that you meant it well and that you did many innovative things to make it work. But looking at it from the outside, it's the result that matters. And for the end users the result is a huge (and rather dangerous) mess. Contents Some recent examples The reporting process Chrome Web ## BIScience: Collecting browsing history under false pretenses DevFeed: [BIScience: Collecting browsing history under false pretenses]() Original publisher: [Read original article]() Author: Anonymous Researcher Published: 2025-01-13T12:57:04Z Content type: article Language: en Sources: [Almost Secure]() Topics: [Browser Extension](), [data](), [SDKs](), [Security]() Tags: [browser](), [data](), [extension](), [most-other-articles-about-add-ons-by-wladimir-palant](), [privacy](), [sdk]() ### AI overview An anonymous researcher examines claims that BIScience and its brands collect users' browsing histories through Chrome extensions, partner extensions, and an SDK, then sell the data through products including Clickstream OS and AdClarity. The article argues that BIScience's public disclosures and privacy practices are inconsistent with its data-collection practices. ### Source excerpt This is a guest post by a researcher who wants to remain anonymous. You can contact the author via email. Recently, John Tuckner of Secure Annex and Wladimir Palant published great research about how BIScience and its various brands collect user data. This inspired us to publish part of our ongoing research to help the extension ecosystem be safer from bad actors. This post details what BIScience does with the collected data and how their public disclosures are inconsistent with actual practices, based on evidence compiled over several years. Screenshot of claims on the BIScience website Contents Who is BIScience? BIScience collects data from millions of users BIScience buys data from partner third-party extensions BIScience receives raw data, not anonymized data Misleading CWS policies compliance BIScience extensions exception claims Partner extensions exception claims, guided by BIScience BIScience SDK Unnecessary features Misleading privacy policy disclosures Misleading user consent Our hope for the future Related reading IOCs Who is BIScience? BIScience is a long-established data broker that owns multiple extensions in the Chrome Web Store (CWS) that collect clickstream data under false pretenses. They also provide a software development kit (SDK) to partner third-party extension developers to collect and sell clickstream data from users, again under false pretenses. This SDK will send data to sclpfybn.com and other endpoints controlled by BIScience. "Clickstream data" is an analytics industry term for "browsing history". It consists of every URL users visit as they browse the web. According to their website, BIScience "provides the deepest digital & behavioral data intelligence to market research companies, brands, publishers & investment firms". They sell clickstream data through their Clickstream OS product and sell derived data under other product names. BIScience owns AdClarity. They provide "advertising intelligence" for companies to monitor competitors. I ## Hack Day 2024: Sports and Election Prototypes DevFeed: [Hack Day 2024: Sports and Election Prototypes]() Original publisher: [Read original article]() Author: Rasha Ardati, Mariot Chauvin Published: 2024-06-17T14:42:54Z Content type: article Language: en Sources: [Guardian]() Topics: [Demo](), [Browser Extension](), [Programming](), [Structured-data]() Tags: [demo](), [extension](), [hack](), [programming]() ### AI overview Guardian colleagues held a two-day 2024 hack day themed around sports and upcoming elections. The article highlights selected concepts, including favicon-based liveblog displays, a browser extension that turns paragraphs into crosswords, and structured tennis scores for liveblogs. ### Source excerpt Recently, colleagues across the product and engineering department, as well as other parts of the organisation, came together for another exciting hack day For our first hack day of 2024 we kicked off with a grand theme around all the major events of the world, including sport and upcoming elections around the world. Hackers played around with the idea of using python programming language and real-time mobile telemetry data to influence the outcome of UK elections, they proposed a bold new journalistic geometry, added fun polls, quizzes and newsletters sign ups to the live blog, as well as posed the question: " Can bedrock do what CAPI can do?" And that's only 4 of the 19 amazing hacks produced and presented over the two-day event! A counter in the favicon for unread liveblog entries, which would appear on liveblogs. A more experimental demo that displayed a tiny version of the Guardian article being read entirely within the favicon. This included a Guardian header, real-time scrolling, all the article text, and images. Continue reading... ## Exploring WebExtension security vulnerabilities in React Developer Tools and Vue.js devtools DevFeed: [Exploring WebExtension security vulnerabilities in React Developer Tools and Vue.js devtools]() Original publisher: [Read original article]() Author: Calum Hutton Published: 2023-11-27T05:00:00Z Content type: article Language: en Sources: [Blog RSS Feed | Snyk]() Topics: [WebExtension](), [Browser Extension](), [Vulnerabilities](), [Security](), [React](), [Vue.js]() Tags: [application-security](), [awareness](), [blog](), [browser](), [code-security](), [developer](), [devrel](), [extensions](), [react](), [security](), [security-vulnerabilities](), [snyk-platform](), [vue](), [vulnerabilities]() ### AI overview This article examines security risks in WebExtensions, focusing on vulnerabilities identified in React Developer Tools and Vue.js devtools. It explains the cross-browser WebExtension architecture and discusses risks including unverified external messages, code injection, and XSS. ### Source excerpt Snyk's security researchers have identified and disclosed some vulnerabilities within some popular browser extensions: React Developer Tools and Vue.js devtools. This post will explore the WebExtension technology and look into the vulnerabilities identified. ## Hack Day: Food Glorious Food DevFeed: [Hack Day: Food Glorious Food]() Original publisher: [Read original article]() Author: Rasha Ardati Published: 2023-05-31T08:45:02Z Content type: article Language: en Sources: [Guardian]() Topics: [Browser Extension](), [App](), [Artificial Intelligence](), [web browser](), [Image](), [stable-diffusion]() Tags: [ai](), [browser](), [extension](), [hack](), [images](), [stable-diffusion]() ### AI overview The Guardian's first hack day of 2023 focused on food-related ideas and produced more than 22 hacks over two days. Projects included browser extensions, recipe interfaces, a restaurant review mapper, microwave-friendly recipes, and an AI tool that generates recipe-step images using stable diffusion or DALL-E. ### Source excerpt This month, colleagues across the product and engineering department, as well as other parts of the organisation, came together for another exciting hack day For our first hack day of 2023 we kicked off with a delicious theme around 'Food', with a side of the usual 'free-for-all' of course. Hackers were invited to think about all things edible, whether as an app, a new search method for recipes, a meal planner or perhaps a choose your own adventure game where your date is coming for dinner in an hour and a half, and you have decided, perhaps too ambitiously, to cook them an elaborate Ottolenghi recipe from the Guardian archives. We produced and presented over 22 amazing hacks over the two-day event. These included: Migrating our tone/recipes page to our latest rendering tiers, A web browser extension to help users understand cooking language and become better cooks, making Guardian recipes microwave-friendly, a restaurant review mapper, implementing a Guardian app section for food content and a web browser extension to appeal to our tofu-eating readers. Continue reading... ## Results of Quick Testing of Documentation Tools' Accessibility DevFeed: [Results of Quick Testing of Documentation Tools' Accessibility]() Original publisher: [Read original article]() Author: Eevis Panula Published: 2023-01-03T08:57:41.997000Z Content type: article Language: en Sources: [Eevis Blog]() Topics: [Accessibility](), [Testing](), [Documentation](), [Swagger](), [Browser Extension](), [OpenAPI Specification](), [Document Object Model (DOM)]() Tags: [accessibility](), [automated](), [color](), [documentation](), [input](), [keyboard](), [openapi-specification](), [screen](), [swagger](), [testing]() ### AI overview This article reports quick accessibility testing of Swagger, Read the Docs, Docusaurus, and GitBook using the Axe browser extension, DOM inspection, and keyboard testing. The testing was not exhaustive because it did not include screen readers, narrower viewports, or zooming. For Swagger UI, Axe identified 64 issues, including color-contrast problems, form inputs without programmatically associated labels, and missing landmark regions. ### Source excerpt When writing my blog post about what backend devs can do for accessibility, I did some quick accessibility tests for different documentation tools. Initially, I thought I'd write about the results in that blog post, but there was just too much to report. So, I ended up writing this blog post. I chose four tools that I know many projects are using. These tools are: Swagger Read the Docs Docusaurus GitBook First, I ran an automated test with the aXe browser extension and dug deeper into the DOM based on the test results. After that, I tested the site with a keyboard. In this blog post, I'll share the test results and some thoughts about them. As you can see from the steps described above, the testing was not exhaustive. I just wanted to get an overview of the issues. I did not, for example, test with a screen reader or with narrower viewports (or zooming). This was a conscious decision, partly because I didn't have time and partly because this blog post would've been super long. And I think this already provides some overview of the state of accessibility of these tools. Let's get started. Swagger URL used for testing: https://petstore3.swagger.io/ Swagger is a set of tools used for API documentation. The Swagger API project started in 2011. Initially, it was a specification, but it was later named OpenAPI Specification. So it has a long history, and many projects use it. One of its tools is Swagger UI, a user interface for browsing the API endpoints. That's the one I'm testing for this blog post. Testing Swagger UI with Axe Runnin Axe-browser extension showed 64 issues, two of which are critical, 35 serious, 18 moderate, and 7 minor. Most of the issues (37) were related to color contrast issues. The contrast ratio for the problematic color combinations ranged between 2.03 and 3.75. Another problem was form input without programmatically associated labels. Some of them were flagged, but when I started digging deeper into the site's code, I noticed that not every insta ## A Front-End Development Experience Working on the TextSecure Chrome Browser Extension DevFeed: [A Front-End Development Experience Working on the TextSecure Chrome Browser Extension]() Original publisher: [Read original article]() Published: 2015-01-14T00:00:00Z Content type: opinion Language: en Sources: [Signal Blog]() Topics: [Development](), [Front end](), [Browser Extension](), [Backbone.js](), [JavaScript](), [pull-requests](), [Chrome](), [Git](), [Library]() Tags: [browser](), [chrome](), [extension](), [front-end](), [front-end-development](), [git](), [javascript](), [pull-requests]() ### AI overview A personal account of learning front-end development while contributing to the TextSecure Chrome Browser Extension. The author describes using Backbone.js, Grunt, Bower, Mustache, Git, and pull requests while separating phone-number input into a reusable Backbone.js view and validating it across multiple HTML pages. ### Source excerpt Winter Break Of Code Day 2 Because I might get sappy, here's a picture to ease that before I let it all out. After being promptly woken up by numerous roosters at 7:30 AM, I still can't believe I'm here. My application was pretty last-minute, completed when I was in a state of droopiness and scholarship-application-hyperdrive. But I got on a plane from the Midwest, went from cloudy, 20 degrees with windchill making it feel like 0 to sunny, 77 degrees with mild winds making it feel still 77 degrees. Read more...