Add default text for a privacy policy

[azaozz]

The text will be used to assist site owners in preparing a privacy policy and should cover the personal data that is collected in WordPress.

[azaozz]

The default text should probably include a section about embedded content supplied by third parties (YouTube, Vimeo, Amazon, Twitter, etc.) as oEmbed support is built-in.

[idea15]

Issues to consider:
-The need to clarify that the output is a means to an end - it is not a legally valid privacy notice magicked up at the push of a button. User input and review is still required
-The need to consider standardising the language and tone of the default text. No more jibberish legalese (sorry Paul).
-Consider people who do not speak English as a native language, consider children, consider people with learning difficulties

[azaozz]

We chatted a bit about this with @alendav and @xkon on Slack: ​https://wordpress.slack.com/archives/C9695RJBW/p1521738876000668

• The default text should probably cover what data is stored for registered users too, or perhaps can have an addendum?
• The privacy policy page should also be linked from the user registration form.

[allendav]

I am assuming this ticket would also support filtering so plugins could add their own suggested snippets for privacy policies for use with #43620 ?

cc @melchoyce

[azaozz]

Replying to allendav:

This is only about the "default" privacy policy text in WordPress. It will be "the base" for it. We'll add it to the policy page when creating it, and also (probably) to the policy metabox, as it should be accessible even after the policy page was created.

As @idea15 mentions above, this text should be easy to translate and will cover all of WordPress' default privacy like oEmbeds, registered user cookies, private data stored in posts, comments, user profile, etc.

It could also mention several groups of commonly used plugins like spam checks, analytics, etc.

[casiepa]

Embedded content: ​https://github.com/gdpr-compliance/info/blob/master/Privacy-policy-snippets.md#embedded-content

Cookies: ​https://github.com/gdpr-compliance/info/blob/master/Cookies.md

Stored data: ​https://github.com/gdpr-compliance/info/blob/master/Synched-info.md

Now how to put these together?

[clickysteve]

Noting that the cookie document still needs work, as it was about 90% done. I can help with that.

[desrosj]

Moving to the 4.9.6 milestone after consensus was reached in the most recent GDPR chat (​https://wordpress.slack.com/archives/C9695RJBW/p1524063200000304).

[mnelson4]

Moving to the 4.9.6 milestone after consensus was reached in the most recent GDPR chat (​https://wordpress.slack.com/archives/C9695RJBW/p1524063200000304).

I missed the meeting, so skimmed it looking for what the concensus was and didn’t find it. Does someone in the know want to update this ticket with what was decided for regarding the default text?

[idea15]

Replying to mnelson4:

Moving to the 4.9.6 milestone after consensus was reached in the most recent GDPR chat (​https://wordpress.slack.com/archives/C9695RJBW/p1524063200000304).

I missed the meeting, so skimmed it looking for what the concensus was and didn’t find it. Does someone in the know want to update this ticket with what was decided for regarding the default text?

Will have first draft late today/early tomorrow.

[idea15]

Just thinking of the section for the privacy notices on what personal data we collect. There's a lot of data which could be listed, depending on the nature of the site, some of which is WP and plugin generated, some of which is not:

• Registered user data
• Oembeds
• Visitor cookies
• Registered user cookies
• Post data
• Comments
• Spam checks
• Analytics
• Telemetry
• Contact forms
• Account creation
• Order fulfilment
• Message boards

and so on.

What are peoples' thoughts on the best way to handle this information collection and drafting without ovewhelming the site administrator, as this section of a PN alone could take as much time as the rest.

[azaozz]

Replying to idea15:

Some of these are strictly plugin related. We can "mention" that "in most cases" data may be used for .... purposes and sent to third party sites, but ultimately the plugins that do this should provide the exact info.

• Registered user data
• Account creation

These are the same and concern only users that want to register. All of the data is listed on the Profile screen. Not sure what exactly to mention about it, perhaps that only username and email are mandatory?

• Oembeds

We have a list of the default oEmbed providers, however other sites can be added by plugins and any WP site is also a provider. Thinking we need some generic text here, perhaps like "Some pages may contain embedded sections from other websites like videos, images, etc. In these cases the other site may collect personal data like IP addresses and may set browser cookies".

• Visitor cookies

No such thing in WP.

• Registered user cookies

All of these are strictly "functional", used for logging in, etc. None is used for any tracking.

• Post data (posts?)

Only registered users with sufficient capabilities can publish posts. Not sure that needs to be in the front-end visitor facing privacy policy, probably nothing. Perhaps can mention that posts contain the user ID on the Profile screen?

• Comments

WP stores the commenter IP address and browser version string in addition to what the commenter provides in the comments form.

• Spam checks

Nothing in WP by default, but can mention that all comment data may be sent to a "third party security scanning service"?

• Analytics
• Telemetry

There two are the same. Can probably mention that most sites store some visitor data to help them improve their services (Google Analytics or local/cPanel).

• Contact forms
• Order fulfilment
• Message boards

Nothing in WP. Can leave for plugins that add the forms and collect the data.

[idea15]

Worked all weekend on this and it's become apparent to me that in order to get this right, it needs to be a three part task.

1. Feeding in the automated information from plugins - per ​https://github.com/gdpr-compliance/info/blob/master/Cookies.md
2. Feeding in "snippets" which should be written in advance - per ​https://github.com/gdpr-compliance/info/blob/master/Privacy-policy-snippets.md
3. Manual input of the required business information - per ​https://github.com/gdpr-compliance/info/blob/master/Privacy-policy-snippets.md

We need to think how we achieve this in terms of

• Language (the words we want people to use)
• Structure (where we store the words we want them to use)
• The user experience (how they are prompted to create the notice).

[clickysteve]

Replying to azaozz:

Replying to idea15:

• Visitor cookies

No such thing in WP.

Not sure if I am missing the mark here, but there are some cookies that are set for visitors to WordPress sites with the default install, are there not? i.e. devicePixelRatio and wordpress_test_cookie.

[azaozz]

Replying to clickysteve:

Core doesn't use devicePixelRatio and sets wordpress_test_cookie only when a user is trying to log in, to test if cookies are enabled in their browser.

Another case is when a user accesses a password protected post. Then a cookie is set so they don't have to type the password every time.

I agree, perhaps these two cases (test and post password cookies) should be mentioned in the default privacy policy.

[clickysteve]

Replying to azaozz:

Replying to clickysteve:
I agree, perhaps these two cases (test and post password cookies) should be mentioned in the default privacy policy.

Thanks for confirming. I think it would be a good idea to explicitly mention them, if only to demonstrate the limited cookies set by Core by default. That said, they should really be listed in a cookie policy rather than the privacy policy. Best practice is to have separate privacy and cookie policies, though I'm not entirely sure what the plan is in that regard.

Also worth considering how what we plan to include with Core will be mirrored on WordPress.org itself, as the language should really be consistent.

[idea15]

I was looking at the draft article I wrote on privacy notices for the upcoming privacy resource centre and here is what I'm thinking about how that needs to translate to the privacy notice tool.

​https://docs.google.com/document/d/18mVeWW3-7Y_opyGj5XqXHcXRJjdxxPRWzyb4dFDDPIo/edit?usp=sharing

The user should be able to choose from the the following available headings:

• Who we are
• What personal data we collect and why we collect it
  • Their own manually input information
  • WP: Contact forms
  • WP: Comments
  • WP: Cookies
  • WP: Third party embeds
  • Analytics
• Who we share your data with
• How long we retain your data
• What rights you have over your data
• Where we send your data
• Your contact information
• How we protect your data
• What data breach procedures we have in place
• What third parties we receive data from
• What automated decision making and/or profiling we do with user data
• Any industry regulatory disclosure requirements

Each section would then have instructional text as I've written in the draft article, for example

Your contact information

In this section you should provide an email address where you can be contacted for privacy-specific concerns. If you are required to have a Data Protection Officer, list their name and full contact details here as well.

Where the notice tool pulls in information from plugins, or from text available elsewhere such as text snippets or the list of cookies, that would be an option to add within that section.

What does everyone think?

[idea15]

(This is now getting into how this ticket relates to #43435 - my focus here is the words.)

[xkon]

If these are all just set as 'standards' to choose from I can think of 2 things:

1] The above list could be 'pre-populated' into the Editor upon creating a new Privacy Policy Page since the Editor is 'empty' by default.
2] Place an extra 'static' expandable area into the existing postbox of #43435 with these so they can again copy/paste them with a link to the article so they can read the full explanations.

Why I'm saying this: we already have a page that will be showing all extra custom meta boxes that plugins might be adding on a site + our own for the Policy Texts it will already be a somewhat hectic page to look at, if we add 'yet another extra' thing that they have to click here get that do this it is going to be overwhelming imho.

I'd just prefer them to be 'with' the incoming policy texts just for the ease of use and everything will seem 'grouped' together if that makes sense.

[idea15]

That's why I asked. We don't want to overwhelm the user but at the same time we shouldn't pretend that they aren't accountable for a lot of information.

[azaozz]

Replying to idea15:

This is a pretty good tutorial on how to write a privacy policy :)

The user should be able to choose from the the following available headings:

I was imagining the "default policy text" to be something that covers the default WordPress installation. I.e. if I install WP and don't add any plugins or themes that use personal data, this text should be pretty much all I need for the privacy policy.

In that terms the default text should be something like:

• Who we are

[Site URL.]

• What personal data we collect and why we collect it
  • Their own manually input information
  • WP: Contact forms
  • WP: Cookies

None of the above.

• WP: Comments

Only applies to visitors that leave comments on the site. We collect the data shown in the comments form, and also the visitor's IP address and browser user agent string to help spam detection.

• WP: Third party embeds

There can be unlimited number of embeds. Needs text that "covers" all up to a certain level. All embeds are Pieces from other websites that are shown on our website. They behave in the exact same way as if the visitor has visited the other site..

• Analytics

None by default. Can mention GA and wp.com/Jetpack as common analytics services.

• Who we share your data with

Nobody.

• How long we retain your data

For visitors that leave comments: indefinitely. This is so we can recognize and approve any follow-up comments automatically instead of holding them in a moderation queue.

For users that register on the site (if any), we also store the data they provide in their profile. All registered users can see, change or delete most of that data at any time except their login name/nickname.

• What rights you have over your data

If you are a registered user or have left comments on our site you can request to see or download the data we have about you. Typically for visitors that have left comments that will be their email address, any IP addresses assigned to them at the time of leaving the comments and the browser user agent strings of the browsers they used. The rest of the data is public as published by the visitors.

You can also request "to be forgotten" and we will erase any personally identifiable data we have about you, typically a year after it was published. Of course this excludes data we need for administrative or security purposes or if we are required by law to retain some of the data.

• Where we send your data

For visitors that leave comments we may send the data to a spam detection service.

• Your contact information

[contact form URL?]

• How we protect your data

All access to sensitive areas of our site is password protected.

• What data breach procedures we have in place

If our site is compromised we will do our best to establish if any personal data was accessed and inform the affected users.

• What third parties we receive data from

None.

• What automated decision making and/or profiling we do with user data

For users that leave comments we may send the comment data to a spam detection service. We don't do anything else for any users.

• Any industry regulatory disclosure requirements

Are there any we can add by default?

[idea15]

We can't put words into users' mouths, but we do have to give them all of the prompts they will be required to show with a European-compliant privacy policy. Even if the WP install out of the box does not generate any data that would fit under any given prompt, they still need those prompts so that they know what to write.

[xkon]

@azaozz Aren't all those 'replies' you wrote going to be mentioned in the postbox under WordPress since they concern pure core? If yes I'm not sure if it's of any help to add them again by default in the editor for example. We will already be pushing them to the users the same way as everybody else. Let them figure it out on their own what they want to copy/paste etc that's not our thing to do imho.

[xkon]

I'm not sure if I have this 100% right as we have different texts in different places and ideas ( git / docs / notes etc ). But I went with @azaozz 's thinking to actually add the default text that is suggested on his comment as that would cover a base install.

Notes on 43473_default_policy_text.diff​ :

Preview 43473_default_policy_text.jpg​ is on a default Twenty Fifteen theme as soon as the Privacy Policy page is created.

I went with using <h3>, <h4>, <p> to keep it simple and as it's the usual 'suspects' in tags that are in a page. I left <h1> out as it's usually meant for the pages title and <h2> as they might want to add an extra header etc. If we're going to add notes I was thinking of <em>.

Questions:

• oEmbeds: Do we just write a general text + input the whole list from ​https://github.com/gdpr-compliance/info/blob/master/Privacy-policy-snippets.md#embedded-content , or just a text ?
• Any industry regulatory disclosure requirements : no idea what to put there.
• Is this text going to be transfered on the WordPress in the postbox -as is- ? If yes I can easily do that as well, so they can go back and copy/paste whatever they like.
• Do we want to also include the texts from @idea15 doc as a guideline? If yes that page will be super heavy on writing and probably not easy to read. I believe that help should be somewhere online & centralized and we just communicate the link for the people to go and read further.

-- Hopefully I didn't mess this up x_x, having texts all over without knowing 100% what to get after all the suggestions I just went with whatever felt best.

[azaozz]

In 43473.patch:

• Continuing from 43473_default_policy_text.diff.
• Moved the policy content to get_default_content().
• Added the help/tutorial content from the above doc.
• Added most of the default content.

@idea15, @allendav, @xkon please edit and review before we submit this for a final review by @pesieminski :)

[xkon]

@azaozz

Notes on text:

• The explanations + default text seem ok to me ( I can easily understand everything and I'm not in my native language by far :) )
• I prefer the way you went with cookies on not specifically stating the actual cookies / by name since that could end up being more difficult for some admins to follow.

Notes in general ( but I don't know if they are for this specific ticket to handle ):

1 ] There are only a couple of places with a WP Default Text and everything else are explanations. If everything was pre-filled by both it could make more sense.

Maybe we should leave the Editor text as a Tutorial and push into the WordPress - postbox all the WP default stuff? This way UX & flow wise any user would understand that this is a text to be edited by 100% not just 'delete all <em> and we're covered'.

2 ] I asked in polyglots before creating my diff if we should go for 1 big blob of text or split into headings/answers this was the reply -> ​https://wordpress.slack.com/archives/C02RP50LK/p1524902883000026 ( I can do that 'dirty' work of splitting them after the texts are done and if that's the way to go ofc ).

[idea15]

My idea was that the guidance texts (e.g. "in this section you should..." would not appear inline in the actual page text, but would be guidance within the interface.

If we put the guidance texts inline we're going to have several million web sites out there with "in this section you should..." as their privacy notice.

[xkon]

can we do something like this maybe?

[idea15]

That's exactly where I want to head. Let me pick up tomorrow.

[ocean90]

Re: 43473.patch​: As @xkon has already mentioned, the text must be split into several translatable strings without any HTML if possible.

Pre-filling the post_content might be a bad idea for locales which don't get the translation ready in time. Those sites would store the English text which means it needs to be manually translated by the editor.

[azaozz]

Replying to xkon:

There are only a couple of places with a WP Default Text and everything else are explanations. If everything was pre-filled by both it could make more sense.

If we put the guidance texts inline we're going to have several million web sites out there with "in this section you should..." as their privacy notice.

Right. This is on purpose :)

1. How do you get all admins to edit their privacy policies before publishing them? It is much more likely to happen when there is text they will have to remove/delete.
2. How do you show the tutorial text on the Edit Page screen, and where? It is too bulky to fit anywhere, I mean, we don't want another bigger box with a scrollbar above or below the editor. Even if we add one, the user will never be able to see all three boxes (the editor, the policy text postbox, and that box with the tutorial. So it will be very very inconvenient to edit the policy and look at the tutorial at the same time.

the text must be split into several translatable strings without any HTML if possible.

...I can do that 'dirty' work of splitting them

OK, lets try that. Hoping the out of context strings won't be a big problem.

[xkon]

43473_split_all_texts.diff​ continues on the text + php class of 43473.patch and:

• splits all sentences into single translation texts
• adds an extra method in the class and separates the editor content with the postbox content
• Postbox shows the 'default WordPress policy' as seen in, editor just has the headings for a 'map' as seen in 43473_split_all_texts_privacy_policy_page.png​ ( Note: I removed the height of the postbox just so I can grab the screenshot and you can preview the text more easily ).
• Privacy Policy Settings page shows the 'tutorial' as seen in 43473_split_all_texts_privacy_settings.png​

Sorry about the 1 !important rule in the CSS but instead of moving the whole block at the moment to make the <h2> stick I thought 1 specifically targeted h2 wouldn't matter having an !important rule. If not we can easily fix it ( did it this way to have a cleaner .diff at the moment ).

[azaozz]

In 43473.1.patch:

• Split the text into lines/paragraphs for easier translation.
• Made it an "editor template" and added some explanations at the top on how to use it.

Note that the italics sections are non-editable in the editor (see the above screenshot). We can also remove them automatically on saving the page, but perhaps should leave the editing to the users.

[xkon]

@azaozz 43473.1.patch​ is brilliant imho! The contenteditable="false" makes it absolutely spot on in both easy editing + giving 1 extra 'hint' that this text HAS to go. And it's copy-pastable again from the meta-box for future misshaps so that is surely a nice extra.

I wouldn't touch anything on 'update' either, leave it to them to delete/add anything they like, let's not 'vanish' stuff from their eyes :D

I'll re-check the whole text from back home this afternoon if there's anything missing from all the editing but UX wise I think this is a really good way to present this.

[azaozz]

Replying to xkon:

43473.1.patch​ is brilliant imho! The contenteditable="false" makes it absolutely spot on in both easy editing + giving 1 extra 'hint' that this text HAS to go. And it's copy-pastable again from the meta-box for future mishaps so that is surely a nice extra.

Thanks! I'm glad you like this approach :)

Going to commit this to be easier to test. It is still pending a review.

[azaozz]

In 43044:

Privacy: add default text for a privacy policy. First run.

Props xkon, idea15, allendav, azaozz.
See #43473.

[azaozz]

The current suggested text. Paragraphs with class="wp-policy-help" are part of the template and should be deleted before publishing.

[idea15]

Final text edits

[azaozz]

In 43048:

Privacy: edits and improvements for the default text for a privacy policy.

Props idea15, allendav.
See #43473.

[melchoyce]

Still seeing a lot of empty space: ​https://cloudup.com/czTs74VtPQr

Will review the new notes/tips interface.

[azaozz]

In 43052:

Privacy: only fold the sections in the privacy policy poxtbox when more than one.

See #43473.

[azaozz]

Replying to melchoyce:

Should be fixed in r43052.

[melchoyce]

Replying to azaozz:

Replying to melchoyce:

Should be fixed in r43052.

Looks like if you "Read More," and then click "Read Less," it collapses down to the smaller size again.

[melchoyce]

Okay, two ideas: Policy: Inline Help: Notices.png and Policy: Link.png.

Inline Notices

Display the help text in our regular WordPress info notices. You can X out of them, but ether way they won’t be rendered in your page, just within the editor block. It uses standard WordPress styles and is attention-grabbing, but takes up a lot of space within the editor.

Link to Guide

Alternately, we could write either a post or a handbook entry guiding folks through filling out their Privacy Policy page, and then link to it at the bottom of the policy metabox. This keeps your admin/editor from getting overwhelming, and allows for additional expansion later on if we decide to write more about privacy policies. This would be my top recommendation.

Regardless of which solution we pick, we shouldn't show the help text within the policy metabox — it takes up a lot of room in a space that's already quite cramped, and it's unclear that the help text isn't a part of your policy itself.

[allendav]

Docs for end user / plugin handbook on how to use wp_add_privacy_policy_content

[allendav]

I've been getting a lot of inquiries on how to use wp_add_privacy_policy_content so I wrote PRIVACY-POLICY-CONTENT-HOOK.md which we can copy into the plugin handbook just like EXPORT.x.md and ERASURE.x.md

[allendav]

Saved the previous file too quickly

[idea15]

@melchoyce I like the inline notices. The external guide for linking should be ready soon (need to double down on that with Paul S)

[azaozz]

Replying to idea15:

The external guide for linking should be ready soon...

Please keep in mind that we (probably) cannot link to any other place than wordpress.org. When a user clicks on a link, the linked site gets the referring site's "private information", IP address / domain name. This is pretty much the same "private data" as when WordPress checks for updates...

I'm not sure how that is/will be handled under the GDPR, but for now seems that any user is "spreading" any site's "private info" by clicking on any external link.

[azaozz]

Replying to melchoyce:

Inline Notices

Display the help text in our regular WordPress info notices. You can X out of them, but ether way they won’t be rendered in your page, just within the editor block. It uses standard WordPress styles and is attention-grabbing, but takes up a lot of space within the editor.

So basically we will use the template with inline help/info but remove that help on saving the page? That was my first idea too but the problem is that when the user saves a draft, the help texts will be removed.

Also, if we remove the help content from the template shown in the postbox, the users will not be able to see that text at all after the policy is saved. It will just disappear.

Link to Guide

Alternately, we could write either a post or a handbook entry guiding folks through filling out their Privacy Policy page, and then link to it at the bottom of the policy metabox. This keeps your admin/editor from getting overwhelming, and allows for additional expansion later on if we decide to write more about privacy policies. This would be my top recommendation.

Yeah, we will need to link to some external resources on wordpress.org in any case. One problem with this is that very few users will actually go to check that out. Another problem is that following a guide that keeps changing every few days is pretty tedious. We can have "extended references" as external link, but think that'd be pretty bad as the main source of help.

If we go with this we will be inserting mostly a "bare skeleton" of section and subsection headings as the suggested policy content. Since the subject matter is pretty new or unknown for most users they will be really lost :) I agree, this may "persuade" them to look for additional help, but since the WordPress suggested text is usually folded in the postbox, it's not going to be easy.

We can add it at the top and not fold it, but then texts added by plugins will always be under the fold and hard to find...

Regardless of which solution we pick, we shouldn't show the help text within the policy metabox — it takes up a lot of room in a space that's already quite cramped,

Yeah, I understand. The help text is indeed quite long, and there's no way we can shorten it.

Having to use another browser tab/page seems worse? Trying to follow instructions on one page and write on another is super inconvenient; need to be switching between the two pages all the time, very easy to loose context, etc. Ideally the screen should be split horizontally with the instructions in one half and the editor in another. That's what I was trying to achieve by adding the postbox.

it's unclear that the help text isn't a part of your policy itself.

Hm, the content is pretty different. Perhaps we can change the styling even more to enhance that difference (if we keep that)?

I've been wondering for a while which is the "lesser inconvenience" when displaying the privacy policy help text. The current way adds a "plain text template" where the help is inline and the user needs to delete it while editing. This seems the simplest way. It may not be super intuitive but describing what to do at the top will help.

Alternatively we can do the second options above, but instead of having an external link to the help, we can add it in the postbox. That way it will be "front and center" when the users visits the edit policy page, and they will be able to see the help and use the editor at the same time. To do that thinking we can replace the current We suggest reviewing this text then copying and pasting it into your privacy policy page... text with the full help text and make it foldable.

I'm actually going to make a quick patch to see how that would look/feel :)

[azaozz]

In 43473.2.patch:

• Add the privacy policy tutorial at the top in the policy content postbox and make it blue.
• Remove the tutorial notes from the suggested text leaving empty paragraphs where we don't have any suggestions.

There is no copy button for the tutorial text :) but there are Read More/Read Less buttons.

[allendav]

Feedback on privacy-policy-tutorial.txt

Please edit your privacy policy content, and add any information from your themes and plugins. You will find it under this tutorial.

Not all plugins will hook privacy policy content, especially right away. Please add a sentence to the effect that “Not all themes and plugins will provide information here - you will want to review your active plugins and theme to make sure that you’ve covered them all.”

Who we are

Would it be possible to highlight the section titles or make them headings? They kinda blend into the text right now.

In this section you should note what personal data you collect from users and site visitors. This may include transactional data, such as purchase information; technical data, such as information about cookies; and personal data, such as user account information.

I would start the “may include” list with the most likely examples for a WordPress site, e.g. “a user’s name or email address…”

“You must also note any collection and retention of sensitive personal data…”

I like how we’ve tended to use “you should” elsewhere. It sounds less legal - and we want to avoid appearing to give legal advice. Could we change “must” to “should?”

“In addition to listing what personal data you collect, you need to note why you collect it. These explanations must note…”

“need to” to “should” and “must note” to “should note”

“By default WprdPress…”

WrpdPress to WordPress

“and only collects the data shown on the User Profile screen fro registered users…”

“fro” to “from”

“However some of your plugins may collect personal data, add the relevant information below.”

“add” to “so, you should add”

Comments. In this subsection you should note what information is captured through comments.

Please add “We have noted the data which WordPress collects by default.”

Embedded content

Do we include the list o’ links I pulled together for embeds and if so, let’s add “We have noted the embeds which WordPress supports by default along with links to their respective privacy policies.”

In this subsection you should note what analytics package you use

Change “what” to “any” - not everyone will have an analytics package

By default WordPress does not share any personal data with anybody.

Change “anybody” to “anyone”

security measures such as 2FA

I’d spell out 2FA as “two factor authentication”

and human measures such as staff training

I’d drop the word human

[allendav]

Feedback on privacy-policy-default-text.txt

Who we are

Would it be possible to make this (and other section headings) headings or bold or something automatically? To make them stand out?

Our website address is: ​http://local.my/trunk3/src.

Could we leave out the local.my address and just stop at the colon, or include a _ ?

If you are a registered user and upload images to the website, you should avoid uploading images with EXIF GPS location data included. Visitors to the website can download and extract any location data from images on the website.

I would make this a new sub section “Media” and move it below Comments

Contact forms

I would move this below Comments

Comments

I would move this up - this is the most likely default behavior that collects personal data for a WordPress site

You can also request that we delete

I’d change “delete” to “erase” to be consistent with the UI + GDPR terminology

This may be located abroad.

I don’t think this helps. I recommend deleting it. Whatever service they use - we’ve already prompted them to add details here.

[melchoyce]

Replying to azaozz:

So basically we will use the template with inline help/info but remove that help on saving the page? That was my first idea too but the problem is that when the user saves a draft, the help texts will be removed.

Also, if we remove the help content from the template shown in the postbox, the users will not be able to see that text at all after the policy is saved. It will just disappear.

No — the notices would remain in the editor, but they wouldn't be rendered on the front-end of your site.

[melchoyce]

Replying to azaozz:

Alternatively we can do the second options above, but instead of having an external link to the help, we can add it in the postbox. That way it will be "front and center" when the users visits the edit policy page, and they will be able to see the help and use the editor at the same time. To do that thinking we can replace the current We suggest reviewing this text then copying and pasting it into your privacy policy page... text with the full help text and make it foldable.

I'm actually going to make a quick patch to see how that would look/feel :)

Testing the patch — it honestly feels even more overwhelming and confusing to have the content duplicated like this. Like, I'm finding it even more stressful on a page that is already generating quite a bit of stress.

[azaozz]

Replying to melchoyce:

No — the notices would remain in the editor, but they wouldn't be rendered on the front-end of your site.

This is not that easy to do. We either have to add another display filter and parse the post content (kind of slow-ish), or have to add some form of hack like inline styles with display: none;, however that will leave the content in the policy page. Also, no idea how that could be done in Gutenberg at all.

[azaozz]

In 43126:

Privacy: do not fold a single section in the privacy policy poxtbox.

See #43473.

[Clorith]

#43944 was marked as a duplicate.

[azaozz]

In 43473.3.patch: add the changes suggested by @allendav in comment 59 and comment 60. Also privacy notice => privacy policy as per #43875.

[azaozz]

Would it be possible to highlight the section titles or make them headings?

They are headings, h2 and h3 :) They look good once pasted in the editor but the styling in wp-admin makes them look that way in the postbox. Perhaps should add some "custom" styling there.

Could we leave out the local.my address...

This is replaced with the site's URL "dynamically". The actual string is 'Our website address is: $1%s.'.

[azaozz]

After many attempts and deliberations this seems good for now, imho.

• The "suggested content" is added as usual and does not include help texts. The sections without content have messages asking the user to look at the tutorial.
• The tutorial is added at the bottom of the postbox. I know we talked about a link there, but we cannot use an external page (for now) as it will have to be translated in all languages. Perhaps having the folded tutorial at the bottom is an acceptable compromise? :)

The 43473.4.patch also includes the changes from 43473.3.patch.

[melchoyce]

The tutorial makes this page more confusing, and now you have to juggle between multiple panels inside a metabox. It's an incredibly frustrating experience.

I'm attaching an additional idea. This one embraces the concept of putting the help text into the editor, but it highlights that text so it's really obnoxious. The bright coloring is instantly noticeable, and will also render on the front-end, making it clear that you need to delete the text before publishing your policy.

However, I still think linking to a page on WordPress.org is the best option. We do have translated content on WordPress.org and WordPress.net (for example, ​https://wp15.wordpress.net/). I'm sure we could figure it out.

[azaozz]

Replying to melchoyce:

However, I still think linking to a page on WordPress.org is the best option.

That page can also be somewhere in WordPress, no need to be external. Then it will get translated in time. If it is OK to have the suggested content on another page, perhaps we can move all of the postbox content there? It will still be quite a bit of text, but.... don't see any way around that.

I'm afraid that once the plugins start to add privacy info, the text in the postbox will become --huge--, even if the tutorial is not in there :)

[macbookandrew]

Fix some typos and grammatical issues

[karmatosed]

There's a lot visually going on the current version, I am totally in agreement with @melchoyce on this that simplification needs to happen. The last thing anyone deep in worry about GDPR (which is the state of most people right now) needs is to have a complicated page like this be their experience.

If at all possible I would strongly suggest having extra information attached as a link. I can see plus and minus points for that being within WordPress. I don't feel that's a hill to stand on personally, but having it not all in this screen feels like it should be. I would note that having it linked as part of a handbook could be amazing as far as resources go for people. It could also allow not just committers to edit the content. Maybe a point worth considering as with all things these regulations could evolve.

[macbookandrew]

Fixes a couple more inconsistencies

[azaozz]

In 43146:

Privacy: change how the default text for privacy policy is added:

• Insert both the text and tutorial in new policy pages and highlight is brightly in the editor.
• Show only the suggested text in the policy postbox.

Props melchoyce, azaozz.
See #43473.

[azaozz]

In 43148:

Privacy: fix typos and inconsistencies in the default suggested text.

Props macbookandrew.
See #43473.

[azaozz]

In 43149:

Privacy: add default text for a privacy policy including a tutorial on now to create one.
Insert both the text and tutorial in new policy pages and highlight is brightly in the editor.
Show only the suggested text in the policy postbox.

Props melchoyce, idea15, allendav, xkon, macbookandrew, azaozz.
Merges [43044], [43048], [43052], [43126], [43146], and [43148] to the 4.9 branch.
Fixes #43473.

[birgire]

43473.7.diff​ fixes a docs typo and suggests using the more familiar %s placeholder for sprintf, instead of $1%s for str_replace(). Translators might not be familiar with the latter form?

[azaozz]

In 43150:

Privacy: use sprintf() in translations.

Props birgire.
See #43473.

[azaozz]

In 43151:

Privacy: use sprintf() in translations.

Props birgire.
Merges [43150] to the 4.9 branch.
See #43473.

[danieliser]

I didn't see it mentioned but during testing of integrating a real plugin I found that it seems out of order without some explicit filters for listing things like cookies.

If I just append our plugin suggested text to the end and it has cookies, they will be separate from the "Cookies" section further up.

Is there plans to implement something to the effect that we could register our cookies like the exporters?

<?php
add_filter( 'wp_privacy_policy_cookies_list', function ( $cookies = array() {
    $cookies['cookie_name'] = [
        'label' => __( 'Cookie Label' ),
        'reason' => __( 'Used for reason x, y & z' ),
    ];

    return $cookies;
});

The same would apply to several other sections. I think outputting those into a simple 2 column table would be easy to work with, clean output and easy enough for plugins & themes to integrate with.

You could do similar and register user meta info collected, or even specific analytics plugins could output label and info on how they use the data directly under the Analytics heading.

Monster Insights, for instance, might add

• Google Analytics: Tracks visitor engagement with the site anonymously for use in marketing & improvement.

[mnelson4]

+1 to @danieliser’s idea. That should probably be another ticket though

[danieliser]

I would like some clarification on exactly how the current implementation would be extended by a plugin, I have written up a guide to GDPR compliance via the new core methods (as I know doc team is working on it but will be some time, and there simply isn't much time left), and I included basic usage of how this new policy suggestion system works and the helper function etc. But even myself I am not clear on what I would use it for currently as it's disconnected from the main privacy suggestion block without the suggestions I made above.

Are we supposed to duplicate each section heading and list how our plugin affects that section of their policy?

Just want some clarification on how you envision it working on our end.

[danieliser]

@azaozz, @melchoyce What about changing it up to a concept like I proposed here: https://core.trac.wordpress.org/ticket/43981#comment:3

Think that would be a really streamlined methodology to adopt (IMO).

[desrosj]

Moving to the new Privacy component.