- From: Thomas Roessler <tlr@w3.org>
- Date: Thu, 15 Feb 2007 12:15:19 +0100
- To: WSC WG <public-wsc-wg@w3.org>
The minutes from our face-to-face meeting on 31 January have been
approved and are publicly visible at this URI:
http://www.w3.org/2007/01/31-wsc-minutes
I'm including a text/plain version below.
Thanks to Sunil and Stuart for scribing.
--
Thomas Roessler, W3C <tlr@w3.org>
- DRAFT -
WSC WG face-to-face San Jose
31 Jan 2007
[2]Agenda
See also: [3]IRC log
Attendees
Regrets
Chair
Mez
Scribe
Sunil, ses
Contents
* [4]Topics
1. [5]Agenda Bashing
2. [6]Safe Browsing Mode Proposal
3. [7]Mozilla Extensions
4. [8]User Interface for Cardspace
5. [9]Note, section 9.1, cont'
6. [10]Note, section 9.2
7. [11]Rec 1, baseline set of information and usability
8. [12]Rec 2, robustness
9. [13]Any Other Business
* [14]Summary of Action Items
_________________________________________________________________
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
[15]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
See also: [16]Slides
Mez: Now for Mike's presentation.
Demos: LocationBar^2, Password Hasher, Password composer, SXIPper, PassPet
LocationBar^2 - makes domain name bold and separate from path. subtle, but
marked improvement
Rachna: So how do you know you're in SSL mode?
Beltzner: Lock icon/yellow bar
Tyler: How do you feel about getting rid of the location bar?
Beltzner: Good, but you'd be surprised how many people enter URI's in there
browser. Something like 40% of page loads are user typed URIs.
... A couple of different password hashing technologies exist.
... One thing this group could do is create meta tags for passwords so that
pages can tell password managers what the password restrictions are.
Phil: This is putting lipstick on a pig.
Thomas: The HTML charter currently in a proposed state and does not have a
directors decisions, includes [something about password signaling]
ses: So the threat model with password hashing is that instead of phishing,
a hacker creates a random site, get users to create accounts, performs a
dictionary attack on the user's master password that generated the hash, and
then has ALL of the user's passwords to all of the user's sites.
Rachna: yes, there's also a google threat model [which stuart didn't
understand and so can't transcribe]
Tyler: agree with Stuart's threat model
Phil: [comments lost while stuart transcribes]
Beltzner: I'm not sure why we're not talking about why password hashing is
bad.
... These schemes must offer value to both user and website creator to be
valuable.
... Bigger issue to highlight here is UI presentation of these features.
SXIP - carrot=it fills in fields for you
Beltzner: We should find people to prototype and play.
Tyler: Do you have folks to help us with add-on development?
Beltzner: It seems to have a lot to do with the willingness of the folks
writing the add-ons. I'd be happy to hoook you into the right people.
[George arrives]
Betlzner: That's the end of the demos.
Beltnzer's Slide: Users don't care about the technology, just want to
perform their tasks, want to relate things back to the real world, want
something in it for them other than "security", and want things to look
pretty.
<tlr> ACTION: beltzner to contribute material re confirmation bias to note
[recorded in [17]http://www.w3.org/2007/01/31-wsc-irc]
<trackbot> Created ACTION-117 - Contribute material re confirmation bias to
note [on Mike Beltzner - due 2007-02-07].
Mez: We need to make sure the confirmation bias is in note.
Maritza: There's a reference in shared bookmarks about how users rationalize
away things.
Tyler: Themes has loads of tartans.
Beltzner: Few downloads
... Were you wondering about legal liabilities of lying to user.
Thomas: Rathole alert.
<staikos> Not using email is not realistic. Fixing email is more realistic
<Tyler> Themes may not be popular, but they're pretty. Ergo tartans can be
pretty
Phil: We've got to differentiate phishing from general impersonation
attacks.
Tyler: I don't want tell anyone to stop sending around links.
Beltzner: You're saying you want more info about where links come from and
whether they're trustworthy?
Tyler: No, I just want to know the identity of where I am.
Beltzner: That's a hard problem.
... So what if no phishing targets ever emailed their customers. Would we
reduce phishing?
Thomas: banks main concern at this point is malware.
Mez: Can we do anything about malware in this charter? Probably only at time
of installation.
Thomas: Install time is in scope.
Rob: There is gridlock in spam prevention. If W3C could help break that
gridlock...
Tyler: One thing I liked about your talk is that your want to add security
and usability in concert.
Mez: There's truly secure and arguably secure.
... Rob is giving a demo of cardspace.
... he's got 30 minutes
<Mez> Phone folks might want to mute for each other, fyi
Cardspace User Interface
Rob: We've not talked enough about malicious code getting onto systems.
... Focus on user and things that user will want.
... [notepad outline of talk] (1) chromeless windows
<Mez> I'm turning down the phone volume; pleas emute folks on the phone if
you're not talking. Someone's making noises
Any modal prompt coming from OS should always be frontmost.
[that was Rob's point]
Rob: In SP2 they start warning people that downloads may be harmful. They
can now call spyware filters.
Phil: When we say that the program is signed we actually mean that the
distribution is signed, not the program.
Rob: Yes. When we look at an ActiveX control we mean a file. The things that
it lays down on the system may not be.
Phil: I've seen firms sign installers and then that installer will install
anything they want in the future (and possibly other's code as well.)
... We want to get to a point where all code is signed.
Rob: Error pages. These say to the user that something's wrong with the
site.
Tyler: Do IE7 Error pages shows in the browser back history?
Rob: [heavily paraphrased] It shows up as the page that would have been
loaded.
Tyler: The replacement web page should be a first class web page so that I
can go back and see it after going through to the page.
[Rob shows banner coming down from location bar for suspicious site.]
Rob: Our usability testing shows this is more noticeable the yellow
information bar by itself. I believe it scores higher [better] than prompt
that user clicks through
[above Rob:]
Rob: Not going to talk about EV other than to show maximized browser window
which looks more integrated into the system.
[Rachna asks for data. Rob says shell team has tested but has no data.]
Rob: ... Demoing sign-in with cardspace user experience.
... Cardspace creates a private desktop that covers everything else with
"dark glass". If there are other applications running the user's process
they can't jump in and muck with things.
... Even locally running code can't draw itself on top of this prompt
[cardspace UI].
... This is V1 experience. I'll be working on V2 experience with input and
feedback of this group. ...
... Note that host identifier at top isn't full URL, just the host domain
name. ...
Rob: When I send credentials to this website I'm letting the software do the
work of figuring out how to uniquely and somewhat securely reflect my
identity to the website.
... By sending that this is an elaborate way for me to get signed in.
Tony: So we've been working on identity selectors for other platforms and
what we ran into with cardspace is the room (space) for cards so you can
potentially lose yourself in selecting an identity.
Rob: Completely agree.
... There are a number of remaining usability hurdles.
Rachna: Having too many cards could increase spoofability.
Rob: Yup.
Tyler: I wonder if this is in scope because it's new technology.
Rob: The UI elements about representing the security and identity of a
website are in scope. All of the great thinking in the identity space that
lies outside of the presentation to the end user may be out of scope.
Tony: It's another user agent so its in scope.
Tyler: Is it too new?
Tony: I don't think so.
Mez: I think it's future technology that's out of scope. [implication, this
exists so it's not future]
Phil: The standard, ws-security, was completed before our group started so
it's not future technology.
... However, this is platform layer not application layer.
Hal: How much of this can be done by browser how much requires OS support?
Rob: Doable but it may be impractical.
Hal: I'm talking about recommendations to builders of user agents, not
operating systems. What can we take from your talk that falls in that
category.
Rob: The way we're handling chromeless windows is something that others
should do. Handling of potentially malicious downloads might be relevant.
Private desktop is an extreme measure.
Tyler: I like the idea of having the web user agent keep better track of the
identifiers a user has and where they've submitted them to. For the actual
[cardspace] infrastructure itself, there's a scope issue.
Tony: I agree that cardspace as a whole is not in scope but the concepts
have a big bearing. And instead of using your protected mode, for example,
we could use xen. In some cases you won't need that extreme. I think this
[cardspace] is very important to this group.
Note, section 9.1, cont'
Mez: Agenda, transition back to transition of 9.1 of the note. Hand-off to
Maritza.
<Mez>
[18]http://www.w3.org/2006/WSC/drafts/note/Overview.html#usability-principle
s
<Mez> [19]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
[20]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 [21]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
[22]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>
[23]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> [24]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> [25]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
[26]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> [27]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 [28]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
[29]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> [30]http://www.w3.org/2006/WSC/drafts/note/
<Tyler> [31]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
[32]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 [33]separate list for basic use cases
<tlr> ACTION: Thomas to map list from blackboard to existing use cases,
possibly add more [recorded in [34]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> [35]http://accesd.secure-desjardins.com/fr/
<yngve> staikos, they are just phishing in a barrel
<staikos> [36]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 [37]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 [38]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 [39]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
[40]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):
[41]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
[42]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 [43]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
Summary of Action Items
<trackbot> Created ACTION-116 - Check whether security usability of form
submission is covered in Note [on Phillip Hallam-Baker - due 2007-02-07].
<trackbot> Created ACTION-117 - Contribute material re confirmation bias to
note [on Mike Beltzner - due 2007-02-07].
<trackbot> Created ACTION-118 - Reword the first two DesignPrinciples points
for possible inclusion in the note [on Maritza Johnson - due 2007-02-07].
<trackbot> Created ACTION-119 - Move consistency bullet point into section 9
[on Tyler Close - due 2007-02-07].
<trackbot> Created ACTION-120 - Contribute further text on \"explanations\"
bullet point; provide [Patrick] reference [on Maritza Johnson - due
2007-02-07].
<trackbot> Created ACTION-121 - Propose rewrite of 9.3 [on Mary Ellen Zurko
- due 2007-02-07].
<trackbot> Created ACTION-122 - Inquire Stephen Farrell about holding next
meeting on 30-31 in Dublin [on Thomas Roessler - due 2007-02-07].
<trackbot> Created ACTION-123 - Send hosting requirements to Tyler [on
Thomas Roessler - due 2007-02-07].
<trackbot> Created ACTION-124 - Initiate work on threat tree [on Stuart
Schechter - due 2007-02-07].
<trackbot> Created ACTION-125 - Map list from blackboard to existing use
cases, possibly add more [on Thomas Roessler - due 2007-02-08].
<trackbot> Created ACTION-126 - Document current practice in terms of
security UI robustness [on George Staikos - due 2007-02-08].
<trackbot> Created ACTION-127 - Document current practice in terms of
security UI robustness [on Yngve Pettersen - due 2007-02-08].
<trackbot> Created ACTION-128 - Document current practice in terms of
security UI robustness [on Mike Beltzner - due 2007-02-08].
<trackbot> Created ACTION-129 - Prod Rob to document current practice in
terms of security UI robustness [on Thomas Roessler - due 2007-02-08].
<trackbot> Created ACTION-130 - Set up poll to confirm date. [on Thomas
Roessler - due 2007-02-08].
<trackbot> Created ACTION-131 - Start rescheduling exercise for telephone
calls [on Thomas Roessler - due 2007-02-08].
[End of minutes]
_________________________________________________________________
Minutes formatted by David Booth's [44]scribe.perl version 1.127 ([45]CVS
log)
$Date: 2007/02/06 13:02:54 $
References
1. http://www.w3.org/
2. http://lists.w3.org/Archives/Public/public-wsc-wg/2007Jan/0219.html
3. http://www.w3.org/2007/01/31-wsc-irc
4. file://localhost/home/roessler/W3C/WWW/2007/01/31-wsc-minutes.html#agenda
5. file://localhost/home/roessler/W3C/WWW/2007/01/31-wsc-minutes.html#agendabash
6. file://localhost/home/roessler/W3C/WWW/2007/01/31-wsc-minutes.html#safebrowse
7. file://localhost/home/roessler/W3C/WWW/2007/01/31-wsc-minutes.html#mozext
8. file://localhost/home/roessler/W3C/WWW/2007/01/31-wsc-minutes.html#cardspace
9. file://localhost/home/roessler/W3C/WWW/2007/01/31-wsc-minutes.html#cont91
10. file://localhost/home/roessler/W3C/WWW/2007/01/31-wsc-minutes.html#note9.2
11. file://localhost/home/roessler/W3C/WWW/2007/01/31-wsc-minutes.html#rec
12. file://localhost/home/roessler/W3C/WWW/2007/01/31-wsc-minutes.html#rec2
13. file://localhost/home/roessler/W3C/WWW/2007/01/31-wsc-minutes.html#aob
14. file://localhost/home/roessler/W3C/WWW/2007/01/31-wsc-minutes.html#ActionSummary
15. http://www.w3.org/2007/01/31-wsc-irc
16. http://www.w3.org/2006/WSC/w3c-wsc-best-of-breed-and-dos-and-donts.pdf
17. http://www.w3.org/2007/01/31-wsc-irc
18. http://www.w3.org/2006/WSC/drafts/note/Overview.html#usability-principles
19. http://www.w3.org/2006/WSC/wiki/NoteDesignPrinciples
20. http://www.w3.org/2007/01/31-wsc-irc
21. http://www.w3.org/2007/01/31-wsc-irc
22. http://www.w3.org/2007/01/31-wsc-irc
23. http://www.w3.org/2006/WSC/drafts/note/Overview.html#usability-wisdom
24. http://www.w3.org/2006/WSC/wiki/NoteAssumptions
25. http://www.w3.org/2006/WSC/wiki/NoteDesignPrinciples
26. http://www.w3.org/2007/01/31-wsc-irc
27. http://www.w3.org/Member/Eventscal
28. http://www.w3.org/2007/01/31-wsc-irc
29. http://www.w3.org/2007/01/31-wsc-irc
30. http://www.w3.org/2006/WSC/drafts/note/
31. http://www.w3.org/2006/WSC/drafts/note/Overview.html#use-cases
32. http://www.w3.org/2007/01/31-wsc-irc
33. http://www.w3.org/2006/WSC/wsc-use-cases/
34. http://www.w3.org/2007/01/31-wsc-irc
35. http://accesd.secure-desjardins.com/fr/
36. https://accesd.desjardins.com/fr/
37. http://www.w3.org/2007/01/31-wsc-irc
38. http://www.w3.org/2007/01/31-wsc-irc
39. http://www.w3.org/2007/01/31-wsc-irc
40. http://www.w3.org/2007/01/31-wsc-irc
41. https://bugzilla.mozilla.org/show_bug.cgi?id=330884
42. http://www.w3.org/2007/01/31-wsc-irc
43. http://www.w3.org/2007/01/31-wsc-irc
44. http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
45. http://dev.w3.org/cvsweb/2002/scribe/
Received on Thursday, 15 February 2007 11:14:07 UTC