Privacy: Privacy policy integration into registration process

[boonebgorges]

Parent ticket: #7698

GDPR requires that

[...consent] should be given by a clear affirmative act establishing a freely given, specific, informed and unambiguous indication of the data subject’s agreement to the processing of personal data relating to him or her, such as by a written statement, including by electronic means, or an oral statement.

The place where a website indicates the nature of the data it collects, what it does with it, etc, is the Privacy Policy. See #7855. So it seems that there should be some sort of integration between the privacy policy and the registration process.

This could take a couple of forms:

1. In the registration template, show a link to the Privacy Policy (if it exists)
2. Add a checkbox or other interface that indicates that the user has read and agrees to the privacy policy, and require it for registration to continue. Ideally, we would keep a discrete record of the user's consent, so that it could be revoked later on (though this revocation would likely mean deleting one's account, since in most cases you can't have a BuddyPress account without having a profile, etc)
3. Include some language about the privacy policy in registration/confirmation emails.

The end responsibility for this stuff is in the hands of the site owner, so I want to be careful not to go overboard, but if we can easily facilitate compliance through something like (b), it seems wise to do so. Thoughts?

[r-a-y]

Re: a) - I like this idea, but how do we determine if a privacy policy already exists on the registration template? What if the site isn't using WP's privacy policy page and is rolling their own either as a separate page or as inline text in the template? We'll probably want to add this link as a hook to allow devs to remove it.

Re: c) - We might want to go one step further and add a link to the privacy policy in the BP HTML email footer. Maybe add it to the existing email footer appearance option so the site admin can remove it if they want?

[boonebgorges]

Re: a) - I like this idea, but how do we determine if a privacy policy already exists on the registration template? What if the site isn't using WP's privacy policy page and is rolling their own either as a separate page or as inline text in the template? We'll probably want to add this link as a hook to allow devs to remove it.

Yeah, good point. For existing sites, I'm not sure there is a good way to do this automatically. Perhaps this is something we could enable by a database option, which would be turned on only for new sites, but could be flipped on for existing sites by either adding a filter in a plugin/theme file or by wp option update bp_show_privacy_policy_on_registration 1 or whatever.

Re: c) - We might want to go one step further and add a link to the privacy policy in the BP HTML email footer. Maybe add it to the existing email footer appearance option so the site admin can remove it if they want?

Yeah, I love this idea, especially since it's editable in the Customizer.

[DJPaul]

In the registration template, show a link to the Privacy Policy

Let's not change BP-Default. Let's add the link to Nouveau only; minimises the impact of the change on the majority of current BuddyPress sites.

Add a checkbox or other interface that indicates that the user has read and agrees to the privacy policy, and require it for registration to continue.

Yes.

keep a discrete record of the user's consent, so that it could be revoked later on (though this revocation would likely mean deleting one's account)

I think we can assume that if consent is withdrawn, the site owner will have to remove the user's account.

[boonebgorges]

7866.diff​ is a first implementation.

I've introduced two new functions:

• bp_signup_requires_privacy_policy_acceptance() defaults to true if a published Privacy Policy page exists, but can be filtered
• bp_nouveau_signup_privacy_policy_acceptance_section() breaks the building of the checkbox markup into a template tag, to avoid overly-complicated error checks etc directly in the template

The checkbox uses the HTML5 required attribute. However, the requirement is only forced on the back end if the hidden signup-privacy-policy-check parameter is present. This is to maintain compatibility with theme templates (eg bp-legacy) that don't have the checkbox markup. This means it'd be possible to craft a POST payload that bypasses the check. I'm not sure of a way around this - any ideas are welcome.

I'd welcome feedback from @imath or @hnla on whether the markup and code organization match what's expected in Nouveau.

And I'd welcome feedback from anyone on default language, etc. Note that the label text is hardcoded into the template function, and can be changed only by overriding the template or using a language file. I'm not sure whether we want this to be more easily customizable.

I haven't yet done anything for the email footer - this needs a separate patch.

[hnla]

@boonebgorges Will run patch next available moment spare, certainly looks ok on a quick scan.

[imath]

Thanks a lot for your work on the patch @boonebgorges It's a bit late here, so i'll look at it in a more detailed way tomorrow 🔬☺️

[imath]

@boonebgorges i’m wondering If there’s a reason not to use the bp_nouveau_get_signup_fields() BP Nouveau is using to create markup for the other signup fields, because we could add around this line ​https://buddypress.trac.wordpress.org/browser/trunk/src/bp-templates/bp-nouveau/includes/functions.php#L1220 something like this :

if ( bp_signup_requires_privacy_policy_acceptance() ) {
  $fields[‘account_details’][‘signup-privacy-policy-accept‘] = array(
   // field args
);
}

This would save a template edit in nouveau.

Then if I understand right, the problem is for template pack != ´nouveau’ so instead of adding an hidden field to see if the check needs to be done i’d probably create a filterable function that checks 'nouveau' === bp_get_theme_package_id() to do the policy acceptance require check in bp_core_screen_signup().

Finally, I would advise to provide some « easy to put in place » for a site administrator back compat for legacy and default like an

add_action( ‘bp_account_details_fields’, function() {
 // if not BP Nouveau and site admin want privacy policy output some markup
} );

[boonebgorges]

@imath Thanks for the review!

Screenshot_2018-06-19_09-54-27.png​ shows (roughly) what your bp_nouveau_get_signup_fields() looks like. IMHO, it's not great: the placement of the checkbox seems bad to me, and I don't like how this "acceptance" is tied together with the Account Details section, rather than broken out into its own area. In most signup processes around the web, I've observed that this type of confirmation is usually put just before the Submit button, and I think it's worth a template edit to maintain that convention here.

Then if I understand right, the problem is for template pack != ´nouveau’ so instead of adding an hidden field to see if the check needs to be done i’d probably create a filterable function that checks 'nouveau' === bp_get_theme_package_id() to do the policy acceptance require check in bp_core_screen_signup().

It's not just template_pack != 'nouveau'. First, some people may already have forked the template in their own (Nouveau-powered) theme, so relying on 'nouveau' would break registrations as soon as they update to 4.0. Second, I don't like tying this too closely to Nouveau, as it should be a part of all future (or custom) template packs. A clunky, but foolproof, way to check would be to load the registration template into an output buffer and look for the signup-privacy-policy-accept checkbox.

Finally, I would advise to provide some « easy to put in place » for a site administrator back compat for legacy and default

Yes, great point. When we decide how it'll work in Nouveau, I'll write a drop-in that devs can add to their own themes.

[imath]

Ah yes, i thought it was the reason about the field to be close to the submit button, thanks for giving it a test 😊 Fine with me for the template edit 👌

Very right about the template ID, especially when there will be a new TP 😉. The hidden field seems ok : creating the account means the user accepts the privacy policy. The text of the generated email should probably be edited : eg « you just registered and accepted the privacy policy, if you did not, please contact site admin email. »

[hnla]

It's correct that the confirmation should be clearly part of the submission portion of the page, I think to some degree aspects of BP like sign up are not the easiest to deal with, I should have some time free Saturday ( clear of pressured release dates) and can look at what template edits might be made.

[hnla]

Looks good to me!

Probably ought to add <label for="signup-privacy-policy-accept"> the for attr even though we are wrapping input.

Getting an error Undefined property: stdClass::$errors

$error = buddypress()->signup->errors['signup_privacy_policy'];

[boonebgorges]

Replying to hnla:

Looks good to me!

Probably ought to add <label for="signup-privacy-policy-accept"> the for attr even though we are wrapping input.

Getting an error Undefined property: stdClass::$errors

$error = buddypress()->signup->errors['signup_privacy_policy'];

Good catches both! Thanks.

It seems like the current approach for registration is generally agreed upon, so I'm going to commit a first pass at it. That'll leave a few more items for this ticket:

• Support for Legacy? It was suggested above that we don't do this, and I agree generally that we shouldn't be adding new features to bp-legacy, but since this one is so valuable and can help with legal compliance, I think it's worth reconsidering.

• A guide or a drop-in that turns on the feature in non-supported themes.

• Adding something about the privacy policy to emails, such as a link in the footer.

[boonebgorges]

In 12178:

Add privacy policy acceptance checkbox to registration process.

When a published Privacy Policy exists on the site, a checkbox appears
just above the submit button on the registration process, which must be
checked in order to proceed with registration.

For maximum compatibility with existing sites, this change is currently
limited to Nouveau.

See #7866.

[boonebgorges]

7866.2.diff​ adds a 'Privacy Policy' link to the email footer. I chose to add it as part of the Footer Text that is editable in the Customizer, so that admins could change the language as they see fit. This also means that existing sites will have the link turned on automatically, as long as they haven't customized the existing footer_text. I also chose to use · as a separator because I like it :) but other ideas are welcome.

Because it's an HTML link, I had to modify the Customizer JS to ensure that HTML wasn't escaped. The HTML is sanitized on the server using wp_filter_post_kses().

[boonebgorges]

Here's a drop-in that will enable support in BP Legacy. I don't see an obvious way around the inline style, but suggestions welcome :)

<?php

add_filter( 'bp_signup_requires_privacy_policy_acceptance', '__return_true' );

add_action( 'bp_before_registration_submit_buttons', function() {
        ?>
        <div class="privacy-policy-accept" style="clear:both;">
                <?php do_action( 'bp_signup_privacy_policy_errors' ); ?>

                <label for="signup-privacy-policy-accept">
                        <input type="hidden" name="signup-privacy-policy-check" value="1" />

                        <?php /* translators: link to Privacy Policy */ ?>
                        <input type="checkbox" name="signup-privacy-policy-accept" id="signup-privacy-policy-accept" required /> <?php printf( esc_html__( 'I have read and agree to this site\'s %s.', 'buddypress' ), sprintf( '<a href="%s">%s</a>', esc_url( get_privacy_policy_url() ), esc_html__( 'Privacy Policy', 'buddypress' ) ) ); ?>
                </label>
        </div>

        <?php
} );

I'm on the fence about whether to include in Legacy. There are likely many sites that have implemented their own such box, and adding one automatically would create duplicate headaches for them. On the other hand, a far larger number of sites would benefit from the automatic addition. I'd welcome others' thoughts.

[boonebgorges]

In 12258:

Add Privacy Policy link to default email footer text.

See #7866.

[boonebgorges]

Let's leave Legacy alone, but document it.

Two things before I close this ticket out:

1. Can @imath or @hnla remind me about our inline protocol for noting template changes? I feel like we agreed to add @since notes in the headers of changed templates (or something like that) but I can't find the details or any examples.

2. How should the Legacy drop-in be documented? Perhaps as part of the 4.0 page on the codex? Or maybe a "Privacy Policy" page on the Codex, which will explain the use of this drop-in, and will also have info about how we integrate into the default Privacy Policy text, etc? Other ideas welcome.

[boonebgorges]

In 12259:

Ensure that Privacy Policy link is added to email footer only if available in WP.

Added in [12258].

See #7866.

[imath]

Hi @boonebgorges

Great work !! 💪. About files located into the no-Nouveau folder, we are editing the @version header tag with the last version of the change, here’s an example : ​https://buddypress.trac.wordpress.org/browser/trunk/src/bp-templates/bp-nouveau/includes/messages/functions.php

As you can see we are doing it for any files not only template ones.

About the drop-in, I like the idea of the codex page, I think whatever decision is made about the drop-in we should have one.

WordPress is now using a setting for the comment checkbox about the cookie management into options-general.php. I wonder if a new option like this could be a possible way to manage the checkbox for new signup. This option could be unchecked in legacy by default but checked in Nouveau. An option is always easier for users to activate/deactivate.

[boonebgorges]

In 12260:

Bump Nouveau @version numbers after [12178].

See #7866.

[boonebgorges]

Thanks, @imath ! I've made the @version changes.

I'll start a codex page for this release that summarizes our Privacy Policy integration.

Regarding the option - IMO this checkbox is important enough that we don't want to give people an easy way to turn it off. The issue with Legacy is not so much that someone might not want it, it's that someone might already have their own version of it, and we don't want to create a duplicate. For this reason, I think we should not have a settings toggle - we'll just hardcode it into Nouveau, and if you really want to remove it, you'll just have to modify the template :-D