- From: Manrique Lopez <manrique.lopez@fundacionctic.org>
- Date: Wed, 04 Feb 2009 10:06:57 +0100
- To: casays@yahoo.com
- Cc: public-bpwg@w3.org
Hello, For technical implementations, what about "inputmode" attribute for XHTML Basic 1.1? Isn't it the same for XHTML MP 1.2? <input type="text" name="pin" value="" inputmode="latin digits" /> References: http://www.w3.org/TR/xhtml-basic/#s_inputmode http://www.w3.org/TR/xhtml-basic/#s_mode-values Thanks and best regards, El mar, 03-02-2009 a las 12:16 -0800, Eduardo Casais escribió: > The action is stated as "Note specific mobile good practice for login forms > regarding use of numerics and mixed case and so on". > > > 1. GOOD PRACTICES. > > Mobile applications strive to fulfil two requirements: > > - minimize input keystrokes; > - minimize possibilities for mistaken input. > > >From these principles, the following good practices have been derived regarding > password input in forms: > > a) Do not mix alphabetic symbols and numbers, nor upper- and lowercase. > b) Use numeric pin-codes rather than passwords. > c) Do not mask input that is being entered by the end user. > > These practices obviously go counter to password guidelines in the desktop Web, > where mixing all sorts of alphanumeric symbols, both upper and lowercase, is > recommended. > > > 2. TECHNICAL IMPLEMENTATION. > > Technically, these practices are implemented via specific attributes in the > input tag in markup, and in rejecting input fields of type password in favour > of normal text fields. > > In XHTML mobile profile (format="NNNN" indicates a 4-numbers field): > <input type="text" name="pin" value="" style="-wap-input-format:NNNN" /> > > In i-mode HTML (istyle="4" indicates a numeric field): > <input type=”password” name=”pin” maxlength=”4” size=”4” istyle=”4”> > > In WML (format="NNNN5N" indicates a numeric field with 4 to 9 symbols): > <input type="text" name="pincode" value="" format="NNNN5N" emptyok="false"/> > > > 3. REFERENCES. > > The following extracts are from several documents that deal explicitly with > password input in mobile applications, and dating from 2001 to 2008. > > Addressed good practices (a, b, c) are indicated for each reference. > > ------------ > > (c) > > Luca Passani: Global Authoring Practices for the Mobile Web v.1.0.4, 2008-11. > > > Manage User Input (use input masks/minimize clicks) > > [NO_PASSWORD_MASK] Do not mask user input when entering a password. > > Rationale: Entering data and text is a very time consuming and error-prone > task for users of mobile devices. Everything possible should be done to > minimize the amount of clicks required to users. > > [...] Reading what is on the screen of a mobile device is often hard enough > for the user of the device. Peeking over the shoulder of the user is less > likely to disclose a password than observing the user's keypress sequence. > For this reason, hiding user input to users themselves by replacing each > character with a '*' (star) symbol (or similar) will do very little to protect > privacy, while making it generally harder to use the service. For this reason, > users should be made enter passwords in clear text. > > ------------ > > (a) (c) > > Nokia: Guidelines For Creating Web Content For Mobile And PC Browsing, v.1.0, > 2004-09-27. > > > 2.12.1 Input fields > > [...] Avoid requiring letters and numbers in the same input field (especially > in a password field). When the password contains both numbers and letters, > users in tests have entered the wrong password without noticing it. > > Avoid requiring case sensitivity (especially in password fields). In password > fields, when input characters turn to asterisks, novice users may have > difficulties remembering what they have input. > > ------------ > > (a) (c) > > Sprint: Usability Requirements for XHTML Basic Applications, 2003-01. > > > 4 PASSWORD ENTRY: A SPECIAL WARNING > > The following recommendations are not requirements because we cannot judge the > security needs of your application. We set this recommendation aside to stress > its importance to usability. We urge you to consider it carefully. > > ! Do not mask out text input with “password” formatting. The usability problems > associated with triple-tapping masked passwords outweigh the costs of hiding > those passwords. Here’s why… > > On the surface, password format appears usable because the user can see each > character as it is entered. Actually, while typing letters, users look at the > keypad — not the display - as they determine the triple-tap sequence for each > character. Once they look up at the display, the cursor will have advanced, > obscuring the just-entered character with an asterisk or similar character. > Even the most experienced users will have occasional trouble with password > format. We do. Consider that each mobile device is a personal device, and its > user has considerable control over it. Unlike kiosk or fixed computer > situations, where somebody could look over a user’s shoulder, in mobile > situations the user can move the screen and keypad wherever desired. When > combined with the difficulty in text entry on most devices and the likelihood > of user distraction partway through text input, masking user input has an > unacceptably high user cost for very low user or security benefit. > > As a developer, do not be swayed by your personal ability to flawlessly > triple-tap a 14-character, mixed-case, alphanumeric password. You are more > capable than your users! Most of them will fail at this task and not return > to your application unless they must. > > In summary: masking passwords (during input) will reduce the amount of > password theft primarily because there will be fewer passwords to steal, > because there will be fewer users. > > ! Avoid unnecessarily complex password formats. The format of your password has > a strong and direct effect on the difficulty of entry. In general, the > difficulty of entering a masked string increases with the complexity of the > string. As a rule: > -- Alphanumeric strings are more difficult to enter than alphabetic, > -- Alphabetic strings are more difficult to enter than numeric, > -- Case-sensitive strings are more difficult to enter than case-insensitive, > -- Strings with symbols are more difficult to enter than strings without > symbols, etc. > > Because complex passwords are more secure passwords, you must find the > appropriate balance for your particular application. All-numeric strings > are the easiest to enter, but because it is not possible to force numeric > format with some PCS Vision phones, we recommend that you not mask out numeric > passwords. > > ! If you do not mask text input with “password” formatting, assign the password > input field to its own page. A password alone is useless. A password combined > with a user ID or other credentials is a different matter. If you choose to > increase the usability of your application by not masking passwords, you can > avoid any additional risks by not displaying a user’s full set of credentials > on one page. > > ------------ > > (b) > > How to create an i-mode site, 2002-11-18. > > > INPUT Tag > > [...] Text input fields can have an istyle attribute that indicates the input > mode for the field. > [...] For password fields: > <input type=”password” name=”name” accesskey=”accesskey” maxlength=”maxlength” > size=”size” value=”value”> > The default istyle attribute value for password inputs is numeric (4) and > cannot be changed, except for the NEC N21i and TS21i. For these handsets > you should force the style to numeric. > [...] Tip: Limit password inputs to numeric only and indicate that a PIN code > is required, rather than a password. > > ------------ > > (b) > > ATT: Guide to mMode-Compliant HTML Coding, v.1.0, 2002-05-14. > > > 2.2.2.6. Forms (User Entry) > 2.2.2.6.1. Text Entry > > [...] Note: istyle is not supported for input element with type equal to > password, which is always set to numeric input. > > ------------ > > (b) (c) > > Openwave: GSM Application Style Guide, 2001-02. > > > Section 9: Data Entry Queries > > [...] Make password fields numeric only, when possible. > It is easier to enter numbers than letters or symbols. > > Do not mask alphanumeric passwords. > Do not mask the entry. It is easier for the user to hide the display > from others than to type with masked characters. > > ------------ > > > E.Casais > > > > > -- José Manrique López de la Fuente <manrique.lopez@fundacionctic.org> Área de Tecnología Fundación CTIC Web: http://www.fundacionctic.org Tel: (+34) 984 29 12 12 Parque Científico Tecnológico de Gijón Edificio Centros Tecnológicos Cabueñes s/n 33203 GIJÓN - ASTURIAS - ESPAÑA #Antes de imprimir este e-mail piense bien si es necesario hacerlo: El medioambiente es cosa de todos.
Received on Wednesday, 4 February 2009 09:07:39 UTC