#43473 closed enhancement (fixed)
Add default text for a privacy policy
Reported by: | azaozz | Owned by: | idea15 |
---|---|---|---|
Milestone: | 4.9.6 | Priority: | normal |
Severity: | normal | Version: | |
Component: | Privacy | Keywords: | gdpr 2nd-opinion has-patch commit |
Focuses: | Cc: |
Description
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.
Attachments (31)
Change History (121)
#2
@
7 years ago
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
#3
@
7 years ago
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.
#4
follow-up:
↓ 5
@
7 years ago
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
#5
in reply to:
↑ 4
@
7 years ago
Replying to allendav:
This is only about the "default" privacy policy test 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.
This ticket was mentioned in Slack in #gdpr-compliance by azaozz. View the logs.
7 years ago
#7
@
7 years ago
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?
#8
@
7 years ago
Noting that the cookie document still needs work, as it was about 90% done. I can help with that.
#9
@
7 years ago
- Milestone changed from 5.0 to 4.9.6
- Owner set to webdevlaw
- Status changed from new to assigned
Moving to the 4.9.6 milestone after consensus was reached in the most recent GDPR chat (https://wordpress.slack.com/archives/C9695RJBW/p1524063200000304).
#11
follow-up:
↓ 12
@
7 years ago
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?
#12
in reply to:
↑ 11
@
7 years ago
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.
#13
follow-up:
↓ 14
@
7 years ago
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.
#14
in reply to:
↑ 13
;
follow-up:
↓ 16
@
7 years ago
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.
#15
@
7 years ago
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.
- Feeding in the automated information from plugins - per https://github.com/gdpr-compliance/info/blob/master/Cookies.md
- Feeding in "snippets" which should be written in advance - per https://github.com/gdpr-compliance/info/blob/master/Privacy-policy-snippets.md
- 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).
#17
in reply to:
↑ 16
;
follow-up:
↓ 18
@
7 years ago
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.
#18
in reply to:
↑ 17
@
7 years ago
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.
This ticket was mentioned in Slack in #gdpr-compliance by mnelson4. View the logs.
7 years ago
This ticket was mentioned in Slack in #gdpr-compliance by azaozz. View the logs.
7 years ago
#21
follow-up:
↓ 25
@
7 years ago
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?
#22
@
7 years ago
(This is now getting into how this ticket relates to #43435 - my focus here is the words.)
#23
@
7 years ago
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.
#24
@
7 years ago
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.
#25
in reply to:
↑ 21
@
7 years ago
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?
#26
@
7 years ago
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.
#27
@
7 years ago
@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.
This ticket was mentioned in Slack in #core by jeffpaul. View the logs.
7 years ago
This ticket was mentioned in Slack in #gdpr-compliance by azaozz. View the logs.
7 years ago
This ticket was mentioned in Slack in #gdpr-compliance by mnelson4. View the logs.
7 years ago
#31
@
7 years ago
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 thathelp
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.
#32
@
7 years ago
- Keywords has-patch 2nd-opinion added; needs-patch removed
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 :)
#33
follow-up:
↓ 37
@
7 years ago
@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 ).
#34
@
7 years ago
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.
#36
@
7 years ago
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.
#37
in reply to:
↑ 33
@
7 years ago
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 :)
- 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.
- 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.
#38
@
7 years ago
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 ).
#39
@
7 years ago
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.
#40
follow-up:
↓ 42
@
7 years ago
@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.
This ticket was mentioned in Slack in #gdpr-compliance by azaozz. View the logs.
7 years ago
#42
in reply to:
↑ 40
@
7 years ago
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.
@
7 years ago
The current suggested text. Paragraphs with class="wp-policy-help"
are part of the template and should be deleted before publishing.
This ticket was mentioned in Slack in #gdpr-compliance by desrosj. View the logs.
7 years ago
#47
follow-up:
↓ 49
@
7 years ago
Still seeing a lot of empty space: https://cloudup.com/czTs74VtPQr
Will review the new notes/tips interface.
#49
in reply to:
↑ 47
;
follow-up:
↓ 50
@
7 years ago
- Keywords has-patch commit added; needs-patch removed
#51
follow-up:
↓ 56
@
7 years ago
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.
#52
@
7 years ago
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
#53
follow-up:
↓ 55
@
7 years ago
@melchoyce I like the inline notices. The external guide for linking should be ready soon (need to double down on that with Paul S)
This ticket was mentioned in Slack in #gdpr-compliance by azaozz. View the logs.
7 years ago
#55
in reply to:
↑ 53
@
7 years ago
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.
#56
in reply to:
↑ 51
;
follow-ups:
↓ 62
↓ 63
@
7 years ago
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 :)
This ticket was mentioned in Slack in #gdpr-compliance by azaozz. View the logs.
7 years ago
#58
@
7 years ago
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.
#59
@
7 years ago
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
#60
@
7 years ago
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.
This ticket was mentioned in Slack in #gdpr-compliance by desrosj. View the logs.
7 years ago
#62
in reply to:
↑ 56
;
follow-up:
↓ 64
@
7 years ago
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.
#63
in reply to:
↑ 56
@
7 years ago
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.
#64
in reply to:
↑ 62
@
7 years ago
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.
This ticket was mentioned in Slack in #gdpr-compliance by azaozz. View the logs.
7 years ago
#69
@
7 years ago
In 43473.3.patch: add the changes suggested by @allendav in comment 59 and comment 60. Also privacy notice
=> privacy policy
as per #43875.
#70
@
7 years ago
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.'
.
This ticket was mentioned in Slack in #gdpr-compliance by xkon. View the logs.
7 years ago
#72
@
7 years ago
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.
#73
follow-up:
↓ 75
@
7 years ago
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.
This ticket was mentioned in Slack in #core by desrosj. View the logs.
7 years ago
#75
in reply to:
↑ 73
@
7 years ago
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 :)
#76
@
7 years ago
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.
This ticket was mentioned in Slack in #gdpr-compliance by desrosj. View the logs.
7 years ago
#81
@
7 years ago
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?
This ticket was mentioned in Slack in #gdpr-compliance by xkon. View the logs.
7 years ago
#85
follow-up:
↓ 86
@
7 years ago
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.
#86
in reply to:
↑ 85
@
7 years ago
+1 to @danieliser’s idea. That should probably be another ticket though
#87
@
7 years ago
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.
#88
@
7 years ago
@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).
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.