[noduerme]

Not mentioned in the article -- a good way to prevent Chrome from ever recognizing the "same" field and attempting to autofill it is to include and randomize a "name=" attribute on all <input> tags, or else name them with a string including a unique user id. This should always be done on web apps. Otherwise the next user on a public computer will see autofill options from previous users.

[mikeryan]

I’d prefer if you didn’t. I like 1Password knowing where to put my credentials when I ask it to.

[noduerme]

It's not necessary on fields where type="password", since those aren't recorded by Chrome (unless you ask it to remember them). But for all other fields, the security of users on public machines far outweighs the convenience of autofill. And as I said, it can be tailored to individual users' uuids if they're logged in.

[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.

[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.