Web Security Context WG Teleconference
25 Jul 2007

 

 

<trackbot> Date: 25 July 2007

<Mez> is Serge the scribe?

<tlr> yes

<tlr> Stephen will join from here.

<tlr> ScribeNick: serge

<tlr> yes, indeed

last meeting's minutes

<tlr> http://lists.w3.org/Archives/Member/member-wsc-wg/2007Jul/0007.html

<tlr> approved

agenda bashing

Mez: agenda includes demo infrastructure
... past decisions, editing rec document, use cases

serge: discussing results of study on phishing indicators

Mez: demo infrastructure, Audian isn't here, so we'll skip it

RecRevisitingPastDecisions

Mez: revisiting past decisions, tlr will lead this

<Mez> http://www.w3.org/2006/WSC/drafts/rec/#pastdec

tlr: revisit past decisions so people don't continue to make stupid decisions
... user agents accessing history of past security decisions
... interactive indicators to display where decision was made
... also allow users to access decisions impacting current context, with option to revert
... allow users to inquire why it made such decisions and ability to change them, or reset to defaults or other modes

serge: users don't understand the connection between actions and consequences

tlr: more about trust anchors, identity indicators
... such as trusting a certificate, or cookies
... some decisions are reversable by closing the browser, which isn't a good way of doing things

<Mez> ack forensics?

Chuck: forensics/computer crime comes into play here, e.g. capturing browser history
... this proposal could have a role in future criminal investigations

<???> more forensic information may make people nervous.

<tlr> depends on who does the forensics. ;-)

<serge> but I don't think you're talking about capturing anything new?
... just presenting it better?

Chuck: capturing new information may make people uneasy

Mez: Shawn hasn't updated the document, we need more editing resources
... difficult to edit in stuff across proposals
... volunteers?

tyler: less text?

<tlr> +1 to MEZ

Mez: we still need structure in order to discuss these things

<tlr> -1 to keeping in the Wiki indefinitely

tlr: we need to extract meat from proposals
... 9 months into charter, what direction are we going?

<Mez> I would like to keep the three topics in sequence

<Mez> 1) editing help

<Mez> 2) organizing discussions

<Mez> 3) FPWD

tlr: how long to keep the wiki?

tyler: we shouldn't be forced to edit proposals that are fundamentally bad

<serge> +1 to tyler

Mez: anyone willing to help edit?

<asaldhan> am new to editing. But I can assist

tlr: limited number of people on call, take this offline and discuss on the mailing list

tyler: how will changing the text force the group to make decisions on what to recommend?

tlr: we have concrete proposals, we need structure before we can make useful decisions
... help to create objectives

<Mez> Anil, thank you for volunteering to help out with editing

tlr: editor should leave opinions outside of editing role

serge: we should be doing testing before any sort of editing

tyler: use what the group knows

stephenF: unreasonable to test before we have a document

<maritzaj> +1 to Tyler on applying what we know before going forward

tlr: not an academic exercise or product dev, it's a specification

Mez: discussions should focus on the whole, and the four categories for structuring
... begin to have discussion on the categories
... primary SCI, seconday, robustness, and minizing trust decisions

maritzaj: lay out what we know so far

Mez: look at primary SCI proposals in wiki

<tyler> PIIbar

tlr: mixed documents, error handling

<tyler> what is the primary vs secondary distinction in SCI?

<maritzaj> primary as in it always displayed in the main UI?

tlr: for certificates

<serge> I assume you mean active vs. passive?
... active indicators interrupt the user's task, whereas passive ones sit off to the side, where we hope someone will notice them

<maritzaj> would secure letter head be primary since it would potentially always be in the chrome

<serge> this sounds like a good thing to add to the glossary!

<maritzaj> has anyone had a look at this break down http://www.w3.org/2006/WSC/wiki/RecommendationUsabilityEvaluationFirstCut

<maritzaj> since it's divided amongst the three of us, we can pick 1-2 from each?

<maritzaj> for next week

tyler: maritzaj and serge should look at proposals to see what is easier to address

<serge> *ahem* I've already brought that up

serge:this isn't a consensus issue! If there's a body of research showing an idea will not work, it's a waste of our time to pursue recommending it, regardless of how many people "like" the idea.

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

tyler: trimming segments is the fastest route to making editing easier

maritzaj: we'll make recommendations on a few of them for next week

tlr: distinguish between academic consesnsus and moving things forward
... we should create recommendations based on our personal opinions to complete the document rather than, you know, having any idea whether it will actually work

tyler: trim the low hanging fruit

<serge> +1 to tyler

<maritzaj> +1 to tyler

serge:yeah, we've brought it up
... but people are stuck recommending stuff based on personal opinions, and refuse to change those opinions regardless of how much prior research has showed it to not work

<maritzaj> that's what i was on the queue to say

<Mez> so why can't one of you start talking about what does work

<Mez> so we can start with that, and move on to what doesn't?

<Mez> then we'll have a foundation for discussions

<maritzaj> most of the results make it easier to say what doesn't work ...

<maritzaj> unfortunately

<serge> we've discussed what does work,
... I can give some examples that have come up,

<Mez> reference the rec track document with the examples

<serge> but people just gloss them over, and then revert to recommending stuff they like, rather than stuff that has shown to work

serge:As I understood it, we were all in agreement in Dublin about not expecting users to interpret the lack of an indicator as a warning. In that case we should be pursuing purely negative warnings. Almost every proposal in the wiki relies on positive warnings which will either go unnoticed or be spoofed. What happened? Do people no longer agree on this principle? Has anyone bothered to read any of the research in the Shared Bookmarks?

PHB: middle ground between structuring and proving, more opportunities for merging proposals
... e.g. favicons and secure letterhead

<Mez> I agree, there are some of us that need the document better structured - putting related items together

tlr: positive vs. negative indicators, we need agreement on success criteria

serge:maritza, rachna, and I are doing that right now

<Mez> that's what I thought serge

<Mez> though again, I maintain hope that some of what you'll do will also verify some subsets

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

maritzaj: rachna, serge, and I are working on it, probably by next Wednesday we can share some results

Mez: we'll start with primary SCI proposals

<serge> have we agreed on the definition of primary SCI?

<PHB> saying negative things will be the low hanging fruit

<PHB> :-)

serge: we need to define the four categories in the glossary

Mez: we'll work through primary SCI proposals, which should structure discussions for a while

<Mez> tlr, please give me an action to put the categories in the glossary

<tlr> ACTION: define categories in glossary [recorded in http://www.w3.org/2007/07/25-wsc-minutes.html#action01]

<trackbot> Sorry, couldn't find user - define

<tlr> gah

<tlr> ACTION: mez to define categories in glossary [recorded in http://www.w3.org/2007/07/25-wsc-minutes.html#action02]

<trackbot> Sorry, couldn't find user - mez

<tlr> ACTION: zurko to define categories in glossary [recorded in http://www.w3.org/2007/07/25-wsc-minutes.html#action03]

<trackbot> Created ACTION-273 - Define categories in glossary [on Mary Ellen Zurko - due 2007-08-01].

<Mez> the mail where I initially defined the categories:

<Mez> http://lists.w3.org/Archives/Public/public-wsc-wg/2007Jun/0064.html

serge:just concluded a study on users' perceptions of current browser phishing warnings. IE7 and Firefox use "active" warnings which interrupt the users' tasks and force them to make decisions about what to do. Prior research has shown that passive indicators are ignored or not trusted (users can see the website, and if it "looks" like the real thing, they trust it more than the indicators). We did a spear phishing attack and found that the active warnings in Firefox and IE were very effective, however there was no statistically significant difference between using popup dialogs than not showing any warnings. Warnings that failed were due to habituation (they looked like other warnings users have seen). Also, no correlation with previously falling for phishing scams or having credentials/accounts stolen and falling for phishing attacks (and/or ignoring warnings) in our study.

Mez:When can you share the results?

serge:I'd prefer to wait until I have it submitted in September, though I can answer questions

tlr: W3C has a confidentiality agreement

serge:But they can still share with all of their coworkers, etc.? It's not just limited to members of the group?

tlr:Correct.

update from Tyler re wsc-usecases

tyler: no new work on use cases, sent out an email last week
... pulling stuff out for the note
... from issue 6

<luis> but then the wiki should never dissapear

<maritzaj> bye

<tlr> serge, please stay on the call

tlr: hmm?