amplitude
Remote Script Loading in `@amplitude/analytics-browser` Violates Chrome Extension Manifest V3 Policies
Issue Summary
The latest version of @amplitude/analytics-browser includes a reference to a remotely hosted script (https://cdn.amplitude.com/libs/visual-tagging-selector-1.0.0-alpha.js.gz). This script is loaded during the operation of the library, which conflicts with Google Chrome Extension Manifest V3 policies. These policies prohibit the inclusion of any remotely hosted code to ensure the security and integrity of Chrome Extensions.
Steps to Reproduce
- Install the latest version of
@amplitude/analytics-browser. - Integrate it into a Chrome Extension project using Manifest V3.
- Submit the extension to the Chrome Web Store.
- The submission will fail due to the inclusion of remotely hosted code.
Expected Behavior
The @amplitude/analytics-browser library should not load any remote scripts to comply with Chrome Extension Manifest V3 policies. Instead, all required scripts should be included within the extension package.
Current Workaround
Downgrading to version 2.9.2 of @amplitude/analytics-browser resolves the issue as this version does not include the problematic remote script.
Request
Please consider removing the remote script loading in future versions of @amplitude/analytics-browser or providing an option to disable this behavior. This change is essential for users who need to comply with Chrome Extension security requirements.
Thank you for your attention to this matter.
Hi, thanks for choosing Amplitude. We are working on a fix for it. For a workaround, please use a version <= 2.9.3.
Hi @Mercy811 - there have been 4 months of improvements to @amplitude/analytics-browser since this guidance was offered. I just had an extension rejected for the reasons mentioned above on the latest version (2.11.11).
If there is no fix imminent, can you recommend some workaround that would allow the current version of the package to be used that doesn't break core functionality?
I'm going to try including the script in my bundle and modifying the extension build output to refer to it, rather than loading from your CDN, although there's quite a bit of code in that resource and it would increase the size of my relatively lean extension by 50%.
But generally this isn't sustainable, as I'll need to pin my version of the @amplitude/analytics-browser SDK, hope Amplitude isn't changing the script on the CDN behind the scenes, and repeat this process every time I want to bump the SDK to the newest version.
It seems like ideally this would be tree-shaken out by rewiring the code to only include it when necessary. Another possibility might be to allow imports of amplitude functions from a different package endpoint, ex:
import { track } from '@amplitude/analytics-browser/web-extension'
This is an approach the Firebase JS SDK team took recently.
Another plus one to this issue from me. I just hit the same rejection. Would love to see a solution from Amplitude for this.
I can confirm that my approach mentioned above clears the approval hurdle at Google so I can use the latest version of the Amplitude JS SDK. As far as whether it has an operational impact on Amplitude functionality in production that will take some time to determine.
This URL is included by Amplitude's autocapture-browser plugin. If that plugin isn't used/needed, a temporary solution is to strip out the URL during the extension build. Not awesome, but does pass Chrome Store inspection.
Example of what we did using vite:
import replace from "@rollup/plugin-replace";
// add this to the plugins array
replace({
"https://cdn.amplitude.com/libs/visual-tagging-selector-1.0.0-alpha.js.gz": "",
preventAssignment: true,
})
+1 , is there any other official way from amplitude ? I'm not sure what is this visual-tagging-selector-1.0.0-alpha.js.gz really used for, and is there any harm removing it?
Hi folks, we're planning to fix this in Sept (cc: @Dogfalo). Currently, the workaround is to strip out the URL like this comment.
@arikark Yes it's on our team roadmap for this quarter. In the meantime please use the workaround.
@vladutjs It's still on track for this quarter, but don't have any other updates for you right now. If this is affecting you, please downgrade to <= 2.9.3 for now