When should libraries prioritise kiosk cleanup over broader feature access?

Why kiosk cleanup comes before adding more features

A public terminal is only safe to expand when the cleanup boundary is dependable. If the session can leave behind a logged-in account, an open download, a cached document, or a redirect into a personal service, the extra feature set creates more ways for the next user to inherit someone else’s state. Cleanup is the control that lets shared access exist at all.

That is why the decision is less about convenience than about sequencing. A library kiosk should first prove that the browser, session, downloads, and local storage reset reliably between users, then decide which functions are still worth exposing inside that reset boundary. Without that proof, broader access is just broader exposure.

What “cleanup first” really means on a shared terminal

Cleanup is not only clearing history. It includes ending active sessions, removing cookies or tokens, closing redirected logins, deleting downloaded files, clearing form data, and returning the browser to a known start state. If any one of those pieces survives the handoff, the next patron may be able to continue a prior user’s activity without noticing.

For libraries, the practical test is whether the kiosk can support a clean, repeatable handoff after the highest-risk task it allows. A terminal that only handles catalog browsing has a much smaller state problem than one that can open webmail, cloud storage, account portals, or document downloads. The more personal the task, the more complete the reset has to be.

A useful rule is to match functionality to the reliability of the reset. If the cleanup process is partially manual, brittle, or dependent on user honesty, keep the feature set narrow. If the reset is automated, verified, and resistant to error, more features can be added without turning the kiosk into a shared-data leak.

How to decide whether broader access is worth the risk

The decision should start with the user impact of failure, not with the requested feature list. A kiosk that can access personal accounts or local files creates a different risk profile from a kiosk used only for browsing or printing. In the first case, a missed cleanup step can expose another user’s documents, session, or account state. In the second, the consequence is usually much smaller.

That is why feature expansion should be treated as conditional on verified containment. If a terminal cannot reliably separate one user’s state from the next, the safer choice is to preserve the narrowest workable function set. This is especially true when login flows, file downloads, or document uploads are involved, because those tasks create artifacts that are easy to overlook during cleanup.

Libraries also need to consider visibility. A kiosk that appears reset but still retains background authentication, synced data, or residual files is worse than a kiosk that simply does less. Users trust public terminals to behave like shared infrastructure, so the failure is not only technical. It is a loss of confidence in the service.

Risk and Threat Considerations

Shared terminals can turn ordinary convenience into accidental disclosure when the reset boundary is weak. The main risk is that one patron’s authenticated session, downloaded file, or redirected account flow becomes available to the next person before the kiosk has truly been cleaned.

Failure mechanism: A browser session or local artifact survives between users because logout, cache clearing, download removal, or storage reset did not complete, allowing the next user to inherit access or data.

Impact: Personal account exposure, document disclosure, unintended access to services, and a repeated trust failure for the kiosk programme.

Practitioner Guidance

What to prioritise: Start by defining the maximum acceptable residue after each session. If the kiosk cannot guarantee that residue stays empty for accounts, downloads, and local files, do not expand functionality until that gap is closed.

What to verify: Test the full handoff path after real user actions, not just a normal logout. Confirm that browser state, downloaded files, and any redirected authentication flow are cleared in the same way every time.

Decision rule: If a feature creates durable user state on the terminal, treat it as conditional until the cleanup process is demonstrably reliable. If it does not create durable state, it is a better candidate for early approval.

Practitioner takeaway: On a shared kiosk, cleanup is the control that makes broader access safe; if the reset is not dependable, the correct response is to narrow the feature set, not to accept more risk.

Related resources from NHI Mgmt Group

• When should organisations prioritise access revocation over broader IAM feature upgrades?
• Should teams prioritise privileged access control over broader IGA feature comparisons?
• When should organisations prioritise privileged access over broader identity cleanup?
• When should organisations prioritise orphaned AWS access over broader entitlement cleanup?