(In reply to Masayuki Nakano [:masayuki] (he/him)(JST, +0900) from comment #5) > It was intentionally disabled in bug 271154. > > dholbert: Do you think the change should be canceled for web-compat issue or something? Yeah, I think we should revert that change. It looks like we disabled undo in password fields, at a UX cost (a basic keyboard function not working), for a *purported* security & compat benefit; however: (1) The compat benefit didn't actually exist and was a misunderstanding (see bug 271154 comment 7 and bug 271154 comment 8), so this was and remains a Firefox-only behavior. (2) The security benefit seems extremely marginal. The attack scenario (having typed your full password into a login form, and then deleted it, and then walked away from your keyboard) seem pretty strained -- and in that scenario, there would be plenty of other similarly-sensitive bits of information (e.g. session cookies in particular, if you forgot to log out of some website) that someone could just as easily take, which we don't bother to protect. The "browser program continuously running on a public computer where users might type in their password and then just walk away" attack scenario from bug 271154 made some sense in 2004; but these days, a setup like that would almost certainly want to involve a browser restart [at a minimum] between usages. Otherwise, there's all sorts of potentially-leaked-between-users sensitive user data, and Ctrl+Z-disabling isn't a particularly robust protection. dveditz, I should probably defer to you on a security-judgement here, both in general & since you were involved in bug 271154 -- do you agree that it'd be fine to revert bug 271154 and reenable Ctrl+Z in password fields (matching how all other browsers behave & have always behaved)?
Bug 1833264 Comment 6 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
(In reply to Masayuki Nakano [:masayuki] (he/him)(JST, +0900) from comment #5) > It was intentionally disabled in bug 271154. > > dholbert: Do you think the change should be canceled for web-compat issue or something? Yeah, I think we should revert that change. It looks like we disabled undo in password fields, at a UX cost (a basic keyboard function not working), for a *purported* security & compat benefit; however: (1) The compat benefit didn't actually exist and was a misunderstanding (see bug 271154 comment 7 and bug 271154 comment 8), so this was and remains a Firefox-only behavior. (2) The security benefit seems extremely marginal. The attack scenario (having typed your full password into a login form, and then deleted it, and then walked away from your keyboard) seem pretty strained -- and in that scenario, there would be plenty of other similarly-sensitive bits of information (e.g. session cookies in particular, if you forgot to log out of some website) that someone could just as easily take, which we don't bother to protect. The "browser program continuously running on a public computer where users might type in their password and then backspace it and then just walk away" attack scenario from bug 271154 made some sense in 2004; but these days, a setup like that would almost certainly want to involve a browser restart [at a minimum] between usages. Otherwise, there's all sorts of potentially-leaked-between-users sensitive user data, and Ctrl+Z-disabling isn't a particularly robust protection. dveditz, I should probably defer to you on a security-judgement here, both in general & since you were involved in bug 271154 -- do you agree that it'd be fine to revert bug 271154 and reenable Ctrl+Z in password fields (matching how all other browsers behave & have always behaved)?
(In reply to Masayuki Nakano [:masayuki] (he/him)(JST, +0900) from comment #5) > It was intentionally disabled in bug 271154. > > dholbert: Do you think the change should be canceled for web-compat issue or something? Yeah, I think we should revert that change. It looks like we disabled undo in password fields, at a UX cost (a basic keyboard function not working), for a *purported* security & compat benefit; however: (1) The compat benefit didn't actually exist and was a misunderstanding (see bug 271154 comment 7 and bug 271154 comment 8), so this was and remains a Firefox-only behavior. (2) The security benefit seems extremely marginal. The attack scenario (having typed your full password into a login form, and then deleted it, and then walked away from your keyboard) seem pretty strained -- and in that scenario, there would be plenty of other similarly-sensitive bits of information (e.g. session cookies in particular, if you forgot to log out of some website) that someone could just as easily take, which we don't bother to protect. The "browser continuously running on a public computer where users might type in their password and then backspace it and then just walk away" attack scenario from bug 271154 made some sense in 2004; but these days, a setup like that would almost certainly want to involve a browser restart [at a minimum] between usages. Otherwise, there's all sorts of potentially-leaked-between-users sensitive user data, and Ctrl+Z-disabling isn't a particularly robust protection. dveditz, I should probably defer to you on a security-judgement here, both in general & since you were involved in bug 271154 -- do you agree that it'd be fine to revert bug 271154 and reenable Ctrl+Z in password fields (matching how all other browsers behave & have always behaved)?
(In reply to Masayuki Nakano [:masayuki] (he/him)(JST, +0900) from comment #5) > It was intentionally disabled in bug 271154. > > dholbert: Do you think the change should be canceled for web-compat issue or something? Yeah, I think we should revert that change. It looks like we disabled undo in password fields, at a UX cost (a basic keyboard function not working), for a *purported* security & compat benefit; however: (1) The compat benefit didn't actually exist and was a misunderstanding (see bug 271154 comment 7 and bug 271154 comment 8), so this was and remains a Firefox-only behavior. (2) The security benefit seems extremely marginal. The attack scenario (having typed your full password into a login form, and then deleted it, and then walked away from your keyboard) seem pretty strained -- and in that scenario, there would be plenty of other similarly-sensitive bits of information (e.g. session cookies in particular, if you forgot to log out of some website) that someone could just as easily take, which we don't bother to protect. The "browser continuously running on a public computer where users might type in their password and then backspace it and then just walk away" attack scenario from bug 271154 perhaps made some sense for internet cafes / hotel-lobby-computers in 2004; but these days, a setup like that would almost certainly want to involve a browser restart [at a minimum] between usages. Otherwise, there's all sorts of potentially-leaked-between-users sensitive user data, and Ctrl+Z-disabling isn't a particularly robust protection. dveditz, I should probably defer to you on a security-judgement here, both in general & since you were involved in bug 271154 -- do you agree that it'd be fine to revert bug 271154 and reenable Ctrl+Z in password fields (matching how all other browsers behave & have always behaved)?