W3C home > Mailing lists > Public > public-bpwg@w3.org > February 2009

[minutes] Tuesday 10 February 2009

From: Francois Daoust <fd@w3.org>
Date: Tue, 10 Feb 2009 17:18:54 +0100
Message-ID: <4991A8EE.1020302@w3.org>
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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:43:00 UTC