WordPress.org

Make WordPress Core

Opened 7 weeks ago

Last modified 11 days ago

#44013 new feature request

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

Reported by: webdevmattcrom Owned by:
Milestone: Future Release Priority: normal
Severity: normal Version:
Component: Privacy Keywords: gdpr privacy-roadmap
Focuses: Cc:

Description

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).

Change History (15)

This ticket was mentioned in Slack in #gdpr-compliance by webdevmattcrom. View the logs.


7 weeks ago

#2 @AskKim
7 weeks ago

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.

#3 in reply to: ↑ description ; follow-up: @xkon
7 weeks ago

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.

#4 in reply to: ↑ 3 @David 279
7 weeks ago

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.

#5 @azaozz
7 weeks ago

  • Milestone changed from Awaiting Review to Future Release

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.

Last edited 7 weeks ago by azaozz (previous) (diff)

This ticket was mentioned in Slack in #gdpr-compliance by allendav. View the logs.


7 weeks ago

#7 @brainstormforce
6 weeks ago

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.

#8 @smub
6 weeks ago

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.

#9 follow-up: @webdevmattcrom
6 weeks ago

@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.

#10 in reply to: ↑ 9 @smub
6 weeks ago

@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.

#11 @webdevmattcrom
6 weeks ago

@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.

This ticket was mentioned in Slack in #gdpr-compliance by pbarthmaier. View the logs.


6 weeks ago

#13 @desrosj
6 weeks ago

  • Component changed from Shortcodes to Privacy

Moving to the new Privacy component.

This ticket was mentioned in Slack in #gdpr-compliance by desrosj. View the logs.


3 weeks ago

#15 @desrosj
11 days ago

  • Keywords privacy-roadmap added
Note: See TracTickets for help on using tickets.