Make WordPress Core

Opened 3 years ago

Closed 3 years ago

#55346 closed defect (bug) (invalid)

Problem in GDPR regulations provided by core wordpress

Reported by: fs5ve's profile fs5ve Owned by:
Milestone: Priority: normal
Severity: major Version: 4.9.6
Component: Privacy Keywords: has-privacy-review
Focuses: Cc:

Description

Hi,

We, a group of researchers from University of virginia and John hopkins university are investigating the GDPR compliance issue for wordpress plugins. During the investigation,
I have installed wordpresss 5.9 in my local machine. Later, I created one root and one regular user account in my local machine. After that, I installed profilepress (https://wordpress.org/plugins/wp-user-avatar/) plugin and activated it. By this time, I have some information (personal information) stored in the database. These days, to comply with GDPR, wordpress comes with data deletion and data access feature. So, to test that, I have made a request to delete my regular user from the database and approved it. In the request table, it showed the status to “completed”. But later when I select the data access, it exported that user’s data. I checked the database, I can still see all the information related to that user.

Note that, I haven’t modified my code from the wordpress core, other than the configuration file.

Can you please take a look at this issue? I can also share the screenshot of the whole process if needed. Please let me know if any other information needed.

Attachments (8)

exported_data.png (182.1 KB) - added by fs5ve 3 years ago.
Exported File
user_creation.png (195.7 KB) - added by fs5ve 3 years ago.
user_creation_console.png (204.6 KB) - added by fs5ve 3 years ago.
user_creation_database.png (261.0 KB) - added by fs5ve 3 years ago.
user_data_export_after_deletion.png (246.2 KB) - added by fs5ve 3 years ago.
user_db_still_exist.png (271.1 KB) - added by fs5ve 3 years ago.
user_deletion_console.png (241.2 KB) - added by fs5ve 3 years ago.
user_export_data.png (244.0 KB) - added by fs5ve 3 years ago.

Download all attachments as: .zip

Change History (17)

#1 @swissspidy
3 years ago

  • Keywords close added; needs-privacy-review removed
  • Severity changed from major to normal

Hi there,

Thanks for opening this. Since WordPress cannot know what type of data plugins store, it's up to the plugins to hook into the data export / erasure process offered by WordPress. See https://developer.wordpress.org/plugins/privacy/ for details.

So in this case, you'd want to reach out to ProfilePress so they can look into this and make any necessary changes to their plugin.

#2 @johnbillion
3 years ago

  • Milestone Awaiting Review deleted
  • Resolution set to invalid
  • Status changed from new to closed

@fs5ve Please note that you received the same response for your previous report at #52024. Please ensure you direct your reports to the affected plugins instead. Thank you.

#3 @paapst
3 years ago

  • Keywords has-privacy-review 2nd-opinion added; close removed
  • Resolution invalid deleted
  • Severity changed from normal to major
  • Status changed from closed to reopened

Hi @fs5ve

Thank you for this report. I have reproduced this problem on a website without any additional plugins.
I created a new user, with all kinds of extra personal information attached to its profile. After that, I went to "Erase personal data". I entered the username, send the request to erase the data about this user. Then it showed "Erasure completed" and it showed a notice that no personal data was found for this user.

Afterwards, I went to the menu item "Export Personal Data", entered the username, and voila... all the information was still there. Conclusion: nothing about this user has been deleted or anonimyzed.

@fs5ve
3 years ago

Exported File

@fs5ve
3 years ago

#4 @fs5ve
3 years ago

Hi @johnbillion , @swissspidy ,

It actually doesn't depend on the installed plugin. Sorry I wrote the description in a way which mislead you. I have uploaded some screenshots showing the problem of data deletion and export. In summary the problem can be reproduced by following-

  1. Register a new user (say it is dummyuser). I tried with subscriber role, but I believe the problem is not related to the user role. While registering I provided first name and lastname, also email and password.
  2. Later from the tools -> export personal data, I have exported the data related to dummyuser.
  3. Then I make a request to delete data for this user. And in the console, it says "No Personal Data is found for this user".
  4. Again, I make a export request for dummyuser.
  5. It generated a export.json file which contains the same data as before the deletion.

To me, it seems like the data deletion in the WordPress is not working as it supposed to be. May be you can try to follow the above step to re-create the problem. If you are not able to re-produce it let me know.

Note that, during the whole process, I haven't installed/activated any other plugins/themes.

Hi @paapst ,

Thanks for letting us know that you were able to reproduce the problem.

This ticket was mentioned in Slack in #core-privacy by paapst. View the logs.


3 years ago

#6 @paapst
3 years ago

From the discussion on the #core-privacy channel, it now seems that this is not a bug but intended behaviour. Basically in this particular case Core offers functionality to plugins that can not be used by core itself. A site owner that wants to comply with an erasure request from a user, needs to manually delete the user account, but can not use the "Erase personal data" Tool for that. To be honest, I would have never expected that.

#7 @johnbillion
3 years ago

  • Version changed from 5.9 to 4.9.6

#8 @fs5ve
3 years ago

So what's the conclusion? Will there be any update regarding this issue? I believe most WordPress developers will have a misinterpretation of the existing feature if they don't go through the documentation. What do you think?

#9 @desrosj
3 years ago

  • Keywords 2nd-opinion removed
  • Resolution set to invalid
  • Status changed from reopened to closed

Closing this issue. As stated above by @paapst from the discussion in Slack, this is intended behavior.

Note: See TracTickets for help on using tickets.