[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 azaozz):

 Replying to [comment:24 carike]:
 > 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.

 Still thinking I may be misunderstanding or missing something here, but
 don't see the similarities. Do you mean the proposed structured privacy
 data format should be filterable and changeable by plugins? If yes,
 thinking that from software development point of view that's not a good
 idea. Each change of the "structure" will bring back-compat concerns, etc.

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

 Don't think there are many "external references" in core. In fact think
 there is only one: to wordpress.org. This, of course, depends on the
 definition of "external references", could you explain/share it for
 clarity's sake.

 Creating multiple hard-coded files for different "components" doesn't seem
 to make sense because:
 1. Nearly all WP components do not access external resources. The only
 exception is Install/Update that accesses only one resource: the API on
 wordpress.org.
 2. Having multiple (hard-coded json, xml, html, text, etc.) files would
 generally be harder to maintain and use.

 > Free-form disclosures would not be as useful as standardized
 disclosures, which allow site owners / admins to compare plugins / themes'
 privacy practices.

 I think this is incorrect. Who will bear the legal responsibilities for
 deciding what is legally required, what is not, and what is "perhaps nice
 to have"? A per-determined format for "standardized disclosures" doesn't
 seem possible from legal point of view.

 > A JSON format helps with standardization and can be easier for
 developers.

 True, however see above.

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

 Sorry but not following here.

 1. What data has to be validated, where and when, and what is has to be
 validated against?
 2. What is the purpose of using the REST API to output a static file? This
 seems like a bad software design?

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

 Right, thanks. Yeah, the "proper way" would be to either make a patch and
 upload to this ticket, or make a PR as suggested by TimothyBlynJacobs.

 > This ticket is intended for designing.
 > However, we need input from a very diverse group of people for this
 initiative...

 Hmm, thinking that there are generally two groups of people that
 are/should be involved with this feature.
 1. People that have legal experience, are interested in web privacy, and
 have an understanding of how software is developed (or are willing to
 learn).
 2. WP developers (designers, coders, etc.) that can "design and create"
 the feature after the requirements are established by the above group of
 people.

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