Hospitals: I only share what I know is done through experience. I agree screens lock quickly, but that’s not a logout of the browser, much less the OS’s user. Can you imagine what people would do if the computer had to login, apply policies, setup network connections, all before loading some application to do whatever doctors and nurses do while somebody was dying? In a similar vein, the logins are not usually username/password as much as badge plus a short PIN for the same reason. ERs, ORs, and most other rooms, still need to document patient information, so where I’ve done work it has been consistent everywhere.
Library: Restart-on-logout policies exist, and are effective as long as the admins manually clean out caches for everything on the box, but I’ve seen as many places do otherwise (one of many reasons I never used shared workstations, at all, ever, with my credentials). I’ve seen the same unfortunate setup in hotels and Internet cafes (or coffee shops) regularly, for what it’s worth.
It seems odd to me that any application would default to this setting for all users in all installations. Security isn’t the focus of most people when they first setup computers, and it’s complex enough generally that it’s people’s full-time professions. Those who setup computers for the public should know better, but browsers have the idea of session cookies to make it easy for application developers to have sessions when when intuitive for users.
Requiring users to understand that they must manually clear a site’s cookies in order to log out, when many sites will both time out session as well as kill them on browser close, seems like requiring too much of people. Not allowing the alternative at all so that a user must remember to use the specific Discourse logout link becomes an issue when users miss the link for any reason; off the top of my head:
User browses away from Discourse following a link.
User browses away from Discourse because they use the tab to go somewhere else explicitly.
User closes the tab in a hurry leaving to go to class/meeting/etc.
Browser crashes for any reason.
SSO implementer has SAML for login, but does not know the application requires explicit logout to kill the application session.
Also, two (2) months seems like a REALLY long time for a login persist. I know some other sites these days may do that, or even be longer, but users can usually control these with those “Public computer” checkboxes which does not apply with SSO, or maybe at all (I’m not a Discourse guru).
Just more thoughts to consider.