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

 I agree with @TimothyBlynJacobs here on using a completely new file to
 support this (it might as well be a JSON for the ease of use). This would
 give us the freedom to create free functionality and built it as needed to
 fulfill the purposes of the DPT and also "tag" it along with all other
 existing `wp_privacy_` functionality.

 I see in the text that the mentions are specifically for "plugins". By
 introducing a new file allow me to take this a step further and say that
 Themes may as well use some of these "headers" and as on any privacy-
 related functionality at the moment, we don't exclude anyone, the
 functions/filters are there and anyone can tap into them.

 Unfortunately, it's a common misunderstanding that we're only dealing with
 plugins because the Privacy functionality is documented under Plugins (not
 sure where else we can move them but we might as well talk about this
 again with the Docs team 🙂).

 To give an example, a Theme comes bundled with plugins (not by externally
 requiring them but actually includes the .zips and asks for immediate
 installation if not automatically set them up as well else the theme won't
 be working).

 In this instance, it's up to the theme author to actually inform of all
 their "built-in" functionality and what they are doing along with those
 extra plugins. Complicated yes, but that's why it has to be general and
 including every author, not only plugin authors.

 About the "headers":

 **External Network Calls PHP/JS/CSS** could be combined into just External
 Network Calls.

 IMO there will be absolutely no difference in the eyes of an everyday user
 if the website is making JS or PHP external calls. They are just external
 calls.

 Also, I don't think that we can expect from any author to literally write
 down every single external call that a plugin/theme might be doing. For
 plugins, it might be easier but for themes as an example it wont.

 Imagine building a theme that comes bundled with a "Preview/Showcase"
 template and that template goes and sets up external images in content
 instead of downloading them all locally or pre-bundling them. I don't
 think that it's optimal or expected for anyone to just note down all of
 these calls. Please do correct me if I'm misunderstanding something here,
 an external image via CSS in my eyes is an "External Call".

 By the example above, I believe that I'm already covering that **Remote
 Assets** & **Calls to External APIs** look kind of similar to this as
 well.

 **Sets Cookies PHP/JS** could be combined into Sets Cookies.

 Similar to network calls, what would be the difference in the eyes of a
 user from what language the cookies are set? None in my opinion and
 there's no need to create unnecessary confusion.

 **Code Audited by Third Party**, what would be the purpose of this
 exactly? I don't believe that the majority of plugins/themes have their
 code audited by a 3rd party and if it was, how do I know as a user that
 the 3rd party selected is OK and why should I feel comfortable with it? If
 by 3rd party this means even automated tools like RIPS, SonarCloud, etc
 out of which some of them include security scans, that's not something for
 a DPT I think again but something for their general description if they
 want to showcase it at their own free will.

 All of the other headers look fine to me as they are related to WordPress
 functionality.

 One last note, I'm not entirely sure what `null` means in this instance.
 Everything is basically True/False as far as I can see and if omitted
 False by default.

 --

 Don't get me wrong, I'm all in for including this functionality and I'll
 be more than happy to help start patching ASAP but I would still like it
 to be understood by the majority of our users not just by experts on the
 matter.

 Simplifying things can go a long way as everything is already complicated
 for an everyday user that has a website and unfortunately they are going
 to become even more complicated in regards to regulations. Let's try to
 keep it as simple as possible.

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