Meeting record: WSC WG weekly 2007-08-22

Minutes from our meeting on 2007-08-22 were approved and are
available online here:

   http://www.w3.org/2007/08/22-wsc-minutes.html

A text version is included below the .signature.

-- 
Thomas Roessler, W3C  <tlr@w3.org>




   [1]W3C

               Web Security Context Working Group Teleconference
                                  22 Aug 2007

   [2]Agenda

   See also: [3]IRC log

Attendees

   Present
          MaryEllen_Zurko, Bill_Doyle, Thomas, johnath, ifette,
          Hal_Lockhart, Maritza_Johnson, luis, +1.703.671.aaaa,
          Chuck_Wade, sduffy, serge, asaldhana, DanSchutzer, Tyler,
          rachna, Tim_Hahn, jvkrey, +1.202.386.aabb

   Regrets
          Audian

   Chair
          MEZ

   Scribe
          hal, tlr

Contents

     * [4]Topics
         1. [5]Approve minutes from last meeting
         2. [6]Newly completed action items
         3. [7]Action items closed due to inactivity
         4. [8]Agenda bashing
         5. [9]Is page info summary a non-Goal?
         6. [10]Usability evaluation of PII Editor Bar
         7. [11]Rec Track conformance language - Error Handling and
            Signalling
     * [12]Summary of Action Items
     __________________________________________________________________

   Â

   Â

   <trackbot-ng> Date: 22 August 2007

   <tlr> ScribeNick: hal

Approve minutes from last meeting

   <tlr> [13]http://www.w3.org/2007/08/15-wsc-minutes.html

   resolution: approved unanamously

Newly completed action items

Action items closed due to inactivity

Agenda bashing

   tlr: suggest switching items 7 & 8
   ... should cover 9 for sure

   mez: will move 9 up

Is page info summary a non-Goal?

   <ifette> no

   <Mez>
   [14]http://lists.w3.org/Archives/Public/public-wsc-wg/2007Aug/0123.html

   tyler: need to apply usability principles
   ... in order to meet criteria should drop page info summary
   ... studies show little benefit
   ... could still put out doc saying what should be done
   ... but not part of rec
   ... not dilute efforts
   ... want readers to immediatly see benefit form following
   recommendation
   ... invites simple criticisms

   tlr: tyler have you looked at most recent draft?

   tyler: no

   tlr: I don't think we are claiming this section will help prevent
   phising
   ... moving it to a note will consume as much time
   ... support keeping it in now
   ... need to consider restructuring infomaiton
   ... need to separate secondary from primary info

   serge: what sort of security scenarios will this help with?
   ... users ignore it and it can be spoofed
   ... why leave it in?

   chuck: attack scenarios change radically
   ... industry is always playing catchup
   ... allow users to prevent future attacks
   ... few people detecting attacks alert others
   ... providing better tools to the few will help the rest

   <tlr> totally +1 to what Maritza says.

   <Zakim> ifette, you wanted to talk about expert users having separate
   tools and not needing something in the browser

   maritzaj: offering improvements will be valuable and not too much work
   - current is real bad

   <Zakim> Mez, you wanted to suggest that if we continue to carry forward
   Info bar we not do any usablity testing on it (as inspired by a comment
   from tyler)

   <Zakim> rachna, you wanted to suggest that assumptions should be
   clearly spelled out in proposals

   <tlr> actually, the "Additional Security Context Information", as it is
   called in the latest draft.

   <serge> We don't need to do any usability testing, because it's already
   been done and shown that this is ineffective.

   mez: suggest including it but not doing usability testing

   rachna: would be useful to expert users

   tyler: use by experts is why I propose moving not deleting - make it a
   note

   <Zakim> johnath, you wanted to try to pull good reasons for dropping it
   out from bad

   rachna: couldn't say so in rec instead of moving it ot note

   <Mez> btw, Rachna, PII editor bar use eval is up after this discussion,
   not last, as the original agenda suggested

   <Mez> so stick around :-)

   johnath: need to separate good reasons from bad
   ... effort may not be most important factor

   <tlr> If arguing that a section puts the document into disrepute, it
   would be refreshing if the argument was at least against the latest
   draft.

   johnath: if we feel we should recommend
   ... current page info is poor, does not prove better would not help

   <tlr> oh yes, indeed. Tech-supporting my mother on a browser that I
   don't run is *so* much fun.

   bill-d: hard for hellp desks to deal with non-std page info

   <Mez> Q: "The page info summary recommendation proposal
   [15]http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#pageinfosummary
   should become a Note, similar to the Threat Trees work, and not be
   included in our FPWD recommendations" (yes/can live with/no)

   <tlr> no

   mez: will do straw poll now

   <Mez> Tim: no

   <Mez> Michael M: no

   <tlr> bill-d: no

   <bill-d> no

   <johnath> no

   <sduffy> no

   <ifette> No (Should *not* become a note, stay in rec)

   no

   <Chuck> no

   <tyler> yes

   <serge> yes

   <Mez> abstain

   <asaldhan> no

   <maritzaj> no

   <luis> neutral

   <luis> no

   <Mez> Dan: yes

   <tlr> (confusion what is meant)

   mez: vote in favor of leaving it

   <tlr> ACTION: thomas to obtain disclaimer-style text for Additional
   Security Context Information [recorded in
   [16]http://www.w3.org/2007/08/22-wsc-minutes.html#action01]

   <trackbot-ng> Created ACTION-282 - Obtain disclaimer-style text for
   Additional Security Context Information [on Thomas Roessler - due
   2007-08-29].

   <tlr> With the observation that this might be reassigned to somebody
   else.

Usability evaluation of PII Editor Bar

   [17]http://www.w3.org/2006/WSC/wiki/RecommendationUsabilityEvaluationFi
   rstCut#head-19caf4993d486f3f77f40171acc200d22fbf016e

   tlr: 2 or 3 observations
   ... in usability section some parts were so unclear they could not be
   tested
   ... need to know if discussions have clarified this

   <tlr>
   [18]http://lists.w3.org/Archives/Public/public-wsc-wg/2007Aug/0127.html

   tlr: need to look at difference between PII and current

   <tlr>
   [19]http://www.w3.org/2006/WSC/wiki/RecommendationUsabilityEvaluationFi
   rstCut

   <tlr> [20]http://www.w3.org/2006/WSC/drafts/rec/Overview.html#piieditor

   <tyler> [21]http://www.w3.org/2006/WSC/drafts/rec/#piieditor

   tyler: wiki is not up to date

   <Mez> PII EditorBar

   <Mez> Requirements - this proposal assumes that:

   <Mez> Users have the extension installed in their browser.

   <Mez> Users are novice users- they are not security experts and
   received no training.

   <Mez> User Expectations- this proposal assumes that:

   <Mez> Users will complete the bootstrap scenario, and they will select
   petnames for sites they care about.

   <Mez> When a user wants to fill out a web form, the user will enact the
   attention sequence key to move from the web form to the editor bar.

   <Mez> The user will notice when an illegitimate page requests
   information that has previously been submitted to this website.

   <Mez> The user will not submit data to a website that requests data
   which has been previously submitted to that website.

   confusion over what is current text

   <Mez> The user will not be tricked by an illegitimate page that tries
   to convince the user to create a new relationship with the site.

   <Mez> The user will remember that they previously created a
   relationship with this website and be suspicious, OR

   <Mez> The browser will detect the reuse of a petname, because the user
   will rename the same site with the same petname as used previously.

   <Mez> Users will pick unique petnames, and they won't be tricked by PII
   editor bar spoofing that attempts to mimic their customization.

   <Mez> Relevant Literature

   <Mez> What is known

   <Mez> Can users use the activation sequence correctly? One prior study
   (A Usability Study and Critique of Two Password Managers by Sonia
   Chiasson and P.C. van Oorschot) indicates that users have trouble
   remembering to activate an attention sequence, activating it at the
   right time (e.g., when focus is in the text box), or in knowing when it
   has been activated. For example, in the study of Password Multiplier,
   they found that users would not know if they had entered the attent

   <Mez> Are users willing to make site specific nicknames? From
   deployments of the petname toolbar (e.g., at HP), we can get an
   estimate of how many users gave a petname to what sites, and how many
   chose the same petname for a given site.

   <Mez> Unknown

   <Mez> Will users be willing to use the attention sequence for each form
   field? Shifting focus away from each field may require more effort than
   the effort of typing, because it is cumbersome and a new skill (most
   users do not use keyboard shortcuts and use the mouse to move between
   fields).

   <Mez> Will users correctly fulfill the behavioral expectations
   described above and not succumb to spoofing attacks?

   <Mez> Testing

   <Mez> We require a prototype implementation of this proposal to do
   further analysis, because much of the usability and security will
   depend on specific design decisions.

   <tlr>
   [22]http://www.w3.org/2002/02/mid/08CA2245AFCF444DB3AC415E47CC40AFDD687
   C@G3W0072.americas.hpqcorp.net;list=public-wsc-wg

   <Mez>
   [23]http://lists.w3.org/Archives/Public/public-wsc-wg/2007Aug/0029.html

   those to URIs point to the same message

   tyler: will need to provide some user training before usability testing

   rachna: possible to train part way thru or train some users and not
   others

   <serge> the Jackson study, it's in the Bookmarks

   <johnath> mez - the picture in picture

   rachna: sometimes training can hurt

   <Zakim> johnath, you wanted to ask if that would artificially inflate
   the success?

   rachna: study of IE 7 is an example

   joahath: need to at least do some with no training

   <Zakim> ifette, you wanted to ask about realism of expecting training
   for browsers?

   joahath: to get realistic results

   ifette: +1 to Johnath

   <ifette> but nobody reads start screens

   <johnath> rachna: true

   rachna: could have some initial help screens

   <Zakim> johnath, you wanted to reply to tyler

   <ifette> +1 to no training

   tyler: if decide no training, should apply to all tests

   <serge> there's another issue: if we show them how to do it in the lab,
   will they continue to do it at home

   johnath: should be clear on what testing is trying to accomplish

   tlr: critical piece is to be clear about what a particular test is
   about
   ... not immediate decision
   ... suggest getting back to main thread

   maritzaj: is this for everyone all the time or just certain situaitons

   tyler: all the time for everyone

   maritzaj: not unreasonable to assume some training
   ... problem with lock is most people don't know what it indicates

   tyler: this apporach is not passive, interrupts user

   <ifette> what they're talking about right now (what user action is
   required, for all vs for some etc)

   maritzaj: user needs to take initiatave first time

   <Mez> [24]http://www.w3.org/2006/WSC/drafts/rec/Overview.html#piieditor

   <tlr>
   [25]http://www.w3.org/2006/WSC/drafts/rec/Overview.html#piieditor-useca
   ses-bootstrap

   tyler: not so look at doc - user is prompted for Pet name

   <tlr> point of order, can we keep *this* discussion to essential
   clarifications and move to the merits at one of the next calls, to
   stick somewhat to the agenda?

   ifette: very worried about interupting users flow or turn off feature

   tyler: does not interrupt - form filler drives it

   ifette: if I am on site and create new account and password will I be
   interupted?

   tyler: only if you use pass manager or form filler

   ifette: worried about dictating UI

   tyler: thats the purpose of WG

   tlr: rather than getting into merits, just stick to clarifications

   <tlr> The user will notice when an illegitimate page requests
   information that has previously been submitted to this website. The
   user will not submit data to a website that requests data which has
   been previously submitted to that website.

   tlr: clarification needed in usability evaluaton

   <Mez> The user will notice when an illegitimate page requests
   information that has previously been submitted to this website.

   <Mez> The user will not submit data to a website that requests data
   which has been previously submitted to that website.

   rachna: wanted to list spoofing conditions that user might notice and
   see if they do

   <tlr>
   [26]http://www.w3.org/2006/WSC/drafts/rec/Overview.html#piieditor-useca
   ses-imposter

   rachna: if user detects something fishy
   ... not describing scenario

   tyler: propsal is completely intrusive, no user option

   rachna: would like authors to define success

   <tlr> ScribeNick: tlr

   hal: if tyler's thing prevents people from typing in, not gonna spend a
   lot of time ...
   ... but maybe is something else wrong? ...
   ... question is, set up test so it's strawman ...
   ... obvious part that should succeed will succeed ...
   ... that seems to be difficult issue ...

   rachna: good point

   tyler, rachna engage in speed talking contest

   tyler: chuck reported people use form filler for banking passwords

   <ifette> lol

   tyler: take from that that form fillers etc are already used ...

   <Zakim> ifette, you wanted to say it should be voluntary

   ifette: if mandatory users will avoid in some way

   rachna: need to test annoyance in UI testing

   <scribe> ScribeNick: hal

   tyler: will only know until we test
   ... believe users will have to interact, not just pictures

   tyler: would like to sit do and be coached on Mozzilla APIs required

   Mez: could do this at F2F

   <Mez>
   [27]http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#error-handling

   <tlr> Code sprint might be useful in *addition* to a f2f.

Rec Track conformance language - Error Handling and Signalling

   tlr: if security is degraded in minor way don't interupt user

   <rachna> signing off- I have to go to a mtg. Tyler let's continue this
   discussion to get your comments into the usability text.

   tlr: if serious change to security properties - interupt user, provide
   help
   ... should be able to get back to where you left off

   <tyler> Ok, you can call me at the office until Thursday

   tlr: error interactions not popups, but error pages
   ... if user disables, ???

   <tlr> [28]http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#id2739434

   mez: looks like section 3.1 follows this, serge do you agree?

   <tlr> *cough* will fix the anchor ASAP

   serge: don't know

   tlr: lots of warnings that get ignored
   ... try to identify really bad security and force interaction

   tlr: try to distingush between to cases

   serge: need strong rare warnings for serious problems

   <tlr> ACTION: serge to contribute references to support 5.3.1 [recorded
   in [29]http://www.w3.org/2007/08/22-wsc-minutes.html#action02]

   <trackbot-ng> Created ACTION-283 - Contribute references to support
   5.3.1 [on Serge Egelman - due 2007-08-29].

   <Mez> hal, want to scribe your comments?

   hal: 2 comments

   ... propsal depends on ability to distinguish between cases, which will
   be hard to establish emprically

   ... going back to where you were may be very hard, especially synching
   btw web site and browser

   tlr: agree with first, second - only back to prior user agent state not
   web site
   ... start TLS negotiaiton - server shows good cert, but domain name is
   wrong

   tlr: have means to know what correct url is

   tlr: suggest augment error page to contain live link to site

   tlr: option to user to follow link
   ... constructing url must be possible from cert alone

   tlr: must use safe method to access site

   <Zakim> ifette, you wanted to note scary use case

   <Zakim> Mez, you wanted to say make more general, if user has nicname,
   use that (probably same as ian)

   ifette: scary scenario - browser appears to endorse bad guy site

   mez: DNS based identity is scary

   tlr: agree attack would be possible
   ... 2 things to mitigate
   ... user needs ?? from authority
   ... would reference org not user

   <Mez> DN's are scarey too, btw (org field, etc)

   tlr: idea is to interrupt flow and check w/o leaking info to bad guys

   bill-d: discussion on list - use known good DNS server - does that
   solve problem?

   <Mez> We're wrapping after this question; it's time folks

   tlr: no - typical circumstance that they are intercepting at TCP level

   <ifette> someone doing the zakim, rrsagent commands to draft minutes?

Summary of Action Items

   [NEW] ACTION: serge to contribute references to support 5.3.1 [recorded
   in [30]http://www.w3.org/2007/08/22-wsc-minutes.html#action02]
   [NEW] ACTION: thomas to obtain disclaimer-style text for Additional
   Security Context Information [recorded in
   [31]http://www.w3.org/2007/08/22-wsc-minutes.html#action01]
   Â
   [End of minutes]
     __________________________________________________________________


    Minutes formatted by David Booth's [32]scribe.perl version 1.128
    ([33]CVS log)
    $Date: 2007/08/29 19:18:59 $
     __________________________________________________________________

References

   1. http://www.w3.org/
   2. http://lists.w3.org/Archives/Public/public-wsc-wg/2007Aug/0138.html
   3. http://www.w3.org/2007/08/22-wsc-irc
   4. http://www.w3.org/2007/08/22-wsc-minutes.html#agenda
   5. http://www.w3.org/2007/08/22-wsc-minutes.html#item01
   6. http://www.w3.org/2007/08/22-wsc-minutes.html#item02
   7. http://www.w3.org/2007/08/22-wsc-minutes.html#item03
   8. http://www.w3.org/2007/08/22-wsc-minutes.html#item04
   9. http://www.w3.org/2007/08/22-wsc-minutes.html#item05
  10. http://www.w3.org/2007/08/22-wsc-minutes.html#item06
  11. http://www.w3.org/2007/08/22-wsc-minutes.html#item07
  12. http://www.w3.org/2007/08/22-wsc-minutes.html#ActionSummary
  13. http://www.w3.org/2007/08/15-wsc-minutes.html
  14. http://lists.w3.org/Archives/Public/public-wsc-wg/2007Aug/0123.html
  15. http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#pageinfosummary
  16. http://www.w3.org/2007/08/22-wsc-minutes.html#action01
  17. http://www.w3.org/2006/WSC/wiki/RecommendationUsabilityEvaluationFirstCut#head-19caf4993d486f3f77f40171acc200d22fbf016e
  18. http://lists.w3.org/Archives/Public/public-wsc-wg/2007Aug/0127.html
  19. http://www.w3.org/2006/WSC/wiki/RecommendationUsabilityEvaluationFirstCut
  20. http://www.w3.org/2006/WSC/drafts/rec/Overview.html#piieditor
  21. http://www.w3.org/2006/WSC/drafts/rec/#piieditor
  22. http://www.w3.org/2002/02/mid/08CA2245AFCF444DB3AC415E47CC40AFDD687C@G3W0072.americas.hpqcorp.net;list=public-wsc-wg
  23. http://lists.w3.org/Archives/Public/public-wsc-wg/2007Aug/0029.html
  24. http://www.w3.org/2006/WSC/drafts/rec/Overview.html#piieditor
  25. http://www.w3.org/2006/WSC/drafts/rec/Overview.html#piieditor-usecases-bootstrap
  26. http://www.w3.org/2006/WSC/drafts/rec/Overview.html#piieditor-usecases-imposter
  27. http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#error-handling
  28. http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#id2739434
  29. http://www.w3.org/2007/08/22-wsc-minutes.html#action02
  30. http://www.w3.org/2007/08/22-wsc-minutes.html#action02
  31. http://www.w3.org/2007/08/22-wsc-minutes.html#action01
  32. http://dev.w3.org/cvsweb/%7Echeckout%7E/2002/scribe/scribedoc.htm
  33. http://dev.w3.org/cvsweb/2002/scribe/

Received on Saturday, 1 September 2007 12:52:24 UTC