Google Killing Chrome Extensions with 1 Week Publishing Delays | Hacker News Reader

Google Killing Chrome Extensions with 1 Week Publishing Delays

getpolarized.io

34 pointsgetpolarized42 comments

Given how much malware the Chrome Web Store pushes, and how sensitive of data extensions have access to, actually taking the time to properly review updates is absolutely warranted.

For a typo? Did you read the post?

If I update the text or change a typo they take a week to release the update. During this time I can't release another version of my app.

They don't know you only fixed a typo until they've had time to review it

They don't do a check of the changes in some automated manner? Is that tooling not available for extensions?

Yes they do. I'm not actually releasing code. This is just the images and text associated with the store. Not the actual app

Improve your QA process and you will not be waylaid by something as simple as a typo.

Hopefully there'd be an option to roll back to some previously approved/released version. So your users may have to wait longer for the exciting new functionality, but at least they won't be screwed.

Exactly. There should be a proper workflow with reversion if needed.

The typo case is certainly unfortunate. This policy changes does present new challenges to product planning and associated marketing, and I sympathize with the short term impact that has on you and others similarly situated. I hope you and others are able to adapt as others who develop for centralized platforms have had to do so.

The week long delay could also be a reflection of how understaffed that team is. Or they haven't yet automated what can be done automatically. It doesn't necessarily mean that the code review is thorough.

The week long delay may well be a mechanism to discourage developers from sending lots of small changes like OP, to lighten the workload.

Limiting rollouts/updates velocity would probably be a good idea too.

We don’t let drug companies sell their products to everyone the second it’s produced. First you test in mice, then 10 people, then 100, then 1000, then, and only then, can you release it to an entire population (roughly speaking).

A "5 line diff" is absolutely enough code to add something malicious.

Why does it take a week to accept/deny that...?

Note that they aren't actually DOING anything in this week.

The Polar extension is literally just sitting waiting for someone to approve it because I updated the images.

They've got a queue to work through. I am sure the queue is prioritized in a way that is not to your advantage (i.e. most popular extensions get reviewed more quickly).

Why don't you suggest your users to switch to a browser that does not force them to use a central repository that's too slow to get your updates? You need to convince them at the same time that there are no benefits lost to the way Chrome Web Store operates.

Presumably they are doing something during that week; namely code reviewing all the patches in front of yours in the queue.

Don't get me wrong. I, too, wish that other developers would drop whatever they're doing on demand to prioritize my immediate needs. I would also prefer that they waive their normal security concerns because, after all, I already know that I am trustworthy. I've got enough self awareness not to publish a blog post about it, though.

They could be applying back pressure on the review queue. I'm going to guess that you'll be doing a lot fewer releases now.

Anyways, I get that the turnaround time stinks.

> Why does it take a week to accept/deny that...?

Because they have to check hundreds of thousands of applications a day, most of which improve stupid things like typos. Having the biggest part of the cake doesn't help either.

While this might be highly burdensome for developers, I much prefer the world where Google reviews even single-line changes to extensions.

You do this by having a "Chrome reviewed" store that gives everyone what they want.

There are a lot pronouns used in this article referring to a "permission". What permission are they referring to? I pushed out an update to a Chrome extension a few days ago and it was live in a matter of hours. Is there some specific permission that triggers this review?

From a comment three days ago: > Right now I'm asking for "all permissions" for our extension as I need to inject a header in an HTTP response for CORS. So we're under auditing for every update.

They seem to be asking for:

      "permissions": [
        "activeTab",
        "fileBrowserHandler",
        "webRequest",
        "webRequestBlocking",
        "webNavigation",
        "<all_urls>",
        "storage",
        "tabs",
        "tabCapture",
        "cookies",
        "http://localhost:8500/rest/v1/capture/trigger",
        "contextMenus",
        "unlimitedStorage",
        "declarativeContent",
        "idle",
        "storage"
    ],

I think <all_urls> is the scary one that lets it read and change all data on any website you visit.

Yeah, that set of permissions is basically handing over all control of the browser. It also isn't just the content of the websites you visit. It gives the extension the ability to read cookies and local storage plus read, modify, and block all web requests. I think it is completely reasonable for Google to give extra scrutiny to an extension requesting these permissions.

While you are, of course, welcome to call upon Google to improve the review speed, there are obvious things you can do on your side as well.

First up: improve the QA process on your extension to avoid having to do 5-line diffs every few days.

In the meantime, you can offer your users to switch to "developer mode" and install the extension manually.

I personally would be against the centralized nature of Chrome extensions world anyway (which, by definition, leads to bottlenecks, for dubious benefits), but at one point Google claimed there were 180,000+ extensions in the web store, and if only 0,1% of those get updated every week, that's 180 extensions to be reviewed every week.

Are the reviews done by humans?

> First up: improve the QA process on your extension to avoid having to do 5-line diffs every few days.

Are you a developer? This is literally the definition of continuous delivery.

Haha, nope, it is not. CD includes testing your changes prior to delivery (it's why it's commonly referred to as CI/CD).

Btw, instead of attempting ad-hominem attacks, perhaps you should stop for a bit and reconsider why you are getting so many down-votes around here.

I already don't like how you constantly push your product on HN, but now you're acting like an entitled asshole to boot. Maybe chill out and don't attack possible users?

Previously-possible users, maybe. After this, I'm guessing uptake from here is lower.

Would it be appropriate to re-architecture your extension, so that only the minimal code necessary is in the actual extension? And put the rest into a progressive web app? The way I think of extensions is similar to a device driver for an OS, a way to add functionality that an app needs that isn't already provided by the base platform.

This way, you only need to push a new extension update whenever you need new api-level functionality, and you have total control over the rest of the user experience (regular HTML/CSS/javascript).

Or would this cause the extension to be rejected by Google, on the grounds that the "api" that it adds would be too open to abuse?

"continuous delivery" != "test in production"

But even if it were, why do you think continuous delivery is the appropriate choice of workflow when you don't actually control the "delivery" part?

Clickbait title, no extensions are "killed".

Between the attitude of the poster and the green-labeled accounts taking their side or talking up the product in question (!), any sympathy I might have had has evaporated.

Perhaps someone else could make this point in a way that would be better-received.

Does anyone else feel that the Chrome Webstore is completely neglected? https://presentio.us/view/c3c537

I think there's a miscommunication here.

When I say typo or image I'm talking about the appstore assets... not the binary.

There's the actual binary you push out to you chrome uses.

Then there is the text and images in the app store. This is NOT part of the app.

IF you fix a typo in the app store description, it causes a one week review.

Even when you didn't actually update the app AT ALL.

The exact same binary - bit for bit.

That's part of the the issue.

The other is that changing a small amount of code shouldn't require a full week to re-audit.

This also appears to be selectively enforced. We have two different extensions with global permissions, but only one requires a 1-week review. For the other we can still push out updates in < 30 minutes.

Welcome to Walled Gardens... we should all read 'Carry On by Bruce Scheiner'

Slightly off-topic, but does anyone use this app as an ebook manager?

I'm looking to switch away from Calibre (which has a cluttered user interface) and if Polar supports common ebook formats it might be worth trying.

Since when are apps allowed hn accounts?

I really hope this gets changed as this currently makes fixing small changes a massive, and wanting to release a feature at the same time on a website and extension means the chrome version must be done a week in advance. This is really killing productivity

This delay seems to be only when requesting specific permissions such the “all url” one. So most extensions shouldn’t need to wait that long.

Reply on news.ycombinator.com