Privacy policy guide: improve UX and readability

[idea15]

We talked a lot about how to convey the information that the user needs about what to write, but presenting it inline as yellow highlighted text does not work in practice.

Additionally, the split of information between the guidance box on top and the text body area is confusing.

[danieliser]

I'm wondering if this is the wrong approach as well and whether we should simply be asking them questions and using a combination of their responses and info fed by core, plugins & themes to generate the bulk of any policy automatically.

There may be options to include additional text in any given section, but I agree, sticking 2 walls of text in front of a non-legal-minded user is going to massively hurt the ease of use for most people.

[danieliser]

Further that though, should there simply be generator function that is separate from the page management itself beyond maybe showing a modal with questions to generate new text?

1. create & assign page.
2. Edit page where there will be some noticeable button to generate policy text.
3. Show modal with tabbed form and ask relevant questions. (allow plugins to define extra questions, like are you using our subscription forms)
4. Generates text based on answers to questions and plugins installed.
5. Offer to insert it automatically or compare it (via the existing revision system) to the existing one so diffs can be merged with the custom text they added.

This would pair perfectly with #44010

That, in my opinion, gives you a reliable way to get a complete policy, with an ability to easily update it with custom text, and easily update it in the future when required.

[azaozz]

This seems a duplicate of #43980.

Unfortunately the suggested text plus the short descriptions under the headings are very long and impractical to show in a postbox.

[azaozz]

Replying to danieliser:

2. Edit page where there will be some noticeable button to generate policy text.
3. Show modal with tabbed form and ask relevant questions. (allow plugins to define extra questions, like are you using our subscription forms)
4. Generates text based on answers to questions and plugins installed.

Like a "wizard" interface? Not sure if that will work. We cannot "generate" a privacy policy even if plugins output their bits of text in a structured form. It will be grammatically wrong as the different bits won't "fit" together, but more importantly this is improper from legal point of view. The site owners should be responsible for their policies, there is no way a policy can be auto-generated.

[danieliser]

Replying to azaozz:

Replying to danieliser:

2. Edit page where there will be some noticeable button to generate policy text.
3. Show modal with tabbed form and ask relevant questions. (allow plugins to define extra questions, like are you using our subscription forms)
4. Generates text based on answers to questions and plugins installed.

Like a "wizard" interface? Not sure if that will work. We cannot "generate" a privacy policy even if plugins output their bits of text in a structured form. It will be grammatically wrong as the different bits won't "fit" together, but more importantly this is improper from legal point of view. The site owners should be responsible for their policies, there is no way a policy can be auto-generated.

To be clear, I completely agree, but you don't think most will leave what you have there now as the default?

But once you factor in the average user you need to consider that the current solution offers the same end result in terms of what the user should be doing with it, that is they NEED to customize it. But the method I proposed means that it won't include unneeded info (if they don't check any analytics for instance, can skip that section). It also means that instead of 20 boxes of notes from Core and 19 other plugins they have installed, you get one box, one of each sections with all the info from all 19 plugins rolled in where it belongs (cookie info with core comment cookie note etc).

So basically even though both solutions require customization by the admin in the end, the current solution means 20x the work on the average site as you merge the info from each plugin into your policy one by one, and my proposed solution means you only have to do it once and the options you chose can be saved for reuse the next time you generate the policy.

Then factor in revision history vs newly generated and the user can at least reasonably get through updates in minutes, only having to invest a lot of time on the first version and easily able to merge changes from the old to new each time updates are needed.

This would also easily lend itself to automatic timestamping of when the privacy policy was last updated.

I just think the current solution is trying to get something out so quickly we are skipping how it will be used. I'm all for rushing something out to beat the deadline for site owners, but if we stick to what is here now, I fear nobody will make the deadline simply due to the sheer time it will take and the massive intimidation factor of the current implementation.

[xkon]

Replying to danieliser:

It also means that instead of 20 boxes of notes from Core and 19 other plugins they have installed, you get one box, one of each sections with all the info from all 19 plugins rolled in where it belongs (cookie info with core comment cookie note etc).

By letting me use 'my own plugin section' makes it way easier for me as a plugin author to communicate with my users.

By giving 1 method only that accepts any text, any given extension can notify about any kind of policy it likes without the need to split methods for each section.

Those sections are also the general guideline so it doesn't mean you'll need everything and doesn't mean that you'll need only them as well.

If core pre-defines the sections for incoming texts, how am I going to push my plugins policies that is mostly used in Greece for example and we have to have 2 more sections because that's how they want it here?

Imho you'll just end up in a more messy situation there as some plugins won't be able to push through what's needed.

[danieliser]

@xkon How does it work now. Same result as what I proposed, just less intimidating. If your plugin needs to add sections that shouldn't be a problem. No one policy can possibly fit all, but we are currently basically generating what reads (with exception of the helper notes) as a complete policy. Do you think many users will think twice about just using it as is? That means that they will likely never merge in the needed info from dozens of plugins on their site. WordPress is supposed to be easy for users to get going. This currently will take days to put together a policy based on my own plugin usages, most of which are pretty common.

I will have to start with the core policy suggestions, rewrite accordingly, then move on to manually merge in the data from 10+ plugins one at a time, each having different data that has to be merged into the same policy template core already suggested, not just appended to.

Plugin A's cookies shouldn't be listed at the bottom by themselves, that makes no sense, yet that is how I imagine most of my own users (very lay) doing it. These penalties can be applied to the smallest of blogs (unlikely but possible), so assuming that every site owner is going to hire a lawyer is a very bad assumption. People writing small blogs occasionally are not gonna spend the time or the $.

I prefer not to have to field 1000 questions on the subject over the next year, which means doing our best to generate as close to possible a ready to use policy. Anything less puts millions of sites at risk.

If your fear is having to write 5 different filters instead of 1, in my opinion as someone who runs multiple plugins that will have to use these new functionalities, I'd say you strongly need to reconsider, you will thank yourself later when you are not answering needless support tickets or having your users get sued out of oblivion for non compliance.

Our users problems are our problems. If we can solve them with a little extra effort on the plugin devs part, that is a no-brainer, which is an underlying principle of WP, cough-cough backward compatibility.

[xkon]

Replying to danieliser:

If your plugin needs to add sections that shouldn't be a problem.

So that will result in a page having 1000 sections because that's what plugin authors decided to do? There's a first problem that I see.

WordPress is supposed to be easy for users to get going.

WordPress yes, the regulations / laws / policies are not. So there's a really really thin fine line that we shouldn't step over imho.

I will have to start with the core policy suggestions, rewrite accordingly, then move on to manually merge in the data from 10+ plugins one at a time, each having different data that has to be merged into the same policy template core already suggested, not just appended to.

And that's what you would/should do if you had 3 plugins saying 'We gather analytics' under the data section you would again have to filter the 2 extras out and re-write it to the tone that you speak with your users.

Plugin A's cookies shouldn't be listed at the bottom by themselves, that makes no sense, yet that is how I imagine most of my own users (very lay) doing it. These penalties can be applied to the smallest of blogs (unlikely but possible), so assuming that every site owner is going to hire a lawyer is a very bad assumption. People writing small blogs occasionally are not gonna spend the time or the $.

I didn't understand at all here. cookies shouldn't be listed at the bottom by themselves what bottom? My plugins cookies will be listed on the policy that I'm pushing to core. You can take that and do as you please with it as with any other information that I might be adding.

If your fear is having to write 5 different filters instead of 1, in my opinion as someone who runs multiple plugins that will have to use these new functionalities, I'd say you strongly need to reconsider, you will thank yourself later when you are not answering needless support tickets or having your users get sued out of oblivion for non compliance.

I don't have a problem writing 10 filters even, but like I said 'communicating' is something that each individual does in a different way, Core can't pre-define that in no means.

Our users problems are our problems. If we can solve them with a little extra effort on the plugin devs part, that is a no-brainer, which is an underlying principle of WP, cough-cough backward compatibility.

I'm just saying that each of ways comes with negatives and positives. The idea is to give freedom to any website owner + plugin author to write their policy and notices as they see fit since that's not Cores territory.

[danieliser]

@xkon

So that will result in a page having 1000 sections because that's what plugin authors decided to do? There's a first problem that I see.

Exactly what happens as it is now ;). If I generate text for a box, it is appended to the default text inserted into the editor (at the bottom, separate from the rest), and we are really to expect users to go back and manually merge it up where it goes?

That is what I want to prevent. Common sections should be standardized with filters to append additional information (cookies, analytics, data usage etc).

But if the common sections don't cover your localized needs, then there are ample ways you can add that info, I mean its WordPress. Actions, filters & editors oh my.. ;)

WordPress is supposed to be easy for users to get going.

WordPress yes, the regulations / laws / policies are not. So there's a really really thin fine line that we shouldn't step over imho.

Correct, and we are again going to assume that the lay masses that use WordPress are going to go above and beyond what the defaults that WP core gives them? I'm betting heavily on not. Since WordPress has the resources( community ) behind it to facilitate decent legaleeze, and to provide a way of easily merging like/similar data ahead of time.

I will have to start with the core policy suggestions, rewrite accordingly, then move on to manually merge in the data from 10+ plugins one at a time, each having different data that has to be merged into the same policy template core already suggested, not just appended to.

And that's what you would/should do if you had 3 plugins saying 'We gather analytics' under the data section you would again have to filter the 2 extras out and re-write it to the tone that you speak with your users.

Well as it is currently there will end up being 3 completely different "Analytics" sections which need to manually be merged. My proposal above again simplifies this. We know common sections like cookies, analytics, data usage, 3rd party services etc are gonna need to be there for most sites. I'm saying make it easy for plugins to send their text directly under those sections in the core suggested text.

Will they still have to rewrite it in their own tone, that is a given (if they even bother). But my proposal doesn't change that, it simplifies it in that they will be able to reword all of the analytics lines at once, not one here, another down the page (which you then cut and paste back at the top).

I didn't understand at all here. cookies shouldn't be listed at the bottom by themselves what bottom? My plugins cookies will be listed on the policy that I'm pushing to the core. You can take that and do as you please with it as with any other information that I might be adding.

To clarify this is the same point I've been making above and I think we are really on the same page, just not communicating it the same.

If your plugin adds to the core text output (as it is now), it gets appended to the bottom. So if you add a list of cookies and a heading above them, that info will come after the very last line of the core text. Meaning the user then has to cut it and paste it back up where the core Cookies section exists already, delete the heading you inserted etc. Very tedious if you have 20 plugins all basically inserting mini privacy policies one after the other and expecting the user to merge them, or even to realize they need to.

1. Core Policy Default Text
2. Plugin A output (containing info that needs to be merged into 1 above, while also removing all the headers needed)
3. Plugin B, & C and on and on.

Ok, so my full proposal I believe will check all of your boxes. From your replies, I think your main issue is that they have to rewrite it in their tone & freedom to update as they see fit.

Since they will always have to rewrite in their own tone from both core and plugins, that really doesn't matter. We are simply talking about the way all of the info is presented, not the words used.

As for freedom, my suggestion is still to provide the default text still, so what they do in the editor after that is completely up to them. I just don't want to have to both reword all that text & have to merge it needlessly.

See my other ticket for context & example of what I'm suggesting #44010.

Also in that ticket I mention using the existing Revision Diff system to allow updated default text to be compared side by side with their own. So it all can work nicely over time if we let it. Most are considering the immediate implications of getting a policy live, few are considering how difficult its gonna be to manage over time adding and removing info.

So consider that if we standardize output of cookies, analytics usage, and various other things, generating policy updates will be much easier, familiar to those using revisions, and less time consuming. That is what I'm advocating for.

[idea15]

Cataegorically, structurally, and legally: absolutely not.

The entire point of GDPR privacy notices is that there are no pre-fed answers beyond the most basic technical paramateter we've already created the functionality for (e.g. this cookie feeds that information).

The entire point of GDPR privacy notices is to get away from site administrators and business owners thinking that this work can be achieved by having it done for them through a template or autogenerated wizards. Look at where that mentality got the web.

The entire point of GDPR privacy notices is that they are the outward reflection of the internal analysis the site administrator has done of the ways their business collects, processes, and shares data. The privacy notice is not a tick-box.

To ask for a template or to expect public disclosure to be done for them has always been the shibboleth of a site administrator who understands neither privacy nor the processes which make it possible, and it will continue to be so.

Replying to danieliser:

fed by core, plugins & themes to generate the bulk of any policy automatically.

[xkon]

Apart from what @idea15 mentioned on comment:11 above, I think I see the difference that @danieliser tries to make.

For a visual example we currently do this on either the postbox that gathers the incoming texts from plugins or the page that is suggested:

WordPress:
What personal data we collect and why we collect it: text
Who we share your data with: text

Plugin 1:
What personal data we collect and why we collect it: text
Who we share your data with: text

Now @danieliser suggestion goes this way:

- What personal data we collect and why we collect it:
WordPress: text
Plugin 1: text
Plugin 2: text

- Who we share your data with:
WordPress: text
Plugin 2: text

Visually it might be better to split it up but in the long run I see people just copy pasting everything and not even care with the divide by heading way.

So as a personal opinion I'll say it again that yes it makes it harder to manage your policy as is at the moment, but it makes it also harder in the good way as you HAVE to read and re-read everything so you completely understand what you're about to write and publish, and imho that's better than a robot-way of copy/paste things that are already split up and ready for you as that shouldn't be the case either way.

Imho this particular new implementation in Core is something that users have to 'easily understand' but not 'easily create' does that difference make sense @danieliser ?

[danieliser]

@xkon Never said it didn't make sense. But a lot of things that make since are still not the right choice.

I'm not sure what your experience with the general WordPress user/admin base is, but I have a great deal over the past 10 years. They (the bulk) are simply not gonna bother. I have spent the last few years developing our interfaces to eliminate problems that shouldn't have existed, simply because users didn't care to spend 3 minutes reading setting descriptions or read the docs.

Is that good for GDPR compliance from a legal standpoint, no, but 90% of them won't care to even modify it, I guarantee you will be able to google exact phrases from core suggested policy in a few months and find millions of results.

Honestly, if we are not careful GDPR has the potential to be a major downfall for WP as a whole. If we don't get this right the first time for all of the community, not just those paying lawyers to help get compliant, you are gonna push them to any other platforms that make it easier, assuming they don't first get fined out of existence.

No offense meant, but I feel like you guys are developing in a bubble, the real world is not all that pretty, and the solution as is won't suffice to prevent a black eye for WP in the world at large.

We build software, we can literally solve any problem with it, I can't fathom how this is the one nobody can solve. A clean & organized suggested text for them to start from is not too much to ask and will ultimately save people a lot of time, money, and effort, for a minimal amount of effort on our part now.

My last 2 cents on the matter. Take it or leave it. Good luck with it, we will all be watching.

[azaozz]

Replying to xkon:

Now @danieliser suggestion goes this way:

- What personal data we collect and why we collect it:
WordPress: text
Plugin 1: text
Plugin 2: text

- Who we share your data with:
WordPress: text
Plugin 2: text

Yeah, I think this is something we should explore as a UI. I actually see it more like different "steps" on different "screens", something like completing a survey:

**What personal data we collect and why we collect it**
  [Description/summary of what to add under this heading]
   Libero Aliquam tristique facilisis sem pulvinar Phasellus malesuada vitae Mauris
   adipiscing. Egestas faucibus consectetuer massa...
------------------------------------------------------------------------------
  WordPress:
    Suggested text: Lorem ipsum dolor sit amet consectetuer convallis...
  
  Plugin 1: text
    Suggested text: Vitae velit consectetuer semper eleifend...

  Plugin 2: text
    Suggested text: Libero Vestibulum sollicitudin Nulla magna...

<< Previous | Next >>

This way the Privacy Policy Guide will be "less cluttered" and perhaps less scary/tedious looking. However this doesn't mean we will automatically insert all of the data/info under each heading. This should remain a "guide" or "tutorial" on making the policy, it can never create a policy by itself.

Ultimately it is @melchoyce's decision if we are going to go that way.

[azaozz]

Replying to danieliser:

They (the bulk) are simply not gonna bother.

I understand your concerns and I share many of them. At the same time there are things we just cannot do as developers or as a community. If people don't care to do something we cannot "make them" care, and as stated above several times, we cannot "write" a privacy policy for anybody, we only can help them write one ("we" as in the WordPress developers and the WordPress community).

Honestly, if we are not careful GDPR has the potential to be a major downfall for WP as a whole.

Yep, I agree, but not just WP. The GDPR has the potential to be a major downfall for the Internet as a whole, eliminating small websites and leaving only huge corporations' websites as only they can afford to be compliant. This makes for a good "conspiracy theory", perhaps. I'm sure there will be people trying to use the GDPR as a censorship "tool" or to "kill" their competitors, but somehow don't believe anything like that will ever happen on a large scale :)

[desrosj]

Moving to the new Privacy component.