Conversation
There was a problem hiding this comment.
Pull request overview
Adds Umami web analytics and documents the associated privacy handling.
Changes:
- Injects the Umami analytics script site-wide.
- Adds and links a new privacy policy.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.
| File | Description |
|---|---|
eleventy.config.mjs |
Adds footer link and analytics transform. |
app/privacy-policy.md |
Documents analytics data processing. |
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
# Conflicts: # .github/workflows/update-umami.yml
|
Moving conversation with @annapowellsmith-nhs from Slack: SL:
Recent Umami script change history (AI summary) So the tracker is actively maintained, with real behavioural and even security-adjacent changes (e.g. referrer leakage fix, double-init fix) landing roughly every 1–4 weeks on average, not just cosmetic tweaks. Honest opinion - what approach would you take here? APS: My instinct is to checksum, version number the script url, and only update for major versions - but there may be things I've missed, I'll have a proper look. (We should probably move this discussion to the PR!) I think the checksum approach is lighter weight, means we can control when we need to update umami, we can do the hash and URL part, and just make a PR to update the version - and assuming the repo owners trust us, it's an easy enough PR to merge. |
| @@ -0,0 +1,91 @@ | |||
| # We keep a reviewed copy of the tracking JavaScript snippet in the repository. | |||
| # Loading it from CloudFront would allow its contents to change without a code | |||
There was a problem hiding this comment.
Not sure this is true if we load it from Cloudfront and use the integrity crossorigin attributes to checksum?
|
@sjlegg thanks for adding a copy of the slack convo! As per comment, I am still wondering if we can just point the I guess the advantage of keeping the file locally is that, when we come to upgrade, future owners of this repo have total confidence over what they're merging: the disadvantage is that when we come to upgrade, we'd need to sync deployment of the Umami upgrade with the merge here, which makes things more complex. Overall, keeping the script third-party feels cleaner to me, but happy to hear counterarguments. :seagull_emoji: |
There was a problem hiding this comment.
I'd put this in a new app/assets/scripts folder.
<head>to stream web analytics data to Umami (NHSE-hosted in AWS)