[Marsymars]

I don't think "users on public machines" are really a subset of people worth catering to at the expense of others.

Public machines without sandboxed user sessions seem largely uworkable in the first place - does anywhere actually do that? (I've never been to a library, school/university or workplace that does.)

[noduerme]

I mostly develop in-house business apps. So a prime example would be an application used at a shared corporate workstation. It's also not just about preventing credentials from leaking -- literally any form that is used by multiple users several times a day will start to accrete autofills, and that needs to be prevented.

By the way, are you under the impression that most internet cafes scrub the browser autofill data once a paid user logs out, or that it isn't collected by the time apportionment software in places like China or Vietnam?

[Marsymars]

I find it surprising that there are corporations that are using shared workstations in that way. My company has shared workstations, but you need to log in with your own account, as has been the case for every one of my previous employers.

Modern operating systems and browsers seem like they’d have all kinds of pain points if they’re used by multiple users.

[noduerme]

Yes. Imagine the front desk of a retail store, where each employee on their shift logs in, uses the software, and then logs out at the end of their shift. You don't want autofill to build up memory of customers or anything over their login period.

[throwawayboise]

A shared workstation should still be using separate user accounts, or an "anonymous" account that is completely reset (files, cache, browser history, etc.) between logins if there is some reason user accounts aren't possible.

[noduerme]

Think hotel chain with 2-3 employees at a checkin desk, plus a manager on a personal laptop and a franchise owner on a tablet off-site. We have nowhere near that level of control even over front desk machines. Can't even dictate whether they're mac or pc. The software has to do all the heavy lifting of verifying each device by SMS confirmation with the managers, but we have no control over how the machines are set up... I don't think they'd even know how to create multiple user accounts, and if they did, no one would actually log out or follow security protocols anyway.

[mikeryan]

The problem here is your initial recommendations is to "Break autofill for everyone on your website so there's not a security risk in a very few edge cases".

Note all of those edge cases are on computers that should have Auto-fill disabled as part of an IT policy.

[noduerme]

the problem is that autofill fields persist regardless of login credentials to a particular site, as long as Chrome detects the input fields to be the same. Like, try a standard form behind a login process... then log out and log in as another user... chrome will suggest what the last user entered if you don't rename the input field.

[ellen364]

Admittedly my first thought was “Turn off the browser’s auto fill.” On reflection, guessing that, although the work is all in-house, the software team has no influence over the setup of the client devices?

If the devices are all under company control, I suppose they could still turn off auto fill. But in a big company that’s a lot of devices and probably comes out of another department’s budget. Then the auto fill behaviour becomes the web app’s problem, despite being a browser behaviour.

[noduerme]

We have every kind of laptop and mobile device logging in at different levels of access, along with retail stations requiring employee logins and customer facing microservices. At best we can kind of dictate that no one is allowed to use Internet Explorer. The Chrome autofill is a genuine problem on kiosks and workstations. We can barely get retail employees to figure out how to clear a browser cache, much less make them configure the preferences to how we'd like them to be. The front end code has to be written as if the employees have absolutely no clue how to use a computer.