- From: Francois Daoust <fd@w3.org>
- Date: Tue, 10 Feb 2009 17:18:54 +0100
- To: MWI BPWG Public <public-bpwg@w3.org>
Hi,
The minutes of today's meeting are available at:
http://www.w3.org/2009/02/10-bpwg-minutes.html
... and copied as text below.
- Progress made during the editorial meeting on MWABP. Adam's working on
an updated draft. Francois will send notes about the meeting along with
ideas we explored.
- Discussion on best practice around login forms. 4 resolutions taken:
* 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.
* 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.
* 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.
* 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
- Everyone to review the new draft of the BP Addendum document, see
Kai's announcement:
http://lists.w3.org/Archives/Public/public-bpwg/2009Feb/0066.html
- BPWG participants to register for the upcoming F2F:
http://www.w3.org/2002/09/wbs/37584/BPWG-F2F-March-2009/
Francois.
-----
[1]W3C
[1] http://www.w3.org/
Mobile Web Best Practices Working Group Teleconference
10 Feb 2009
[2]Agenda
[2] http://lists.w3.org/Archives/Public/public-bpwg/2009Feb/0065.html
See also: [3]IRC log
[3] http://www.w3.org/2009/02/10-bpwg-irc
Attendees
Present
jeffs, tomhume, francois, miguel, abel, jo, SeanP,
Kai_Dietrich, achuter, manrique, DKA
Regrets
dom, yeliz, adam
Chair
DKA
Scribe
francois, SeanP, Jo
Contents
* [4]Topics
1. [5]Mobile Web Application Best Practices Editorial Meeting
2. [6]BP on login forms
3. [7]Registration for London F2F
4. [8]Accessibility
5. [9]CT Discussion
6. [10]BP Addendum
* [11]Summary of Action Items
_________________________________________________________
Mobile Web Application Best Practices Editorial Meeting
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.
->
[12]http://lists.w3.org/Archives/Public/public-bpwg-comments/2009Jan
Mar/0005.html WSC WG feedback
[12]
http://lists.w3.org/Archives/Public/public-bpwg-comments/2009JanMar/0005.html
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?
BP on login forms
<jo> [13]summary of discussion on Login Forms
[13] http://lists.w3.org/Archives/Public/public-bpwg/2009Feb/0063.html
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> [14]https://addons.mozilla.org/es-ES/firefox/addon/462
[14] 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
Registration for London F2F
<DKA> [15]http://www.w3.org/2002/09/wbs/37584/BPWG-F2F-March-2009/
<-- registration for london f2f
[15] http://www.w3.org/2002/09/wbs/37584/BPWG-F2F-March-2009/
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
Accessibility
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> [16]Alan's update
[16] http://lists.w3.org/Archives/Public/public-bpwg/2009Feb/0069.html
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
[17]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].
CT Discussion
<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> [18]jo's comments ref link rewriting and OPES
[18] http://lists.w3.org/Archives/Public/public-bpwg/2009Feb/0021.html
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
BP Addendum
->
[19]http://lists.w3.org/Archives/Public/public-bpwg/2009Feb/0066.htm
l Kai's email
[19] http://lists.w3.org/Archives/Public/public-bpwg/2009Feb/0066.html
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]
Summary of Action Items
[NEW] ACTION: Chuter to summarise outstanding Accessibility issues
and circ to list under this action [recorded in
[20]http://www.w3.org/2009/02/10-bpwg-minutes.html#action01]
[End of minutes]
Received on Tuesday, 10 February 2009 16:19:31 UTC