Hello,
Q1: That’s how AddToAny stays evergreen, performant and secure without the need for constant plugin updates. As you found, you can locally cache the assets with the exception of the utility frame which serves to respect end-user preferences.
Q2: The GDPR doesn’t prohibit third party requests. AddToAny is widely used by .eu and EU agency sites with no issues due to proper privacy practices that are compatible with the GDRP.
Thread Starter
Lyk
(@lyk-1)
Hello and thank you for your reply.
Q1: Is there any way to disable these external requests? If not, are there any plans of doing so in the future?
Regarding the cache, as already mentioned, it does not eliminate all the 3rd party requests from the visitors browser.
Q2: Performing a 3rd party request without user consent is a potential GDPR violation.
The visitor’s IP is exposed to the 3rd party without the visitor ever agreeing or doing any action to justify the exposure of that personal data (IP in our case).
We had legal departments from various companies mention such restrictions pretty specifically.
The plugin is great but this area needs some investigation.
Thank you!
Privacy regulations do not prohibit third party requests, and there’s no change to the previous answers above.
Sites that are controlled by overly fearful lawyers are free to implement ‘consent banners’ that block site functionality by default. A banner for basic functionality is never a good idea because it unnecessarily disrupts visitors, but it’s entirely possible with plugins that implement the WP Consent API, which AddToAny supports.
Thread Starter
Lyk
(@lyk-1)
Thank you for your replies.
I mostly agree with the overly fearful lawyers part. Still I believe external requests are best to be avoided unless strictly necessary. Reasons range from performance and security, to reliability and availability if the dependence is strong.
From what I can tell, there are no plans to change this for the AddToAny plugin, so I am closing the topic.
Thank you!
You’re welcome, Lyk!
In your case, with the local cache option enabled, I’d recommend looking into adding a strict Content Security Policy to the site’s pages so that only the site’s first-party assets load. This would effectively block the utility frame and you’ll just get notices in developer tools/scanners that the asset is blocked, which is intentional of course.
Thread Starter
Lyk
(@lyk-1)
Thank you for mentioning that.
So if the external request to https://static.addtoany.com/menu/sm.25.html#type=core&event=load is blocked, it is ok and not expected to cause any functionality issues with the plugin?
Correct, AddToAny is failure-resistant in all respects, but if you run into any problems feel free to post here or to contact AddToAny.
Thread Starter
Lyk
(@lyk-1)
Ok nice.
I wasn’t sure what the request to https://static.addtoany.com/menu/sm.25.html#type=core&event=load is about. That’s why I wanted to verify.
That makes sense. I should’ve been more explicit when I tried to explain end-user preferences:
which serves to respect end-user preferences
End-user preferences are what the AddToAny sm.##.html utility page are all about.
Thread Starter
Lyk
(@lyk-1)
I see! Thank you for the reply.
