WSC WG face-to-face San Jose 31 Jan

Agenda Bashing

rachna: [by phone] I expect to get to the meeting about 10 minutes late.

[chair displaying agenda]

mez: Stuart is scribe. I sent out updated agenda today.
... 1 hour best of breed mozilla, then 15 minutes for cardspace (Rob), break, bob leads discussion on safe browsing mode proposal
... section 9, lunch, 9.2 learning from past efforts (1/2 hour)
... 9.3 (45 minute), look at overall schedule again, afternoon break
... time to talk about recommendations (1 hour for first, 1 hour for second)

beltzner: can we swap demos while I look for mac presentation adapter?

<scribe> chair: bob?

Safe Browsing Mode Proposal

bob: sure, i can go now.
... safe browsing mode = separate tab or window in which you can only view websites that you've previously determined are trusted in some way.
... in most cases the decision on which sites to be trusted is made by the individual [ user ] but this could be certified by others (e.g. subscription services that list trusted sites)
... benefits. users could choose to browse only those sites they've deemed trusted.
... how to choose whether site should be added to trusted list is hard. push it off to users.
... there would be a white list compiled by a trusted party... [steps back]
... many ways to add site to trusted list through conscious user action.
... the trusted list would contain at a minimum the URL of the site and a fingerprint of the cert.
... So you build these up over a period of time and safe browsing would only allow user to access sites with URLs on the list and with certs that match the fingerprint list
... so how do you get into safe browsing mode?
... it seems like it should be automatic to be effective, but two arguments against that are that (1) the user should know when they're in safe browsing mode and (2) it should be hard for malware to trigger safe browser mode.
... once the whitelist is compiled certs may change, so you need some way to update the signature. so there might need to be some third party certificate service to make sure that the signatures on the whitelist are kept current?
... if users are forced to take a specific action to add trusted websites to the list and to activate the mode it does not seem like the type of functionality people would use for most websites. they would only use it when entering [particularly] sensitive information.
... it's unlikely that banks will ask users to enter safe browsing mode all the time because banks are leery to make customers do things too differently.
... so there's an issue of motivation.
... is there some way that users can be motivated to actually use this.

hal: is the safe browsing mode anything more than the white list?

bob: you're in a special tab or window where you can only access those sites on the whitelist?

[ignore ?]

hal: the name implies that there's something safer about the browser. is the browser different or just a whiltelist

Tony: isn't safe browsing more than just a site, but also limitations on plugins and isolating the process so that it's fresh and new. for example cardspace puts itself in a separate OS process space. another example would be xen on a linux box.

Tyler: So if I'm in safe browser mode and the site I'm looking at contains a link to a site that's not on the white list and I click on it, what happens?

bob: I don't know. I suppose the link shouldn't work.

Tyler: So white-listed sites can't link to non-white listed sites?

Bob: If the site that I'm trusting is putting a link and I trust that link...

Tyler: You could transition out of safe browsing mode.

Bob: I suppose it could do so.
... Another question is that if you had a safe browsing mode could you transfer lists between browsers?
... Use cases [see Bob's email describing it which goes through cases in detail]

[beltzner's cable arrives]

[Rob Franco arrives]

[the above two events are correlated, not causal]

yngve: Would users activate it? One thing I was thinking about in partiuclar was the scenario where I get an email that looks like it's from some site I trust and now I think should I change it to trusted mode now?

Bob: So you're asking that if you click on the link do you put it into safe browsing mode after you click on the link?
... If you just click on the link and you're not in safe browsing mode you'll just go to the site.
... You could put the browser into safe browsing mode and click on the link again.
... The way you would get into safe mode is to signal the operating system which would signal the browser to go into safe mode.
... The reason why to do it this way is that it's less subject to attack [in response to yngve pointing out that not all browsers have such tight interaction with the OS]
... There are usability issues to debate and think through further.
... Agreement that control-alt-delete is too much to get to your website. perhaps market is highly motivated security-concious users.

Yngve: Servers couldn't know if this mode was on.

Mez: Correct. I think that's something you brought up.

Yngve: Fingerprints must be generated from somthing that's static.

Mez: agree that there are issues with fingerprint changing, for examples when keys are rolled over.

Phil: I'm trying to work out how safe browsing mode really differs from EV mode in that it seems to me is that what we're really talking about here is turning off things that may be bad.

Bob: What do you mean by EV mode?

Phil: Green bar implies...

Mez: How does that related to this working group?

Phil: Maybe green indicator should only come up if it's EV cert + some of these other conditions (e.g. not submitting forms to an HTTP url)

Rob: There are no heuristics in any of the browsers to see if the page is developed securely.

Tyler: By default there is the dialog if HTTPS page has HTTPS content
... What is the indicator that you've left EV mode?

Rob: Green bar goes away. It's a pretty significant thing.

Phil: We need to have defined levels of trust and those need to be small in number. Safe browsing mode needs to be though of as a feature of the green experience. [mez objects] ok, the splunge experience.

Hal: It seems like there's a model here that users have 3-5 security-critical sites. Phil's point is that if all those had EV certs than we could merge these features. [scribe is taking some liberties here in interpreting Hal.]
... It's not clear since there's no actual protection or behavior improvement that this mode is any more than a whiltelist. So I think Phil's question is whether an EV whitelist might be just as good.

Bob: There would need to be something about safe browsing mode (e.g. the tab) that informs you that you are there and can only reach the whitelist.
... If the banking industry came out with an industry specific whitelist...

mez: Thanks very much and you're out of time.

Phil: It occurs to me, do we have the forms submission included in the note?

Rachna: what do you mean?

<tlr> ACTION: Hallam-Baker to check whether security usability of form submission is covered in Note [recorded in http://www.w3.org/2007/01/31-wsc-irc]

<trackbot> Created ACTION-116 - Check whether security usability of form submission is covered in Note [on Phillip Hallam-Baker - due 2007-02-07].

Phil: The fact that when you enter a form ...

Best of Breed anti-phishing Mozilla Extensions

Note, section 9.1, cont'

Mez: Agenda, transition back to transition of 9.1 of the note. Hand-off to Maritza.

<Mez> http://www.w3.org/2006/WSC/drafts/note/Overview.html#usability-principles

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

Maritza: Before I get started, I think we're missing a lot of the design principles.

Tyler: I couldn't put them in because I didn't understand them and wanted you to add them in.

Mez: Let's continue by picking up on 9.1.6. and then transition to wiki source for the remaining time.

[Maritza reads 9.1.6, 9.1.7]

"Know who your user is. Create user profiles according to level of experience, education, cultural differences, etc. [Scheiderman]."

Mez: there were some objections to this

Tyler: I objected because Rachna's study showed no correlations between demographics and susceptibility to phishing.

maritiza: We need to look at use cases to categorize users by goals and information that users require to meet their goals

"Create task profiles (use cases) representative of the tasks the user will complete [Schneiderman]."

Rachna: You must at least know the capabilities and skills of your users.

Hal: I don't get the task thing. There's no way for the browser to determine that. [stuart is transcribing but has no idea what's being said] To me, task is I want to pay a bill, read email. But the web browser doesn't know any of that.

Mez: Please don't leap ahead.

Tyler: Does the second bullet point say anything other than "you should have some use cases"

Hal: Well, I heard a suggestion that the second bullet point is the answer for one.

Tyler: I don't know we can categorize their users.

Rachna: Start with that their humans and go from there.

Tyler: You didn't see correlation

Rachna: That doesn't mean it wasn't there. It was a small study not designed to pull these out.

Mez: What are you suggesting we do here.

Rachna: Who are we designing for.

Hal: Do we treat all people as a homogenous group?

Rachna: One recommendation might be to make sure that the browser is usable in a secure state by someone who is using it for the first time and also for expert users.

Mez: What do you visualize as the process we will use as a team to get to the recommendations.
... The answers I can imaging are (1) to use the traditional persona message. create personas. tie them to tasks... (2) Start with use cases that we have.

Thomas: I was hearing we're making recommendations for people who make browsers. This is to some extent right. But the way we'll do that is to say that a browser conforms to a spec if you do X. X must be empirically testable. This brings me to a question that I think I just heard.

Rachna: When we do user studies we need to draw a sample population that's representative of our users. If demographics didn't matter, we could use CS students as a sample population.

Mez: We could have a recommendation that just said conformance means a certain amount of user testing.

Rachna: A bigger contribution than results could be guidelines and a framework for testing and comparing solutions.

Tyler: We have another task here, which is what we put in 9.1 for general design principles.
... Does anyone have an argument that bullet point one is relevent to the presentation of security information.

Phil: We need to define separate user profiles because we need to test different aspects. e.g. users using a system for the first time vs. those who use a system daily. If you don't have profiles you have bias that's implicit rather than explicit.

Beltzner: For this first bullet, the question is how will the effect our design. I think we can come up with a generalized profile of a web user that is extraordinarily wide.

Rachna: Our study just didn't find a relationship between demographics and results, but it wasn't looking for them.

Rob: Creating user profiles is pretty standard practice.

Rachna: I think we need to acknowledge different level of user skills and that should be in there.

Thomas: I'm coming back to my earlier point. If we write up a framework for usability testing that framework would need to describe populations to be tested.
... We must also consider what level of assumptions for the recommendations we are making.
... Perhaps Tyler was getting at was that we don't want different recommendations for different types of user.

Maritza: This point was taking from a book. For our purposes, we don't necessarily have to do it by level of experience and those criteria. We don't need to know that it's a 90 year old grandmother, but that this user has this goal.

Mez: Maritza, please type wording into IRC

Tyler: I'd be surprised if we had rational way of...[stuart dropped understanding]

<Mez> because we need to figure out how we'll make recommendations

<Mez> so you all tell me how we'll make recommendations

<Mez> ok, got that part

Rob: I want to get back to user personas. I think it's very important to MS product development and I'm sure it's not unique to us.

Mez: Queue= Mike, Phil, Rachna and that's it

Beltzner: We all want to classify users for our design. We at Mozilla have found it very useful to design for the lowest skill set they want to support.

Phil: The mechanisms that we're looking at our designed for particular groups with assumptions of knowledge and tolerance levels.

Rachna: One way to categorize users is by their choice of operating system, browser, and such and so we should at least know them in that way.

<maritzaj> I'll attempt a rewording during lunch

Hal: I use 4 browsers/operating systems.

Rachna: Yes, but that's an important characteristic of who you are for this purpose.

Mez: we're taking the first two bullet points and reword them or provide the reasoning behind them to motivate their inclusion in the note.

Hal: So we silently drop the rest?

<tlr> ACTION: maritza to reword the first two DesignPrinciples points for possible inclusion in the note [recorded in http://www.w3.org/2007/01/31-wsc-irc]

<trackbot> Created ACTION-118 - Reword the first two DesignPrinciples points for possible inclusion in the note [on Maritza Johnson - due 2007-02-07].

Mez: [Enters stage left, in shrill voice] No! We'll get to them by email. [lowers head and shakes it. spotlight moves to left. cue smoke]

<Mez> shakes saber

Maritza: "Consistency. The cues should be displayed consistently in location and across sites and browsers in an attempt to prevent spoofing and vonsusion of the user [Schneiderman]."
... Lock icon is example.

Hal: [dropped by Stuart due to packet overload]

<yngve> Rachna, Choice of OS, browser does not necessarily indicate what kind of user we are dealing with. It might indicate that on desktop, but not necessarily in a reliable way. It is far less reliable on mobile devices.

Mez: So consistency requirement may thwart solutions that work by introducing inconsistency?
... move consistency bullet from bullets to section 9 of note.

<hal> it is possible to argue that if users could configure their browser so that the chrome was completely non-std, e.g. orange with URL at the bottom

<tlr> ACTION: tyler to move consistency bullet point into section 9 [recorded in http://www.w3.org/2007/01/31-wsc-irc]

<trackbot> Created ACTION-119 - Move consistency bullet point into section 9 [on Tyler Close - due 2007-02-07].

Tyler: Can I just cut and paste words following consistency in the notes? [Mez OKs]

<hal> it would be nearly impossible for an atttacker to spoof their screen using attacks such as picture in picture

Final bullet-point before lunch: "Provide Explanations, justifying the advice of information given [Patrick]"

<hal> not arguing this is the correct approach, merely a logical possibility

Martitza: users should know that they're not just jumping through hoops for no reason. [Stuart envisions fun usability test where users are given hoops and asked to jump through them until they stop from exaustion]

Tyler: Needs full reference for "[Patrick]" reference.

<tlr> ACTION: maritza to contribute further text on "explanations" bullet point; provide [Patrick] reference [recorded in http://www.w3.org/2007/01/31-wsc-irc]

<trackbot> Created ACTION-120 - Contribute further text on \"explanations\" bullet point; provide [Patrick] reference [on Maritza Johnson - due 2007-02-07].

Tyler: A general word from the editor. It would help me a lot of people gave actual text that they're willing to have put in the note.

Maritza: I put a note in saying "Please let me know if you want these in full sentences."

Tyler: I'm letting you know [cue canned laugher with a "dang!"]

[Group breaks for lunch. Stuart realize he can't reach pizza due to new case of RSI.]

Note, section 9.2

Mez: now we are looking at section 9.2

<Mez> http://www.w3.org/2006/WSC/drafts/note/Overview.html#usability-wisdom

Tyler: 9.2 data comes from Notes assumption page
... wasn't sure what most of the contents meant, but he stuck it in, for folks to discuss

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

Tyler: the assumptions section lays out the process section, we are going to reach to experts in other groups ...

Mez: the best thing to do is discuss 9.2 as a whole
... one of the thrusts in the assumptions part of the Note wiki is that we are going cite and rely on existing research efforts and results in the phishing area...
... and in section 9.2 we have called out 2 specific results that Tyler abstracted out from Wikis (and mailing lists?)
... the first item is 'No user categories in phishing vulnerability'
... section 9.2.1 has been discussed very well.

Rachna: Each research findings have multiple takeaways, how did Tyler decide which ones to take

Tyler: there was some stuff that he didn't add, and Mez says that if there are sections that anybody disagrees, or want to add other research results, they can be added

Mez: unpublished results, including deployment experience, can be added too

<staikos> is he?

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

<beltzner> staikos, yeah, has been all week

<yngve> staikos, definitely

<beltzner> heh

Tyler: there is lots of work going on in understanding why phishing is possible, section 9 is to highlight the stuff that hasn't been covered in section 8

tlr: is confused by section 9.2, and so is Mez

Mez: the purpose is to extract lessons learnt that we believe will apply to the future discussions in context of this WG

tlr: asks what's the difference b/w 9.1 and 9.2

rachna: 9.1 is general usability, 9.2 is security and especially focus on phishing

tyler: thinks more importance should be given to things that have been peer-reviewed, rather then one way published

Mez: peer-review certainly carries more defensible weight, she'd give more weight to deployment experience then someone's adhoc thought expressed on website/blog
... onto 9.2.2

Tyler: the wording of the section might be mangled by him

Mez: we need to make sections that are useful and defensible

hal: two points seem to be too less, but he doesn't have a suggestion

Tyler: there's lot of overlap b/w section 9 and section 8, hence this section is too less. He asks everyone to bringup things that should be in this section, including things from 'shared bookmarks' that should be here

Mez: add things to 'shared bookmark's will be useful for citation
... now onto section 9.3

Tyler: didn't do any editing, he picked up verbatim (from where?)

tlr: we should use section 9.3 to reach out to ppl doing user research testing, and contribute their findings

Mez agrees, and says lots of other complex stuff that I don't completey get...

tlr: the other ways to reach out to get research findings is conference talks

Martiza: hopefully we'll get good news (?) by tomorrow. there's talk of some security and usability study proposal.

<tlr> ACTION: zurko to propose rewrite of 9.3 [recorded in http://www.w3.org/2007/01/31-wsc-irc]

<trackbot> Created ACTION-121 - Propose rewrite of 9.3 [on Mary Ellen Zurko - due 2007-02-07].

Martiza: FSTC's use cases are very specific uses cases, she should have a test plan within next 2 weeks, and they'll be doing studies by April. The context of the study is site's authenticating to user. Their focus is within banking industry. Their use cases are a subset. ...
... will have a testing doc written within 2 weeks, and put it on the mailing lists

Mez: Is it acceptable with FSTC?

Bob: I'm not sure
... will find out more.

Rachna: is it true for test plans, or is it true for results too?

Mez: even if the direct results aren't shareable, maybe some higher level points may be shared
... there should be something on user education.

it was part of the Wiki and didn't make it to the Notes

Mez: done with section 9.0 and open for questions

Tyler: Asks should schedule be part of section 9.0, about when will we do user testing. Mez doesn't think so.

beltzner: Says once we know what kind of resources we have, then we can start scheduling, similar to product mgmt...
... should we hold on publishing the note till usability studies is done

tlr: note is work in progress by defn, hence says no to Mike...
... we do owe the community an update on schedule, as we are not following what is on the charter

Mez: talks about schedule from the 'Proposed revised schedule' email that was sent to public email list...
... as per that email we are going to do usability studies by June

beltzner: should the next f2f be earlier then june

Rachan: what is it we are trying to test? In 3 mnths we are develop user tests, but is it enough to develop all prototypes? All these needs to be answered before we decide on the schedule

ses: seemed to disagree with Mike, if the purpose of the meeting is develop 'study design'. it's difficult with group of this size

tlr: the milestone for the second f2f should be a editor's draft of recommendation

Tyler: is uncomfortable about editor's draft before usability testing is done on the recommendations

Rachna: develop recommendataions based on existing research results, and then carry out usability testing and iterate...

Maritza: we should start developing prototypes, before we put in effort to develop browser extensions

Mez: we should aim for usability testing post first draft of editor's recommendations. i.e around May timeframe should start designing tests

tlr: describes the process a little more. says the first draft is just proposed recommendations, and should not be confused with final recommendations

<PHB> I assume that the May f2F will not clash with Banff?

<ses> Two browser security extensions enter. One extension leaves. We call it, ThunderChrome! ?????? ]

bwporter: the first draft doesn't have to be detailed.

Mez: the first draft will be everything we have discussed, a superset. Doesn't have to be precise, defensible, detailed

PHB: thinks some recommendations can be made without further usability testing. we already have prior results

hal: asks, if we make first draft as a superset, does it mean that we might drop entire sections, once we have made it public?

tlr: says 'yes'.
... dropping part of recommendations happen, rewriting happens. and explains little more of the process...

Tyler: what if some of our recomendations get their 'butt kicked' during usability. Should we drop them?

Mez: no, put them in as 'negative results'. Basically, Don't do this!

staikos: his new tools should be easy for non programmers to prototype

betlzner: let's not discuss the technology of prototyping, but the fidelity

Mez: we have abt 15-30 members to help out (depending on active, or registered members)

I'm glad I don't have to transcribe Mike's gesticulations anymore. (I think the last one was that Amir ran away with a bunny)

<beltzner> ses, haha

<staikos> we should get the subjects to pay for it

Rachna: carrying out studies takes lot of work (involved 67 subjects). It took about 4-6 person months. That was testing one solution, with 3 diff conditions...

Tyler: talks about the technique Collin Jackson, at Stanford, used

tlr: we have one thing in our favour, W3C's 'fame'

Rachna: $500 for one idea, and scales linearly for number of ideas to be tested

ses: money isn't the problem, but other administrative hassles...

various members talking about creative ways of funding, carrying out usability tests, etc... not worth scribing

ses: if we can get users to consent and download, and carry out distributed user tests, it could be of immense value, and commits to coding efforts

beltzner: this functionality is coming in mozilla, but doesn't commit to timeframes

<tlr> http://www.w3.org/Member/Eventscal

tlr: discusses about next f2f, coming up in either may or june
... options are first or third week of may,
... aiming for 29-31st May
... in Dublin

<tlr> ACTION: Thomas to inquire Stephen Farrell about holding next meeting on 30-31 in Dublin [recorded in http://www.w3.org/2007/01/31-wsc-irc]

<trackbot> Created ACTION-122 - Inquire Stephen Farrell about holding next meeting on 30-31 in Dublin [on Thomas Roessler - due 2007-02-07].

Mez: break till 2.45 and then start with recommendations

<tlr> ACTION: Thomas to send hosting requirements to Tyler [recorded in http://www.w3.org/2007/01/31-wsc-irc]

<trackbot> Created ACTION-123 - Send hosting requirements to Tyler [on Thomas Roessler - due 2007-02-07].

Rec 1, baseline set of information and usability

Mez: We'll talk about recommendations...
... Tyler will be the editor for the recommendations too, and everyone is overjoyed
... The first recommendation, 'Minimal set of security context information'

<yngve> :)

Mez: the maximal set is what is outlined in section 7.0

tlr: suggests changing minimal to baseline.
... another important criteria is exhibiting an implementation. if that can't be done, puts us in bad situation.
... before the charter was finalized, there was some feedback from AC, some other folks.

Mez: The baseline set needs to be targetted towards web user agents, web apps authoring and web server deployments...
... Tyler has suggested, 2.4.1 as a structuring exercise, basically take use cases, and come up with list of what's reqd to complete those use cases...

Tyler: section 2.4 talks about what's the min that the user needs to know to proceed with his/her tasks

Mez: we should prioritize the use cases based on which ones are tightly related to our core goals...
... brainstorm about the minimal set, and Tyler to identity the core use cases, say 4.

Tyler: suggests start with uses cases to come up with minimal set

<tlr> http://www.w3.org/2006/WSC/drafts/note/

<Tyler> http://www.w3.org/2006/WSC/drafts/note/Overview.html#use-cases

starting with 6.1

Tyler: What does Betty need to know to prevent the attack

Mez: is there a all valid use cases, i.e. there's no attack. The answer is no.

Tyler: the capture phase of the attack doesn't matter.

bwporter: should we describe scenario separate from the attack or attack as the scenario

bletzner: we should first start with what is the user trying to do, and then have sub sections, one for the safe case, and others for attack scenario

ses: suggest some specific methodology, that the scribe doesn't quite grasp the subtelities... now ses writing on white board that scribe will try to capture

ses is dissecting use case 6.1 and coming up the threat tree, a directed acyclic graph.

<beltzner> Sunil, nice description

<yngve> AFAICT Betty would have three-four options for finding out if it is the right side or not: 1) hostname in URL, 2) certificate information 3) manual/automatic fraud check 4) browser remember previous sites. 2 and 3 requires correct and/or up-to-date information

ses: is there a attack possible where two different websites are opened within two diff tabs can communicate with each other, and can one tab open a pop up above the second site's window

staikos: the answers seems to be no. both tabs do know the geometry of the windows though.

<yngve> ses, there have been lot of work counteracting that scenario that past few years

<staikos> Sunil: correction... any tab know sthe geometry and position of any other tab in the same window. No tab can communicate with any other tab or window

<staikos> some browsers allow tabs to steal focus from other tabs in the same stack

<staikos> of course a tab does know the geometry of its own window

staikos, thanks for the correction

<tlr> Next meeting: 30/31 May, Dublin.

<staikos> tlr: officially?

<tlr> Stephen has confirmed that he's happy to host us these days.

<staikos> :-/

<tlr> huh?

<staikos> expensive for me ... especially with no direct flights

<staikos> or skype in :)

tlr: do you have a camera to take a pic of ses's drawing? ascii art in IRC will be tough

ses: let's shortlist the use cases during f2f, and then come up with the threat model offline

Bob: suggests let's start with recommendation to help use identify the unknown sites, and then talk about the threats/attacks to those recommendations

ses: suggests we should get the baseline attacks first, and then come up with counter measures

<beltzner> ses: mentioned a book [anyone catch the name?]

tlr: the f2f can benefit the most is settle on the use cases, basically agrees with ses.

hal: for each use cases let's highlight 1 or 2 attacks. should we pre-prune or post-prune?

<maritzaj> book mentioned - Writing Secure Code

<maritzaj> didn't catch the author

Bob: are we starting with all threats, and working our way up to what browser cues that address those threats, or other way around.

ses: neither. we want to start with what users want to do

Bob: comes up with three scenarios (i) you have already interacted with the site, and have bookmarked it.

ses: challenges that ppl don't usually bookmark it, but likely that they have typed in the URL...

martizaj: listing the use cases and listing the security information we have available that could be potentially available, how do we show them

Mez: what do we do with the threat tree

ses: do we separate use cases from threat tree?

tlr: says it's complementary, and is tempted to throw huge pieces of hw at ses, to come up with a useful threat tree

Rachna: ses starts one in Wiki, and everyone contributes to it. bwporter +1

ses: information is available in Note, only difficult to get at it due to the way it's structured. he'll come up with the threat tree by end of next week...

<tlr> ACTION: stuart to initiate work on threat tree [recorded in http://www.w3.org/2007/01/31-wsc-irc]

<trackbot> Created ACTION-124 - Initiate work on threat tree [on Stuart Schechter - due 2007-02-07].

tlr: what we have now will be the first version of the note draft, and the one with threat tree will be the next iteration of the note

<bwporter> question: did we decide yesterday whether/if we wanted to amend the structure of section 8 at all? i remember we tabled that, but i don't recall if we brought it back up and resolved it?

ses: pull out the use cases, independent of the threats

Bob's three scenarios i) go to site you have never been before, ii) go to a site where you have been before and are somewhat familiar, iii) you have been before and have relationship with

tlr starts a separate list for basic use cases

<tlr> ACTION: Thomas to map list from blackboard to existing use cases, possibly add more [recorded in http://www.w3.org/2007/01/31-wsc-irc]

<trackbot> Created ACTION-125 - Map list from blackboard to existing use cases, possibly add more [on Thomas Roessler - due 2007-02-08].

<staikos> for a canadian bank - somehow they targetted me

<staikos> http://accesd.secure-desjardins.com/fr/

<yngve> staikos, they are just phishing in a barrel

<staikos> https://accesd.desjardins.com/fr/ <-- web link had that as the text

<staikos> " Attention aux courriels frauduleux"

<staikos> oh wow, if you're english, you don't get phished with this one

<staikos> it redirects you to the real site

ok, I start scribing again...

Rec 2, robustness

Mez: 2nd recommendataion. Specify techniques to render the presentation of security context info more robust against spoofing attacks.

(i) Limitations on scripting capabilities, (ii) shared and protected secrets, and protection of those secrets, (iii) trusted path between web user agent and user, (iv) Safe mode browsing

<bwporter> (Apologies in advance that I need to leave at 4:30pm)

tlr: analyze the techniques that the two popular browsers have already employed

<yngve> tlr, what about the third and fourth browsers?

<staikos> yngve: you feel bad for IE and FF? :)

<tlr> proposed ACTION: staikos to document current practice in terms of security UI robustness

<tlr> ACTION: staikos to document current practice in terms of security UI robustness [recorded in http://www.w3.org/2007/01/31-wsc-irc]

<trackbot> Created ACTION-126 - Document current practice in terms of security UI robustness [on George Staikos - due 2007-02-08].

<tlr> ACTION: yngve to document current practice in terms of security UI robustness [recorded in http://www.w3.org/2007/01/31-wsc-irc]

<trackbot> Created ACTION-127 - Document current practice in terms of security UI robustness [on Yngve Pettersen - due 2007-02-08].

<tlr> ACTION: beltzner to document current practice in terms of security UI robustness [recorded in http://www.w3.org/2007/01/31-wsc-irc]

<trackbot> Created ACTION-128 - Document current practice in terms of security UI robustness [on Mike Beltzner - due 2007-02-08].

<yngve> staikos, they need to allowed to play, too :)

<tlr> ACTION: thomas to prod Rob to document current practice in terms of security UI robustness [recorded in http://www.w3.org/2007/01/31-wsc-irc]

<trackbot> Created ACTION-129 - Prod Rob to document current practice in terms of security UI robustness [on Thomas Roessler - due 2007-02-08].

<staikos> yngve: sigh fine

tlr: do we have a good survey of proposed anti spoofing techniques that might be relevant?

Mez: there might be good research on 'Shared and protected secrets' techniques

<staikos> *** For those who think we should be adding all kinds of information to the browser to track what the user has done and know how strong the relationship is, please see (for example): https://bugzilla.mozilla.org/show_bug.cgi?id=330884

tlr: to what extent does the XUL makes available with XUL content type is an issue?

beltzner: user is asked for extensions; when XUL is served as content, it's constrained.

PHB: CardSpace doesn't rely on shared secret

Mez: we'll make progress on 1st recommendation once we have full threat trees to full set of use cases

tlr and ses: discuss whether decisions points are part of uses cases or threat tree

ses: they'll become clearer once threat models are developed.

Bob: should we brainstorm about cues, instead of the current appraoch of developing use cases and threat models and using that to come up with cues

Mez: doesn't want to miss the no-threat case.

ses: It's going to be there, under the assumption that nothing's wrong

Any Other Business

tlr: Stephen Farell will host us in Dublin for the next f2f

<tlr> ACTION: Thomas to set up poll to confirm date. [recorded in http://www.w3.org/2007/01/31-wsc-irc]

<trackbot> Created ACTION-130 - Set up poll to confirm date. [on Thomas Roessler - due 2007-02-08].

<tlr> ACTION: thomas to start rescheduling exercise for telephone calls [recorded in http://www.w3.org/2007/01/31-wsc-irc]

<trackbot> Created ACTION-131 - Start rescheduling exercise for telephone calls [on Thomas Roessler - due 2007-02-08].

<tlr> resolved: change schedule to 90 minutes

<tlr> meeting adjourned

WSC WG face-to-face San Jose

31 Jan 2007

Attendees

Contents