See also: IRC log
DKA: Had a meeting this morning
with Adam and Francois.
... We made some good progress
francois: Agree with Dan. I need
to edit the minutes and get back to the group with concrete
suggestions
... We recommend a couple of changes in terms of BPs.
... We also talked a bit about BP flags, wonder if we could
mention the idea?
... about WSC WG feedback, wonder if people in the group had a
chance to review the comment
... we talked about that this morning.
-> http://lists.w3.org/Archives/Public/public-bpwg-comments/2009JanMar/0005.html WSC WG feedback
francois: We do have some concrete proposals for the group, so again, we need to get back to BPWG at large with our thoughts
DKA: the main point of WSC WG is
that there is no real overhead associated with HTTPS once you
go through the initial handshake
... OK, we'll get back to the group with our
recommendations.
jo: Before we move on, how about best practice for login form which I think was discussed on the mailing-list?
<jo> summary of discussion on Login Forms
DKA: could you paste a proposed resolution to see where people stand on that?
jo: In summary, I think it goes down to the 3 main things I mention in the email, and if you want, we could take that as proposed text for the document.
achuter: For people who use
alternative modes, such as screen readers, this does not sound
right to expose the text
... The text would be read aloud.
... That means you can't have people typing in passwords in
public areas.
DKA: how does that connect with Jo's proposal?
achuter: part c) in the email
<jo> PROPSOED RESOLUTION: Amend the text on Login forms to say "Take the following
<jo> into consideration:
<jo> a) If the application has a desktop aspect, users may find it confusing
<jo> to have different passwords for different aspects of the same service.
<jo> [But then again, most people don't find it confusing that they have to
<jo> use different keys for different cars.]
<jo> b) Balance the convenience of having the system remember passwords with the possible
<jo> security consequences of doing so. Take into account the presence or
<jo> absence of password managers in the devices.
<jo> c) Adjust the properties of login screens according to device
<jo> properties. Default to hiding the password for devices with complex
<jo> input capabilities, and showing for devices with simple capabilities.
<jo> Provide the user with a choice to change the default selection.
<jo> Remember to take into account the case of users with assistive
<jo> technologies, which may read passwords aloun if in plain text
DKA: that seems rather counter-intuitive and non-w3c-ish.
jo: Right. Isn't that covered with the advice to provide a link to a version that hides the password?
achuter: right, but I think the advise should be "hidden by default" with a possible link to a version where the password is shown.
dka: what did we say about login forms this morning?
francois: We did say that we didn't feel like recommending best practices on the topic.
<jeffs> why not?
francois: There's nothing
specific to mobiles for login pages (save the password
hidden/show stuff)
... and it does not feel exactly like a good idea to show the
password by default.
<jeffs> agree w jo there are issues specific to mobile here
jo: There is something
specifically mobile: the possibility to have different
passwords for mobile and desktop experiences.
... I think it's appropriate to say something.
<EdC> My view in short: if phone factor=>numeric pin and hide password. If keyboard capable, normal passwords. If readers=>hide password/pin. In any case, try to keep same pin/password for all devices.
jo: The first thing is that
having different passwords for different experiences is
probably confusing to users.
... It may be wrong though, as different keys open different
cars, meaning users are used to having different keys to go to
the same direction.
dka: well, here it's about being
online.
... If we say we're talking about the Web, then you may have
the expectation that logins should be the same regardless of
the modality you're using to access the Web.
<tomhume> In my experience...
<tomhume> PINs are easy to type, but this doesn't make them good as choice of passwords. Users tend to pick 1234, 1111, 0000, ATM PIN or DOB
<tomhume> This makes them quite easy to guess and not actually that secure
<jo> PROPOSED RESOLUTION: Amend the text on Login forms to say "Take the following into consideration:
<jo> a) If the application has a desktop aspect, users may find it confusing to have different passwords for different aspects of the same service.
<tomhume> I'm also unconvinced that hiding passwords is that necessary in a mobiel context, when you can hide the whole device
<EdC> My experience: my accounts in Switzerland use numeric usernames and passwords and nonces. Formats imposed by banks...
<DKA> +1 to a
<tomhume> +1 to a
<EdC> -1
<SeanP> 1
+1 to a
<achuter> +1
EdC: Two issues, rather formal:
what is a desktop aspect? Are you referring to the form
factor?
... Whatever the form factor is, different passwords for
different aspects of the same service is still confusing.
jo: Right. Fair enough.
<jo> PROPOSED RESOLUTION: Amend the text on Login forms to say "Take the following into consideration: a) If the application has more than one distinct representation, e.g. desktop and mobile, users may find it confusing to have differnet passwords for different representations.
<SeanP> +1
<DKA> +1
<tomhume> +1
<EdC> +1
<jo> +1
EdC: it addresses my point. I think it needs to be completed with "if you have a keypad, then", or "if you have a keyboard"
jo: Let's go back to that as a d.
RESOLUTION: Amend the text on Login forms to say "Take the following into consideration: a) If the application has more than one distinct representation, e.g. desktop and mobile, users may find it confusing to have different passwords for different representations.
<jo> PROPOSED RESOLUTION: Add to the text above: b) Balance the convenience of automatically remembering passwords with the possible security consequences of doing so. Take into account the presence or absence of password managers in the devices.
<EdC> As such this is not objectionable, but what is exactly the advice -- or what are the concrete pro/contra factors?
<tomhume> Is the aim of this advice to be normative?
francois: What does automatically remembering passwords mean?
<Zakim> francois, you wanted to wonder about automatically remembering passwords
<jo> how about "storing passwords between sessions"
francois: We're talking about using hashed identity tokens and that kind of things, right?
<jo> PROPOSED RESOLUTION: Add to the text above: b) Balance the convenience of storing passwords between sessions with the possible security consequences of doing so. Take into account the presence or absence of password managers in the devices.
<EdC> An explicit mention of what are the risks to balance would be appropriate.
<EdC> Basically: give example of the main issue: if the device gets stolen, and the password manager is not protected by encryption...
<jo> PROPOSED RESOLUTION: Add to the text above: b) Balance the convenience of storing passwords between sessions with the possible security consequences of doing so. Take into account the presence or absence of password managers in the devices. For example, if the device gets stolen, and the password manager is not protected by some access control mechanism, the user may be exposed.
<EdC> +1
<tomhume> +1
<achuter> +1
<SeanP> +1
<jo> +1
<DKA> +1
RESOLUTION: Add to the text above: b) Balance the convenience of storing passwords between sessions with the possible security consequences of doing so. Take into account the presence or absence of password managers in the devices. For example, if the device gets stolen, and the password manager is not protected by some access control mechanism, the user may be exposed.
<jo> PROPOSED RESOLUTION: Add to the text above: c) Adjust the properties of login screens according to device properties. Default to hiding the password. Provide the user with a choice to change the default selection, as it is hard to type hidden text on some devices and the user may feel that sufficient security is provided by the context of the device and its context of use.
<EdC> some devices = most devices actually...
DKA: This sounds nice, but is it
a best practice?
... sounds complex, may not want to provide this if you want a
simple UA
<Zakim> tomhume, you wanted to point out issues with PINs and to point out that lots of well-designed services reduce numbers of options
Jo: We had a debate on the list--one the one hand it is good practice; on the other hand it is bad practice.
<EdC> Question: why default to the contrary of what is the agreement in the mobile Web (as per references sent)?
DKA: If there isn't agreement, then there is nothing we can put in the document, so that is an argument for staying silent.
<tomhume> That's pretty well it actually... if a best practice is to have lots of user choice, then you could conceive of very well designed services which don't do this
<tomhume> ...i.e. "best practice" isn't.
Jo: The default is set the way it is because you may not know which assistive tech is use, so you may put the user in an awkward position.
<jo> PROPSOED RESOLUTION: Remain silent on the subject of hiding passwords
<DKA> +1
<tomhume> +1
<jo> -1
Alan: Seems intuitive that you would warn people to use a password field for a password.
<jo> PROPOSED RESOLUTION: Add to text on Passwords: c) Some services do not use the Password attribute on input fields that are passwords because on some devices it is hard to type hidden passwords (using multi-tap, for example). However this practice exposes users of assitive technology to the risk of their password being read aloud in public.
jo: Right. How about this?
DKA: that's a nice little note, but where's the recommendation?
<EdC> replace "some" by "many" ? All keypad-form-factor devices -- still a majority of mobile devices.
jo: so what about "If you're going to expose password, provide a secure alternative".
achuter: it could be link that says "expose the password".
<EdC> Are you stating a BP for applications (on the server) or for the user agent (on the device)?
<jo> PROPOSED RESOLUTION: Add to text on Passwords: c) Some services do not use the Password attribute on input fields that are passwords because on many devices it is hard to type hidden passwords (using multi-tap, for example). However this practice exposes users of assitive technology to the risk of their password being read aloud in public, so provide a hidden input mechanism id passwords are...
<jo> ...requested in the clear, and be aware that this hinders operation of password managers.
jo: I have the feeling that it is actually bad practice.
dka: for me, it's bad practice, because it's removing semantics that could be processed by the user agent. If you remove semantics, there's no way to add client-side features around password storage.
<EdC> True re. removing semantics, but usability has been balanced against semantics for years in the mobile world...
jo: Right.
SeanP: I think it should be a browser function.
<EdC> So: are the BP for applications or for user agents?
SeanP: I agree with Dan here.
<jo> PROPOSED RESOLUTION: Add to the text above: c) Adjust the properties of login screens according to device properties. Default to identifying the password field as such, and hence hiding the password while input. Provide the user with a choice to change the default selection, as it is hard to type hidden text on many devices and the user may feel that sufficient security is provided by the...
<jo> ...context of the device and its context of use.
<achuter> https://addons.mozilla.org/es-ES/firefox/addon/462
<jo> PROPOSED RESOLUTION: Add to the text above: c) Adjust the properties of login screens according to device properties in respect of password field handling. Default to identifying the password field as such, and hence hiding the password while input. Provide the user with a choice to change the default selection, as it is hard to type hidden text on many devices and the user may feel that...
<jo> ...sufficient security is provided by the context of the device and its context of use.
dka: I can live with that but would rather remain silent
<achuter> +1
<DKA> +1 (but preferred to remain silent)
<EdC> I'd rather go the other way around re hiding/showing the password. Once again: the proposed BP goes _against_ the established BP in the mobile Web...
jo: this is dragging on a bit, let's have a straw poll
<SeanP> +1
achuter: if you want to remove the password, you can do that with a script and a link next to the field for instance.
<EdC> OK. I gave references. Give yours?
<SeanP> There seems to be a difference between the recommendations for this issue that EdC provided and actual practice on the mobile web.
<EdC> 0
<jo> +1
<DKA> For the record, Ed, after reviewing your references on this topic, I remain unconvinced that this is good existing practice.
<EdC> d) PROPOSED RESOLUTION. Take into account the preferred or main form factor when entering identifications in login forms. For instance, PINs are easier to type in keypad-only devices.
RESOLUTION: Add to
the text above: c) Adjust the properties of login screens
according to device properties in respect of password field
handling. Default to identifying the password field as such,
and hence hiding the password while input. Provide the user
with a choice to change the default selection, as it is hard to
type hidden text on many devices and the user may feel that
sufficient...
... security is provided by the context of the device and its
context of use.
<EdC> +q
[discussion between Dan and EdC on the fact that devices have moved on ...]
dka: what do other people think about Eduardo's proposal?
<jo> PROPOSED RESOLUTION: Make a note under the section on passwords that devices have developed since the time of recommending numeric only ids and passwords for mobile
<EdC> Oh, by the way: is anybody considering other forms of input? voice, fingerprint, whatever...
[I think gestures are used as well to log in to a certain mobile device]
<jo> PROPOSED RESOLUTION: Make a note under the section on passwords that devices have developed since the time of recommending numeric only ids and passwords for mobile and that consequently it is not adviable to recommend this any longer in view of more advanced devices and the needs of some applications to preserve consistency between mobile and non-mobile representations
<EdC> +q
<jo> +1 to EdC
<Kai> +1
EdC: I just wanted to say you can keep silent, then it means that whatever other recommendations that are out there prevail, because they are not.
Jo: where are we going on this,
dan?
... I believe that you have made the point that devices have
moved on.
... [scribe is having audio problems]
<jo> PROPOSED RESOLUTION: Make a note under the section on passwords that devices have developed since the time of recommending numeric only ids and passwords for mobile and that consequently it is not adviable to recommend this any longer in view of more advanced devices and the needs of some applications to preserve consistency between mobile and non-mobile representations
Jo: I think the proposed resolution explains the compromise
dka: francois, W3C view?
francois: I wish I knew...
<jo> +1
<DKA> +1
<SeanP> +1
francois: I think it can be turned into a forward-looking BP actually, considering new forms of entering information.
<Kai> +1
<jsmanrique> +1
<EdC> 0
RESOLUTION: Make a note under the section on passwords that devices have developed since the time of recommending numeric only ids and passwords for mobile and that consequently it is not adviable to recommend this any longer in view of more advanced devices and the needs of some applications to preserve consistency between mobile and non-mobile representations
close ACTION-908
<trackbot> ACTION-908 Note specific mobile good practice for login forms regarding use of numerics and mixed case and so on closed
<DKA> http://www.w3.org/2002/09/wbs/37584/BPWG-F2F-March-2009/ <-- registration for london f2f
jo: only ~10 responses so far please indicate your attendance _or otherwise_
dka: yeah, more people need to
respond to the poll. I agree with Jo. Always.
... I agree with your sentiment, Kai (about getting the red-eye
to be there)
... we will get more specific on the agenda
... note from Adam - he has secured non-NDA facilities so we
will be hosted by Google
jo: alan sent a note
alan: have updated - not with all comments and input - still issues pending that need discussion. Not sure that they need discussion, not sure in this group or not
<francois> Alan's update
alan: not sure what is happening
over at WCAG
... I will make a summary of issues tomorrow ...
<jo> ACTION: Chuter to summarise outstanding Accessibility issues and circ to list under this action [recorded in http://www.w3.org/2009/02/10-bpwg-minutes.html#action01]
<trackbot> Created ACTION-909 - Summarise outstanding Accessibility issues and circ to list under this action [on Alan Chuter - due 2009-02-17].
<Kai> Questions about the Addendum?
<francois> scribe: francois
jo: Charles had an action to go
back to my comments on OPES
... He did not. I feel that we need to press on in the absence
of that.
<jo> jo's comments ref link rewriting and OPES
jo: I still haven't proposed
text, but will do that.
... I will do that in the next couple of days.
... That's current status on CT.
... Let's move on with the addendum
-> http://lists.w3.org/Archives/Public/public-bpwg/2009Feb/0066.html Kai's email
kai: just remind people that I produced a new draft of the addendum
dka: the action is on everybody to review that and to come back with comments.
kai: the whole thing has been rewritten.
dka: does this make sense to have this on the agenda next week and give you time to tour us through the document?
kai: I can certainly do that, but
note I basically took into account comments from dom.
... I think it's important that people take a look at it by
themselves.
dka: ok
[call adjourned]