Ipfs-companion: Permanent in-depth review on Chrome Web Store

[lidel]

What happened?

Google makes it more and more difficult to publish powerful extensions such as IPFS Companion.

In preparation for Manifest v3 (https://github.com/ipfs-shipyard/ipfs-companion/issues/666) Chrome Web Store artificially slows down publishing of extensions that request access to certain APIs.

Why we need those APIs?

IPFS Companion uses webRequest APIs to redirect requests for IPFS resources to local gateway and to display menu items for things like copying CIDs/URL or pinning.

We are unable to switch to Manifest v3 (https://github.com/ipfs-shipyard/ipfs-companion/issues/666) because it was not released yet.

What does this mean for IPFS Companion?

Due to this change, both Beta and Stable releases may land days or weeks after official release. Google is slowing down publishing cycle of extensions like ours without providing alternative APIs.

I will look into ways we could mitigate this and post updates in this issue.

[lidel]

Published v2.9.0 (Stable) today to Chrome Web Store, let's see how long it takes Google to review it.

(v2.8.6.855 (Beta) is pending since yesterday)

[lidel]

First data point: v2.9.0 got reviewed and published sometime today. It took 3 days.
(Let's keep this issue open for tracking review time over time)

[lidel]

Submitted v2.9.0.860 (Beta), same warning, pending review :grimacing:

[lidel]

Tried to submit v2.9.0.862 (Beta) but failed:

old interface:

new interface:

I am also unable to cancel review of old version nor bump/replace it with new one.
Beta channel for Chrome is effectively useless if we do releases more often than once a week.

[lidel]

Submitted v2.9.0.881, starting the clock again.

[lidel]

Submitted v2.10.0, v2.9.0.881 still pending review.

[lidel]

• v2.9.0.881: got approved on 19th
  _(once again, after exactly 7 days – hardcoded delay? :thinking: )_

• v2.10.0: still in review (guessing.. 2 more days?) yup, approved on 23th

On the bright side, this is a generic problem, not specific to IPFS Companion.
Everyone using webRequest APIs is on the same boat:

• The Pending Review process is broken: can we please get an update

[lidel]

Submitted a new beta (v2.10.0.887) to Chrome Web Store.

This time, submission process forced us to fill rationale for permissions requested by our extension.
I was unsure what specificity is expected, so used moderate one in every field:

Fingers crossed.

[lidel]

Aaaand we got rejected:

I asked for clarifications on how can we comply.

cc @autonome for visibility

[lidel]

Re-submitted with updated, more detailed list:

Full text below:

Single Purpose Description

Detecting IPFS resources on the web (CID, DNSLink), redirecting them to local IPFS gateway and providing context actions for importing files to IPFS.

activeTab

Ability to get URL of current tab and inject content scripts enabled by the users. Effectively superseded by Host Permission, but listed for interop reasons (we maintain single codebase for Chromium and Firefox).

tabs

"tabs.onActivated" is used to update tab.id used in context actions,
"tabs.create": necessary to create a new tab when recovering from a failed HTTP request to a public gateway or a DNSLink website that is currently offline

webNavigation

"webNavigation.onCommitted" is used for updating actions in context menus (menu items for copying CID of current IPFS resource etc),
"onDOMContentLoaded" is used for injecting content scripts of experiments enabled by the user (eg. linkify one, which makes content paths clickable)

webRequest

Blocking webRequest APIs are necessary for extension to inspect URL of every request to make a decision if it should be redirected to local IPFS gateway. It also handles network failures by detecting them and recovering via IPFS, when possible.

Host Permission

We request "" because IPFS Companion needs to be able to inspect URL of every request to make a decision if it should be redirected to local IPFS gateway. ("activeTab" is not enough, as it won't work for background pages fetching content from IPFS, such as a music player)

Remote Code

No remote code, everything is bundled with the extension, and sources are available at https://github.com/ipfs/ipfs-companion/

[lidel]

Got a generic reply without any specifics:

Dear Developer,

Upon review of your Product, [IPFS Companion (Beta @ 3092cb2) ], with ID: [hjoieblefckbooibpepigmacodalfndh], we find that it does not comply with the Chrome Web Store’s User Data Policy, and it has been removed from the store.

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.

To reinstate your Product, please ensure that your Product requests and uses only those permissions that are necessary to deliver the currently stated product’s features.

If you’d like to re-submit your Product, please modify your Product so that it complies with the Chrome Web Store’s Developer Program Policies, then re-publish it in your Developer Dashboard.

Please reply to this email for questions / clarifications regarding this Product removal.

Thank you for your cooperation,

Google Chrome Web Store team

Constructive advice would be very useful here, but Google do not seem to care about extension developers :-C

We can rewrite rationale for each permission and submit again, but it starts to feel like a futile task without knowing what exactly is "future proofed too much" or which permissions are "redundant" in their opinion.

Update: reached out to @dotproto for help :crossed_fingers:
Update2: got human-readable feedback, will prepare a fix :-)

[lidel]

Submitted a new version (v2.10.0.889) which no loger requests alarms and activeTab permissions. Hopefully it will be enough to pass the review.

[lidel]

So far the publishing delay was around 7 days, due to COVID-19 it will get even worse:

[lidel]

Based on latest stats:

• [x] Beta: v2.10.0.902 (for some reason this was quick, approved under 3 days!)
• [x] Beta: v2.11.0.904 (submitted 2020-04-05, approved 2020-04-06 – 1 day!)
• [x] Stable: v2.11.0 (submitted 2020-04-06, approved 2020-04-08 - 2 days!)

it is safe to say Chrome Web Store updated their logic and some "trusted" / "previously vetted" extensions are now approved MUCH faster.

I'll keep this issue open for another release cycle tho, just to be sure the problem is gone (1-2 days is pretty acceptable, but still slow for releases with a security fix)

[lidel]

Google now wants explanations for more permissions and apis :no_mouth:

Wrote explainers that will be submitted with next release:

• idle
  
  
  
  • We need to read it so we don't update peer count when browser is in idle state.
  
  
• notification
  
  
  
  • We display notifications when IPFS node changes state between online and offline, and when shareable link is copied to clipboard. Notifications can be disabled in Preferences.
  
  
• storage
  
  
  
  • When user opt-ins to running embedded js-ipfs, we need storage for IPFS datastore
  
  
• unlimitedStorage
  
  
  
  • Node identity is stored along the IPFS cache and this ensures node does not hit browser limits and that PeerID and keys are not lost due to browser's crude garbage collection (js-ipfs has its own GC mechanism)
  
  
• contextMenus
  
  
  
  • User can select text, image or video and add it to IPFS via context menu actions.
  
  
• clipboardWrite
  
  
  
  • User can copy a shareable link to files imported to IPFS.
  
  
• webRequest
  
  
  
  • webRequest APIs are necessary for extension to inspect URL of every request to detect IPFS resources on the web. It also handles network failures by detecting them and recovering via IPFS, when possible.
  
  
• webRequestBlocking
  
  
  
  • Blocking webRequest APIs are necessary for extension to inspect URL of every request to make a decision if it should be redirected to local IPFS gateway. It also handles network failures by detecting them and recovering via IPFS, when possible.
  
  

[lidel]

Lo-fi day today, so I submitted v2.11.0.918 to the beta channel.

Interesting fact: even if we unpublish/cancel/abort published version, it is still blocked until the review happens:

This is important caveat to understand: means if we publish a buggy version and unpublish by mistake or in a hurry, it's not easy to restore if in "pending review" state.

[lidel]

Cancelled and resubmitted 2.11.0.923

[lidel]

Submitted v2.12.0 as well. Stable channel has >30k users now:

[lidel]

_the prophecy is true_: we are unable to ship a bugfix release v2.12.1.926 until the previously submitted one is approved:

I really like the amount of whitespace before the OK button.
Really highlighted all my options as a browser extension developer :ok_hand:

[lidel]

It gets better: update to the Stable channel got rejected "because of reasons" (something related to privacy policy, but generic text does not help much):

Note that our privacy policy did not change. Unsure if it is because we've moved location to https://github.com/ipfs-shipyard/ipfs-companion/blob/master/PRIVACY-POLICY.md recently, or maybe they changed the rules since they've read our privacy policy the last time in February (https://github.com/ipfs-shipyard/ipfs-companion/issues/808#issuecomment-588314544).

I've reached out to @dotproto asking for more details.

[lidel]

2.12.1.926 got approved, so I assume privacy policy is ok – re-submitted v2.12.1 with the same policy/links

[lidel]

2.12.1 got accepted (under 2 days, good sign)

[lidel]

We might get hit in a crossfire in August, Google plans to double down on "spam extensions":
https://blog.chromium.org/2020/04/keeping-spam-off-chrome-web-store.html
(so far we had problems nearly every time they changed policy at Chrome Web Store)

[lidel]

Submitted 2.13.0 to stable channel

[lidel]

v2.13.0 got approved ~3 hours ago (this time it took ~10h, interesting!)

[lidel]

Submitted v2.13.0.939 to Beta channel ... and approved within 1 day.

[lidel]

Submitted v2.13.1 to Stable channel... approved within 12h(!)

[lidel]

Submitted v2.13.1.950 approved <2days

[lidel]

Submitted v2.14.0 approved in 1 day

[lidel]

Submitted v2.14.0.959

[lidel]

v2.14.0.959 got rejected because of invalid privacy policy link:

I checked and for some reason the privacy policy had space in front of the URL:

Note that (afaik) we did not change it recently, and both Beta and Stable got previously approved with the same value. This is yet another example of Chrome Web Store review process being severely flawed and brittle.

I've removed the space from URL and resubmitted, but we may get rejected again due to newly added(?) rules:

Right now privacy policy is in both description and the dedicated field (pictured above). The URL at https://ipfs.io/companion-privacy is a redirect to https://github.com/ipfs-shipyard/ipfs-companion/blob/master/PRIVACY-POLICY.md

Just to be very clear: none of this was a problem the last time we published with the same privacy policy URL (both Stable and Beta :exclamation:) :expressionless:

Provided the above feedback to Google.

[lidel]

v2.14.0.959 got approved after 2 days without any explanation why it was rejected in the first place :expressionless:

Assuming it was that whitespace character + some new validation rules Google added since our last release.

[lidel]

Got a reply from Google, turns out it was not our fault :hugs:

[lidel]

Submitted v2.14.0.966 (Beta) – approved within 1 day :partying_face:

[lidel]

Submitted v2.15.0 – approved the same day :exploding_head: :heart:

[lidel]

Submitted v2.15.0.972 (Beta) – updated November 2, 2020

[lidel]

Ok, last test cycle, if the next stable version gets approved within 1-2 days I'll close this issue :crossed_fingers:

Submitted v2.15.0.977 (Beta)

[lidel]

Submitted v2.16 but may be delayed due to https://github.com/ipfs-shipyard/ipfs-companion/issues/942

Update: nope, it was accepted after ~8h

[lidel]

Review time has been within 1-2 days, and recently under 1 day (8h) so I'm closing this as we no longer seem to be impacted :+1:

(Will reopen if review time becomes a problem again)