Responding to ArsTechnica (Condé Naste) and 'Mellow-Drama' Articles

Responding to ArsTechnica and Mellow Drama Article

Hey, it's Arslan, the original author of the Mellowtel library here. I want to clarify a few things as the article on ArsTechnica (Condé Nast) by Dan Goodin contains disinformation and is misleading on a variety of levels. The original analysis by John Tuckner was more technical and analytical, raising some valid points which I'll address here.

Here's the link to the articles for reference. Dan Goodin (ArsTechnica): https://arstechnica.com/security/2025/07/browser-extensions-turn-nearly-1-million-browsers-into-website-scraping-bots/

John Tuckner (original post): https://secureannex.com/blog/mellow-drama/

What Mellowtel Actually Does

To give context of what Mellowtel does, as we have described in our GitHub and website, we are trying to build an open-source alternative to ads and a monetization engine for the AI world.

Instead of collecting users' data, tracking them across the web, and showing them ads non-stop, we are building a monetization engine for developers based on bandwidth/resource sharing. Users who want to support a free software product or creator can decide to opt-in to share their bandwidth. This is used to give access to the web to AI companies that need to scrape data from public websites (think of services like ChatGPT search, deep research, or Perplexity that retrieve data from the web for every query). These companies pay to access these websites, and we share the revenue with the developers whose users decided to support them. Then developers can decide to offer them additional features and content or simply use the money to keep the products free and available.

We believe it's the right time for a new monetization engine to keep software and products free and allow creators to keep creating.

In fact, with the rise of AI and its need of web access and simultaneously declining ad rates, the rise of adblockers, and people becoming increasingly desensitized to ads, traditional advertising is becoming a less sustainable monetization model. We hope Mellowtel can be the AI-era solution that keeps software and the internet a free space by allowing users to voluntarily share a small fraction of their bandwidth to support their favorite developers. This bandwidth directly fuels the AI frontier - think of every time you use ChatGPT's search or deep research features, it needs to retrieve data from the web. Or when you need to consult external documentation in Cursor or use any AI automation tool. Mellowtel bridges that gap by providing the infrastructure that AI companies need while creating a fair, transparent revenue stream for developers and creators. Unlike ads that interrupt user experience and often invade privacy, Mellowtel works invisibly in the background. Users support creators they love, developers get sustainable income, and AI companies get the web access they need to innovate. Users maintain complete control and can manage their settings anytime at https://www.mellow.tel/user-control.

Now let's delve deeper in the article

Addressing Claims from the ArsTechnica Article

I'll start quoting some sections from the article and then replying to them.

"Advertisers as Customers"

Claim: "[...] behalf of paying customers, which include advertisers"

Response: I'm not aware of any advertisers paying us. Mellowtel is the open-source alternative to ads. Our business model is based on bandwidth sharing, not collecting and selling users' data like advertisers do.

I'm also not sure how the author came up with that "information". Our customers are seed to Series A startups based out of SF and NY and working in the AI space. They are backed by YC, Khosla Ventures, Kleiner Perkins, General Catalyst and other top tier VCs. They access the Mellowtel technology through Olostep. The reason for not exposing a direct endpoint in Mellowtel was mainly to avoid security holes that black-hat hackers could potentially take advantage of. By keeping the two seperate we could manually onboard customers and solve any issue as they arise with less fear of hackers or malicious actors.

Revenue Split Transparency

Claim: "[...] extension developers receive 55 percent of the revenue, and MellowTel pockets the rest"

Response: Correct, the revenue split is 55% to developers and 45% to Mellowtel (to cover server costs + salaries). It's exactly like the YouTube Ad revenue split model with creators. We think it's a pretty fair compensation system.

Contact Attempts

Claim: "Attempts to reach MellowTel representatives were unsuccessful."

Response: I checked our Discord, GitHub, info@mellowtel email inbox and didn't receive any request from the author of the article (or from John). I have reached out to Dan both via email and Signal.

Privacy Concerns

Claim: "[...] that collects the location, available bandwidth, heartbeats, and status of extension users. Besides the privacy erosions"

Response: The author mentions privacy erosion as a concern here. All this data is completely anonymous, it doesn't point back to any user, and isn't stored except the minimum time needed to act on it:

• Location: The only information used is country level (e.g. US, ES, DE). I don't see how this undermines privacy of users because it isn't associated with any Personally-Identifiable-Information (PII) at all.

• Available bandwidth: This is collected solely to determine if a user is on a slow connection. If they are, we don't send requests to avoid overloading low bandwidth devices (things like mobile connections, etc.). You can see this in our code: measure-connection-speed.ts and websocket.ts

• Heartbeats: We do send periodic heartbeats from the server to maintain the websocket alive since by default it would die after a timeout. This heartbeat is a simple JSON message sent from the server and doesn't collect/contain any data. Example: { type_event: "heartbeat" }. You can see the heartbeat handling here - it's simply returning and not communicating back.

• Status: I think the author probably refers to the opted in/not opted in status. We do in fact need to collect this status just to avoid sending requests if a user is opted out. It's not even sent to the server since, if a user opts out from the library, it doesn't even create a connection with the websocket: index.ts

Security Headers

Claim: "The library dynamically modifies rules that will remove security headers from web server responses and then claims to add them back after the web page has loaded"

Response: "Claims to add them back" - This is a pretty verifiable claim since anyone that knows a little bit of code can just analyze the source code on GitHub. Like John did for the removal code: dnr-helpers.ts, there is also the code which reinstates them: reset-crawl.ts

User Consent and Vulnerability

Claim: "[...] users unintentionally becoming bots, but their actual web browsing is more vulnerable as well."

Response: First I'll focus on "unintentionally". Our approach is always opt-out by default. I'll write more below on how we are going about enforcing it now as part of a stricter approach to maintaining a transparent ecosystem. We provide default opt-in/out hosted pages to simplify asking consent and have left this page where users can see all the plugins to which they have opted-in and manage their settings with no developer as an intermediary: mellow.tel/user-control.

On the browsing being more vulnerable, we reinstate these headers immediately after a request is handled. But John is right and there is a small window of vulnerability that lasts around 30 seconds. We'll be working in the coming days to remove these rules only on the specific hosts necessary for the request - this will greatly decrease, if not completely remove, vulnerability concerns due to the removal of these rules.

It might be that this approach - to the author - looks "[...] reminiscent of a 2019 analysis that found browser extensions installed on 4 million browsers collected users' every movement on the web" but one of the main reasons we created Mellowtel was to specifically avoid extension developers having to resort to these privacy-invasive tactics to monetize their users.

Extensions that are using Mellowtel to monetize don't have to resort to becoming spyware and tracking/selling their users' private browsing data/cookies/session tokens or worse. You can read a bit more about it here.

Extension Removals

Finally, on the "removal by malware", there needs to be a distinction between correlation and causation. There is indeed the Chrome single purpose policy. But the review team just asks developers to remove the integration (there is no automatic removal) if deemed not single purpose. The policy is also specific to Chrome and not on other browsers. Chrome also removes plugins that they consider malware. Some of the extensions that got removed were most probably opting in users automatically and doing other malicious stuff. But it doesn't mean that makes Mellowtel a malware. On our side, we can do more and we'll try to address these faulty integrations with a quarantine system going forward to avoid issues to end-users and run security audits for products that use our library. More on this in the Opt-in Enforcement paragraph

Addressing John Tuckner's Technical Analysis

I will also now try to address the concerns raised by John Tuckner in his original post.

Open Source Transparency

Claim: "[...] which the developers use persuasively as a sign of good security hygiene, though all browser extension code is available to anyone using the extension."

Response: You are right about all extension code being available to everyone, but as you surely know a lot of companies try to minify/make their code more complex so that you could uncover what it does only after a lot of analysis and wasted time. By being completely open source, on the other hand, we want to encourage developers and security researchers like yourself to be able to scour the code, find any threats and report them (hopefully in private so black-hat hackers can't exploit them while we're fixing them. Which is one of the main reasons why the scraping endpoint is separate and with a different name than Mellowtel).

Opt-in Enforcement

Claim: "[...] but that is functionally optional as there are no checks to determine if a real user knows what they are approving or to determine if the developer just opts all users in on their behalf"

Response: That's a valid concern, thanks for bringing it up. We do have a page where users can go and see if they are opted-in or have been opted in without their knowledge from the developer: mellow.tel/user-control

But you are right and we should do more. We have started enforcing the opt-in policy from today (by simply checking each integration and not sending requests to those that don't show an opt-in) and will be doubling down on that in the coming days. Each new websocket request from an unknown integration will be quarantined and we won't allow requests to go through until we have controlled the integration is compliant and is asking users to opt-in + is leaving an opt-out option clearly visible. We will also start enforcing routine checks on our Mellowtel integrations to create a transparent environment.

User Interface Clarity (idleforest)

Claim: "After installing 'Idle forest,' it asks the user if they would like to 'Start Planting' as the opt-in to MellowTel."

Response: You're right, the button could be more explicit but I think in this case it might be just a bit justified considering the whole website + extension listing + explainer video and product talks about bandwidth sharing as a way of planting trees ("The browser extension that turns your unused bandwidth into a force for reforestation" -