Opened 7 years ago
Closed 6 years ago
#7855 closed defect (bug) (fixed)
Privacy: Suggested privacy policy text
Reported by: | boonebgorges | Owned by: | |
---|---|---|---|
Milestone: | 4.0 | Priority: | normal |
Severity: | normal | Version: | |
Component: | Core | Keywords: | has-patch 2nd-opinion |
Cc: |
Description
Parent ticket: #7698
WP has a new set of tools for creating a Privacy Policy page, as well as a help page where WP and plugins suggest text for that page. We should add to that page.
Attachments (3)
Change History (15)
#3
@
7 years ago
Oh, one more thing about cookies: I've described what bp-legacy
does. I'm pretty sure bp-nouveau
doesn't use any of the activity cookies, and I'm not sure it uses the messages cookies. I figure it's better to overdescribe, but if anyone has a better idea, I'm all ears.
#4
@
7 years ago
- Milestone changed from 3.1.0 to 4.0
The cookie review ticket is at #7856.
In light of that review, I've made some changes to the suggested text of the Cookies section. See 7855.2.diff
#5
follow-up:
↓ 7
@
6 years ago
Patch feedback:
- Use
bp_admin_init
for internal consistency? I know it has no impact. - I think
add_privacy_policy_content()
should use a version comparison check, not afunction_exists()
. It's more consistent with what we do elsewhere, and when we increase the minimum WP version required, it makes searching for now-redundant compatibility blocks much easier. - HTML escape all translations.
- Let's double-check if "deleted items are removed from the message thread for all recipients" is accurate, re: #7523
Wording is great, thank you for your work on this. :)
#7
in reply to:
↑ 5
@
6 years ago
Thanks for the review, @DJPaul. Initial version is committed.
- Use
bp_admin_init
for internal consistency? I know it has no impact.- I think
add_privacy_policy_content()
should use a version comparison check, not afunction_exists()
. It's more consistent with what we do elsewhere, and when we increase the minimum WP version required, it makes searching for now-redundant compatibility blocks much easier.
I made both changes.
- HTML escape all translations.
The pattern in WP and in other plugins I checked is to sanitize content through wp_kses_post()
when adding via wp_add_privacy_policy_content()
. Escape functions are thus redundant. But since our text doesn't contain any HTML, it doesn't hurt, so I added the escaping.
- Let's double-check if "deleted items are removed from the message thread for all recipients" is accurate, re: #7523
You're right - what I wrote in the patch is incorrect. I've removed it.
Wording is great, thank you for your work on this. :)
#8
@
6 years ago
@boonebgorges Reads really well, great job and effort.
One really minor thought, where we state something like message visibility is it worth qualifying 'never' as 'never intentionally' i.e our intended approach is that it's not visible but...
#9
@
6 years ago
Perhaps a silly question, if so forgive me, but what is the thinking about display of this text, WP introduces an option to generate a page along with a skeleton template of sections with some detail added for users to review and edit to thier requirements, how do we propose handling BP specific content, grabbing the WP content, merging BP sections into it before returning?
#10
@
6 years ago
@hnla Thanks for having a look!
One really minor thought, where we state something like message visibility is it worth qualifying 'never' as 'never intentionally' i.e our intended approach is that it's not visible but...
If private message content is visible to someone other than the intended recipient, it's a bug in BuddyPress (or the site) that should be fixed. I don't think that the privacy policy language should reflect that.
Perhaps a silly question, if so forgive me, but what is the thinking about display of this text, WP introduces an option to generate a page along with a skeleton template of sections with some detail added for users to review and edit to thier requirements, how do we propose handling BP specific content, grabbing the WP content, merging BP sections into it before returning?
WP's utilities for the privacy policy text allow plugins to register text that will appear on wp-admin/tools.php?wp-privacy-policy-guide=1
. Next to each of these items appears a 'Copy' button, which takes the suggested text and puts it into the clipboard. Beyond that, it's up to the site admin to create the page, do additional edits, etc. See Screenshot_2018-06-24_12-55-31.png
7855.diff is a first pass at implementation. There are really a couple things to discuss here: implementation and content. See
/wp-admin/tools.php?wp-privacy-policy-guide=1#wp-privacy-policy-guide-buddypress
First, regarding implementation, I've pretty much borrowed from WP. I stuck everything in the
BP_Admin
class. Theoretically, we could have different components register their own text, but this is liable to get complex, so I went with the simplest possible approach for the time being.Second, regarding content. Much/most of the WP default content applies directly to us. I've only added what's BP specific. And I've focused on *personal data* and *cookies*, which I see as the two categories of content named in GDPR that are specific to BP (above and beyond retention and other policies that are not specific to BP).
For personal data, I broke out XProfile, Messages, and Activity - the three areas where we keep arguably personal data, which is subject to various visibility/privacy settings. (Groups and friends are more like relationships and don't really have content.) Suggestions regarding language, or anything I've left out, are quite welcome.
For cookies, I just searched the codebase and described all the places where we set cookies. The text, as it stands, describes our *actual* use of cookies. IMO we should change some of this behavior as part of the privacy push - I will open a new ticket momentarily - and if we change cookie behavior, we should change this text.