Add Basic Access and Deletion Front-end Request Forms as shortcodes/widgets/blocks

[webdevmattcrom]

Per this Slack discussion:
​https://wordpress.slack.com/archives/C9695RJBW/p1525394015000159

In order for the new GDPR features to truly work "out of the box" (per WordPress Philosophy standards), and to not force users to find their own options ("Decisions not Options") it would be best if WordPress Core provided at least a simple name/email frontend form for users of a website to create their "Right to Access" and "Right to be Forgotten" requests that would populate the admin entries for those tools.

I understand how that might seem like form-plugin territory, but without it, these new tools are so limited as to not be useful.

Naturally, the output of these shortcodes/widgets/blocks can have filters so form plugins can hook into them to customize the forms further than the default, but the bare minimum would simply be one form for "Right to Access" and one form for "Right to be Forgotten" that simply has an email address field (no other fields are truly necessary since the confirmation emails would be sent automatically, and no action would happen until confirmed).

[AskKim]

I'll second that. We can't simply rely on a third party implementation here for the basics of this form & form handling. Too many things can go easy wrong and it will reflect very badly on WP itself if it does and we can't point to a fundamental and working option.

[xkon]

Providing a core way of handling this would be good imho as well but with 1 note:

Replying to webdevmattcrom:

(no other fields are truly necessary since the confirmation emails would be sent automatically, and no action would happen until confirmed).

Auto-confirmation should be made as a setting for each Admin to choose (either in the settings privacy screen or a flag in the form shortcode etc).

Why:

• The regulation says that you have to provide the data no later than a month from the receipt except if there's a tech issue of course (but I have no idea what counts as receipt, the day you took the request? Or the day you confirmed it?)

• Some websites depending on their business background will choose extra means of confirmation, for example by phone first before sending the actual e-mail if that e-mail is sent eventually even. I already have 2 websites under my care that deal with this by phone first and then asking for a 'written' confirmation. By making it auto-confirm without the option of cancelling that it might create a problem for some as they wouldn't expect their lists to become confirmed instantly on their admin tools especially when the actual export/erasure actions are not automated.

I can't openly say why these 2 websites do it like this of course but I can outline the flow but you'll see that the 'confirmation' part is pretty much the last step:

• Users send an email with their request adding their contact information (phone + email are mandatory).
• They get contacted by phone first from the company.
• They receive the email stating that they will receive their data in X time (depending the situation) by Y means (usb/email/hdd whatever else).
• They confirm that they have read / understood the above told and that they asked for their data.
• They get their data.

[David 279]

Replying to xkon:

Why:

• The regulation says that you have to provide the data no later than a month from the receipt except if there's a tech issue of course (but I have no idea what counts as receipt, the day you took the request? Or the day you confirmed it?)

From what I have read it's the day the request was made, it doesn't matter if you were away on a 2 week holiday at the time, it's not when you read it, but rather when it reached your system, this prevents people doing something dodgy like only reading their SAR's once a decade and then saying I acted as soon as I read it.

[azaozz]

Thinking that a widget (block) would work best here. Shortcodes would be quite limited.

As @xkon mentions this will have to be left to the site owners to decide, a widget will let them add that form exactly where/when they need it.

However it's a bit late for v1, we are nearly at RC. This seems "v2 material" :)

@David-279

From what I have read it's the day the request was made...

That may be true, but still depends on the method of a request. If it is by email, it may as well be spam and the recipient will never see it :)

I.e. it has to be proven that a request is genuine before accepting it.

[brainstormforce]

Just a plain email address in privacy policy will do the job.

For those who want to automate the process with a form, there can be a plugin for that.

[smub]

To comply with GDPR in this situation, all that's needed is a privacy policy page with an email address that a user can use to contact the webmaster and request removal.

This is most definitely plugin territory.

[webdevmattcrom]

@brainstormforce and @smub -- keep in mind that this ticket was created in light of the fact that the work of creating admin tools has already been done and is scheduled to be released with WP 4.9.6. So whether an email address in the privacy policy does the job or not is not relevant.

What is relevant, is that the admin tools will exist, but populating the entries in those tools will be completely manual until some sort of front-end request form is created. I have no doubt that form plugins will rush to fill that gap. But I also believe (as a plugin author myself) that it would benefit the whole WP ecosystem for Core to provide the bare minimum frontend form (just like it does for registration/login) and that form plugins can then extend or hook into that existing form.

[smub]

@webdevmattcrom I'm not sure if it's wise to dismiss relevancy of a point just because it doesn't agree with your opinion.

The point that myself and @brainstormforce brought up are very valid in response to the original ticket. Putting an email in the privacy policy in combination with the tools already built for 4.9.6 admin area provide an "out of the box" solution for users to ensure compliance.

I'm all for creating hooks, filters, and APIs that plugin / theme authors can use to build front-end things.

But like many other API/hook/filter that WP have, I believe this too should be left in core code, so plugin authors can extend to add UI elements like Shortcodes, Widgets, GutenBlocks, etc.

This IMO will provide a better user experience rather than having duplicate UI elements that plugins will add which will inherently function better than any "bare-minimum" solution.

[webdevmattcrom]

@smub -- it wasn't my intention to be dismissive: apologies. My intention was to clarify that your response seemed to misunderstand the point of the ticket. Either way, your points ARE very valid, we're both trying to solve the problem for the user but in different ways.

[desrosj]

Moving to the new Privacy component.

[desrosj]

Removing the GDPR keyword. This has been replaced by the new Privacy component and privacy focuses in Trac.

[garrett-eclipse]

After discussing #44676 with @desrosj wanted to add a note to this ticket.
If both move forward we'd advise the front-end form to suppress multi-submissions capabilities as individual users should only be making requests for themselves from the front-end.

[garrett-eclipse]

For the V2 Privacy Roadmap we should probably look at this functionality first as a feature plugin.
We can probably look to @audrasjb's plugin for pre-existing work on this topic and potentially have it be the feature plugin.
​https://en-ca.wordpress.org/plugins/gdpr-data-request-form/

[garrett-eclipse]

Cleaning up the milestone, this is being closed as it will be worked on via a Feature Plugin.

[arena]

Major issue with a form is ... spam, and then mail bounce ...

I would prefer a dedicated mailbox (privacy[at]mydomain[dot]tld)
accessed via pop3 with a specific word in subject (export or erase)
that posts a request using wp_create_user_request

regards

[garrett-eclipse]

Hi @arena

Replying to arena:

Major issue with a form is ... spam, and then mail bounce ...

For sure, the potential for spam was the main driver behind working on this via a Feature Plugin rather than a patch for core.

Replying to arena:

I would prefer a dedicated mailbox (privacy[at]mydomain[dot]tld)
accessed via pop3 with a specific word in subject (export or erase)
that posts a request using wp_create_user_request

That's an interesting setup idea and sounds pretty useful but feels like it would fall outside of core as the mailsetup and server action to either make a REST request or wp-cli request to trigger wp_create_user_request that would all have to be configured externally on your server outside of core.
That being said, the WP-CLI action to create the requests isn't built yet but is a part of the V2 privacy roadmap here;
​https://make.wordpress.org/core/roadmap/privacy/
And as to the REST request, there's not currently an endpoint specific to requests but as they're simply a custom post so the Posts endpoint can be used for that;
​https://developer.wordpress.org/rest-api/reference/posts/

If you do move forward with your concept would love you to share your findings with the team and if there's any blockers hampering you from accomplishing that request flow.

Thanks for sharing.

[arena]

Replying to garrett-eclipse:

Hi @garrett-eclipse

Well, wordpress is already using pop3 access to mailbox in core for posting (there is a pop3 class for that) see screenshot attached.

i already have coded that kind of way of posting a Data Export Request on my website.
(if you mail me at contribute[at]mailpress[dot]org i will tell you how to test it).
It is under test before release inside my favorite plugin ...

The major problem is that if you receive a mail from an email (the FROM mail header), the email complies with the web standards (RFC) but but but ... you see were i am going, the request will be discarded due to is_email() not compliant with RFC rules .. ;-)

have a nice week end

Hi @arena

Replying to arena:

Major issue with a form is ... spam, and then mail bounce ...

For sure, the potential for spam was the main driver behind working on this via a Feature Plugin rather than a patch for core.

Replying to arena:

I would prefer a dedicated mailbox (privacy[at]mydomain[dot]tld)
accessed via pop3 with a specific word in subject (export or erase)
that posts a request using wp_create_user_request

That's an interesting setup idea and sounds pretty useful but feels like it would fall outside of core as the mailsetup and server action to either make a REST request or wp-cli request to trigger wp_create_user_request that would all have to be configured externally on your server outside of core.
That being said, the WP-CLI action to create the requests isn't built yet but is a part of the V2 privacy roadmap here;
​https://make.wordpress.org/core/roadmap/privacy/
And as to the REST request, there's not currently an endpoint specific to requests but as they're simply a custom post so the Posts endpoint can be used for that;
​https://developer.wordpress.org/rest-api/reference/posts/

If you do move forward with your concept would love you to share your findings with the team and if there's any blockers hampering you from accomplishing that request flow.

Thanks for sharing.

[arena]

pop3 access in wordpress core

[garrett-eclipse]

Thanks @arena I hope you enjoyed your weekend. I appreciate you pointing that out I overlooked the Post by Email feature.

The feature you mention sounds quite useful for sure and would love to check it out once you're done testing, pass me a link on slack.

With most of these types of features, like those in the V2 privacy roadmap, a good starting place is as a plugin similar to what you're planning. The email RFC compliance is another hurdle of course.

[arena]

@garrett-eclipse
not expecting any response but if you want some reading ...​read this (no personal data collected)