Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Permanent in-depth review on Chrome Web Store #808

Closed
lidel opened this issue Oct 30, 2019 · 39 comments
Closed

Permanent in-depth review on Chrome Web Store #808

lidel opened this issue Oct 30, 2019 · 39 comments
Labels
area/chromium Issues related to Chromium-based browsers kind/maintenance Work required to avoid breaking changes or harm to project's status quo need/maintainers-input Needs input from the current maintainer(s)

Comments

@lidel
Copy link
Member

lidel commented Oct 30, 2019 •
edited
Loading

What happened?

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

In preparation for Manifest v3 (#666) Chrome Web Store artificially slows down publishing of extensions that request access to certain APIs.

Screenshot_2019-10-30 IPFS Companion (Beta be25e31) - Edit Item

Screenshot_2019-10-30 IPFS Companion (Beta be25e31)

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 (#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 lidel added kind/maintenance Work required to avoid breaking changes or harm to project's status quo area/chromium Issues related to Chromium-based browsers labels Oct 30, 2019
This was referenced Oct 30, 2019
Closed
Closed
@lidel
Copy link
Member Author

lidel commented Oct 31, 2019 •
edited
Loading

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)

Screenshot_2019-10-31 Developer Dashboard - Chrome Web Store

@lidel
Copy link
Member Author

lidel commented Nov 3, 2019

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
Copy link
Member Author

lidel commented Nov 12, 2019 •
edited
Loading

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

@lidel
Copy link
Member Author

lidel commented Nov 14, 2019 •
edited
Loading

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

old interface:
2019-11-14--20-09-56
new interface:
2019-11-14--20-11-47

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.

This was referenced Dec 6, 2019
Merged
Closed
@lidel
Copy link
Member Author

lidel commented Dec 12, 2019 •
edited
Loading

Submitted v2.9.0.881, starting the clock again.

@lidel
Copy link
Member Author

lidel commented Dec 16, 2019

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

@lidel
Copy link
Member Author

lidel commented Dec 21, 2019 •
edited
Loading

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

  • 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:

@ghost ghost mentioned this issue Jan 7, 2020
Closed
@lidel
Copy link
Member Author

lidel commented Feb 14, 2020 •
edited
Loading

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:

new-developer-dashboard-2020-02-14--23-54-18

Fingers crossed.

@lidel
Copy link
Member Author

lidel commented Feb 19, 2020 •
edited
Loading

Aaaand we got rejected:

Screenshot_2020-02-19 Gmail - Chrome Web Store Removal notification for IPFS Companion (Beta 3092cb2)

I asked for clarifications on how can we comply.

cc @autonome for visibility

@lidel
Copy link
Member Author

lidel commented Feb 19, 2020

Re-submitted with updated, more detailed list:

Screenshot_2020-02-19 Privacy

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 "<all_urls>" 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
Copy link
Member Author

lidel commented Feb 24, 2020 •
edited
Loading

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 🤞
Update2: got human-readable feedback, will prepare a fix :-)

lidel added a commit that referenced this issue Feb 24, 2020
@lidel
fix: remove redundant/unused permissions
dfce797 
Addressing review:
#808 (comment)

(We no longer use alarms API and activeTab is superseded by  <all_urls>)
@lidel lidel mentioned this issue Feb 24, 2020
Merged
lidel added a commit that referenced this issue Feb 24, 2020
@lidel
fix: remove redundant/unused permissions (#849)
c0442cd 
Addressing review:
#808 (comment)

(We no longer use alarms API and activeTab is superseded by  <all_urls>)
@lidel
Copy link
Member Author

lidel commented Feb 24, 2020 •
edited
Loading

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 lidel mentioned this issue Mar 5, 2020
Closed
@lidel
Copy link
Member Author

lidel commented Mar 30, 2020

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

covid

@lidel
Copy link
Member Author

lidel commented Apr 6, 2020 •
edited
Loading

Based on latest stats:

  • Beta: v2.10.0.902 (for some reason this was quick, approved under 3 days!)
  • Beta: v2.11.0.904 (submitted 2020-04-05, approved 2020-04-06 – 1 day!)
  • 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 lidel added the need/maintainers-input Needs input from the current maintainer(s) label Apr 6, 2020
@lidel
Copy link
Member Author

lidel commented May 13, 2020

Google now wants explanations for more permissions and apis 😶

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
Copy link
Member Author

lidel commented May 15, 2020 •
edited
Loading

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:

Screenshot_2020-05-15 Package Information

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
Copy link
Member Author

lidel commented May 19, 2020

Cancelled and resubmitted 2.11.0.923

@lidel
Copy link
Member Author

lidel commented May 20, 2020 •
edited
Loading

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

Screenshot_2020-05-20 Developer Dashboard

@lidel
Copy link
Member Author

lidel commented May 20, 2020

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

Screenshot_2020-05-20 Store Listing

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

@lidel
Copy link
Member Author

lidel commented May 21, 2020 •
edited
Loading

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):

2020-05-21--14-40-14

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 (#808 (comment)).

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

@lidel
Copy link
Member Author

lidel commented May 23, 2020

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

@lidel
Copy link
Member Author

lidel commented May 25, 2020

2.12.1 got accepted (under 2 days, good sign)

@lidel
Copy link
Member Author

lidel commented May 27, 2020

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
Copy link
Member Author

lidel commented Jun 4, 2020 •
edited
Loading

Submitted 2.13.0 to stable channel

@lidel
Copy link
Member Author

lidel commented Jun 5, 2020 •
edited
Loading

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

@lidel
Copy link
Member Author

lidel commented Jun 13, 2020 •
edited
Loading

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

@lidel
Copy link
Member Author

lidel commented Jun 15, 2020 •
edited
Loading

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

@lidel
Copy link
Member Author

lidel commented Jul 9, 2020 •
edited
Loading

Submitted v2.13.1.950 approved <2days

@lidel
Copy link
Member Author

lidel commented Jul 10, 2020 •
edited
Loading

Submitted v2.14.0 approved in 1 day

@lidel
Copy link
Member Author

lidel commented Jul 21, 2020

Submitted v2.14.0.959

@lidel
Copy link
Member Author

lidel commented Jul 22, 2020

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

2020-07-22_11-51

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

2020-07-22_11-53

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:

2020-07-22_11-58

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 ❗) 😑

Provided the above feedback to Google.

@lidel
Copy link
Member Author

lidel commented Jul 24, 2020

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

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

@lidel
Copy link
Member Author

lidel commented Jul 25, 2020 •
edited
Loading

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

2020-07-25--18-28-37

@lidel
Copy link
Member Author

lidel commented Oct 16, 2020 •
edited
Loading

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

@lidel
Copy link
Member Author

lidel commented Oct 20, 2020 •
edited
Loading

Submitted v2.15.0 – approved the same day 🤯 ❤️

@lidel
Copy link
Member Author

lidel commented Oct 29, 2020 •
edited
Loading

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

@lidel
Copy link
Member Author

lidel commented Nov 9, 2020

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

Submitted v2.15.0.977 (Beta)

@lidel
Copy link
Member Author

lidel commented Nov 18, 2020 •
edited
Loading

Submitted v2.16 but may be delayed due to #942

Update: nope, it was accepted after ~8h

@lidel
Copy link
Member Author

lidel commented Nov 19, 2020

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 👍

(Will reopen if review time becomes a problem again)

@lidel lidel closed this as completed Nov 19, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
area/chromium Issues related to Chromium-based browsers kind/maintenance Work required to avoid breaking changes or harm to project's status quo need/maintainers-input Needs input from the current maintainer(s)
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@lidel