- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 11 Apr 2018 10:00:06 +0000
- To: public-css-archive@w3.org
The Working Group just discussed ``obscuring text for `<input type=password>` styling``, and agreed to the following resolutions: * `RESOLVED: input-security: auto|none in UI 4 and applies to input type=password only` <details><summary>The full IRC log of that discussion</summary> <dael> Topic: obscuring text for `<input type=password>` styling<br> <fantasai> emilio: Your induction should include reading http://rhodesmill.org/brandon/2012/one-sentence-per-line/ :)<br> <dael> github: https://github.com/w3c/csswg-drafts/issues/2495<br> <emilio> fantasai: hah, thanks for the tip, will do :)<br> <fantasai> emilio, http://fantasai.inkedblade.net/weblog/2011/inside-csswg/ is likely also useful :)<br> <dael> myles: Currently input type=password has at least 2 different behaviors. One is password managers use this to do autofill. Another is the text you see is obscured. WE'd like to separate those things because we've seen content stop using input type=password because they want to control the obscure.<br> <dael> myles: Means password managers don't work.<br> <dael> myles: We'd like to split this. In the thread suggestion is to use text-transform so you can have a text-transform to say please obscure. Seems reasonable way to achieve this.<br> <dael> florian: Alternative was a dedicated property.<br> <dael> TabAtkins: If text-transform is used any existing password-inputs that have the text-transform applied would become unobscured.<br> <dael> TabAtkins: Might be small enough to not matter.<br> <dael> myles: I don't think we're amrried to a solution. But we could handle that case separately.<br> <dael> florian: Wouldn't that defeat the point, that people want to remove it so we want to allow people to not apply.<br> <dael> fantasai: You apply in UA stylesheet and text-transform:none turns it off. This breaks inheritance already.<br> <dael> emilio: Should we say only some kind of elements it applies to?<br> <dael> fantasai: text-transform option it applies to all. A sep text-security property you can say it's only that.<br> <dael> emilio: I'm not sure how easy it is to input<br> <dael> tantek: Additional use case in the issue mentions spoilers. We're seeing that with content warnings. text-security property might be worth exploring. THe cow path here is webkit introduced a new property for this, it's another data point.<br> <dbaron> I'm glad that <input type="text" style="text-transform: uppercase"> works today, as shown in http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cinput%20type%3D%22text%22%20style%3D%22text-transform%3A%20uppercase%22%3E<br> <dael> myles: We're interested in a solution we can all agree to.<br> <dael> florian: An earlier point, if we do this through txt-transform we want to allow them to use this value on other and do it on password fields. But if you accidently do text-transform:uppercase to a password field you unobscure. IS that rare enough it doesn't occur?<br> <dael> tantek: Even if it's rare the bad side is too high<br> <dael> myles: Could accept a set.<br> <dael> fantasai: Wouldn't fix the problem.<br> <dael> dbaron: If UA style sheet has obscure on input type password I think it's low-ish. Also given how mobile works I don't think it's horrible if someone messed that up in the past. In mobile you can kind of see the password.<br> <dael> eae: Interaction we're talking about is some way of showing the password I just typed in. Stikes me that's a feature that should be built in by the browser.<br> <dael> fremy: That's what we do.<br> <dael> myles: Impetus for this whole thing<br> <myles> q+<br> <dael> fremy: We already do it and it's better then if you do JS. We make sure you can only do it if it's not auto fill. WE do it better then any property. But I'm not opposed to saying if you have input type=pin you can't want that level of security.<br> <dael> florian: Authors are doing it because most browsers don't have this.<br> <dael> myles: We're bringing this up because it is happening today<br> <Rossen> q?<br> <myles> q-<br> <dael> fremy: If we're talking about changing browsers it's an option. It'll stop completely. It gets the feature that people want and I'm puzzled other browsers don't do that.<br> <dael> fremy: I agree why not spend the time to have this code. Then authors won't need to do this.<br> <dael> plinss: Raises and issue that there are number of controls where if peole show the password button and if browser gives it we should be able to remove it.<br> <dael> Rossen: When we originally shipped you can detect if the action is visible and based on this don't show yours. Or hide ours and put yours. We do the same for search.<br> <dael> tantek: supports can detect.<br> <dael> Rossen: In the beginning we had silly cases with two xs. People that cared either used our or theirs. In either case nothing else needed. For what fremy said in the beginning for all the pre-auto-full you can't show. So if I come to your computer and go to facebook I can't see your password.<br> <richr> eae above was me (richr)<br> <dael> plinss: For me using extensible web manifesto it would be ideal to have a mech to control and expose these features and then have css properties to set. Something you can polyfill.<br> <Rossen> q?<br> <dael> florian: You said some authors hide yours and use theirs for theirs having the property would be useful.<br> <dael> plinss: Let's explain native behavior we've had by css properties. Let's control the hide and pretend it's always on in the UA stylesheet. Let's build it from what we have.<br> <dael> myles: Question on Edge impl, one common UI is to show the character afte ryou type for 100ms. Can you do that?<br> <rego> it seems text-transform is not inherited in <input>: https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=5886<br> <dael> Rossen: Yeah. Behavior you desc we have for mobile when you're on touch. Idea is you're typing fairly slowly. We don't have it on by default. Feature is supported.<br> <dael> myles: Desktop?<br> <dael> Rossen: That's not exposed.<br> <dael> tantek: You don't want that responsibility on the website.<br> <dael> Rossen: We're not going to let people fiddle with our settings.<br> <dael> myles: So WG says make better password fields?<br> <dael> plinss: I think we need CSS to make those better out of CSS so other authors can reason with it.<br> <dael> tantek: WE want authors to use input type=password. That hooks into password managers and such like so authors can impl show me your password. For authros to turn input type=text into a password field I don't want to do that. Because then you have to hook into password managers.<br> <dael> plinss: I don't think we want type-text to take a password but we want type=password to be better.<br> <dael> fantasai: I think if you were wanting to obscure input type=numbers you don't want the spinner, you just want to restrict to numbers and there's ability for that. You use type=password and restrict to numbers.<br> <dael> plinss: Points to a flaw in input where type=password should be orthogonal to data type. I should be able to put in a number field that asks like a password.<br> <dael> tantek: And then you end up with a new attribute to the dom<br> <dael> plinss: I think it should be done, not here.<br> <dael> TabAtkins: Request to have password be manipulatable, given what the browsers attach it should be a separate text-security property.<br> <dael> plinss: And you might want an obscure with count of characters in the future.<br> <tantek> or obscure WITHOUT count of characters or implied number of characters (one "dot" • per pw char)<br> <dael> fantasai: issue with this. If we're giving the author abilityt o make password field no longer obscure we run into fremy problem where you auto-fill a password and that becomes visible.<br> <dael> TabAtkins: If you have visible access to a computer then you own it.<br> <dael> myles: It's an argument for not text transform so the browser can say it's a property and it's auto fill so we'll obscure anyway.<br> <dael> TabAtkins: Text-seurity<br> <dael> fantasai: no effect on anything other then password.<br> <dael> TabAtkins: Yes. We'll handle spoiler case differently.<br> <dael> myles: We want this only to apply to password related things.<br> <dael> tantek: Related use case<br> <dael> florian: Spoilers are reasonable for text-transforms.<br> <dael> plinss: We can remove restiction later.<br> <tantek> no, spoilers are not reasonable for text-transform<br> <dael> myles: inherited I guess.<br> <dael> fantasai: If it's inherited you want it to not ever expand in scope because people will set at root.<br> <dael> tantek: UA could still override it.<br> <dael> plinss: If someone turns on text security at the root and expect it to cascade if we expand you obscure the whole page.<br> <dael> TabAtkins: This isn't for spoilers. This is to involke UA password mechanism. It's for passwords.<br> <dael> smfr: And also not effect placeholder text, just password content.<br> <dael> Rossen: Which we all support.<br> <TabAtkins> s/visible access/physical access/<br> <dael> tantek: WE need to spec it's only password inputs<br> <dael> all: yes<br> <tantek> s/it's only/it only applies to<br> <dael> fantasai: Why aren't people impl by siwtching type to text and back?<br> <dael> tantek: Have you tried?<br> <dael> smfr: Password fields have special behavior, switching may have side effects.<br> <dael> myles: Not inherited?<br> <dael> TabAtkins: If it's inherited it won't do anything.<br> <dael> myles: Spec?<br> <dael> TabAtkins: UI<br> <dael> fantasai: I would say initial value is what browsers do by default. Why would UI style sheet set it?<br> <dael> TabAtkins: That's true. WE can make it inherit.<br> <dael> florian: I don't think it should be.<br> <dael> TabAtkins: What's cleaper? Not. Make it not inherited.<br> <dael> myles: New property with auto and 'do not obscure'<br> <dael> tantek: name is text-security<br> <dael> myles: text-security auto|??<br> <dael> florian: none<br> <dael> tantek: make it obvious.<br> <dael> fantasai: visible and hidden?<br> <dael> myles: always visible.<br> <dael> tantek: You might want to obscure the number of charater to plinss point. You can have different varients in the future.<br> <dael> florian: WE need to name adiquetly.<br> <dael> plinss: Auto is a good set up. None is fine for show as if there's no secity.<br> <dael> myles: We're satisfied.<br> <dael> tantek: What's the webkit value?<br> <dael> myles: I'll look.<br> <dael> fremy: If it's only password I'd like it called password-security.<br> <dael> fantasai: Makes sense.<br> <dael> tantek: Intent to broaden later?<br> <fantasai> password-visibility: visible | hidden<br> <dael> Rossen: It's such a specific feature tied in to so much internal logic so we want to have the ability to circumvent all complexity and let authors toggle. I think keeping it specific makes sense.<br> <dael> myles: Webkit we impl accepts disc, circle, square, none.<br> <dael> TabAtkins: That's the 3 bullet styles.<br> <dael> tantek: Why have the 3 styles?<br> <dael> myles: I don't think we should read into the design of this.<br> <dael> tantek: So auto?<br> <TabAtkins> password-security: auto | none<br> <dael> myles: password-security: auto|none<br> <dael> fantasai: What does none do? Other effects then what it looks like?<br> <astearns> +1<br> <dael> tantek: It sounds semantic, not visual. It's an argument for text-prefix.<br> <dael> fremy: [missed]<br> <leaverou> Would this work on other elements too?<br> <dael> tantek: You don't want to enable copy/paste<br> <dael> TabAtkins: Why not?<br> <fremy> s/[missed]/we want to enable copy and paste<br> <TabAtkins> leaverou, no, this is just for turning off password obscuration<br> <dael> plinss: If you can see it you can copy. What's the harm in control-c<br> <tantek> that seems like a bad idea from a security perspective<br> <dael> Rossen: password-securty:auto|none<br> <leaverou> TabAtkins: So it would do nothing when applied on <input />? That seems a bit confusing.<br> <dael> plinss: Maybe input-security?<br> <dael> plinss: Passwords, PINs and CVV are commenly secured. SSN<br> <dael> leaverou: bank account<br> <dael> myles: treating those as a password is okay<br> <dael> leaverou: then browser offers to save.<br> <dael> tantek: You don't want password type for CVV.<br> <dael> dbaron: I get asked that a lot.<br> <dael> myles: I think that's a feature.<br> <dael> leaverou: But then it overrites your password for the site.<br> <dael> myles: Use a better manager.<br> <dael> fantasai: Do you want SSN in auto fill or password maanger.<br> <dael> tantek: And now it's something password like again<br> <fantasai> s/maanger./manager?<br> <dael> plinss: There's policies about not retaining CVV for example. Let's not get into health and medical laws. Something slightly broader then passwrod is reasonable.<br> <dael> fantasai: secure-text<br> <Rossen> security: none<br> <fantasai> Florian: Disables https :)<br> <dael> myles: We have one proposal and a wish<br> <dael> plinss: input-type-security<br> <leaverou> text-redacted?<br> <dael> Rossen: Say it's only for input type=password only. If we need to extend it we may.<br> <astearns> s/-type-/-<br> <dael> Rossen: input-security: auto|none<br> <dael> Rossen: Objections?<br> <dael> rune_: none password fields?<br> <dael> Rossen: only input-type password.<br> <cbiesinger> s/rune_/cbiesinger/<br> <dael> Rossen: Let's re-cap. WE are designing a feature which will allow people to reveal or hide characters in an input type password element for now. There have been suggestions that type=password might not be the only type people want to hide information on. CVV and credit card numbers are common input form elements that want to obscure or not. Currently all browsers obscure input type=password and we want this to work. That's why we started with password-security<br> <tantek> I've also seen bank web UIs obscure *part* of "normal" text inputs, e.g. only showing first 3 letters of username (obscuring the rest), only showing last 4 digits of a credit card number (obscuring the first part)<br> <tantek> I prefer input-security or text-security over password-security<br> <dael> Rossen: Because other applications we wanted a door and say input-security: auto|none if we want to allow this in the future on type=text. That's the reasoning behind the naming. I agree with you for now, and we're going to spec it's password type only for now and if we change out mind there's a way out. If we don't the name isn't too terrible. It does have a bit more meaning.<br> <tantek> to allow expansion to other non-pw inputs<br> <tantek> s/expansion/sensible expansion<br> <dael> myles: Auto is just whatever is normal.<br> <dael> leaverou: security in the name seems weird for newbies, yOu're opening a security hole in the website.<br> <dael> Rossen: That's what you're doing.<br> <dael> myles: Cool.<br> <dael> Rossen: Objections to input-security: auto|none in UI 4 and applies to input type=password only<br> <dael> RESOLVED: input-security: auto|none in UI 4 and applies to input type=password only<br> <TabAtkins> (Well, it will apply to "password inputs", defined by the host language; HTML only defines <input type=password> to be that.<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/2495#issuecomment-380397331 using your GitHub account
Received on Wednesday, 11 April 2018 10:00:14 UTC