[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:32 TimothyBlynJacobs]:
 > 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.

 Right, this should include **only** privacy related data that is
 considered public.

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

 Right again, the data should be disclosed **only** to the site owner(s).

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

 Right. This ensures each site owner can decide (or hire a lawyer if
 needed) what their Privacy Policy should contain, and bear the legal
 responsibility for it.

 > By making the privacy data as fact based as possible, it reduces the
 burden on plugin authors who want to provide this information.

 Yeah, perhaps. Looking at the examples above, a lot of points are not
 particularly clear, but thinking this can be improved?

 > It'd also allow for plugins or other tools to compile comprehensive
 privacy policies and other documents based on the structured information.

 Wrong. Privacy policies **cannot** be compiled by "(other) tools". They
 have to be written by people who will be legally responsible for the
 content.

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

 Yeah, this is a good idea. However the example "schema" above has a lot of
 things that don't seem "privacy related", needs more work.

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

 So we will need to maintain/sync two different "schemas", one in core and
 another on wp.org. Then plugins will be "forced" to include a (json
 formatted) file that will have to contain all the "required fields" or
 will be marked as "failed", even when they do not contain any user privacy
 related stuff? That seems... not ideal.

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

 Yeah, this needs more thinking imho. The majority of plugins have nothing
 to do with user privacy.

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

 Right, the question of syncing the schema between wp.org and core...

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

 Even if not cached, the validation will (likely) fail every time the
 schema is updated. Then all existing plugins will "fail"...

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

 The static json files supplied by plugins. But yeah, probably not a huge
 deal if these are not going to be accessed often. As far as I see it, on
 most sites these might be accessed 1-2 times per year, or less :)

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

 Making the data supplied by plugins "public" on a specific site will at
 least disclose which plugins that site is using. This in itself can be
 seen as a "privacy breach", can be used for "fingerprinting", the plugin's
 versions will probably be "guessable" from the data, etc. :)

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

 Right, so the data contained in the plugin's json files would be "private"
 (on a per site basis) and only site owners will be able to see it? (Only
 the site owners will need to see it anyways as it is intended for creating
 a Privacy Policy). Or am I reading this wrong?

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

 It's not that it is not a part of it but... Would you add an end point to
 output /readme.txt or /license.txt? Does it make sense from "restful"
 point of view? What's the point of having that in the REST API
 (considering that this data would be very rarely accessed and used only by
 site owners/users with the highest permissions).

 As far as I understand it the (compiled) data from all the plugins json
 files can be outputted by the REST API, in case a plugin might want to
 replace the (proposed) page in wp-admin (instead of extending it), but...
 At the end this is the same like outputting all the data for the Comments
 page for example, just because a plugin might eventually decide to replace
 it? Seems WP may get there one day but...?

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