Avoiding Chrome Web Store Removal

[InboxSDK]

There have been a few cases of people having their extensions removed from the Chrome Web Store due to executing remote code. This has happened to us here at Streak and we have some recommendations on how to avoid this happening to you.

From what we know extension flagging is a 2-step system. First system is automated which then sends the the extension to be manually reviewed. This is a good thing because you can demonstrate to the manual reviewer that you are a legitimate business and the inboxsdk is a legitimate library.

The way we do it here at Streak is to include a comment in our main app.js file that is included in the extension that explains to the reviewer who we are, why we're legitimate, why the SDK is legitimate. We also talk about why we load the javascript remotely - specifically to increase our iteration time since we release fixes and features many times a day.

Here's a gist showing both comments that you can use as a template https://gist.github.com/omarstreak/a0981ded176e65f9e18c7bd80241d6ac

This is obviously an important issue to us and all users of the InboxSDK library so if you have any other thoughts or want to share your own experience please do.

Thanks!

[Aleem Mawani]

We should add that we are actively reaching out to the chrome teams to ensure they are aware of the SDK and exclude it from the review process.

[Alexey Panteleev]

Yes, yesterday they prevented us from updating out package and then later on they took down our listing.

I hope we'll be able to clarify things during the manual review.

On Thursday, June 30, 2016 at 12:50:26 PM UTC-7, InboxSDK wrote:

[Aleem Mawani]

Alexey - what is the name of your app? Even better, do you have the chrome webstore id?

--
You received this message because you are subscribed to the Google Groups "InboxSDK" group.
To unsubscribe from this group and stop receiving emails from it, send an email to inboxsdk+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/inboxsdk/1b9a01e1-30a3-4c0f-aea6-b1dccdf06a7b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Alexey Panteleev]

Id: adelbnepkcbhmnmdcohmpgflfghiidop

But the listing is down now. We’ve just published our beta 0.0.0.2 a couple of weeks ago. Good thing this happened now while we have just a few beta users.

-Alexey

[Aleem Mawani]

What was the name?

[Alexey Panteleev]

Gmail plugin for Salesforce users (beta)
Yoxel (beta)

[Alexey Panteleev]

Google activated our extension again :) Great!

https://chrome.google.com/webstore/detail/gmail-plugin-for-salesfor/adelbnepkcbhmnmdcohmpgflfghiidop

Not sure what has helped exactly but I followed the suggestion to include elaborate comments into our content script and resubmitted the package earlier today.

-A

[Peter Hartree]

Hi folks,

Do you have any updates on the CWS removal risk issue?

On the InboxSDK Quick Start page, you recommend loading app logic remotely. You write:

For high usage or frequently updated apps, you may not want to wait for the chrome extension system to update all your users extensions (which can sometimes take days or weeks) to the latest version. To handle this scenario, you can host your actual application code on your own server (or somewhere convenient) and remotely load it when needed. This allows you to make updates to it and your users will simply need to refresh Gmail to get the changes.

The upsides of this approach are very attractive, but this is clearly somewhat in tension with the CWS Developer Program Policy, which states:

Where possible, make as much of your code visible in the package as you can. If some of your app's logic is hidden and it appears to be suspicious, we may remove it.

Two questions:

1. In light of the CWS removal risk, would you still recommend remote loading to the author of a brand new extension?
   
   
2. Do you have any other insights on the kind of trust signals the CWS review team are looking for? The comment example you gave is helpful. I'm just an individual working on an extension as a side project, so I was thinking my own comment should perhaps just include my real name and physical address as well as links to my personal website and social profiles.

All the best,

Peter

[Omar Ismail]

Hi Peter, I think putting your physical address is probably overboard (unless it's a business address), but links to your social profiles and personal websites will be helpful I'm sure.

And yes, still recommend remote loading even for new extensions. There are hundreds of extensions, many of which are quite popular, that use the InboxSDK so each new extension makes it better for everybody - strength in numbers and all of that.

ᐧ

Omar

--

You received this message because you are subscribed to the Google Groups "InboxSDK" group.

To unsubscribe from this group and stop receiving emails from it, send an email to inboxsdk+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/inboxsdk/742321be-1ef6-4585-b583-daa0cc4bfc00%40googlegroups.com.

[Aleem Mawani]

To follow on, we are in active discussions with the chrome team a d are trying to figure out a solution that works for all parties. In the meantime, if you have any issues, let us know here and we can pass it on to the right ppl.

To unsubscribe from this group and stop receiving emails from it, send an email to inboxsdk+u...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/inboxsdk/742321be-1ef6-4585-b583-daa0cc4bfc00%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "InboxSDK" group.

To unsubscribe from this group and stop receiving emails from it, send an email to inboxsdk+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/inboxsdk/CA%2BjPuQ_4N%2Bp3c29cwYME1%3D4LD9ULUTbpOW_%2BicMdRv8LeNwqOQ%40mail.gmail.com.

[Jim -]

Looks like I got hit now

violates the section of the Developer Program Policy relating to Malicious Products as its obfuscating a part of code. Per our policies, where possible, make as much of your code visible in the package as you can. If some of your app's logic is hidden and it appears to be suspicious, we may remove it."

To have your item reinstated, please make any necessary changes to ensure:

• All of the files and code are included in the item’s package.
• All code inside the package is human readable (no obfuscated or minified code).
• Avoid requesting or executing remotely hosted code (including by referencing remote javascript files or executing code obtained by XHR requests).

Once your item complies with Chrome Web Store policies, you may request re-publication in your developer dashboard. Your item will be manually reviewed for policy compliance which typically takes a few business days, prior to re-publication. If you have any questions about this item’s removal, you may reply to this email 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. This may also result in the suspension of related Google services associated with your Google account.

Thank you for your cooperation,

Google Chrome Web Store team

[Aleem Mawani]

We've recently spoken with the CWS team about this and the issue isn't the remote loading of the SDK but rather the remote loading of your application script. Remote loading is discouraged unless your domain is "trusted" by google. 

My suggestions are as follows:

- send me your extension ID

- reply to the email sent by the chrome webstore team explaining why you'd like to remotely load your app

- document your remotely loaded script at the top to explain why you're doing it and any links demonstrating the trustowrthiness of your company/domain

--

You received this message because you are subscribed to the Google Groups "InboxSDK" group.
To unsubscribe from this group and stop receiving emails from it, send an email to inboxsdk+u...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/inboxsdk/bf5116c1-3489-433d-a42a-3294469beb56%40googlegroups.com.

[se...@amitree.com]

Bumping this thread to try to gain some clarity around Chrome Web Store policies and InboxSDK.

In the past (as recently as June 2017) we have had our extension removed from the Chrome Web Store for both having minified code and for fetching code over the network, so we have instituted strict policies against doing either of those things in our extension- we even built some pre-commit hooks to prevent it from happening.

Now we are looking at InboxSDK and while it appears to provide a lot of value for us, it seems like a very risky dependency to adopt given our experience with Chrome Web Store removal and the importance of our extension to our business. At the same time, it seems like it could not possibly be as risky as it seems given the number of extensions that do use it and do not get banned from the CWS.

Overall this seems to me like an unfortunate consequence of the opacity of the CWS review process. I know that no one here can provide any guarantees around the CWS review process, but I wonder if anyone could provide a little more clarity or even just some anecdata around the process and how risky it is to use InboxSDK.

Thanks,

Sean

[Aleem Mawani]

We've worked with the chrome web store team to make sure the inboxsdk is whitelisted for everyone to remote load. If you have any issues from the web store team regarding the sdk please let me know. 

To view this discussion on the web visit https://groups.google.com/d/msgid/inboxsdk/6e883602-6232-4bbc-9106-99644b3447ae%40googlegroups.com.

[David Rees]

Is there an option to just have InboxSDK local? I realize that means more extension updates, but I feel much more comfortable getting to review all the code in my extension. And for my company's internal extensions that is a requirement (since the any remote code has access to corporate data). Thx!

[Aleem Mawani]

Unfortunately we don't offer a local version. This is primarily to ensure compatibility across extensions (the SDK ensures cross extension compatibility so long as they are running the same version) as well as being able to instantly push out updates for frequent gmail changes.

ᐧ

To view this discussion on the web visit https://groups.google.com/d/msgid/inboxsdk/3ebbf082-0670-48b7-9b3a-d787aefb2f28%40googlegroups.com.

[Maximilian Paju]

Have InboxSDK developers considered the content of the blogpost Chrome released in October last year, concerning obfuscated code or externally loaded code?

https://blog.chromium.org/2018/10/trustworthy-chrome-extensions-by-default.html

[Matúš Balaščák]

Hi,

I know it has nothing to do with this thread but I'm not able to create appID (https://groups.google.com/forum/#!topic/inboxsdk/FzajhtJLbvs). The response from the server is always 503. Can you give me an explanation? There is no way to get support other way.