Skip to main content

An add-on for Plone that provides functionality for better complying with the EU's General Data Protection Regulations and ePrivacy Regulations

Project description

https://travis-ci.com/collective/collective.privacy.svg?branch=master

collective.privacy

This Plone add-on adds concepts from the EU’s General Data Protection Regulations to Plone configuration, which makes it easier to create Plone sites that respect the privacy rights of indivuals.

Features

  • ZCML based declaration of uses of data

  • User-facing privacy management form

  • Integration with core Plone features

Core Plone

The following core Plone overrides are included:

  • The sendto_form now validates a to email address against people who have opted-out. The legal basis chosen by default here is legitimate_interest.

  • The analytics viewlet also relies on legitimate interest, on the basis that it assumes the tracking is unobtrusive and that this will be allowed by the upcoming changes to the ePrivacy regulations. If the tracking is obtrusive or the site owner doesn’t want to make this assumption it should be overridden to use consent.

Examples

Users can define a new data processing reason as configuration. For example, an add-on that provides for embedding media might cause users to be tracked. The ZCML would be modified to include:

<configure
    xmlns="http://namespaces.zope.org/zope"
    xmlns:gdpr="http://namespaces.plone.org/gdpr"
    xmlns:i18n="http://xml.zope.org/namespaces/i18n"
    i18n_domain="collective.privacy">
    <gdpr:data_use_category
        name="show_example_media_embed"
        title="Embedded media from example.com"
        description="We use example.com to embed media into the site. example.com monitors
                     the usage patterns of users to provide enhanced analytics to site owners."
        legal_basis="consent"
        identifier="collective.privacy.identifiers.CookieIdentifier"
        storage="collective.privacy.storage.CookieStorage"
        cookies="media_cookie_*,other_cookie"
        />
</configure>

This would add a new item to the privacy controls that relies on consent to proccess data. This means that by default the permission is denied until an end user gives permission.

Note that the i18n domain of your configuration must be collective.privacy if you want to translate titles and descriptions of your new data processing reasons.

You can then guard your uses of the data, for example:

<div tal:condition="python: context.portal_privacy.processingIsAllowed('show_example_media_embed')">
    ...
</div>

Identifiers

It is necessary to tell one user from another when managing their preferences. In some cases different identifiers are more useful than others. For example, when sending email we want to key users on the email address, but using cookies should be managed by the browser, regardless of the user’s logged in state.

The way of choosing which is used is called a identifier. The following are available:

collective.privacy.identifiers.CookieIdentifier

This identifier should be used in cases where the storage is cookie based. It allows the current user to be identifier, but not other arbitrary users.

collective.privacy.identifiers.EmailIdentifier

This identifier should be used when the user needs to be identified by email address. It can optionally use the email address of a logged in user to identify the current request, but in general it cannot identify the current user.

The identifier is a UUID derived from the email address using a one-way function, not the email itself.

collective.privacy.identifiers.IPIdentifier

This identifier should be used to identify a connection. It can be used to identify the current user or other arbitrary users. It is less reliable than the CookieIdentifier as users IP addresses can change.

The identifier is a UUID derived from the IP address using a one-way function, not the IP itself.

collective.privacy.identifiers.UserIdentifier

This identifier can only be used to identify logged-in users. It can identify any users who are registered on the site, but not anonymous visitors. As such, it’s appropriate for data processing that only occurs for registered users.

The identifier is a UUID derived from the user name using a one-way function, not the username itself.

Storages

The storage determines how the user’s preferences are persisted. There are three storages available:

collective.privacy.storage.CookieStorage

This storage uses a cookie called ‘dataprotection’ on the user’s browser. Consent is not required to set this cookie as it is set to comply with legal obligations and cannot be used to track the user.

collective.privacy.storage.DatabaseStorage

This storage uses BTrees inside the portal_privacy tool to store the time the user consented or objected. It is currently the only storage that allows for the preferences of users to be queried outside of a request they have initiated.

collective.privacy.storage.NoChoiceStorage

This is a stub storage to be used with legal bases such as vital_interest where the user has no option to object to processing.

Cookies

This attribute lists the cookies that should be deleted if the user objects to the use of the corresponding data processing. It is optional and may contain wildcard (*).

Translations

This product has been translated into

  • French

  • Dutch

Installation

Install collective.privacy by adding it to your buildout:

[buildout]

...

eggs =
    collective.privacy

and then running bin/buildout

Varnish

If you use this product combined with Varnish ensure that your Varnish config does not remove cookies for requests where caching should be ignored

Example of config:

if (req.http.Cache-Control ~ "(private|no-cache|no-store)" || req.http.Pragma == "no-cache") {
    return (pass);
}

Thanks

Thanks to Jazkarta ( http://jazkarta.com/ ) and YES! Magazine ( http://www.yesmagazine.org/ ) for each sponsoring some of the development costs of this add-on.

The irony that these are both US companies is not lost on us.

Contribute

Support

If you are having issues, please let us know.

License

The project is licensed under the GPLv2.

N.B., the GPL states:

THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM “AS IS” WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION.

This add-on has not received any contributors from lawyers and should not be interpreted as legal advice.

Contributors

Changelog

1.1.0b2 (2022-01-07)

  • Fix Fixed ModuleNotFoundError: No module named ‘App.class_init’ on Zope 5. [laulaz]

  • Defer the execution of consent.js (#18). [comwes]

1.1.0b1 (2021-08-19)

  • Fix translation domain & add translations for custom text in send_to_form email [laulaz]

  • Fix traceback on send_to_form when sending an email : getConsentLink method must be accessible from template [laulaz]

  • Fix consent banner miss (when there are multiple cookies to accept) by ensuring JS event is only registered once on consent banner button. [laulaz]

  • Handle multilingual & subsites configurations by rendering consent form on navigation root (#15) [laulaz]

  • Fix JSON call for banner consent to get correct language in some multilingual configurations, if the current language must be taken from context (#14) [laulaz]

  • Ensure that consent banner shows on top (z-index) of everything else (eg: Google Maps) [laulaz]

1.1.0a1 (2020-05-12)

  • Add Python 3 and Plone 5.2 compatbility [mpeeters]

1.0b1 (2020-04-30)

  • Avoid caching for consent banner [mpeeters]

  • Don’t show consent banner on consent form [laulaz]

  • Allow to delete specified cookies if user objects to their use [laulaz]

  • Add Dutch translation [laulaz]

  • Add link to manage privacy settings [laulaz]

  • Translate all messages / data processing reasons [laulaz]

  • Fix consent submission [mpeeters]

  • Fix validator for sendto_email [mpeeters]

  • Add French translations [laulaz]

  • Add code to give better warnings around cookie use [MatthewWilkes]

  • Provide uninstall steps in profile (#1) [Mikel Larreategi]

  • Possible fix for diazo compatibility [MatthewWilkes]

  • Unintrusive analytics are legitimate [MatthewWilkes]

  • Remove unneeded skins call [MatthewWilkes]

  • Add missing files [MatthewWilkes]

  • Remove unneeded deps [MatthewWilkes]

1.0a1 (2018-08-25)

  • Initial release. [MatthewWilkes]

Project details


Download files

Download the file for your platform. If you're not sure which to choose, learn more about installing packages.

Source Distribution

collective.privacy-1.1.0b2.tar.gz (39.7 kB view details)

Uploaded Source

File details

Details for the file collective.privacy-1.1.0b2.tar.gz.

File metadata

  • Download URL: collective.privacy-1.1.0b2.tar.gz
  • Upload date:
  • Size: 39.7 kB
  • Tags: Source
  • Uploaded using Trusted Publishing? No
  • Uploaded via: twine/3.6.0 importlib_metadata/4.8.1 pkginfo/1.7.1 requests/2.26.0 requests-toolbelt/0.9.1 tqdm/4.62.3 CPython/3.7.0

File hashes

Hashes for collective.privacy-1.1.0b2.tar.gz
Algorithm Hash digest
SHA256 65cbd023499b4bdae40b33bb9a89fcf20cb59f90de7ce1a1953c23669b91c622
MD5 07bda9a51fb17f3e0b067352036eb1cb
BLAKE2b-256 c98f5eb183aff052839fb3169a3bd9245775f3ede918f1cc86f19f6a07aaafe4

See more details on using hashes here.

Supported by

AWS AWS Cloud computing and Security Sponsor Datadog Datadog Monitoring Fastly Fastly CDN Google Google Download Analytics Microsoft Microsoft PSF Sponsor Pingdom Pingdom Monitoring Sentry Sentry Error logging StatusPage StatusPage Status page