The way Google Analytics is implemented in the layout template causes personal information in the form of an email address to be leaked to Google.
It understands the desire to have a user (rather than browser) identifier in Analytics, so the motivation for the tagging is clear. However, it is not clear if the leak of personal information is intentional or an oversight. Nevertheless is likely problematic for jurisdictions with or subject to GDPR-like privacy frameworks.
The obvious way to work around this and still preserve the functionality is to use a one-way hashing algorithm on the email address before presenting it as a tag. Unfortunately, I've not found an obvious way to do this directly in jinja2. (Flask's implementation seems to only have the native jinja2 filters, and so excludes more useful hashing functions we're used to in e.g. Ansible).
I've commented this out of the templates on our instance. Rather than simply forgetting about it, I thought to open an issue so it can be properly evaluated.
The way Google Analytics is implemented in the layout template causes personal information in the form of an email address to be leaked to Google.
It understands the desire to have a user (rather than browser) identifier in Analytics, so the motivation for the tagging is clear. However, it is not clear if the leak of personal information is intentional or an oversight. Nevertheless is likely problematic for jurisdictions with or subject to GDPR-like privacy frameworks.
The obvious way to work around this and still preserve the functionality is to use a one-way hashing algorithm on the email address before presenting it as a tag. Unfortunately, I've not found an obvious way to do this directly in jinja2. (Flask's implementation seems to only have the native jinja2 filters, and so excludes more useful hashing functions we're used to in e.g. Ansible).
I've commented this out of the templates on our instance. Rather than simply forgetting about it, I thought to open an issue so it can be properly evaluated.