[wp-trac] [WordPress Trac] #51092: Create a JSON schema for Privacy and Other Related Disclosures

[WordPress Trac]

#51092: Create a JSON schema for Privacy and Other Related Disclosures
----------------------------------------------+-----------------------
 Reporter:  carike                            |       Owner:  (none)
     Type:  feature request                   |      Status:  new
 Priority:  normal                            |   Milestone:  5.6
Component:  Privacy                           |     Version:
 Severity:  normal                            |  Resolution:
 Keywords:  needs-privacy-review 2nd-opinion  |     Focuses:  rest-api
----------------------------------------------+-----------------------

Comment (by TimothyBlynJacobs):

 > Right. This question was raised when the initial discussion happened,
 around two years ago if I'm not mistaken, and don't think there's been a
 clear answer yet.

 As I understand it, the point is to create a superset of facts about how a
 plugin handles user data, makes external API requests and other privacy
 related info. That way, individual plugins can be created for different
 privacy laws. The Core part is more about standardizing a data format so
 that plugins, and perhaps Core, can implement functionality based on the
 laws of the region the site adheres to. As well as making sure that data
 is disclosed to the site owner in an easy to understand way.

 This can really only work if the standard is in Core to give the best
 potential at plugin adoption.

 The current system we have in place is freeform, and I don't think has
 proven to be very successful. Plugin authors aren't lawyers, but are
 practically being asked to write up "legal" privacy policy information
 that the site user then needs to figure out a way to cobble into a legal
 document of their own.

 By making the privacy data as fact based as possible, it reduces the
 burden on plugin authors who want to provide this information. It'd also
 allow for plugins or other tools to compile comprehensive privacy policies
 and other documents based on the structured information.

 > I'm still thinking we're talking apples and oranges here :)

 Probably :) My comments are really only focussed on the technical side
 assuming this is the feature set we want to implement.

 > Where the data that needs validation comes from? Static file(s), one
 supplied by core and (eventually) a few supplied by plugins.

 As you mentioned, Core is pretty simple. As I understand it, the main
 audience here is plugin developers. So eventually data can be displayed in
 the admin and on the WordPress.org plugin page.

 > When should the validation happen? On every request of... what? Or once
 after a plugin is installed and then the result is saved in the DB? Or....
 how is that going to work efficiently?

 For Core, it could be validated when the data needs to be accessed on the
 privacy page. For .org, I imagine it'd validate when zips are built.

 > What happens when the validation fails? The plugin supplying the data
 is... rejected (deleted, disabled, or... rejected how)?

 I think this is mainly for @carike. But I think the idea is just that the
 plugin would show as having an incomplete or invalid privacy disclosures.
 I don't think the idea currently is, and probably never would be, for Core
 to completely forbid plugins from operating unless they have complete
 disclosure data. I imagine there would probably be plugins that do
 implement something like that.

 > Does it make sense for such validation to be in core at all, or maybe
 better to be on accepting plugins to the plugins directory, or..?

 I think it is still necessary to have in Core to handle the plugins that
 don't live in the WordPress.org directory. Having a JSON Schema in Core
 also gives us versioning tied to WordPress releases.

 > What happens then the schema needs to be changed? Re-validation?

 If we do need to cache validation status, yeah we could re-validate that
 in a fairly straightforward way I think.

 > Generally (continuously) validating static, non-editable files in core
 seems... unwise?

 Which files would that be? I don't think we'd need to do that for Core's
 privacy disclosures. Just plugins, and I don't think it'd need to be
 continuous. And if we need to implement caching, I don't think it'd be
 that complex.

 > quite a bit of the data seems "sensitive", i.e. only admins should be
 able to see it.

 In what way? As I understand it, the idea is that this data would be
 displayed publicly on WordPress.org.

 > So at best this should be a page under the Plugins and Themes menu items
 in wp-admin accessible only to site admins, or perhaps a "More Info" link
 for each plugin and theme.

 I think it would be guarded the same way we guard the Privacy Settings
 page already.

 > The point is: whether this should be available through REST API should
 be decided after the implementation details and UI are ready, not before.

 How is the REST API not a part of the implementation discussion? Ignoring
 the REST API until the last second and seeing it as merely a simple data
 transport mechanism is how we continuously get into trouble.

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