• If you are still using CentOS 7.9, it's time to convert to Alma 8 with the free centos2alma tool by Plesk or Plesk Migrator. Please let us know your experiences or concerns in this thread:
    CentOS2Alma discussion

Input How to have your Plesk EU GDPR compliant

Bitpalast

Plesk addicted!
Plesk Guru
Yesterday a customer brought to our attention that while surfing the Plesk GUI connections are being made by the browser to firehose.us-west-2.amazonaws.com. This took me by surprise, because I had never seen it before myself although I am working at least 900 hours annually in and with the panel.

I see that "User Activity Tracking" was first mentioned on the forum in an old thread that dealt with other panel options:

A support article showed up:

So obviously there has been a change that requires users to explicitely disable "User Activity Tracking" in panel.ini if they do not want it. I did not find any place where the option is explained, so it remains unclear what is tracked and what is done with the data that is created by that tracking. What does User Activity Tracking do? At least it is nothing that is needed, and unfortunately it is an issue for GDPR in the European Union, because we'd need to list transmission of and storage of user data on a non-EU server in the GDPR policies.

So for you folks that have not yet noticed that the GUI is transferring data to an unwanted external target, you can and should disable User Activity Tracking by this entry in panel.ini:

Code:
[userActivityTracking]
enabled=false
 
Last edited:
Peter, the connection of "User Activity Tracking" to firehose.us-west-2.amazonaws.com is used by the internal Plesk tool, which is intended for collecting statistics. It is expected to see it in the browser. All the data is transferred anonymously (no violation of the GDPR) and used only by Plesk to improve product quality.
It collects which modules you are using, if you often use, for example, PHP Settings in Tools & Settings, so we can gather data on which part of Plesk is used more frequently.
 
@IgorG Thank you for the explanation. I thought it would do something like that. However with the "anonymous": That is unfortunately not true by at least some high court decisions. The moment the IP address of a user becomes known to an external party it is considered "personal information" (in Germany), and in this case the receiving party must be included in the GDPR of the operator (us) plus a link to their privacy policy. The transaction is not done from within a Plesk script that resides on the server. It is triggered by a JavaScript component in some way so that the element shows up in the browser stream, hence the IP address of the user's browser becomes known to the receiver. (Prove me wrong if this ain't the case ...) For that reason I think that for this and other EU countries it can be problematic.

It would be different if the connection was made from a server side component without becoming part of what is transmitted between the user's browser and the server. Because then it would only make the server's IP known to the receiver. But here this is not the case. When you, e.g. right-click in Firefox, then press Alt-Q to open the analzyer, then choose "network analysis" and reload a page, e.g. backup manager, you can see that the connection between the user's browser and the server includes a connection to Amazon AWS in the United States. In this very moment the GDPR is violated if it has not informed the user that his IP address will become known to Amazon AWS.

Not a big problem here, we'll just turn it off, but maybe you can discuss this with your staff internally. I do understand that the fine limits of laws and regulations in other countries may not be so obvious to your developers at all times.
 
Hi @Peter Debik
At least it is nothing that is needed, and unfortunately it is an issue for GDPR in the European Union, because we'd need to list transmission of and storage of user data on a non-EU server in the GDPR policies.
I assure you that we do not collect any PII information in User Tracking Activity as we spent a considerable amount of resources to anonymize all data to comply with GDPR law when it was announced back in 2018.

You can explicitly disable it in the Cookie section in Plesk:
uat.png
Also, you can read more about this in the Plesk Privacy Policy Legal
uat2.png

Please let me know if you need more details. I and Igor will be happy to provide them.
 
I would like to underline that this is not a complaint of mine. I am only bringing to your attention that there is a minor issue with GDPR how Plesk sees it and how the European Union requires it.

The problem is the IP address of the "User Activity Tracking" (and the sentry.io tracking) that is not done through a server-side algorithm but through something between the user's browser and the receiver (Amazon AWS in the U.S.).

According to decision C-582/145 of the European Court of Justice on October 19th, 2016, (see
CURIA - Documents for details in English and other languages) IP addresses are considered personal data and are protected as such by privacy laws. So even if Plesk anonymizes data, what it cannot anonymize when using JavaScript or images is the user's browser IP address at the time when the connection is made. It is not about the content, it is about the fact that the user's IP address becomes known to the external storage location or resource.

Personally I think this is a total legal exaggeration, but unfortunately some dudes think that it is a problem for them if their dynamically changing browser IP address becomes known to external systems. It is annoying, craziness by data protectors, but the ruling is here, so we have to abide to it.

So what we are talking about is not cookies, neither the collection of anonymized user data. What we are talking about is the algorithm that Plesk choose to do it. If Plesk would collect the data server-side, e.g. monitor a user activity and then store it anonymized from a server-side script with the server's IP address to an external location - that would most likely be fine in most cases. But this is not what's happening. What is happening is that a browser-side script is connecting to an external location. And that makes the user's IP address known to that external location. This can be seen in the network traffic monitor of the browser.

Here in Germany, for example when people place a "Facebook Like" button on a a website, when they include Twitter content, Youtube content or anything else in their websites that connects to a third party - although no "real" personal data is being transferred - the connection alone where FB, Twitter, Youtube and alike receive the IP address of the user is considered transmission of personal data. This is what C-582/145 is about. For that reason here all media and websites that are connecting from a browser to a different website that the user is not currently surfing on need the explicit consent of the user. This is normally done by something like "Click here to see external Twitter content" buttons or similar. However, what the Plesk software is currently doing (when the operator has not disabled it by a panel.ini setting), it is connecting to firehose.us-west-2.amazonaws.com from the browser without explicit user consent.

I hope this makes it clearer why this is a legal issue here. No problem though when you know that the server operator can disable the options in panel.ini. I just thought that this should rather be the preset after installation.
 
Personally I think this is a total legal exaggeration, but unfortunately some dudes think that it is a problem for them if their dynamically changing browser IP address becomes known to external systems. It is annoying, craziness by data protectors, but the ruling is here, so we have to abide to it.
[...]
Here in Germany, for example when people place a "Facebook Like" button on a a website, when they include Twitter content, Youtube content or anything else in their websites that connects to a third party - although no "real" personal data is being transferred - the connection alone where FB, Twitter, Youtube and alike receive the IP address of the user is considered transmission of personal data.
I think you are underestimating how much data is leaked by including stuff from a 3rd party.
First and foremost, the Referer: tells which page it is included from. So unless the whole site operates on POST to the index.php, you can pretty much tell what the user is doing from that URL alone. Second, the browser can be fingerprinted to track the user even across sites.
That Plesk doesn't use that data doesn't mean that amazon Firehouse can't or won't collect it.
This would not have as much impact if that include was cached and thus downloaded only once, but such includes for tracking purposes are explicitly set to no-cache. (And even if includes are allowed to cache, there's no guarantee that they'll stay that way. There's just too much money in selling user tracking data nowadays.)
 
Yes, but it does not change the case. The moment a browser-side script contacts a third-party system it is considered transmission of personal data. This is even true if the script does not transmit anything at all. The process of contacting the third-party system makes the user's IP address known to that third-party system, and that is considered transmission of personal data.
 
And, as stated above, the IP address is not the only data transmitted because the browser sends quite a lot extra metadata.
 
Guys, thanks for the additional valuable aspects you brought up on this thread. We will carefully consider and investigate them in the framework of specially created task PPM-4626. Upon completion of this, we will share the results of our investigation of this topic.
 
Perhaps it would also be good to display a clear warning when registering the server with the plesk360 service for monitoring or administration. Obviously, not only the names, but also the email addresses of the customers are transferred here.
If a customer explicitly does not want his data to be processed in non-eu countries, you might have bigger problems.
 
Sorry to be intrusive in this thread after a year. However it seems that nothing happened here since, especially with the 1-Click-Installer.
Just to be clear: This behavior is clearly a violation of the GDPR as already mentioned by @Bitpalast
You should disable this behavior otherwise you'll make yourself vulnerable in relation of a penalty to your company of about 4% of your total yearly revenue worldwide and in relation to compensation against your customers.

Please provide a proper solution for your customers in Europe.
 
Hello @Frisch12, there should not be any such issues in Plesk remaining. Could you please explain in detail what exactly s wrong with 1-click-installations in your opinion?
 
Back
Top