Wp-calypso: GDPR/Privacy: Provide a means to create/edit/post a privacy policy for a site

[allendav]

Updated on March 8 to broaden scope beyond just Stores on WordPress.com. This really applies to any site.

Proposed Tasks:

• [ ] for new sites, or sites without a privacy policy, prompt site administrators to create a privacy policy (esp. EU sites)
• [ ] decide where to expose privacy policy page editor and settings ( Sites and/or Sites > Store ) — see also core WordPress https://core.trac.wordpress.org/ticket/43389 and https://core.trac.wordpress.org/ticket/43435 )
• [ ] decide what to do (if anything) about privacy policy contributions (snippets?) that core WordPress and any other plugins (e.g. core WooCommerce, WooCommerce Services, Jetpack, etc.) provide

See also:

https://github.com/Automattic/wp-calypso/issues/22624 Front-of-site privacy banners

Detailed Requirements:

It would be good to have a dedicated view for a user to manage their site's privacy policy. With GDPR and CalOPPA (and other laws) privacy policies are a must-have for a modern web site.

Beyond a simple page editor, the view could

• provide placeholders / prompts for sections
• provide prefab "blocks" for things that are active on the site (e.g. stats, google analytics, jetpack, etc.)

Places like Settings > Traffic > Google Analytics could link out to this view (i.e. when someone activates GA, they will want to update their privacy policy to mention it.

Features like Business Plan > Store on WordPress.com could also "link out" to this view.

needsdesign cc @hollyannehogan @kellychoffman @jameskoster

[allendav]

Could perhaps leverage this: https://github.com/GDPRWP/standard/issues/5

[kellychoffman]

Sounds like we need this for new sites:

• Sample page added to all new sites called Privacy Policy
• Content is pre-filled with suggested sections (copy needed)

And this for existing sites:

• An admin notice explaining that a Privacy Policy is needed (copy needed)
• Two action buttons: Create the page yourself or have us create one for you (will still need to be edited of course)

Does that sound right?

provide prefab "blocks" for things that are active on the site (e.g. stats, google analytics, jetpack, etc.)

Could you explain this further? Where would these blocks live?

[allendav]

Does that sound right?

IANAL, but that sounds like a good start

provide prefab "blocks" for things that are active on the site (e.g. stats, google analytics, jetpack, etc.)

I _think_ these "blocks" could maybe be (read-only?) paragraphs/bullet points from each of those plugins, that, if the plugin/feature is enabled, gets automatically added to the site's policy, something along the lines of what I've proposed in https://github.com/GDPRWP/standard/issues/5

In other words, the "blocks" would be translated text that lives in those plugins and is hooked by those plugins into special shortcodes embedded in the various sections of the doc and/or exposed via some "policy builder" UX in calypso. The possibility of Gutenberg blocks for those blocks also crossed my mind (see what i did there?).

And even though some things like "WordPress.com stats" aren't a plugin per se, things like that could use the same framework to report out on how they collect and use visitor data.

[kellychoffman]

Ah, interesting. I think we might have to stick with shortcodes to start, until Gutenberg comes around.

IANAL, but that sounds like a good start

I'll wait to hear back from our legal team to see if we need anything else. Otherwise, this feels fairly straight forward from a design perspective.

[allendav]

The ideal solution will

• provide a template for merchants (and their counsel) to use/fill-in
• have clear prompts for key concepts such as
  
  
  
  • What data is collected from the user
  
  
  • What the merchant does with the data / why the data is collected
  
  
  • Who the data is shared with (e.g. third-parties)
  
  
  • Where the data is stored, how access to the data is protected
  
  
  • How long data is retained
  
  
  • What options the user may have about data collection and use
  
  
  • How the user can access, update, or delete the collected data
  
  
• somehow incorporate how active plugins handle data

Related GDPR articles: 7, 13, 14

[stale[bot]]

This issue has been marked as stale and will be closed in seven days. This happened because:

• It has been inactive in the past 9 months.
• It isn't a project or a milestone, and hasn’t been labeled `[Pri] Blocker`, `[Pri] High`, `[Status] Keep Open`, or `OSS Citizen`.

You can keep the issue open by adding a comment. If you do, please provide additional context and explain why you’d like it to remain open. You can also close the issue yourself — if you do, please add a brief explanation.