bibliata

All other websites with SNAP on the same server and PHP version are working. Deleted the plugin. Reinstalled. Seems to OK for now
//THANKS

The import is allowed because the user clearly commented under a post of your website (regardless if the platform was FB or WP or whatever). According to GDPR, this makes you controller of the information as well as the social platform (FB or WP or whatever). The new rules may require you to request consent, but the grandfathered comments are as is and are treated under your website as controller just like the user who made comment under your post using regular FB API app that provides comment box.

The difficulty with “comments were imported by SNAP can use those same buttons to download/delete their comments” is that users MUST know their FBdigitalID@faecbook.com email in order to request download/erasure which they generally dont.

GDRP require the controller of the information to provide a “human form” of the request, meaning, providing a way which is somehow obstructed or is no way to request download/erasure is basically seen as direct non-compliance with GDPR.

Same if not worse difficulty is proposed by users who commented with FB accounts that are inactive any-longer or somehow anonymously. They have no way to provide a valid email with their request for download/erasure. Nevertheless, GDPR still entitles to that right as owners of the information.

• This reply was modified 8 years, 2 months ago by bibliata.

GDPR plugins now are asking for user email where they can send _confirmation link_ from where the user can click and receive the requested data.

This cannot be done (IMO) with userIDnumeric@facebook.com type emails:
1. Users hardly know what their ID is
2. Facebook will probably block a mass email from domain/IP to multiple userIDnumeric@facebook.com type emails as SPAM.

The gray area is correct, and therefore most websites are including privacy consent. Obviously a user is (somewhat) aware they are posting publicly on FB under a public link that belongs to a public website. Thus, GDPR does not argue against displaying the comments, but for the option to be forgotten and/or removed at any given time.

If the user can provide their userIDnumeric@facebook.com, GDPR plugins can remove their comments BUT ONLY IF they can receive the confirmation email and click on the link provided. Otherwise, anyone can go to a website enter a number of userIDnumeric@facebook.com type emails and remove comments left and right without proper confirmation from each user.

The old option was to identify user via FB login, but if FB is removing apps that will be no go, as it seems

Regular WP comments differ from SNAP imported comments by the email with which they are recorded and identifiable. In the case of FB imported comments for example this format is as follows: userIDnumeric@facebook.com There an auto recorded URL to the user profile: facebook.com/userIDnumeric

Current WordPress GDPR tools/plugins have no way to identify these comments as they are not recorded with user’s personal email. Most users don’t know their userIDnumeric@facebook.com and will not be able to use such tools to request/delete their data; which leaves the website’s “information controller” (the actual legal term) with no way to fulfill their requests having no way to identify a given user’s information and comply with the requests. This in term, may move responsibility to the plugin that controls how this information us used (transferred and recorded) thus making it the sole “information controller.” Admittedly, this is still gray area in GDPR legality, but it’s perhaps worth looking into for the plugins own sake and for the safety of websites that use the SNAP plugin.

Thanks for the answer – I will stick to the first one for clarification

If the data is anonymized, then it should not be identifiable by the info controller (not just the site owner); meaning after the info is anonymized no one should not be able to identify the account to delete but rather will have to delete all anonymized accounts manually to ensure deletion.

Is a deletion request interpreted as mandatory anonymization but deletion as controller’s choice OR is deletion mandatory when the user requests deletion?

//THANKS