Chrome Rejection Received with Violation Code: Blue Argon

[Jon Pedersen]

We have received the following email message several times now:

Hi there,

We regret to inform you that the most recent submission of your item was rejected.

Please find the details below.
Violation(s):
Violation reference ID: Blue Argon
Technical Requirements - Additional Requirements for Manifest V3:
Violation: Including remotely hosted code in a Manifest V3 item.
How to rectify: Ensure that all logic related to the extensions operation is included in the extension package.
Relevant section of the program policy:
Extensions using Manifest V3 must meet additional requirements related to the extension's code. Specifically, the full functionality of an extension must be easily discernible from its submitted code. (learn more).

What we have done so far:

• As per some of the issues here, we checked our firebase implementation and did the suggested solutions in seen in other created posts online - as we see that this is an increased issue for many Chrome extensions.
  
• And thereafter attempted numerous updated uploads - all of which have been rejected.
• Submitted several support tickets (e.g., 8-6155000035252)

Our Chrome Extension ID: cbnaodkpfinfiipjblikofhlhlcickei

However, it is also very challenging with a generic rejection message, and as the issue seemingly still persists, we hope you can help us further identify and pinpoint the issue. We have been unable to provide updates for considerable time now to 500,000+ Chrome Extension users. 

Thank you.

[Patrick Kettner]

Hi Jon

Really sorry to hear you're having a problem. As a general reference, the errors are all listed on this page, where you may be able to find a bit more information. Based on the text of the ticket you submitted earlier today (8-6155000035252), I can see that you already know that there is an issue with Firebase. There is an ongoing thread on firebase's github with a number of steps you can take to fix the problem. Looking at the compressed source of your extension, it looks like you are including the entirety of firebase auth, which at the present time will result in a rejection. The firebase team is working on a fix, in the meantime, using a build step with treeshaking should take care of all of the issues you are encountering. If you are still having problems after following the steps on that thread, please do feel free to reach out, i'd be happy to help if you are able to share the source of your project.

--
You received this message because you are subscribed to the Google Groups "Chromium Extensions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-extens...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/22fe9b1d-acdf-4ce2-ba4a-95e8e36f4f07n%40chromium.org.

[KS]

Hi Patrick,

I found your comment above helpful to diagnose our rejected package submission. Thank you very much.

Because we're using an older version of the firebase API (v9.9.1), it appears we cannot use the tree-shaking solution to the problem. Couple questions:

1. A workaround on the github thread is to replace the two mentioned .js links, in compiled code, with empty strings. Do you see any problem with this workaround?  Eventually, we'll upgrade to the firebase modular SDK and incorporate tree-shaking, but in order to release our extension urgently, we're considering the workaround. 

2. We published an earlier version which has the same firebase .js links in compiled code, but that package submission was successful. Would you know what might have triggered a rejection this time around?

Kind regards,

Sunny K

[KS]

Patrick, for more context on my post above, here's our Google support ticket id: 7-9348000035512

[Uladzimir Yankovich]

Same problem. It is impossible to respond to this deviation without additional inputs.

[Uladzimir Yankovich]

Problem found: Firebase links to https://apis.google.com/js/api.js 😤. It remains to find a solution.

I checked our builds, and these links have been there for several months.

[Oliver Dunk]

Hi Uladzimir,

Thanks for sharing your experience.

I'm hopeful we might be able to add more information in the rejection email in the future, but I don't have anything to share at the moment.

Thanks,

Oliver Dunk | DevRel, Chrome Extensions | https://developer.chrome.com/ | London, GB

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/82993ee9-cdd5-4931-954a-873a27eadc03n%40chromium.org.

[Patrick Kettner]

@Sunny

> Because we're using an older version of the firebase API (v9.9.1), it appears we cannot use the tree-shaking solution to the problem.

For my own edification, is there a reason you aren't able to move to a newer version? Was there any missing functionality, or just haven't had time to do it yet?

> 1. A workaround on the github thread is to replace the two mentioned .js links, in compiled code, with empty strings. Do you see any problem with this workaround?  ...  in order to release our extension urgently, we're considering the workaround. 

I responded to the concept in that thread a couple of places, but in general I don't like it but it is acceptable. The issues are around maintainability.  There is no problem with removing the strings as far as policy goes, as long as the code that still exists continues to work without errors. If you are needing to use the technique, then I would suggest using patch-package rather than editing the files directly, if only to make it slightly more maintainable until you migrate

> 2. We published an earlier version which has the same firebase .js links in compiled code, but that package submission was successful. Would you know what might have triggered a rejection this time around?

I am really sorry to hear that, it should not have been approved. I am working with the review folks to make this a less painful experience in the future. If you have any problems regarding it, please do not hesitate to contact me directly for support.

@Uladzimir

> Same problem. It is impossible to respond to this deviation without additional inputs.

Can you elaborate on what you mean? What input do you need?

> Problem found: Firebase links to https://apis.google.com/js/api.js 😤. It remains to find a solution.

I am really sorry :( - In the above listed thread, there are a number of workarounds being posted. Are you having an issue with any of them?

> I checked our builds, and these links have been there for several months.

See my last note to Sunny, but tl;dr is sorry that it happened, but if it was approved before then that was a mistake.

As always, if there is anything I can do to help don't hesitate to reach out.

[Uladzimir Yankovich]

@Oliver, @Patrick, no problem. Especially to you personally. Thanks for staying in touch. This gives a feeling of confidence and control of the situation 🙏.

Of course, I’m sorry that this situation surprised us, but it’s life. I’ve already sent the new release for re-moderation. Hopefully, an update will be posted soon.

Let me explain what I mean when talking about the lack of input from the support service. I believe that it would be valuable in the message that the release is rejected to receive a notification about which JS file the reference to the remote code was found in and which particular remote file was called.

In our case, it would be: worker.js and https://apis.google.com/js/api.js. This would have saved us a lot of nerves and an hour of expensive time.

[Uladzimir Yankovich]

By the way, the only solution we could use was to remove these lines from the compiled package. This is a bad and unreliable solution.

I also know from Patrick that a stable solution will only appear for a few months. Is there a chance to solve the problem on the CWS team's side? I mean, allow loading of remote Firebase files—something like a white list.

[Patrick Kettner]

Hi Uladzimir

Thanks for explaining - Oliver and I met with folks from the review team today to discuss this very issue. We are working to improve the experience as much as possible, and hope to be able to share some updates about it soon.

> Is there a chance to solve the problem on the CWS team's side? I mean, allow loading of remote Firebase files—something like a white list.

Nothing is going to be allow listed. Out of curiosity, are you losing out on functionality? Once you have updated the files/build process, is there an outstanding problem (other than the maintenance burden)?

[Uladzimir Yankovich]

Fortunately, so far, only time has been spent on the release process.

But the feeling of stress that we edit by hand with the code of the library that serves our database and authorization is still with me 😂.

I'll be waiting for news!

--

Uladzimir Yankovich,

Founder @ Manganum (manganum.app).

[Pawel Kacprzak]

I pointed out this exact issue (api.js from Firebase) a year ago, and posted a temporary solution to remove it from the build: https://groups.google.com/a/chromium.org/g/chromium-extensions/c/xQmZLc8cu6Q/m/K29jlJIoBQAJ

Before updating to MV3 I wanted to be sure that no external code is ever linked even if it is not used at runtime, so I simply removed it. Never faced any problem with rejections since. 

[Uladzimir Yankovich]

🙏

[Patrick Kettner]

If you edit the files (rather than them being impacted via treeshaking), I'd really suggest using something like patch-package if you aren't already.

Hope to share good news soon

[KS]

@Patrick thanks for the detailed response.

> For my own edification, is there a reason you aren't able to move to a newer version? Was there any missing functionality, or just haven't had time to do it yet?

We just haven't had time to do it yet. 

>  If you are needing to use the technique, then I would suggest using patch-package rather than editing the files directly, if only to make it slightly more maintainable until you migrate

Thanks, will look into using patch-package. 

> I am really sorry to hear that, it should not have been approved. I am working with the review folks to make this a less painful experience in the future. If you have any problems regarding it, please do not hesitate to contact me directly for support.

We removed the offending links from our package and submitted to the Chrome store. It's been in 'review pending' for close to a week now, the longest it's ever taken. Would you know the reason why a package review is taking this long?

Thanks again for your advice.

[Patrick Kettner]

Hello again!

Looks like it was approved after 4 days, a bit after you sent your message - let me know if you have any other questions!

patrick