After 3 Years of Work, Chrome Killed My Extension and Won’t Tell Me Why

4 min readJun 18, 2020


UPDATE: Part II is here.

Imagine you have a small business.

One day, a robot passes you a note saying you are not complying with some part of the governor’s policy. He doesn’t tell you where you’re violating but you have 14 days to come into compliance or you will be exiled. If you submit for a compliance too many times, the robot says, you will be exiled forever.

This is the game of Russian roulette that the Chrome Webstore has forced us to play.

Some are lucky, and eventually pass compliance after good guesswork and hassling, like Pushbullet. Some don’t get lucky and shutdown.

We didn’t get so lucky. We guessed wrong and have been delisted since June 11. Our business is dead and now at the mercy of someone we have no communication with.

Our extension is an accessibility tool that enables people with motor disabilities or injuries to use the browser with their voice, instead of the mouse and keyboard. It’s a honest business with no ads, and no data harvesting — just straightforward free or paying subscribers, a 4.7 star review and 4000 weekly active users.

We have invested 3 years full-time into it.

On May 26, we were notified that it did not comply with the following:

“User Data Privacy”

Your product violates the “Use of Permissions” section of the policy, which requires that you:

* Request access to the narrowest permissions necessary to implement your product’s features or services.

* If more than one permission could be used to implement a feature, you must request those with the least access to data or functionality.

* Don’t attempt to “future proof” your product by requesting a permission that might benefit services or features that have not yet been implemented.

After guessing which permissions they were referring to, we invested late nights in changes, and resubmitted with reduced permissions.

We held our breath and waited.

Before: debugger, notifications, tabs, activeTab, tts, storage, unlimitedStorage, host permission

After: tabs, debugger, notifications, tts, storage, host permission

On June 16 we got a fresh rejection email, but this time it said we were in violation of a different policy. This email sounded promising because it said that our previous accepted version would remain listed on the store, and we would just need to update the description. The problem was, our previous version was rejected for a permissions issue. So our extension remains a 404 on the store.

New rejection:

“Spam and Placement in the Store”

Do not use irrelevant, misleading, or excessive keywords in item descriptions, titles, or metadata.

Please ensure that your item has a description that clearly and directly relates to its functionality.

We thought this was a good sign, that we guessed right with the permissions at least. And this is more important, because reducing permissions further would mean further diminishing the functionality that is critical for our accessibility users.

We didn’t see where there might be keyword abuse, but there were a lot of words since we put our changelog of new features in the description. So we removed the changelog reducing our description by 90%.

New description:

On June 17th we got the same rejection letter as previously about “Spam and Placement in the Store”.

Genuinely confused at this point, we reduced our description even further. Perhaps it’s the mentioning of the specific sites we’ve built functionality for (eg. Gmail, Google Sheets, Reddit, Hacker News) that they don’t like. We have plugins in our extension that give specific functionality to those sites, eg. on Gmail you can say (“compose”, “reply” or “back to inbox”) but perhaps the reviewers aren’t noticing that.

We quickly trim down the description further to this:

This morning, June 18 we wake up to another rejection email from the Chrome Webstore. This time it’s not the “Spam and Placement in the Store” message, but it’s back to the same one we got the first time around, regarding permissions.

How can we be back to square one? We have only changed the description and haven’t uploaded a new package with new permissions. It doesn’t make sense.

We are at a loss here. We have emailed Chrome Webstore Developer Support but have not received a response.

Nobody is telling us what permissions are extraneous for our extension. We have studied each permission carefully and verified that each of them is critical to our functionality.

The emails from the Chrome Team all end with:

Repeated or egregious policy violations in the Chrome Web Store may result in your developer account being suspended or could lead to a ban from using the Chrome Web Store platform.

After 3 years of service bringing better accessibility to Chrome, it’s shocking to get such an inhuman treatment from the faceless Chrome Webstore Developer Support team.

Here are the permissions we use and what we need each one for. We don’t see which ones are unnecessary for our functionality:

The activeTab permission would give us permission to the tab that the user has clicked the extension icon on. This is insufficient for us.
Consider this, the user activates LipSurf by clicking our icon, then says “next tab” to go to the next tab in the window. At this point, the user wouldn’t be able to execute commands without the tabs permission. Because activeTab only gives permission to the tab that the user initially pressed our extension icon on. Hence the less restrictive, tabs permission is necessary.

Needed to type keys via voice (eg. press left, press enter). Firing event listeners on the page doesn’t work in many cases, eg. on Google Sheets or in certain contenteditable divs. Cannot be an optional permission (manifest limitation).

host permission
This one is added automatically because our content-scripts are given permission to run on all pages. We need to inject the content script that interacts with the DOM to give users control — eg. clicking the link, scrolling the page, playing the video etc.

For our users with dyslexia that need to have text read back to them. Cannot be an optional permission (manifest limitation).

Letting users know when LipSurf has been automatically turned off from inactivity, or updated.

Storing user settings and custom plugins.

Continue to Part II