[wp-trac] [WordPress Trac] #43750: Establish a standard means of core reading privacy declarations from plugins’ readme.txt

[WordPress Trac]

#43750: Establish a standard means of core reading privacy declarations from
plugins’ readme.txt
------------------------------------+------------------------------
 Reporter:  allendav                |       Owner:  (none)
     Type:  enhancement             |      Status:  new
 Priority:  normal                  |   Milestone:  Awaiting Review
Component:  Privacy                 |     Version:  trunk
 Severity:  normal                  |  Resolution:
 Keywords:  gdpr needs-patch close  |     Focuses:
------------------------------------+------------------------------

Comment (by allendav):

 Replying to [comment:12 iandunn]:
 > Hmmm, I'm kinda leery of the idea of relying on a dev manually setting
 `readme.txt` headers. It feels like it'll be much more likely that results
 will be inaccurate. A dev could forget to update it when they add/remove
 export/erase callbacks, use the wrong values, etc.
 > It's also adding another thing that devs have to learn about and do.

 Absolutely - this is a downside to this. That said, I don't think plugin
 developers will be in the habit of removing integration to core privacy,
 in fact i suspect they'll probably be adding these privacy related tags
 just once in their plugin's lifecycle.

 I'm also comforted by the fact that themes do this tag business already.

 > I wonder if there's a way we can add support for identifiers to the
 export/erase callback registration process, in a way that'll maintain
 back-compat?

 We could, but what would you do for plugins that don't need the
 exporter/erasers because they don't collect or copy personal data? The
 plugin header approach supports those plugins (which i suspect are the
 vast majority of plugins.)

 > Or maybe [https://stackoverflow.com/a/2222404/450127 use
 ReflectionFunction to determine the plugin that the callback is from], or
 see which plugins are hooking in to `wp_privacy_personal_data_exporters`.
 Those could have some false-positives there too, though, but maybe it's
 less likely than relying on them being manually set?  Maybe automatic
 detection could be the primary method, then then there's also a filter to
 let devs override the result?

 We could do this, but we wouldn't know what plugins implemented the export
 and erasure hooks until after we call all the registered exporters and
 erasers? I'd love to present this information to the admin before they run
 any export. Seems a little complicated and therefore potentially brittle
 too?

 It also suffers from the vast-majority problem - plugins that don't
 collect or copy personal data and so don't need to participate in export
 or erasure.

 >
 > None of that feels like a very elegant solution, though; a `readme.txt`
 header would probably be simpler. I don't have a strong opinion either
 way.

 LOL, nope, neither is foolproof, but i think the readme.txt header tags
 idea has an edge in simplicity.

 Another neat thing about the Tags: idea is that other concepts might show
 up there, like requires-php-7 for example :P

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/43750#comment:13>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform