#43435 closed enhancement (fixed)
Add settings screen for creating a privacy policy
Reported by: | azaozz | Owned by: | idea15 |
---|---|---|---|
Milestone: | 4.9.6 | Priority: | normal |
Severity: | normal | Version: | |
Component: | Privacy | Keywords: | gdpr fixed-major has-dev-note |
Focuses: | Cc: |
Description
Add a page under the Tools menu to make it easier to create comprehensive privacy policy.
By default WordPress doesn't collect any data from visitors unless they post a comment. However many plugins add third party services that collect visitor data. Also most embeds may collect data or add cookies (including from iframes).
A good privacy policy would disclose some or all of the ways a site gathers, uses, discloses, and manages user data (see https://en.wikipedia.org/wiki/Privacy_policy). To be able to create such policy a site owner will need to know how each plugin operates, if it sends data to third parties, if it stores personal data, etc.
Good way to gather all information from core and plugins is to have a separate screen for it. All plugins will have a place to output the necessary details and the site owner will be able to compose the privacy policy based on all information.
Attachments (11)
Change History (123)
#2
follow-up:
↓ 3
@
7 years ago
Would this overwrite existing Privacy Policy pages created through the standard Pages section of wp-admin
? This seems like it would have some overlap with the Meta (more so Plugins) team to ensure plugins that collect any data disclose the fact. I think the main onus is on the site owner, however I think some reasonable steps should be made in ensuring plugins hook into some kind of Privacy screen and disclose what information is sent.
#3
in reply to:
↑ 2
@
7 years ago
Replying to danieltj:
Would this overwrite existing Privacy Policy pages created through the standard Pages section of
wp-admin
?
No. This ticket is mostly about the mechanism of creating a privacy policy, how to include plugins data in it, and where plugins would display that data.
#4
follow-up:
↓ 5
@
7 years ago
So thoughts on this. I think it would make sense for all plugins that get accepted in the WordPress.org repository to have mandatory privacy information, outlining what data they collect and how they use it. It would be something plugins must do in order to be accepted into the repository. Part of the review process for plugins could then be to check that the data collection being declared is correct.
It seems to me that this should be part of the readme.txt
file for a plugin. It could have a compulsory "Privacy Information" section included which is shown on the wordpress.org plugin repository page for the plugin. Additionally this information could then be pulled through onto the Tools > Privacy
Information screen in the admin.
A plugin guidelines page would probably be needed on wordpress.org somewhere to guide plugin developers on the information they would need to declare in their plugin readme.
#5
in reply to:
↑ 4
@
7 years ago
Replying to wpmarkuk:
I think it would make sense for all plugins that get accepted in the WordPress.org repository to have mandatory privacy information...
It seems to me that this should be part of the
readme.txt
file for a plugin. It could have a compulsory "Privacy Information" section
Most of the plugins in the repo (there are ~60 000 of them!) don't have anything to do with collecting or storing any type of user data. Not sure it is a good idea to have a "compulsory section" that will be empty most of the time. On the other hand it would be nice to indicate when a plugin doesn't "touch" anything related to user privacy.
In any case this should be on the meta trac. Once a decision how to proceed is made we can incorporate any parts that should be in core.
#6
@
7 years ago
Agreed in that compulsory is perhaps overkills, but certainly the readme.txt
file could be used as the place where this information is declared.
#7
@
7 years ago
I like the idea of at least having plugins declare any privacy concerns in their readme.txt - we have just started assembling / discussing guidelines for plugins in the gdpr-compliance org slack channel this morning - having plugins include privacy concerns in their readme.txt would be a good addition to those guidelines
IMHO the plugins should provide all details, but the site owner(s) should compose and edit the privacy policy.
Yes definitely - short of programmatically emitting translated policy text, at the minimum we could surface plugins readme.txt details in such a settings page
#8
@
7 years ago
- Keywords has-patch added; needs-patch removed
43435.diff adds an empty ( for now ) Privacy Policy page under the Tools menu so we can see how to start populating all the information in it when we're ready. I've also added the Help Bar on top with some dummy content as I'm sure we will create a Docs page with further information in the future as well.
#9
@
7 years ago
Hey @xkon -- as mentioned in slack, how about instead of a separate page we have a wide meta box that appears when editing the privacy policy page into which plugins can filter their privacy policy items, which can then be cut and pasted into the site's actual privacy policy in the co-located page editor.
That way the user has a single page to accommodate their "I'm updating my privacy policy" workflow instead of having to work between two pages. Maybe even supports a Gutenberg single page flow down the road too.
We can know that we are on the privacy policy page once #43389 is in.
What would you think about a sort of tabbed view, with plugins (and core itself too at the top) on vertical tabs on the left and each plugin's (or core's) privacy snippets in a larger area to the right. That way you don't have to suffer from seeing all the snippets at once. Might even make it easy to highlight changes. Ideally there will be a handy way to cut-and-paste content from the snippets into the co-located page editor.
And lastly, as mentioned in slack, maybe we should be able to hook different content into different sections. We would need to define some sections up front.
#10
@
7 years ago
- Keywords needs-patch added; has-patch removed
Adding the information here as means of notes & continuation:
As discussed in slack: https://wordpress.slack.com/archives/C9695RJBW/p1520271733000031?thread_ts=1520270079.000490&cid=C9695RJBW
- Add "Privacy" page under Tools menu that has:
- Tabs [maybe / depends on UI/UX]
- Tab 1
- A button to create a page and set it as the Privacy Policy.
- A drop-down to designate an existing page as the PP page. Once one of these is done, show a link to edit the PP page.
- A tool to anonymize comments by the email.
- A tool to anonymize user by email (and/or login name).
- Explanations what each tool does.
- Tab 2 [changes counter]
- Gathers all the latest Policy changes from the Plugins
- Short explanation of how to use all of this information (in relation with the PP page created)
- Vertical Tabs that list in order Core followed by all plugins (maybe depending if the updates list is actually that long to be in a single output - similar to the setup of the PP informational copy/paste box)
Ticket #43389 will be eventually brought here as well
---
What do we need from Plugins to report back to us (this list might get updated / altered depending of needs, can-dos etc - we can start creating our base filters with it)
- What personal data does this plugin collect? (Cookies, telemetry, anything)
- Why is that data collected? (Consent and legal basis)
- Is data passed to third parties? (Social media logins are third parties!)
- What personal data is stored on the database and remotely?
*
- What privacy options does the plugin administrator have? ( this is for Admins eyes only not the PP page )
- What consent mechanisms are provided for the users?
- What privacy options (such as settings) does the user have?
- What data does the plugin transfer internationally (non-EU?)
* A privacy notice should never be forced to include information which would have the opposite effect of actually jeopardizing safety, for example, "credit card numbers are stored on the database".
#11
@
7 years ago
privacytoolsmaybe.png is just a quicky mockup of the simplest way I personally found to show everything on this screen. It is missing it's 2nd major tab that will host the incoming data from core + plugins, which will esentially be again a vertical tab list like the one shown.
I've tried to use elements that already exist in the Admin's UI of course so people are familiar with them. They will already be confused with all the new incoming stuff so let's at lest try and keep the UI as 'baby-driven' as possible :D
#12
@
7 years ago
We'll need to make this as dead simple as possible both visually and in terms of language. If we have to hold everyone's hand through everything I'm fine with that.
#13
@
7 years ago
Design and UI/UX in general was split from this ticket so we can keep this to update general functions needed and base back-end structure to have cleaner and easier tickets to maintain + commit. See #43481 for further UI/UX details.
#14
@
7 years ago
@xkon @azaozz - i just posted an updated patch that adds the privacy policy page setting to @xkon 's original patch. It also provides a link to create a new page in the event no page is selected. Please let me know what you think.
I'll add a comment on #43389 that this is over here now
#15
@
7 years ago
This is starting to look good :)
Thinking we can have a "Create Privacy Policy page" button that will act like a submit button and we can insert a new page titled "Privacy Policy" directly, no need to send the user to the New Page screen. After inserting it, or after the user selects a page from the drop-down and saves, we should show a link to edit the policy.
Now comes the fun part: when editing the policy there will be a "postbox" that contains all the text suggested by core and plugins. In addition to showing the text, it will have to store the old text and highlight parts when they are updated. Perhaps not quite a diff, but draw the attention to any changed block of text.
In addition after core or plugin update we should show an admin-wide notice when some privacy text(s) were updated, perhaps until the user dismisses it.
#16
@
7 years ago
I have some 'flow' notes that maybe it could be done easier, if not it is more than fine for a start!
The current flow:
- You're on Privacy Page you don't have anything selected so you get a message to 'Create' a page.
- You click -> you get redirected -> you publish the page.
- Back to the Privacy Page -> no option set yet -> Message to create yet another new page.
That might seem somewhat confusing to some people since they already created a page and might think oh nice it was so easy! yay! ... wait... where are my extra goodies? - oh snap - I have to go back and Select it as well.
So I would suggest to convert this little piece of flow into this if possible:
You get to Policy Page ->
- Your select doesn't have anything.
- You have a message to create a page.
Action time:
- You click create a page
- You get a notification-success. ( ajax magic ! )
What Happened in the background? :
- A page is simply put in by our code with a slug of like 'privacy-policy-{$timestamp}' so it's always unique.
- Without redirects we are updating instantly the <select> + the
option
followed by a message 'Your page is ready! You can view it <here>' or something in that context. - The user doesn't have to do anything else. User can even continue scrolling through the Privacy Tools page or check the already incoming plugin hooks on the next tab if he wants.
The idea of this is to avoid all of this back and forth and just give them a straight up page that with this idea will show their metabox and everything already as it is properly registered from scratch.
Either way you're keeping the ID for the select so we don't care about slugs / post names they can do whatever they want with them :] as long as there's something bound to that select box.
What do you think about that? I would personally find it perfect to not interrupt with redirects etc my 1st click on this new page
:D
The trash notice is super clever btw _
#17
@
7 years ago
After my last comment I just went ahead and actually created 43435.3.diff since we're 12h apart so 1 wakes up 1 sleeps haha just in case we can save some time. This is based on @allendav 's patch but with the idea of not using redirects straight away.
I'm sure this patch can get a lot prettier + more secure or fail-safe but at least it works as expected for the means of previewing.
@allendav if you are OK with this ( I think it will really play along nicely with the idea of #43481 and accordions etc. It will be a seamless experience imho ) please make a pass on this to shape it up so we can commit it maybe asap so I can pass over all the other UI items as well after, this way we can start clearing tickets as well and focus on new ones easier :).
( note: I wasn't sure where to add all the jQuery + minor css stuff for this page so I just bumped them insite tools-privacy.php to at least have them handy for the time being )
#18
follow-up:
↓ 19
@
7 years ago
Should this new interface be integrated into the Settings > Reading
screen where the select a homepage and blog page? Putting it into the tools section doesn't seem to be the right flow here. I'm inclined to suggest it's move as an option that is always selectable (as opposed to the home/blog page options that require it being switched on).
A whole new page for this seems a bit much to me because once you have a page created, the only useful option here is the select box which doesn't need it's own page.
I've also not tested the patch yet, but if it doesn't already, it should have a 'Privacy Policy' suffix in the page list just like it does with 'Front Page' and 'Blog' pages do to identify they're special pages.
#19
in reply to:
↑ 18
@
7 years ago
Replying to danieltj:
Should this new interface be integrated into the
Settings > Reading
screen...
A whole new page for this seems a bit much
We've discussed that in #gdpr-compliance in Slack and the consensus was to add all privacy tools on one screen under Tools menu. It's not going to be just the policy page, there will be UI for anonymizing and/or deleting comments and posts, link to anonymizing/deleting a user, help/text explaining how each works and how that will impact the site, warning about change to the suggested policy text, perhaps a list of pending requests, etc.
#20
@
7 years ago
@danieltj to comment further on @azaozz reply see #43481 so you can understand how this 'empty' for now page will end up being pretty much :). We're still on a chaotic-ticket system as there was a need to open everything as a ticket to see what we can do and start but it will make sense in the end especially after some parent-commits are made. It looks confusing if you're missing the chats & meetings on the #gdpr-compliance that's certain :D .
#21
follow-up:
↓ 22
@
7 years ago
@azaozz & @xkon
That makes sense to me now; I was curious as to why one option was in a newly created page but if more privacy options and settings are coming then that seems appropriate for a new page.
To follow on from what @azaozz said about comments, I was thinking about creating a plugin to 'forget' users who leave comments to remove the personal information. I'll direct my efforts here in that case.
Are we currently focusing on just creating the privacy page for now then? Sorry I'm a bit out of the loop with this ticket and Slack channel discussion so I'm trying to keep up as best I can!
#22
in reply to:
↑ 21
@
7 years ago
Replying to danieltj:
Welcome aboard!
Are we currently focusing on just creating the privacy page for now then?
No, focusing on all tickets, as much as possible :)
https://core.trac.wordpress.org/query?status=!closed&keywords=~gdpr
#23
@
7 years ago
@xkon wrote:
A page is simply put in by our code with a slug of like 'privacy-policy-{$timestamp}' so it's always unique.
You had me up to -{$timestamp}
- why do that?
#24
@
7 years ago
@allendav
I just added this so we can always have a unique page just in case. Might not be the best option but I don't know another way. They can always go later on and change the slug if they don't like it. We are only doing it for the 'ID' either way, it was an easy trick I thought to avoid conflicts in the case of an existing identical 'slug'. Some sites might already have pages named 'privacy-policy' 'privacy-policy-page' or whatever else we could've thought.
#25
@
7 years ago
@xkon : If we don't specify the slug, wp_insert_post will work anyways and manage/version any slug - I recommend removing it
A few other comments on the patch:
1) Lets use __( 'Privacy Policy' )
for the post_title argument to wp_insert_post
2) Do we really need the incremental complexity of AJAX for this part? How about just another form+button that posts a create-privacy-page action in a similar manner to how tools-privacy.php (in this patch) currently handles the set-privacy-page action? We can then have add_settings_error emit something like "Privacy policy page created successfully" similar to how the updated action does. If we get rid of the AJAX, the little bit of CSS can go too.
AJAX will be needed later, certainly, for things like exporting or removing a user's personal data, but let's not bother with it for this, ok?
3) Let's keep the view/edit link (if a page is selected) but it needs to be localized. Let's keep the jQuery in the file but just have it hide the view/edit link if the user changes the selected page in the dropdown (i.e. 1) to avoid confusion by having the link no longer link to the page displayed in the SELECT and 2) to avoid people not saving their changes
Mind if I submit a 43435.4 with those changes?
#26
@
7 years ago
I'm good with everything you mention ( It was just my cranky early-morning way of doing things ).
@
7 years ago
Localize, remove CSS, replace AJAX with action to create privacy policy page, don't timestamp page slug
#27
@
7 years ago
- Keywords has-patch added; needs-patch removed
@allendav Tested and re-tested here, it seems seamless and superb from what I saw.
#28
@
7 years ago
As far as I see the plan to stay dot release compatible is:
- "Take over" the privacy.php file, move existing content from there to freedoms.php and load it with a query arg. Tried couple of alternatives but that seems the simplest and works best (keeping the old content in privacy.php expands the Tools menu item).
- Add any extra CSS to wp-admin/forms.css.
- Add any JS to wp-admin/xfn.js. That file seems least used, and the existing content is all tied to HTML IDs so no chance for any breakage.
Patch coming up.
#30
@
7 years ago
Noticed a few things that could be improved, see 43435.5.diff
1
The label for the select is empty, there's no text. As per the Accessibility coding standards, please always use explicitly associated labels (for/id attributes), avoid wrapping labels, never do both.
A visible label always helps because it's clickable. I'd propose to just follow the existing pattern and change the text in the left cell to a label. Also, I'm not sure a fieldset with a legend helps that much in this case. Fieldsets are meant to be used to group a set of related form controls. In this case there's just one select. I'd propose to simplify and remove them.
2
add_settings_error()
doesn't support a type warning
: this is used to output CSS classes and the notice misses the left border (see screenshot below).
Either the CSS should account for .notice.warning
to display an orange border and the add_settings_error()
documentation should be updated, or just use an error. After all, if the currently selected page doesn't exist, that's an error. The patch changes warning
to error
.
3
Moved Edit or view your privacy policy.
out from the table: it shouldn't be a table header (<th>
). I'd suggest to use a simple paragraph or a notice-info. For consistency, I've opted for the notice (see screenshot below). Can be changed to a simple paragraph if the notice doesn't feel so appropriate to y'all.
4
The two submit buttons have the same ID: IDs should be unique. Passed additional parameters to submit_button()
to fix it. Note: same happens for id="_wpnonce"
but I guess this can't be changed.
5
Removed the class="title"
from the H2 as it seems to me it doesn't do anything.
#31
follow-up:
↓ 34
@
7 years ago
A few more things not included in the previous patch:
- I'm not sure the H1
$title
is really necessary: seems the page title is always the same, so the string could be used directly in the H1 - html in translatable strings should be avoided; ideally all the html should be replaced with placeholders
- the links "Edit" and "View" in
Edit or view your privacy policy.
are not so clear when read out of context. This is important for assistive technologies that list links in a page and allow users to navigate through links. See for example in VoiceOver:
I'd suggest something like: [link]Edit your privacy policy[/link] or [link]view your privacy policy page[/link].
- I'm not a native English speaker so I may be wrong but in the following sentences:
Please create or select new page Please create or select new privacy policy page ... Create new page for your privacy policy
Shouldn't a
be used before new
? E.g. Please create or select a new page
.
Happy to patch these points if there are no objections, any feedback welcome.
#32
@
7 years ago
One more thing... :)
Once a page has been "set", there's no way to "unset" it. Or, better, the UI doesn't make this clear. It is possible to choose the initial option – Select –
and submit to set the value to 0
. Here's what happen when doing so:
This actually sets the page_for_privacy_policy
option value to 0
and that's what we need. But then I'd suggest to change – Select –
to None
and display a proper message when the page is unset.
#34
in reply to:
↑ 31
@
7 years ago
Replying to afercia:
the links "Edit" and "View" in
Edit or view your privacy policy.
are not so clear when read out of context.
I'd suggest something like:
[link]Edit your privacy policy[/link] or [link]view your privacy policy page[/link].
Hmm, these links are "inline" in a sentence, they are not meant to be read separately. The repetition sounds pretty bad to me. Perhaps we should add button-looking-links that will show next to the "Privacy policy page" h2. That seems to be used in a lot of other admin screens.
Once a page has been "set", there's no way to "unset" it.
There is a way and you found it :)
However I'm not sure we need to support that at all. Once a page is set, it can be managed and edited as any other page in WP. Of course it can be moved to the trash and deleted too. Thinking to hide the "Select another page..." section completely and perhaps add some text telling the user to edit and manage the page as any other page. However adding more text means the edit
and view
links will still have to be inline in a sentence and not make sense out of context.
There is another place that may need looking into: if you move the current policy page to the trash, there is an error shown on the Tools => Privacy screen that has a link to restore the PP page. Perhaps we should remove the link and add a button [Restore]
instead?
#35
@
7 years ago
Thanks @azaozz. About the Edit and View links, I think it's fine to expect users to explore the links surrounding text to some extent so, when navigating the content, leaving them as they're could be fine. The problem is more evident in the list of links screen readers offer to users, where there's really no context to understand what "Edit" and "View" mean. Can't think of other solutions though.
Perhaps we should remove the link and add a button [Restore] instead?
Hm if it stays as a link pointing to the Trash page, as it is now, then it should be a link. Instead, if you mean a new feature that automatically restores the page from the trash (without triggering any navigation) then it should probably be a button.
#36
@
7 years ago
The idea in the above screenshot is to have a postbox that will show only when editing the privacy policy page. That postbox will contain all privacy related text suggested by core and plugins to assist the site owners in creating their privacy policy.
In addition if any of the available text changes (after a core or plugin update) it will get highlighted to alert the site owner to review and edit the policy.
#37
@
7 years ago
I agree with @azaozz - a cool "Please edit this!" button that requires an admin to OK the text, at least on the first time they see this, would be good.
I think of the clever interference modal when editing a theme or plugin:
Heads up!
You appear to be making direct edits to your theme in the WordPress dashboard. We recommend that you don’t!
(I think this was @melchoyce's work too?)
Something that reads like
Heads up!
This Privacy Policy is a very important part of your website. We believe you should do X, Y and Z. We've got sample text for you to use (as do these plugins A, B + C) but it is your responsibility to understand your site. You should further adding details about your site's specific customizations (whether that be advertising, analytics, plugins or cookies) should be done.
Something that reads clear enough for an end user, but formal and inclusive enough that @webdevlaw would like it.
I see it as a modal and prompting admins to do a bit of reading, including a "remind me about this later" bit. In reality, this release might be the first time that many people hear about GDPR, and giving some context should help those confused.
Let me know if there's anything I can do to help with this.
#38
@
7 years ago
Seems that there is a need to bring @melchoyce design work closer to the discussion on this ticket, as I see some double work being done.
#39
@
7 years ago
- Keywords needs-patch added; has-patch removed
Something that should be addressed in following patches:
- In translatable strings
#8217;
should be used instead of escaping the apostrophe like in\'
. - If a translatable string has a placeholder a
translators:
comment should be added. - The indentation of the
if ( ! empty( $privacy_policy_page_id ) ) {}
block is off by one.
#40
@
7 years ago
Hey @dejliglama, in the GDPR chat, it was suggested I break the design out into a separate ticket. What's in #43620 is a riff off of @azaozz's earlier concepts in here.
#41
@
7 years ago
Working on updating the design for this screen, and wanted to check on something:
- When you first go to select a Privacy Policy page, you have the option of using an existing page, or creating a new page.
- After selecting or creating a page, you have the option of changing the page you're using for your Privacy Policy.
- However, you can only switch it to using an existing page — you can't create a new page at this point.
Can someone clarify why you can't create a new page afterwards?
#42
@
7 years ago
To answer the question easily, it's just how it was done at that time without over-thinking about it.
Further information:
You can 'create' a new page if you put the option back to -Select-
and hit the Save button to clear the ID, not that it's obvious of course :D but that triggers the code of if there's no ID set so the buttons to create a page are there again.
Either way all of these where UI/UX proposals as we where chatting about the whole concept and they changed day by day as the idea was to get everything in asap and then sit down and refine them as we move forward.
#43
@
7 years ago
See Tools.png for the updates I'm proposing to the Privacy Tools setting screen.
Layout Updates
- The screen contains some sort of explanation at the top, describing what this page is for and why it's important.
- The select/create options have been combined into one setting. The existing setting, in which they're separate options, makes it look like you can do both — when really, this is an either/or option.
- After selecting or creating a page, there's a subtle
#E5E5E5
divider between the edit/view options and the options to change your page. The "create" option returns.
Copy Updates
I made a couple copy edits for both clarity and overall tone. Copy should be friendly, but informative, and guide people towards next steps where applicable.
- "Select a Privacy Policy page" → "Select a Privacy Policy page"
- The two options are:
- "Either select an existing page:"
- "Either select an existing page:"
- Button labels:
- "Set Page" → "Use This Page"
- "Create Page" → "Create New Page"
- General think this makes them a little more clear.
- Success upon selecting or creating a page:
- "Privacy policy page updated successfully." → "Your Privacy Policy page has been created. You’ll want to review and edit your policy next." (with "review and edit your policy" linking to the "Edit Page" screen)
- Success upon changing your page:
- "Privacy policy page updated successfully." → "Privacy Policy page updated successfully. Remember to update your menus!" (with "update your menus" linking to the menu panel in the Customizer)
- Edit/View after selecting or changing:
- "Edit or view your privacy policy." → "Edit or view your privacy policy page content."
- The about blurb needs to be written.
Let me know if y'all have questions, or items to discuss.
#44
@
7 years ago
I can get the About blurb and some general wordsmithing to you for close of play Tuesday UK time.
#45
@
7 years ago
for multisites|multinetworks it'd be very nice to have relevant information supplied automatically to subsite admins about what data is touched/held/etc by the network (eg. wp_users and wp_usermeta and a statement from network that its needed and protected - idk what all else); also, a way for network admins to add additional info as needed (eg. perhaps network handles SMTP setup for subsites to send through).
further, ability of network admins to provide subsite admins additional guidance re. privacy page process generally (eg. ability to filter content of proposed heads-up mssg, or even just insert additional, like a support link or such) would be sweet.
seems like many kinds of networks would stand to benefit from tools to help network admins deal effectively with privacy/gdpr: small biz w/ several locations, WPaaS, education/institution and large orgs generally, etc.
apologies; not a coder at this lvl, only have my 2cents to offer here as a network admin... will try to find some other part of gdpr effort to pitch in on.
and, re. security by design, will be great to have #28521 :)
thanks for the awesomeness.
This ticket was mentioned in Slack in #gdpr-compliance by allendav. View the logs.
6 years ago
#48
@
6 years ago
43435.6.diff is a first pass based on Tools.png suggestions.
It still needs the appropriate texts to be filled instead of Lorem Ipsum
etc but other than that it should be ok following @melchoyce 's mockup + input.
Note for @melchoyce I've added the divider ( <hr> ) permanently instead of showing it after selecting or creating a page just to have a permanent division between explanation + the actual 'tools'. But we could still go on showing/hiding it with the Edit - View message if it feels off.
#49
follow-up:
↓ 51
@
6 years ago
Error on WordPress 5.0-alpha-42971
Tools > Export Personal Data, enter email, confirm it from my email, it goes into 'Confirmed' => all fine
But if I want to filter on all the 'Confirmed' ones (by clicking the word 'Confirmed'), I get an error. The URL is incorrect
It should be:
but it tries to go to:
#50
@
6 years ago
Also:
Entering a wrong email address in the 'Remove Personal Data' is showing an error about 'unable to add export request...'
#51
in reply to:
↑ 49
@
6 years ago
Re: comment 49 and comment 50
This ticket was mentioned in Slack in #meta by danieltj. View the logs.
6 years ago
#54
@
6 years ago
- Milestone changed from 5.0 to 4.9.6
- Owner set to idea15
- 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).
#55
@
6 years ago
Just a thought but it seems really odd that plugins, which are not allowed any longer to claim anything with regards to legal compliance on WordPress.org plugin directory readmes are now not just allowed, but tacitly encouraged to give pseudo-legal advice in the form of suggested additions to a privacy policy.
What legal issues/liability does that potentially open plugin authors to, particularly with the current implementation that does not stress at all the suggestions are not to be construed as legal advice?
#56
@
6 years ago
That's conflating two separate issues. We're going to be looking at the plugin guidelines separately (starting today, in fact) to see how privacy could be better defined and clarified for future development. We're also working on the functionality for plugin authors to provide privacy information in a way that can be captured by the privacy notice tool. But the need to provide information about data flow and capture isn't "pseudo-legal advice" - it's now a regulatory requirement.
Our challenge has been to find a way to make that easier for everday administrators without having to be developers and lawyers at the same time, hence the compliance project. The privacy notices we're discussing here will be the sole responsibility of the site administrator. The tool will not write the policy for them, nor publish it. What it will do is pull in information about plugins from the functionality we're creating, and will also provide prompts for administrators to manually fill in details like their international data transfer information. Administrators are solely responsible for finishing and publishing the notice.
This ticket was mentioned in Slack in #gdpr-compliance by mnelson4. View the logs.
6 years ago
This ticket was mentioned in Slack in #gdpr-compliance by webdevlaw. View the logs.
6 years ago
#60
@
6 years ago
Can I ask if https://core.trac.wordpress.org/ticket/43473#comment:21 is what we need to move forward? It's much more of a chicken and egg task than it may have appeared at first.
#61
follow-up:
↓ 74
@
6 years ago
@idea15 yup!
To move this forward I guess we need design thinking first :D
@melchoyce
https://core.trac.wordpress.org/ticket/43473#comment:21 is the text that needs to be shown to an Admin when editing his Privacy Policy page along with the postbox that gathers all the Policy Texts (from this ticket), I've also added some initial thoughts of how we could do this ( on a later comment in #43473 ).
Can you take a look when possible so we can start building this as well?
#62
@
6 years ago
I'd also like to change the language in https://core.trac.wordpress.org/changeset/42978/ to make it more consistent
This ticket was mentioned in Slack in #core by jeffpaul. View the logs.
6 years ago
This ticket was mentioned in Slack in #gdpr-compliance by xkon. View the logs.
6 years ago
#65
follow-up:
↓ 68
@
6 years ago
Change: This page provides tools with which you can manage your user\'s personal data and site\'s privacy policy.'
To:
This page provides tools to help you manage your site's privacy settings and compliance requirements.
The privacy notice tool will help you to draft a privacy notice that meets European data protection law requirements.
The personal data tool will allow your European users to request and export a copy of their personal data.
Change: The first step towards privacy laws compliance is to have a comprehensive Privacy Policy...
To: If your website collects or processes personal data about people within the European Union, you will need to display a Privacy Notice which conforms with the requirements of European data protection law as well as the expectations of your European users.
If you already have a privacy page, please select it below. If not, create one by (doing what/how?)
The new page will include headings and suggestions for your privacy notice text. However, it is your responsibility to use those tools and resources correctly, to provide the information that your privacy notice requires, and to keep that information current and accurate.
#66
@
6 years ago
Note to avoid double patches for the new text in the previous comment: There's a ticket that is addressing the readability on this page. See #43865 .
#67
@
6 years ago
@xkon @idea15 ,
Thanks for the follow-up.
Is the above text final? So, we can update the patch accordingly and merge it with #43865
Best Regards,
#68
in reply to:
↑ 65
@
6 years ago
Replying to idea15:
Few things:
- "privacy notice" sounds quite undefined. Don't think we should use this term. See #43875.
- We are not adding that screen only so users can comply with one law in one area. We should avoid mentioning GDPR or Europe or anything similar :)
- There's no "personal data tool". It's "Export Personal Data" screen that contains few things. It is also a completely different screen.
Also:
If your website collects or processes personal data...
As long as visitor IPs are considered personal data, all sites collect "personal data" in the server logs. The above doesn't make sense?
So, the text after applying some of the suggested changes will become:
The first step towards privacy laws compliance is to have a comprehensive Privacy Policy. If you already have a Privacy Policy page, please select it below. If not, create one. The new page will include headings and suggestions for your privacy policy. However, it is your responsibility to use those resources correctly, to provide the information that your privacy policy requires, and to keep that information current and accurate. After your Privacy Policy page is set, we suggest that you edit it. On the edit page screen you will find additional privacy information added by your plugins. We would also suggest reviewing your privacy policy from time to time, after a WordPress or a plugin update. There may be changes or new suggested information for you to consider adding to your policy.
#69
follow-up:
↓ 70
@
6 years ago
1) "Privacy notice" isn't a matter of my personal opinion, it's European regulator terminology. "Notice" is a conscious effort to get away from "policy", which is seen as an American contractual term. Policy = internal document. Notice = public statement. It's like the difference between Wordpress and WordPress, dangit
2) While that's true, we also need to meet the expectations of our users who need to do the privacy notice process for GDPR. They've had many years to do this independently outside any regulatory deadline.
On the suggested text, let's please make it as user friendly as possible. I suggest the following:
This tool wil help you to create a comprehensive and accountable privacy notice.
If you already have a privacy notice page, please select it below. If not, create one.
After your privacy notice page is created or selected, you will be able to manually edit it. The page will include headings, suggestions, and plugin details to help you capture all the information you need. However, it is your responsibility to use those resources correctly, to provide the information that your privacy notice requires, and to keep that information current and accurate.
We strongly recommend reviewing your privacy notice from time to time, and after you update your WordPress software and plugins. Updates can create changes which you may need to reflect in your privacy notice.
#70
in reply to:
↑ 69
@
6 years ago
Replying to idea15:
1) "Privacy notice" isn't a matter of my personal opinion, it's European regulator terminology.
I don't see anywhere in the GDPR where it forbids the term "policy" (in English), and replaces it with the term "notice"? In any case, thought we are discussing this particular term in #43875.
It's like the difference between WordPress and WordPress, dangit
...it has nothing to do with a spelling mistake :)
#71
@
6 years ago
It's not the raw text of GDPR you need to be taking your cue from, it's the interpretive guidance from regulators and the A29WP. They are using the term "notice" to specifically differentiate between the Americanism of "policies". Please go with that.
This ticket was mentioned in Slack in #gdpr-compliance by desrosj. View the logs.
6 years ago
#73
@
6 years ago
They are using the term "notice" to specifically differentiate between the Americanism of "policies".
Ah, I see the problem. The default language in WP is en_US (i.e. US English). There are translations to en_UK, en_CA, en_AU, etc.
Perhaps using the words "privacy notice" instead of the words "privacy policy" won't be so confusing in the UK. That should be handled in the translation imho. I'm also not sure if there is big difference between "notice" and "policy" in other languages. WordPress has over 200 locales. Thinking the translators will have to decide there :)
#74
in reply to:
↑ 61
;
follow-up:
↓ 75
@
6 years ago
Replying to xkon:
https://core.trac.wordpress.org/ticket/43473#comment:21 is the text that needs to be shown to an Admin when editing his Privacy Policy page along with the postbox that gathers all the Policy Texts (from this ticket), I've also added some initial thoughts of how we could do this ( on a later comment in #43473 ).
Can you take a look when possible so we can start building this as well?
Can you help me understand how this differs from the current policy metabox folks can copy/paste from?
#75
in reply to:
↑ 74
@
6 years ago
Replying to melchoyce:
Can you help me understand how this differs from the current policy metabox folks can copy/paste from?
It's not, false alarm, sorry! I was under the impression at the start that the text was going to be added as 'extra' in the page so they can Copy/Paste anything/anytime they wanted.
This ticket was mentioned in Slack in #gdpr-compliance by desrosj. View the logs.
6 years ago
#78
follow-up:
↓ 80
@
6 years ago
Note from bug scrubs: We need to check the texts here and add ( if needed the Help tab text as well ). Part from that the Tools -> Privacy page has been 'stationary' without extra touching for quite some time now so I think we're good.
Will create a patch later on with
This tool wil help you to create a comprehensive and accountable privacy notice. If you already have a privacy notice page, please select it below. If not, create one. After your privacy notice page is created or selected, you will be able to manually edit it. The page will include headings, suggestions, and plugin details to help you capture all the information you need. However, it is your responsibility to use those resources correctly, to provide the information that your privacy notice requires, and to keep that information current and accurate.
#79
@
6 years ago
43435.7.diff is based on the last comment and replaces the pages text with:
If your website collects or processes personal data about people within the European Union, you will need to display a Privacy Policy which conforms with the requirements of European data protection law as well as the expectations of your European users.
Please use one of the options below if you already have a Privacy Policy Page or want to create a new one.
After your Privacy Policy page is created or selected, you will be able to manually edit it. The page will include headings, suggestions, plugin and theme details to help you capture all the information you need.
However, it is your responsibility to use those resources correctly, to provide the information that your privacy notice requires, and to keep that information current and accurate.
@desrosj I think we can get this in any further edits etc will go into new tickets I suppose.
#80
in reply to:
↑ 78
;
follow-up:
↓ 81
@
6 years ago
Replying to xkon:
Couple of things:
- Think we settled to use "privacy policy" as the default WP language is
en_US
. That can be translated to "notice" or other term when WP is translated for other locales, includingen_GB
,en_CA
,en_AU
, etc.
- This seems wrong:
If your website collects or processes personal data about people within the European Union, you will need...
These are general privacy tools and we suggest all websites to have a privacy policy, no matter where they are located. Furthermore who can guarantee when an EU resident may stumble on a website located in another region? :)
The proposed text is:
The first step towards privacy laws compliance is to have a comprehensive Privacy Policy. If you already have a Privacy Policy page, please select it below. If not, create one. The new page will include help and suggestions for your privacy policy. However, it is your responsibility to use those resources correctly, to provide the information that your privacy policy requires, and to keep that information current and accurate. After your Privacy Policy page is set, we suggest that you edit it. On the edit page screen you will find additional privacy information added by your plugins. We would also suggest reviewing your privacy policy from time to time, after a WordPress or a plugin update. There may be changes or new suggested information for you to consider adding to your policy.
Any last minute edits?
#81
in reply to:
↑ 80
;
follow-up:
↓ 82
@
6 years ago
Replying to azaozz:
Any last minute edits?
Nope, I'm personally good with Privacy Policy as we've discussed. And as for the 1st sentence yup it makes sense :).
The only thing I would change is on the last paragraph from added by your plugins
to added by your plugins & themes.
I wouldn't leave themes out of anything as some are adding google fonts, maps / analytics (through bundled plugins) and other various 3rd party stuff so some will and should push over policies as well to explain things to their users. Would that be ok?
#82
in reply to:
↑ 81
@
6 years ago
- Keywords has-patch added; needs-patch removed
Replying to xkon:
The only thing I would change is on the last paragraph from
added by your plugins
toadded by your plugins & themes.
Yep, makes sense. I'll change that and commit. Thanks for the review :)
#92
@
6 years ago
Ugh, where did my fix to this sentence get lost?
"The first step towards privacy laws compliance is to have a comprehensive Privacy Policy"
If we're not going to agree how to write that in better English, can we just delete it altogether?
This ticket was mentioned in Slack in #gdpr-compliance by azaozz. View the logs.
6 years ago
This ticket was mentioned in Slack in #gdpr-compliance by desrosj. View the logs.
6 years ago
#96
@
6 years ago
If we can change "The first step towards privacy laws compliance is to have a comprehensive Privacy Policy"
to "You may be required to comply with national or international privacy laws. One aspect of compliance may require creating and displaying a comprehensive privacy notice."
I'm happy with that.
#97
@
6 years ago
The first step towards privacy laws compliance is to have a comprehensive Privacy Policy
Let's avoid compliance (don't want them to get a false sense of compliance)? And say something like this instead?
The first step towards protecting your user's privacy is to have a comprehensive Privacy Policy.
#98
@
6 years ago
Final first sentence as agreed in office hours:
As a website owner, you may need to comply with national or international privacy laws. For example, you may need to create and display a privacy notice.
Go with that please
#99
@
6 years ago
I'm OK with what we've agreed today and this comment shouldn't be a blocker, just as more discussion for the future.
I just still think it doesn't answer the holistic answer as directly as possible, so I'm leaving this proposed revision to current text to make sure it's captured in Trac:
National or international law may require your site to have procedures in place to secure that privacy of your users. The first step towards protecting your users is a comprehensive Privacy Policy that includes helpful background information and suggestions for your privacy policy.
It is your responsibility to use those resources correctly, to provide the information that your privacy policy requires, and to keep that information current and accurate.
#100
@
6 years ago
To me "have procedures in place to secure that privacy of your users" is conflating technical and security measures with rights-based requirements such as the right to be informed.
One thing at a time.
#101
@
6 years ago
Another suggestion:
Creating a privacy policy helps your visitors understand what data you collect about them, and how it's used. Being transparent helps to build trust, and ensures people feel safe interacting with your site.
Think this sums it best, and doesn't have the problems the other suggestions have.
#102
@
6 years ago
I don't go to a privacy policy expecting to see twee customer service language like "Being transparent helps to build trust, and ensures people feel safe interacting with your site", and if I do it tells me they're probably hiding something.
#103
@
6 years ago
From the meeting today, it sounded like this sentence had the most consensus:
As a website owner, you may need to follow national or international privacy laws. For example, you may need to create and display a privacy policy.
Since the deadline didn't give us a chance to fully iterate on the intro text, I've started a new ticket to continue the discussion for 4.9.7: #43933.
#107
@
6 years ago
- Keywords fixed-major added; needs-patch removed
- Resolution fixed deleted
- Status changed from closed to reopened
I think those two commits resolve the open issues with the intro text, except for those being discussed in #43933.
So, I think we can call this ticket done after everything is backported to the 4.9 branch.
Related: #43389.
In slack we discussed few options for this. IMHO the plugins should provide all details, but the site owner(s) should compose and edit the privacy policy. This has several advantages: