| Summary: | Page title (and thus browser history) exposes patron names, other unnecessary PII | ||
|---|---|---|---|
| Product: | Koha | Reporter: | Jake Bateman <jake.bateman> |
| Component: | Staff interface | Assignee: | Bugs List <koha-bugs> |
| Status: | NEW --- | QA Contact: | Testopia <testopia> |
| Severity: | enhancement | ||
| Priority: | P5 - low | CC: | gmcharlt |
| Version: | Main | ||
| Hardware: | All | ||
| OS: | All | ||
| GIT URL: | Initiative type: | --- | |
| Sponsorship status: | --- | Comma delimited list of Sponsors: | |
| Crowdfunding goal: | 0 | Patch complexity: | --- |
| Documentation contact: | Documentation submission: | ||
| Text to go in the release notes: | Version(s) released in: | ||
| Circulation function: | |||
| Attachments: | An example of the floating/quick history menu in Edge displaying full patron names, after a staff user has logged out of Koha. | ||
Perhaps the HidePatronName system preference should be extended to apply to page titles? |
Created attachment 192234 [details] An example of the floating/quick history menu in Edge displaying full patron names, after a staff user has logged out of Koha. We've recently had a library express privacy concerns relating to the exposure of full patron names, along with application verbs like "issuing to" and "modify user" in the page title, which propagates to browser history and persists after a staff interface logout. While live page titles and browser history of computers used by administrative staff should be considered "not for viewing by unauthenticated users", some cases of computer-sharing or shoulder-surfing in a library setting seems highly likely. This inclusion of full names in page titles to me does not seem strictly necessary. In some testing, we find that a popular CRM also exposes names like this in page titles, while the administrative pages of Gitea and Cloudflare seem to make an explicit effort not to do so. Do we think this warrants changing? I do feel this problem can most effectively be mitigated with process changes, but the question remains; could Koha minimise PII exposure here without impacting functionality?