Just realized that the file I sent in the chat is not correct, it is in sitepress-multilingual-cms/classes/menu/ams-ate-console/AbstractConsoleSection.php return $this->endpoints->get_base_url( WPML_TM_ATE_AMS_Endpoints::SERVICE_AMS ) . 'https://cdn.wpml.org/mini_app/dashboard.js'; and return $this->endpoints->get_base_url( WPML_TM_ATE_AMS_Endpoints::SERVICE_AMS ) . 'https://cdn.wpml.org/mini_app/run.js';
Thanks again. I was able to check the file and verify that's indeed external. I've escalated that to get a second opinion and will keep you updated. It might take a few days to receive feedback on that.
I received feedback from our devs. I'll summarize it based on each keypoint:
1. WordPress Guidelines: the WordPress.org guideline you linked applies specifically to plugins hosted and distributed through the official Plugin Directory. Since WPML is distributed independently, that particular rule does not apply rigorously to the WPML plugin.
The script in question — hidden link, is part of WPML’s own service infrastructure (AMS/ATE) and is loaded from our controlled domain. It is not a third-party library or an ad/analytics tracker. Because of this:
2. Privacy: that script does not collect or transmit user data beyond what is necessary to operate WPML services. For employment law or GDPR compliance, the important point is that the asset comes from WPML’s own service endpoint, not from an unrelated third party.
3. Security: Loading assets from WPML’s own domain does not introduce a new risk by itself. As with any remote resource, the main consideration is whether the domain is under our control (it is) and whether connections are encrypted (they are, via HTTPS). Unless the site already has another vulnerability that allows malicious injection, this is not a security concern.
I hope this address your concerns, and explains why the script is loaded that way. If you have noted any other script that you thinks falls outside what's been described here, please let me know.
>The script in question — hidden link, is part of WPML’s own service infrastructure (AMS/ATE) and is loaded from our controlled domain. It is not a third-party library or an ad/analytics tracker.
And why can it not be bundled/shipped together with the plugin?
Unless you dynamically change the content of this script - which would make it insecure - there's no technical reason to not bundle it with the plugin.
2) afaik this is wrong, especially when the user is located in the EU but WPML's server is located in the US
3)
>3. Security: Loading assets from WPML’s own domain does not introduce a new risk by itself.
This is totally wrong. What if any of (the code on) your servers suffer a security breach and an attacker modifies the .js file you serve with malicious code? Suddenly it is spread to all WPML users.
This isn't secure.
It would be secure, if you loaded the script with file integrity/SRI to guard against this kind of attacks. But the SRI would obviously have to be part of the plugin, which then begs the question: why not just bundle the JS with the plugin right away?
Anyway: especially, with the recent supply-chain attacks shown in npm, this is a massive security risk.
Thank you very much for taking the time to provide such a thorough explanation of your concerns regarding the external loading of JS/CSS files from our AMS/ATE service.
We’ve carefully reviewed the points you raised, including:
WordPress Plugin Guidelines – The guideline you referenced applies to plugins hosted on the official WordPress.org directory. Since WPML is distributed independently, this rule does not apply to us. Additionally, the assets in question are part of WPML's own service infrastructure, not third-party resources.
Privacy Implications – The external script is served from our own domain and does not collect or transmit user data beyond what’s required to operate WPML services. This setup is aligned with our privacy policy, and we do not see any direct conflict with data protection laws such as GDPR in this context.
Security Risks – We understand the hypothetical risk you described — namely, that if our servers were compromised, malicious code could be served to users. While this is a valid consideration, it is a very specific and theoretical scenario. Given the significant architectural effort required to change this, and the fact that these assets are served securely via HTTPS from our own controlled infrastructure, we believe the current approach strikes the right balance between flexibility and security.
We truly appreciate your detailed feedback, and while your concerns are noted, we’ve decided not to make changes in this area at this time.
Thank you again for your understanding, and please feel free to reach out if you have any further questions.
