[wp-trac] [WordPress Trac] #44518: GDPR Functions 4.9.6 need improvements & customisation

[WordPress Trac]

#44518: GDPR Functions 4.9.6 need improvements & customisation
---------------------------+-----------------------------
 Reporter:  lifeforceinst  |      Owner:  (none)
     Type:  defect (bug)   |     Status:  new
 Priority:  normal         |  Milestone:  Awaiting Review
Component:  Privacy        |    Version:  4.9.6
 Severity:  major          |   Keywords:
  Focuses:                 |
---------------------------+-----------------------------
 When attempting to use the GDPR enhancements such as Export Personal Data
 & Erase Personal Data in WordPress 4.9.6 they create more issues than that
 address. It seems to have good intent but seems to have been rushed into
 implementation.

 As has been discussed in a number of forums...

 **ISSUE 1 - GDPR EMAILS sending address**
 ----

 They are sent from wordpress at sitename, this is diabolical and should as a
 minimum use the admin configured email address.  More significantly the
 core function must support a customised email address which is stored in
 _options, that way the email could come from  a configurable address such
 as privacy at sitename.

  Using the email address wordpress at sitename will often result in may email
 systems and gateways marking the email as spam.  **The sending address
 must be configurable.**


 **ISSUE 2 - GDPR EMAILS content**
 ----

 The default email messages are also poor in terms of wording, style etc
 and look like someone has hacked a site to generate some prank as they
 contain no styling elements from the site. Ideally these should be
 customised, but as a minimum there should be a hook so that a theme or
 plugin can change the email content.  This needs to be properly documented
 so that it is then clear what needs to be returned to ensure that the
 email is appropriately customised.

  As have been noted in a number of forums, the ability to Brand the emails
 are essential to enable recipients to affirm the authenticity of the
 sender and not mark it as spam. This needs to be configurable or hooks
 with proper documented use and examples provided.

 **Issue 3 - Security - Exposing admin URL**
 ----

 The confirmation emails exposes the WordPress admin login URL, which is
 detrimental for security reasons. Also it looks much less professional and
 may lead some people to think the message is spam. You should create a
 custom landing page for such requests which is not associated to the admin
 URL, this could be something such as sitename/gdpr-confirmation-request.

 Due to the use of admin URL, the confirmation email links will often fail
 when used with various security plugins, especially if those plugins hide
 the WordPress admin login. The confirmation emails should not use a wp-
 admin URL.

  This is security 101 and needs to be addressed to not use the admin URL.

 **Issue 4 - only accessible by admin**
 ----

 These tools are only accessible by the supersite admin, good practice
 should limit the use of this admin account. These functions should also be
 available to a lower level authority such as Editor or you may need a new
 user level account called Data Administrator (which again ties back into
 the GDPR legislation requirements to have an identified Data
 Administrator).

  Need the ability to access GDPR functions from other WordPress user
 levels.

 **Sundry other issues or improvements**
 ----

 * The functionality should provide the ability to send the zip file as an
 attachment to the customer when the send email button is pressed, this
 saves the customer having to connect tot he site again to retrieve their
 requested data.

 * In the admin interface, sometimes after clicking on the send request
 button sometimes you receive a message link expired.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/44518>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform