[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:  trunk
 Severity:  normal                            |  Resolution:
 Keywords:  needs-privacy-review 2nd-opinion  |     Focuses:  rest-api
----------------------------------------------+-----------------------

Comment (by carike):

 Replying to [comment:21 TimothyBlynJacobs]:

 > I think it'd probably be better to put the schema in either a GitHub
 repo or at least a PR against wordpress/develop. In its current form,
 providing comments on it is really difficult.

 Thank you for the advice. Working on it :)

 Replying to [comment:22 azaozz]:
 > > For the most part, the actual "controlling" is planned for a sibling
 plugin, the Permissions Tab, which is not currently intended to be merged
 into Core.
 >
 > Two things:
 >
 > 1. Not sure what "controlling" means in this context? Control what
 exactly?
 > 2. Thinking this is not a good idea. A "feature" is either in core or it
 isn't. Adding "something" to core that will need a plugin to become useful
 is not the way to go imho.

 The best way I can explain this is to compare it to Site Health.
 Some Site Health features enhance what is already in Core, but they are
 not necessary for a not-insignificant number of users, or more useful for
 a limited amount of time, so they are intentionally kept in the plugin.
 The Core implementation works - and is useful - in its own right, but it
 is augmented by additional (debugging) features in a plugin.

 The aim is to decide what constitutes sane defaults for Core and then to
 provide extended **options** via a Permissions plugin.
 In this case, the Core functionality is more focused on awareness /
 education.
 The aim is to help site owners / admins understand their privacy risk
 profile.
 Advanced options may need some sandboxing capabilities (to enforce site
 owner / admin choices) that would not be ideal for Core, but may be in
 high demand as a plugin.

 > > Each plugin, theme and core component can have a file called
 disclosures.json
 >
 > This makes sense for themes and plugins but perhaps not for core? In
 this context what is "core component" and why "all" core components need
 separate files? WP core is not build from "independent components".

 To create a disclosures.json file for Core would be a large undertaking
 (which would include documenting all external references in the code).
 Breaking it up in to the various components make it more achievable and
 also makes it more useful to the site owner / admin because it is
 explained in more manage-able chunks.

 > > ...using relatively simple REST API functionality
 >
 > Why this should be available (only?) through the API and not as a simple
 text or HTML? How is this going to be used in core? Seems the "application
 design" part of this is not formulated (yet).

 Free-form disclosures would not be as useful as standardized disclosures,
 which allow site owners / admins to compare plugins / themes' privacy
 practices.
 A JSON format helps with standardization and can be easier for developers.
 The REST API is used to validate the JSON data and to make it accessible
 in a format that is more friendly towards site owners and admins.

 > (Also a quick note: multiple code examples in the ticket description are
 hard to follow and not particularly useful.)

 These are not multiple examples. They are intended to be a single schema.
 I just split them into separate blocks because on the laptop, the vertical
 scroll bar is at the bottom.
 I am working on getting a copy up on GitHub though, as per Timothy's
 suggestion, as I understand that it can be hard to read here.

 Replying to [comment:23 azaozz]:

 > On second thought, this is (inseparable) part of #51144, perhaps can be
 closed as duplicate and handled there. The whole feature still needs
 designing.

 This ticket is intended for designing.
 However, we need input from a very diverse group of people for this
 initiative and they do not want to read through a lot of items that do not
 apply to them, hence the separate (but highly related) tickets to allow
 for multiple working groups.

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