- From: Daniel Cheng <dcheng@google.com>
- Date: Wed, 1 Oct 2014 21:15:02 -0700
- To: Gavin Sharp <gavin@gavinsharp.com>
- Cc: Dan Poltawski <dan@moodle.com>, whatwg@lists.whatwg.org
On Oct 1, 2014 4:34 PM, "Gavin Sharp" <gavin@gavinsharp.com> wrote: > > Firefox developer here (I was involved in our behavior change). Sorry > to hear that it's causing you trouble. Unfortunately this seems like a > pretty specific, uncommon use case, so we hadn't considered it. And we > probably aren't reasonably able to fix things for you without breaking > other more common use cases we care about (people using password > fields for passwords). > > The underlying use case seems to be obfuscating text in an input field > that isn't a password. From a spec perspective, a feature to opt-in to > obfuscation that isn't type=password could address this (e.g. > type="masked-text"). From your perspective, I suppose you could work > around this by obfuscating the text in the field yourself rather than > letting the browser do it. > > Gavin Doesn't adding this new input type defeat the whole point of ignoring autocomplete=off? Now sites that want to disable password managers will just use this for their password field, and we're back to square one. Daniel > > On Wed, Oct 1, 2014 at 12:19 PM, Dan Poltawski <dan@moodle.com> wrote: > > Hi All, > > > > Over the past few months all the browser vendors have moved towards > > ignoring autocomplete="off" with password fields. I understand the > > rationale behind this, but in our software project this has lead to > > the frustrating situation where we seem to have no good option to deal > > with this and the change is actively harming the security of our > > users. > > > > To outline the situation in broad terms: > > * We have shared secrets on the page which we protect against shoulder > > surfing by using the password element with autocomplete="off" > > * The password managers are now all auto-filling these fields with > > passwords on the same domain and in many cases without the user even > > noticing (optional fields they wouldn't look at) > > * The passwords then get stored in our shared-secret fields clear text > > and available to all their peers > > * This can then be used for privilege escalation etc > > > > It seems like our only option is avoid use of password field at all > > and invent our own 'fake' password field to protect our users > > passwords from being exposed. That seems like a really disappointing > > solution. > > > > (Apologies in advance if this is completely off-list, I saw some > > threads leading to this list and it wasn't clear to me if this sort of > > discussion was acceptable). > > > > cheers, > > Dan
Received on Thursday, 2 October 2014 04:15:26 UTC