Chrome Web Store: Removal notification for Hover Zoom+

[extesy]

I have just received the following email from Google:

Dear Developer,

Your Google Chrome item "Hover Zoom+" with ID: pccckmaobkjjboncdfnnofkonhgpceea did not comply with our policies and was removed from the Chrome Web Store.

Your item did not comply with the following section of our Program Policies:

"Content Policies"

• We don't allow content that contains nudity, graphic sex acts, or sexually explicit material.
• We also don't allow content that drives traffic to commercial pornography sites.
• Google has a zero-tolerance policy against child pornography.
• If we become aware of content with child pornography, we will report it to the appropriate authorities and delete the Google Accounts of those involved with the distribution.

Once your item complies with Chrome Web Store policies, you may request re-publication in the Chrome Web Store Developer Dashboard. Your item will be reviewed for policy compliance prior to re-publication.

If you have any questions about this email, please respond and the Chrome Web Store Developer Support team will follow up with you.

Important Note:

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.

This may also result in the suspension of related Google services associated with your Google account.

Sincerely,

Chrome Web Store Developer Support

I've submitted the latest version for re-review and I'm also trying to reach out to @dotproto for support.

In the meantime, a few more similar examples of Google's attitude towards open source:

• https://blog.pushbullet.com/2020/05/13/lets-guess-what-google-requires-in-14-days-or-they-kill-our-extension/
• https://github.com/uBlockOrigin/uBlock-issues/issues/745
• https://github.com/dessant/search-by-image/issues/63

[khamseen]

What the actual fuck did I just read? How the hell they link those policies to a reason to disallow HoverZoom is a bit beyond me.

[YellowApple]

My guess (as a random person stumbling upon this by following links from the uBlock Origin account of Google's kafkaesque policy enforcement) is it has to do with the plugins for various arguably-pornographic sites listed in the manifest. In particular, pretty much everything handled by plugins/kink.js (plus probably the ones separately handling ImageFap, FetLife, and probably FurAffinity) is probably in violation.

It's absurd, but unfortunately unsurprising, that Google is so puritanically terrified of what adults do in the privacy of their own computers that it would object to an extension offering any semblance of support for pornographic websites.

[extesy]

@YellowApple That is a very good point, thank you! If re-review fails then I'll try to delete that plugin. However, I still don't see how having that plugin violates any of the listed policies. The extension neither contains porn (unless you classify bad JavaScript as such) nor does it drive traffic to porn sites.

[YellowApple]

I don't think it's the plugin itself per se, but rather the references to known-pornographic domain names in the manifest (and possibly also the plugin's filename). I ain't exactly an expert on these sorts of things, though, so who knows.

nor does it drive traffic to porn sites

I'm sure by some convoluted logic Google considers any explicit support for a website to be "driv[ing] traffic" to it.

Maybe the long-term solution here is to use some kind of userlist-like functionality like what most ad-blockers use? That is: ship with a "safe" list of image replacement rules, and then allow users to download/enable other lists that "may or may not" add support for "naughty" domains. Probably not an easy fix, sure, but probably better for long-term maintainability anyway (since it would generally reduce or eliminate the need for hardcoded support for websites, safe-for-work or otherwise).

[bjornstar]

I also had problems publishing on the Chrome Web Store. I documented everything in public for the 2 months that it took to publish an update of one of my extensions. It actually spans multiple issues, but the final issue is https://github.com/bjornstar/intercept-redirect/issues/15

While it was pending for 2 months, I took the opportunity to publish it on the Mozilla Add-On site as well as the one for Opera. In the end the only productive communication I received was from @dotproto through the Chromium Extensions Google Group.

I hope you get your extension back!

[GrosPoulet]

Damned, yesterday i asked for an update of HZ+ on Chrome webstore, et voilà :(

Goggle webstore probably searches for "offending" keywords in extensions. Some plug-ins "hot" names (pornbot.js, slutcapades.js...) & urls (dungeonsex.com, sexandsubmission.com...) in manifest.json might have triggered it. Plug-ins can be renamed, but for urls that's more complicated. Some obfuscation could help, or maybe using 2 manifests (standard, NSFW)...

What sounds strange is that Imagus extension should run into trouble too, as their file sieve.json (storage for regex) contains NSFW references such as: sex.com, and so on. BTW, the last update of Imagus on Chrome webstore was on April, 16th.

Let us know if we can help.

Le 14/05/2020 à 02:35, Oleg Anashkin a écrit :

@YellowApple https://github.com/YellowApple That is a very good point, thank you! If re-review fails then I'll try to delete that plugin. However, I still don't see how having that plugin violates any of the listed policies. The extension neither contains porn (unless you classify bad JavaScript as such) nor does it drive traffic to porn sites.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/extesy/hoverzoom/issues/512#issuecomment-628317514, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFTQMUL5VKFYTRW274M5IC3RRM4ETANCNFSM4NAFAVPQ.

[Eiion]

Here's an idea: What about publishing the extension without any possibly problematic plug-ins and (for now) we'll add them ourselves via github manually. And in the future there'll be a very basic interface for us to simply specify a folder path for the plugins that we want to add that are located on our local storage?

Apart from that there's always the option to install extensions manually in dev mode. But then releases should be made here on this github page - unfortunately there's none for any older version right now.

[extesy]

Let me try to get any response from Google or @dotproto first. I now understand what could have triggered the takedown, but I don't agree with their logic. If common sense doesn't work then I will be doing workarounds.

[dessant]

@extesy, although this time I have not received a rejection, Search by Image has been under pending review since February. Since then several updates have been released that I can no longer publish on the Chrome Web Store, and the outdated extension has become half-broken on Chrome.

I have pinged @dotproto on GitHub almost two months ago, and more recently I have sent him a DM on Twitter, and also contacted Chrome dev support. I have not received any response, and the extension continues to be in pending review.

I think the time is right to ask ourselves if Google's censorship of open source projects should be challenged in court. Once Google will be compelled to open up Chrome to third-party extension stores, they will no longer have the power to abuse their dominance in the browser ecosystem to dictate which browser extensions are allowed to exist, and which open source projects are worthy to be enjoyed by Chrome users.

[bjornstar]

I see it's back in the Chrome Web Store with the last updated date of May 17, 2020

Did you hear back from them with an explanation or did they just publish it without saying anything?

[extesy]

@bjornstar Thanks for letting me know. I had no idea it's back because I have received absolutely zero communication from Google. Very typical of them: no explanations, no communication.