This repository has been archived by the owner. It is now read-only.
Redact emails in GA events #121
Merged
Conversation
Prevent apps from accidentally sending government user’s email addresses to Google Analytics. This was previously added on a case by case basis in app code. However some emails still made it through as it wasn’t always considered. Instead do a blanket prevention.
|
|
fofr
added a commit
to alphagov/signon
that referenced
this pull request
Mar 30, 2016
Now provided at the JS level by govuk_admin_template: alphagov/govuk_admin_template#121
fofr
added a commit
to alphagov/whitehall
that referenced
this pull request
Mar 31, 2016
This is now handled by the admin gem itself, in the JS layer: alphagov/govuk_admin_template#121
fofr
added a commit
to alphagov/support
that referenced
this pull request
Mar 31, 2016
This is now handled by the admin gem itself, in the JS layer: alphagov/govuk_admin_template#121
fofr
pushed a commit
to alphagov/transition
that referenced
this pull request
Mar 31, 2016
Pick up change to automatically strip email addresses from all event actions and labels: alphagov/govuk_admin_template#121
h-lame
added a commit
to alphagov/govuk_frontend_toolkit
that referenced
this pull request
Sep 29, 2017
We don't use email addresses in any path segments, query strings, or event tracking on the site at the moment, but that doesn't mean that we don't end up tracking them if they're added to incoming urls. We try to detect any potential email addresses in any arguments sent to our analytics trackers and swap them out for the placeholder `[email]`. We took inspiration from similar work in govuk_admin_template (see: alphagov/govuk_admin_template#121) although our regexp is different. The admin version uses `\S@\S` but this is too greedy for our purposes, as it would turn a path like `/talk/to/government/embedded.email@example.com` into `[email]`, when we want to keep theh rest of the path, just strip out the email address. We instead use `[^\s=/?&]@[^\s=/?&]` which allows us to stop the regexp at standard url path or query string boundaries. We only use `stripPII` in the `trackPageview`, `trackEvent`, `trackShare`, and `setDimension` methods and leave `addLinkedTrackerDomain` as it was. `addLinkedTrackerDomain` sets config, rather than sends data to the tracker so it's safe to leave as is (and it's not clear what might happen if we interfered with the arguments to this method). It doesn't look like any code on github uses `sendToTrackers` directly, so we should be covered by stripping PII only in those methods.
h-lame
added a commit
to alphagov/govuk_frontend_toolkit
that referenced
this pull request
Nov 2, 2017
We don't use email addresses in any path segments, query strings, or event tracking on the site at the moment, but that doesn't mean that we don't end up tracking them if they're added to incoming urls. We try to detect any potential email addresses in any arguments sent to our analytics trackers and swap them out for the placeholder `[email]`. We took inspiration from similar work in govuk_admin_template (see: alphagov/govuk_admin_template#121) although our regexp is different. The admin version uses `\S@\S` but this is too greedy for our purposes, as it would turn a path like `/talk/to/government/embedded.email@example.com` into `[email]`, when we want to keep theh rest of the path, just strip out the email address. We instead use `[^\s=/?&]@[^\s=/?&]` which allows us to stop the regexp at standard url path or query string boundaries. We only use `stripPII` in the `trackPageview`, `trackEvent`, `trackShare`, and `setDimension` methods and leave `addLinkedTrackerDomain` as it was. `addLinkedTrackerDomain` sets config, rather than sends data to the tracker so it's safe to leave as is (and it's not clear what might happen if we interfered with the arguments to this method). It doesn't look like any code on github uses `sendToTrackers` directly, so we should be covered by stripping PII only in those methods.
h-lame
added a commit
to alphagov/govuk_frontend_toolkit
that referenced
this pull request
Nov 14, 2017
We don't use email addresses in any path segments, query strings, or event tracking on the site at the moment, but that doesn't mean that we don't end up tracking them if they're added to incoming urls. We try to detect any potential email addresses in any arguments sent to our analytics trackers and swap them out for the placeholder `[email]`. We took inspiration from similar work in govuk_admin_template (see: alphagov/govuk_admin_template#121) although our regexp is different. The admin version uses `\S@\S` but this is too greedy for our purposes, as it would turn a path like `/talk/to/government/embedded.email@example.com` into `[email]`, when we want to keep theh rest of the path, just strip out the email address. We instead use `[^\s=/?&]@[^\s=/?&]` which allows us to stop the regexp at standard url path or query string boundaries. We only use `stripPII` in the `trackPageview`, `trackEvent`, `trackShare`, and `setDimension` methods and leave `addLinkedTrackerDomain` as it was. `addLinkedTrackerDomain` sets config, rather than sends data to the tracker so it's safe to leave as is (and it's not clear what might happen if we interfered with the arguments to this method). It doesn't look like any code on github uses `sendToTrackers` directly, so we should be covered by stripping PII only in those methods.
h-lame
added a commit
to alphagov/govuk_frontend_toolkit
that referenced
this pull request
Feb 7, 2018
We don't use email addresses in any path segments, query strings, or event tracking on the site at the moment, but that doesn't mean that we don't end up tracking them if they're added to incoming urls. We try to detect any potential email addresses in any arguments sent to our analytics trackers and swap them out for the placeholder `[email]`. We took inspiration from similar work in govuk_admin_template (see: alphagov/govuk_admin_template#121) although our regexp is different. The admin version uses `\S@\S` but this is too greedy for our purposes, as it would turn a path like `/talk/to/government/embedded.email@example.com` into `[email]`, when we want to keep theh rest of the path, just strip out the email address. We instead use `[^\s=/?&]@[^\s=/?&]` which allows us to stop the regexp at standard url path or query string boundaries. We only use `stripPII` in the `trackPageview`, `trackEvent`, `trackShare`, and `setDimension` methods and leave `addLinkedTrackerDomain` as it was. `addLinkedTrackerDomain` sets config, rather than sends data to the tracker so it's safe to leave as is (and it's not clear what might happen if we interfered with the arguments to this method). It doesn't look like any code on github uses `sendToTrackers` directly, so we should be covered by stripping PII only in those methods.
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Prevent apps from accidentally sending government user’s email addresses to Google Analytics.
This was previously added on a case by case basis in app code. However some emails still made it through as it wasn’t always considered. Instead do a blanket prevention.
Based on existing Sign on approach:
https://github.com/alphagov/signonotron2/blob/ac7e56dcc84e5572ef51aa066356d32f6fcc122a/app/helpers/application_helper.rb#L31
https://trello.com/c/0SLWcJwI/337-strip-personally-identifiable-information-before-sending-to-analytics-medium