[wp-trac] [WordPress Trac] #49272: Add support for new privacy headers in core

[WordPress Trac]

#49272: Add support for new privacy headers in core
-------------------------+--------------------------------------
 Reporter:  carike       |       Owner:  (none)
     Type:  enhancement  |      Status:  new
 Priority:  normal       |   Milestone:  Awaiting Review
Component:  Privacy      |     Version:
 Severity:  normal       |  Resolution:
 Keywords:               |     Focuses:  administration, privacy
-------------------------+--------------------------------------

Comment (by carike):

 This project is driven via core-privacy because it has the largest
 overlap.

 **However, we should remain mindful of the fact that, first and foremost,
 the purpose of the project is to help site owners / non-technical admins
 make more informed choices when choosing between plugins and / or
 themes.**

 I find that the use of a term like privacy.json causes confusion, as some
 of the items do not appear strictly related to privacy.
 I propose that we should use disclosures.json instead.



 One of the objections I hear the most often is that "plugin / theme
 authors won't understand" or will lie.

 I'd like to note here that most of these items are already covered by the
 Detailed Plugin Guidelines and the Required section of the Theme Review
 Team Handbook.

 **Licensing:**

 Plugin Requirement:

 {{{
 1. Plugins must be compatible with the GNU General Public License #
 All code, data, and images — anything stored in the plugin directory
 hosted on WordPress.org — must comply with the GPL or a GPL-Compatible
 license. Included third-party libraries, code, images, or otherwise, must
 be compatible.

 2. Developers are responsible for the contents and actions of their
 plugins.
 Developers are expected to confirm, before uploading to SVN, the licensing
 of all included files, from original source code to images and libraries.
 In addition, they must comply to the terms of use for all third party
 services and APIs utilized by their plugins. If there is no way to
 validate the licensing of a library or the terms of an API, then they
 cannot be used.
 }}}

 Theme Requirement:

 {{{
 - Be 100% GPL and/or 100% GPL-compatible licensed
 - Declare copyright and license explicitly. Use the license and license
 URI header slugs to style.css
 - Declare licenses of any resources included such as fonts or images.
 }}}

 Requiring a list of the URLs with the license terms that apply to the
 various assets isn't onerous on the authors.

 **SaaS:**

 Plugin Requirement:

 {{{
 6. Software as a Service is permitted.
 The service itself must be [...] clearly documented in the readme file
 submitted with the plugin, preferably with a link to the service’s Terms
 of Use.
 }}}

 Requiring a list of the URLs with the Terms of Service that apply to any
 SaaS element isn't onerous on the authors.

 **Contacting third party sites:**

 Plugin Requirement:

 {{{
 7.  Plugins may not track users without their consent.
 In the interest of protecting user privacy, plugins may not contact
 external servers without explicit and authorized consent. This is commonly
 done via an ‘opt in’ method, requiring registration with a service or a
 checkbox within the plugin settings. Documentation on how any user data is
 collected, and used, should be included in the plugin’s readme, preferably
 with a clearly stated privacy policy.
 }}}

 Theme Requirement:

 {{{
 Don’t ‘phone home’ without informed user consent. Make any collection of
 user data “opt-in” only and have a theme option that is set to disabled by
 default.
 }}}

 Requiring links to the privacy policies applicable to all calls to
 external servers is clearly reasonable, as plugin and theme authors should
 already be providing these anyway.

 Plugins may also not send executable code via third party systems.
 The suggested headers for the disclosures.json file would make it easier
 to evaluate whether external calls comply with this requirement or not.

 **Credits:**

 Plugin requirement:

 {{{
 10. Plugins may not embed external links or credits on the public site
 without explicitly asking the user’s permission.
 All “Powered By” or credit displays and links included in the plugin code
 must be optional and default to not show on users’ front-facing websites.
 Users must opt-in to displaying any and all credits and links via clearly
 stated and understandable choices, not buried in the terms of use or
 documentation. Plugins may not require credit or links be displayed in
 order to function.
 }}}

 Theme Requirement:

 {{{
 Themes may have a single footer credit link, which is restricted to the
 Theme URI or Author URI defined in style.css
 Themes may also have an additional footer credit link pointing to
 WordPress.org
 }}}

 Requiring that authors declare if they ask for backlinks is reasonable.

 **Advertising:**

 Plugin Requirement:

 {{{
 11. Plugins should not hijack the admin dashboard
 Upgrade prompts, notices, alerts, and the like must be limited in scope
 and used sparingly, be that contextually or only on the plugin’s setting
 page. Site wide notices or embedded dashboard widgets must be dismissible
 or self-dismiss when resolved.
 }}}

 Theme Requirement:

 {{{
 Themes should not display “obtrusive” upselling.
 }}}

 Requiring that authors declare upfront if they advertise in wp-admin is
 clearly reasonable and it allows the potential user to decide upfront if
 they are okay with some advertising in exchange for free code.

 If these items are confusing or authors are not aware of them, then we
 have bigger problems...
 These items are also checked during plugin and theme reviews,
 respectively.
 This change would effectively only be that the information needs to be
 provided in a standardized place, in a standardized format.

 **This will also make it a lot easier for reviewers.**
 (which is also incidentally why I proposed splitting the advertising into
 three, based on the location of the advertising - as doing so will make it
 easier for reviewers / potential users to decide whether or not it is
 obtrusive).

 External calls are split into three (based on the language), as this will
 affect additional checks that are planned for high risk / high impact
 functions later on.

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