1735384 - [css-ui-4] Implement "input-security" CSS property

Status: NEW

(Core :: Layout: Form Controls, enhancement)

Description

[Luke]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/100.0.4662.6 Safari/537.36

Steps to reproduce:

https://drafts.csswg.org/css-ui-4/#input-security

Expected results:

Firefox should implement the input-security CSS property.

Comment 1

[Luke]

WebKit has implemented this https://bugs.webkit.org/show_bug.cgi?id=184510

Comment 2

[Release mgmt bot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::Layout: Form Controls' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Comment 3

[Emilio Cobos Álvarez (:emilio)]

I agree this is a bit overdue... We already have code for this using autofill and it's easy to extend. I have a question for Masayuki though:

Right now we store unmasked password ranges in TextEditor/PasswordMaskData. However it seems we only use it to mask/unmask the whole field at once: https://searchfox.org/mozilla-central/rev/d37daf2f82ed22b6a2a5cbbb975423825dfd69fa/toolkit/components/passwordmgr/test/LoginTestUtils.jsm#561-571. Is this something we can simplify after implementing this to always unmask the whole thing? We should probably also remove the automask timer and all that stuff to implement it in JS.

Comment 4

[Emilio Cobos Álvarez (:emilio)]

Attachment: Bug 1735384 - Implement input-security. r=jfkthame!,masayuki!

I believe a bunch of the editor masking / unmasking APIs can be
simplified with a bit of effort (I gave it a shot but there's also the
Android "echo password" code so I got a bit confused).

But anyhow probably can be a follow-up. Masayuki if you have pointers
I'd be happy to do the work.

Comment 5

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

(In reply to Emilio Cobos Álvarez (:emilio) from comment #3)

Right now we store unmasked password ranges in TextEditor/PasswordMaskData. However it seems we only use it to mask/unmask the whole field at once: https://searchfox.org/mozilla-central/rev/d37daf2f82ed22b6a2a5cbbb975423825dfd69fa/toolkit/components/passwordmgr/test/LoginTestUtils.jsm#561-571. Is this something we can simplify after implementing this to always unmask the whole thing?

The API can be simplified, but partial unmasking feature is used on mobile to show last input character for a moment. So the implementation cannot be simplified.

We should probably also remove the automask timer and all that stuff to implement it in JS.

The timer is also used on mobile. And I'm not sure it's better or not to move the timer to JS because it makes code implementing a feature separated to multiple places, and it may cause making it harder to understand for new developers.

Comment 6

[Mats Palmgren (inactive)]

The 'input-security' property may be used by authors to enable or disable this obscuring.

Hmm, why should the CSS author be involved in that?
Isn't the problem here that we haven't implemented bug 502258?
(a built-in button inside the password field that the user can click on the show the password text)

It seems to me that the user should be in control of this, not the CSS author.

Comment 7

[Mats Palmgren (inactive)]

The spec says:

Users may wish to temporarily disable this obscuring in order to confirm that they’ve typed their sensitive information correctly. The input-security property may be used by authors to enable or disable this obscuring.

https://drafts.csswg.org/css-ui-4/#input-security

I agree with the use case -- users need a way to temporarily disable the obscuring -- but I think the spec authors arrive at the wrong solution.
I'm guessing their intent is that the page author should build an unmasking button and set the input-security property to do the unmasking.
I think this is a bad solution to the problem. This feature is much better implemented in the UA by supporting it directly in the password field.
That way the user only need to learn one way of doing the unmasking, the same way for all sites, and it will be available everywhere.
Also, an UA can likely implement a much better solution just in terms of usability/discoverability etc. E.g. putting the unmasking
button inside the password field itself, having a keyboard shortcut consistent with the platform etc.

I tend to think we should not implement this property. We should instead raise the concern that pushing the burden
of implementing this feature onto page authors has numerous problems. It will undoubtedly lead to numerous
incompatible implementations, some of which completely fail to work in some UAs. I suspect most implementations
will also require JavaScript, so they will not work for NoScript users.

EDIT: this will very likely lead to abuse as well, e.g. * { input-security: none; }

Comment 8

[Sebastian Zartner [:sebo]]

For reference, the specification of this property was decided in https://github.com/w3c/csswg-drafts/issues/2495.

I guess you're right that the main point here is that users need a way to show the value they've entered and that's also what François Remy wrote in that thread.

I think the main use case for having such a property (or new values for text-transform) is to allow to obscure other inputs than passwords.
And I agree that something like * { input-security: none; } should rather not be possible for page authors, though they can already achieve this by using normal inputs instead of password inputs. (And that is obviously already done in order to implement the unobscuring feature.)

Anyway, the discussion about this feature should rather take place within the CSSWG.

Sebastian

Comment 9

[Mats Palmgren (inactive)]

(In reply to Sebastian Zartner [:sebo] from comment #8)

I think the main use case for having such a property (or new values for text-transform) is to allow to obscure other inputs than passwords.

Well, they should use <input type=password> for anything that is a secret, whether that's a password or not. I don't really see a use case where a different control would be more appropriate.

The more I think about this feature, the more I think we should object to it. I'll file a spec issue to begin with...

Granted, we should also urgently fix bug 502258 to provide a reveal button.

Comment 10

[Mats Palmgren (inactive)]

I filed https://github.com/w3c/csswg-drafts/issues/6788

Comment 11

[Release mgmt bot [:suhaib / :marco/ :calixte]]

There's a r+ patch which didn't land and no activity in this bug for 2 weeks.
:emilio, could you have a look please?
For more information, please visit auto_nag documentation.

Comment 12

[Emilio Cobos Álvarez (:emilio)]

Let's do bug 502258 and keep discussing.