W3C

Web Security Context Working Group Teleconference
22 Aug 2007

Agenda

See also: 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


 

 

<trackbot-ng> Date: 22 August 2007

<tlr> ScribeNick: hal


Approve minutes from last meeting

<tlr> 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> 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 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 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

http://www.w3.org/2006/WSC/wiki/RecommendationUsabilityEvaluationFirstCut#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> http://lists.w3.org/Archives/Public/public-wsc-wg/2007Aug/0127.html

tlr: need to look at difference between PII and current

<tlr> http://www.w3.org/2006/WSC/wiki/RecommendationUsabilityEvaluationFirstCut

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

<tyler> 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> http://www.w3.org/2002/02/mid/08CA2245AFCF444DB3AC415E47CC40AFDD687C@G3W0072.americas.hpqcorp.net;list=public-wsc-wg

<Mez> 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> http://www.w3.org/2006/WSC/drafts/rec/Overview.html#piieditor

<tlr> http://www.w3.org/2006/WSC/drafts/rec/Overview.html#piieditor-usecases-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> http://www.w3.org/2006/WSC/drafts/rec/Overview.html#piieditor-usecases-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> 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> 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 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 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 http://www.w3.org/2007/08/22-wsc-minutes.html#action01]
 
[End of minutes]

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