WSC WG face-to-face
31 May 2007

<tlr> ScribeNick: PHB

<tlr> Date: 2007-05-31

MEZ: Most of today to be discussion of Shawn's draft of proposals

agenda bashing

MEZ: realtime review and change o' structure, wrapu timeline nextsteps by 5:30

<sduffy> ;-)

Next meetings

Mez: First next sequence of face to faces
... Questionaire free times, would be good to squeez in an extra f2f ...
... befor the tech plenary ...
... date had fewest people could not make Oct 2nd and 3rd, Austin Texas ...
... Tony Nadalin has confirmed goodness of the date ...
... F2F after is Nov in Cambridge, 5,6 Nov ...

Thomas: 2008 dates ...
... plan in advance cancelling is easier than arranging ...
... WWW2008 is april22-25 (moved to avoid Olympics ...
... to put out questionaire with dates ...
... Think about hosting ...

Note review

Mez: Issues

(Tyler takes the projection cord)

(wait for projector to warm up)

Issues from reading note coded as issues

<tjh> http://www.w3.org/2006/WSC/track/issues/open

<Mez_> http://www.w3.org/2006/WSC/Group/track/issues/open

Mez: are folk ok with way issues are going?
... aiming for last call in june ...

TLR anyone seen comments from Bruno

(Brunos flight cancelled due to strike)

TLR: any issues we have not settled

MEZ: yes all the ones that are not closed!
... external issues require additional layer of process, give pointers to issues created ...

TLR: if there is an edit it is polite to tell folk

MEZ: some people submitt a lot of issues, may not be settled at same time, overhead
... (discussion of tools we would like to exist) ...

tlr: some folk have been using bugzilla successfully for external comments

<tlr> ACTION: thomas to look at better issue tracking for rec-track documents [recorded in http://www.w3.org/2007/05/31-wsc-minutes.html#action02]

<trackbot> Created ACTION-241 - Look at better issue tracking for rec-track documents [on Thomas Roessler - due 2007-06-07].

Tyler: add threat trees to note, take list of attacks Rachna presented...

TLR: list of security contexts is a moving target, is it useful to subject it to process or just leave as a wiki page

MEZ: everyone agrees useful in the note

TLR: amount of work neded to make it available in note is concern

Tyler: if someone brings up issue that depends on something that is not in the list that is an important result

Stephen: can see it is very hard to know it is complete

MEZ: point is that this is everything we know about

Tyler: if it is important on not on this list you need to tell us

Stephen: for ecxample the file extension from the mime encoding.

?? yes really good , add it

stephen: informal nature of the list is striking

phill suggests using a mindmap

Mez feels we should do what we are doing

TLR: zoom in on section 7

Stephen: may change

MEZ: issue is not closed

<Mez_> the proposed change for exhaustive is still part of issue 20

<Mez_> http://lists.w3.org/Archives/Public/public-wsc-wg/2007Apr/0324.html

<scribe> Rachna, why do we say the list is exhaustve?

PHB: may need more explanation, stating the mime type is there does not necessarily bring across the implication of the mime type extension definition

TLR: list is most important as an internal tool

Dan: more complete the list is the more information giving to people reading the note, ...
... allow people reading note to inform their comments ...
... can excise later on ...

tyler thomas challenged me by saying is this in scope for this group ...
... mime filetype extension thing, if the browser is told to save a gif as an exe, ...
... that bad need a proposal, claim that the list is exhaustive is 'perfect'

MEZ: list helps reduce number of comments by making comments of form 'did you think about this' unnecessary

Stephen: do not like exhaustive should state that it is a list of things we thought about

<tlr> tyler, your case about .exe is actually covered by use case 16, and some others

<tlr> grep for "software installation"

Mez: time for a proposal

Thomas:Sending e-mail to list right away with proposed wording for introduction to list; no action needed.

<tlr> ACTION: farrell to add file extension remark to security context information list - due 2007-06-01 [recorded in http://www.w3.org/2007/05/31-wsc-minutes.html#action04]

<trackbot> Created ACTION-242 - add file extension remark to security context information list [on Stephen Farrell - due 2007-06-01].

<Mez_> http://www.w3.org/2006/WSC/wiki/ThreatTrees

[fragmentary conversation; turning toward threat trees]

Rachna: easier to state a vulnerability

Stephen: some databases online

Rachna somethin more formal?

Stephen: NIST?

Bill 'MITRE'

Mez surf to common Vunerabilities and Exposres

Thomas: still think threat trees useful, and to publish ...
... is it useful to get them in publishable form in time for last call ...
... should we take threat trees out of critical path for the use cases note ...
... useful analyticl material for analysing ...
... can issue multiple notes ...

PHB: CVE is very specific, describes attcks not high level taxonomy we need

Bill-d: a lot of stuff here is out o scope, if the threat is a GUI exploit its not our business

Mez: is consensus to tur threat tree into something we can all share and enjoy
... Stephen agrees with all that ...
... will add that with the threat tree if it is a taxonomy right cannot rule entire branch out of scope ...
... may be some race attack in DNS that is in scope ...

<Mez_> we have concensus that in theory it's a good idea to put something into wsc-usecases that says we're working on threat/attack informatoin, with a url to the wiki area we're working on it.

<Mez_> tlr, please give me an action to propose. tx.

<tlr> ACTION: zurko to propose link from note to threat trees [recorded in http://www.w3.org/2007/05/31-wsc-minutes.html#action05]

<trackbot> Created ACTION-243 - Propose link from note to threat trees [on Mary Ellen Zurko - due 2007-06-07].

<tlr> mez, note you just caught a due date that's next week

Mez: should we put

PHB: are we using terms like risk threat attack as terms or art here or is it loosey goosey?

MEZ: who is gonna lead the threat tree discussion when we put it on the agenda

<tlr> ACTION: zurko to arrange for future thread tree discussion [recorded in http://www.w3.org/2007/05/31-wsc-minutes.html#action06]

<trackbot> Created ACTION-244 - Arrange for future thread tree discussion [on Mary Ellen Zurko - due 2007-06-07].

Mez: wrap us 5 mins early, going pretty good, bill and I will work on procedure, thomas has action to get us a better process so ...
... what we going into next is a discussionof the recomendations ...
... most of us have not had a chance to look over the URL sean sent out ...

sean: I can

<sduffy> http://www.w3.org/2006/WSC/drafts/rec/

MEZ: too early for a break

Thomas: is useful

MEz: take ten

<cafeine and pastries consumed>

Mez: so

Discussion of initial draft for rec-track deliverable

<johnath> repaste, for those following along at home: http://www.w3.org/2006/WSC/drafts/rec/

Shawn: overall structure of what we have got here make sure it makes sense.
... Took proposals using tylers template and put them into the note ...
... proposals to change the template need to be applied ...
... different people used template differently ...

<tlr> who is scribing again?

<beltzner> tyler, I think

<tlr> ScribeNick: tyler

rachna: I like having information about attacks addressed in the proposals
... how should we do this

johnath: I like keeping a separate list of attacks from the use cases

tlr: +1 to adding the threats to the note

rachna: I'll update the template to include attacks

<tlr> attack resistance is in there anyway, so that should cover the attacks

<tlr> current template: http://lists.w3.org/Archives/Public/public-wsc-wg/2007May/0179.html

tyler: Explaining use-cases and threats in tandem is a convenient way of describing a proposal

tlr: I need to add a conformance section to the template

<tlr> ACTION: thomas to draft conformance section [recorded in http://www.w3.org/2007/05/31-wsc-minutes.html#action07]

<trackbot> Created ACTION-245 - Draft conformance section [on Thomas Roessler - due 2007-06-07].

tjh: We need an overview in the rec explaining the template

<tlr> ACTION: hahn to draft introduction text [recorded in http://www.w3.org/2007/05/31-wsc-minutes.html#action08]

<trackbot> Created ACTION-246 - Draft introduction text [on Tim Hahn - due 2007-06-07].

Mez__: Let's move on from the template to the actual proposals

tlr: we need to mark in the wiki which things have been transferred

<tlr> ACTION: shawn to mark in wiki what proposals have been transferred into the note [recorded in http://www.w3.org/2007/05/31-wsc-minutes.html#action09]

<trackbot> Created ACTION-247 - Mark in wiki what proposals have been transferred into the note [on Shawn Duffy - due 2007-06-07].

<sduffy_> http://www.w3.org/2006/WSC/wiki/RecommendationDisplayProposals

yngve: My proposal didn't make the transition from the wiki to the pub

stephenF: I'ld also like to discuss the content of each proposal

tlr: +1 to content discussion, but want to frame it in terms of what each proposal is making conformance requirements about

Mez__: I'm worried we'll miss our schedule if we don't concentrate on the publication issues

tyler: In addition to short term delays we also need to put some effort into avoiding larger scale setbacks
... to the schedule

beltzner: fleshing out the proposals is also useful

tlr: So long as we realize that we might not get a lot of consensus at this stage

sduffy_: Send me updates to your proposals

rachna_: Do we want to set a deadline on finishing these proposals

tlr: How about a mid-June deadline

<tlr> RESOLVED: cut-off for suggestions that get into FPWD due 15 June

<PHB> ACTION PHB to write up non-indication cert attribute

<PHB> ACTION: Hallam-Baker to write up non-indication cert attribute [recorded in http://www.w3.org/2007/05/31-wsc-minutes.html#action10]

<trackbot> Created ACTION-260 - to write up non-indication cert attribute [on Phillip Hallam-Baker - due 2007-06-14]

johnath: If we just get consensus on the template and deadline that's a good outcome

stephenF: I really want to discuss the content

rachna: The content of the Goals section in particular needs discussion since many proposals just list all the Goals

tjh: looking for more details on the proposals

PHP: How about a don't show the padlock icon proposal

<beltzner> ScribeNick: beltzner

Mez__: time to go into the document and discuss the sections

<stephenF> PHB: that needs a new extension/policy OID so gotta go to PKIX first probably?

Site-identifying images in chrome

Mez__: Site-Identifying Images in Chome (http://www.w3.org/2006/WSC/drafts/rec/#favicon)
... any problems discussing this without the proposer in the room?

beltzner: not really, as long as we take notes and give a chance to clarify/respond

rachna_: how does 2.1 support "Document the status quo"?

stephenF: I understand this as an attempt to deal with users being misled by favicons ...
... we need to get data on that, or refer to it btw, ...
... but this is about getting the browser folks to adhere to this; is that possible?

johnath: that's actually being discussed at Mozilla right now ...
... not removing outright, since they're useful for site-identification, but not sharing space with trust indicators

tyler: wonder why we're picking on the favicon when none of the info is reliable ...
... all the location bar elements are chosen by the attacker

johnath: the concern is mixing trust indicators with site controlled elements

tlr: so the key requirement is what johnath said; not mixing trust indicators with user controlled elements

stephenF: does this require good definition of chrome?

<serge> yay, more definitions.

<Audian> what is chrome?

<Mez__> http://www.w3.org/2006/WSC/wiki/Glossary

tyler: want to get johnath to elaborate; do you think that other info would go out of chrome?

johnath: dunno about s2.1, but there are a lot of ideas of interpreting the content and interpreting it in chrome

<rachna_> this proposal assumes that users can distinguish trusted content (chrome) from non-trusted content. Currently, that is not the case. The usability question would then be whether you can train users to make this distinction once this proposal was implemented.

<serge> rachna_: are you saying that we may need to do some user testing? :)

<Zakim> PHB, you wanted to point out that a recomendation should probably be that clients define an area of secure chrome, i.e. push off the primary definition problem to the browser

maritzaj: I don't think that indistinguishability between trusted and untrusted chrome is a concern as much as the advantage of decluttering the chrome

PHB: my feeling is that the rec is mistitled, and it should be that clients need to define areas of "secure chrome" and "content" and maintain them
... it's to the browser vendor to work out how that might look

<Zakim> tlr, you wanted to note that no, this does not need a definition for chrome

PHB: further, user agent / browser / client needs to maintain that space, further don't confuse with non-trusted chrome

<PHB> (and then as Maritzaj requests the favicon issue becomes a comment in that recommendation)

<serge> beltzner: sure, that's an implementation issue. however, before recommending it, we should at the very least have an ideal design in mind that is supported by empirical evidence. if we can't show that our "ideal design" conveys the difference between content and chrome to the user, there's no point recommending this.

tlr:repeats the earlier point he made

serge, huh?

<Zakim> serge, you wanted to point out that there is little reason to believe that users will be able to distinguish "secure chrome" from anything else, or that it won't be easily spoofed.

bill-d: +1 to thomas

<PHB> Further to Thomas, want to make sure we recommend MUST NOT allow even worse than favicons (javascript anyone) in the secure chrome area

<tlr> +1 to PHB

serge: without reason to believe that users can distinguish between secure and non secure chrome, this recommendation seems like it won't be effective

<Zakim> johnath, you wanted to pick up rachna's point

<serge> beltzner: that's exactly my point.

<Zakim> stephenF, you wanted to tend to agree with PHB (with quibbles:-)

tyler: due to the ineffectiveness of passive indicators, it feels like this might be an early candidate for filtering

<scribe> serge, I'm scribing,

<scribe> serge, I'm not actually talking to you ;)

<serge> oh, heh

stephenF: defining "secure content" will be hard

<tlr> Secure area MUST be verifiable --> attention sequences?

<stephenF> +1 to killing proposals that don't work

<stephenF> I dont understand what "verifiable" means

<serge> stephenF: nor will an end user

<Audian> lets make a decision regarding favicons, then continue discussion of secure chrome concept

dan: feels like it's worth mentioning this as a virtuous principle or best practise, in the abstract as tlr suggested

rachna_: tyler asked about killing off proposals, wondering what the criteria for that might be

<Zakim> johnath, you wanted to ask how this broader rec would be specific enough to be actionable

johnath: if we were to change this from favicons to the more general case suggested by tlr, I wonder if we can specify it well enough to be actionable ...
... especially in terms of trying to be compliant ...
... like would back/foward not be compliant? ...
... sounds pretty broad to me.

<Zakim> stephenF, you wanted to say that chrome info comes from DNS, TLS, ...

stephenF: not true that information from chrome comes from browser, it comes from the web as well ...
... talking about secure chrome isn't really right, we just want some part of the display that's "less vulnerable"

<serge> so we're arguing semantics now?

<Zakim> beltzner, you wanted to suggest design proposals vs. best practises vs. recommendations

stephenF: maybe think "less vulnerable" than "secure"

<Mez__> note our charter says something like robust against spoofing attacks

<Mez__> which I take as a form of "less vulnerable"

<tjh> perhaps we're all circling around how to exhibit (in neither a passive nor active manner) the "confidence level" the user agent is able to establish for each piece of information displayed.

<Zakim> PHB, you wanted to point out we want something more broad

beltzner: is our document only to be design proposals, or also best practises and guidelines?

<johnath> I think thomas suggested general principle, with favicon being a specific example in the document, which makes sense to me.

<tyler> I also like the idea of calling out "best practices" that are true across particular proposals. I think we should add an explicit section for them to the document

PHB: it's important to provide both concrete design proposals as well as best practises that don't actually deal with existing problems but ones that people might "work up to with practise"

roby: +1, making everything concrete limits the effects of the work

<scribe> tyler, yeah, definitely a different section

roby: I think most of our proposals should be abstracts

tlr: I want to come back to "what is secure" and "what is controlled by ???" ...
... dealing with information that has semantic content that is interpreted by the browser ...
... yes, it's chosen by an attacker, but the browser can modify it to be more useful/helpful ...

<johnath> locbar2 link, fyi: https://addons.mozilla.org/en-US/firefox/addon/4014

tlr: and this is different than things that the browser just passes through by default ...
... and this rec feels like we want to not mix direct pass-thru with security indicators

<stephenF> "totally under the control of the attacker" depends on your threat model, so isn't fixed

<tjh> it is clear (to me at least) that while computers are binary-friendly, security is not ... so where are our recommendations for exhibiting some continuum/graded levels of confidence/verifed-ness ?

Audian: are we proposing to propose the next "gold lock"? we know that the gold lock has no integrity because it's spoofable, but it was spoofed because it was trusted ...
... are we proposing to do a better version of a gold lock?

<Zakim> beltzner, you wanted to respond to Audian

<stephenF> +1 to tjh (would love to see experiments on that)

beltzner: no
... I don't think that's what 2.1 is about, nor what anyone's proposing

serge: one reason chrome is spoofable is that browsers allow websites to hide chrome

johnath: that's in there in the robustness stuff

<Zakim> tlr, you wanted to ask who writes the "interactive security check" proposal

<scribe> ACTION: johnathan to ensure that the robustness stuff (MozillaCurrentPractises) ends up in the recommendations [recorded in http://www.w3.org/2007/05/31-wsc-minutes.html#action12]

<trackbot> Created ACTION-248 - Ensure that the robustness stuff (MozillaCurrentPractises) ends up in the recommendations [on Johnathan Nightingale - due 2007-06-07].

<Zakim> tlr, you wanted to ask about next step with this one

<tyler> tyler: The "Disruption" section of proposal 2 doesn't match the template.

tlr: am I to take the template from yesterday and merge it with the notes from today and propose it as a change to the document?

<tyler> tyler: the current text of "Disruption" does not address how deploying this proposal would disrupt existing web browsing behaviour

Audian: I think that there should be a change made based on the should/must issues, as well as the generalization

<Zakim> beltzner, you wanted to ask meta point about adding owners of recs in draft so we know

<tlr> ACTION: thomas to propose revision of 2.3 in line with updated template, current discussion [recorded in http://www.w3.org/2007/05/31-wsc-minutes.html#action13]

<trackbot> Created ACTION-249 - Propose revision of 2.3 in line with updated template, current discussion [on Thomas Roessler - due 2007-06-07].

beltzner: 1. how do we change the document based on the feedback from this session?
... 2. can we (at least for the draft) assign owners to the recommendations so we know who is on the hook for clarification and editing downstream changes?
... 3. do we want to seperate best practises from design recommendations and present them using a different template?

stephenF: yes, yes and no, the "no" because it will be hard to structure things until we have a better idea of the content

maritzaj: {{footage not found, can someone supply}}

tlr: I think we should start strong and back down to "should"
... an interesting question will be when we want to "must" an implementation technique

<maritzaj> footage from earlier -- i had imagined best practices would come out of the discussion of documenting the status quo which would have points from research results to support the best practices we recommend based on what does and doesn't work

stephenF: this feels more like a requirements spec where we can use must/should

<scribe> maritzaj, thx

<serge> "must", "should", "would be nice", "if you have the time", "we weren't going to say anything, but now that you bring it up..."

<Zakim> stephenF, you wanted to say that I think 2.3 needs someone to do the abstraction thing

stephenF: does ACTION-249 include ...

tlr: ... yes

sduffy_: clarification of ACTION-249, you mentioned that it might need to be retitled? trying to get a sense of what we're thinking of changing. are we changing it? breaking it out? elevating it?

tlr: not sure I know yet, see my response to the action

<Mez__> stephenf

stephenF: I think 2.4 is its own section

<scribe> ACTION: stephen to propose breaking out section 2.4 into its own recommendation [recorded in http://www.w3.org/2007/05/31-wsc-minutes.html#action16]

<trackbot> Created ACTION-250 - Propose breaking out section 2.4 into its own recommendation [on Stephen Farrell - due 2007-06-07].

<stephenF> "cert info belongs in trusted area" for self-signed as well?

bill-d: if you expand 2.3 I think 2.4 folds into it

tjh: there may be other aspects of certificates that might want to be displayed, and that doesn't seem to fit with 2.3 and the rest of 2 as currently worded

<stephenF> server-cert is just one of the outputs from TLS to the browser

PHB: I would distinguish based on accountability; self-signed certs aren't accountable ...
... EV is one process to create accountability ...

Audian: I think 2.3 is about removing and 2.4 is about adding, don't see how they belong in the same section

bill-d: because they're all trust indicators, they might indeed be related in a recommendation

<Zakim> beltzner, you wanted to say this might be moot depending on tlr's action

tyler: I think that each proposal needs to justify the list of goals and claims as to how it achieves them

<serge> maybe we need to actually test them...

<Mez__> which one should we test first?

<Zakim> tlr, you wanted to suggest that there's also EV and Secure Internet Letterhead

<scribe> ACTION: tyler to update the recommendation template to include justification for goals [recorded in http://www.w3.org/2007/05/31-wsc-minutes.html#action17]

<trackbot> Created ACTION-251 - Update the recommendation template to include justification for goals [on Tyler Close - due 2007-06-07].

<serge> Mez__: whichever one we've hashed out the most and is unlikely to drastically change on a whim

<Mez__> can you take a stab in the current crop?

<serge> possibly.

<serge> I guess I can create an action item to map out a few study proposals

<serge> not sure if we already have one for that?

<Mez__> I would love that

<scribe> ACTION: serge to map out some study proposals for existing recommendations, co-ordinate with Rachna who owns usability testing plan in general [recorded in http://www.w3.org/2007/05/31-wsc-minutes.html#action18]

<trackbot> Created ACTION-252 - Map out some study proposals for existing recommendations, co-ordinate with Rachna who owns usability testing plan in general [on Serge Egelman - due 2007-06-07].

Mez__: lots of actions, not sure that all of it is at the editorial level

<Audian> was TLR's recommendation to merge 2.4 and 7.0?

<tlr> ScribeNick: rachna

dan: discussing safe browsing mode section 4

safe browsing mode

dan: SBM addresses need for user to be at trusted website usecases
... browser should have a mode where only know trusted websites can be accessed

stephen: can place browser in a state (e.g., "lock down mode") where users can visit any site and be safe

tyler: is disabling features part of the proposal?

<johnath> linkydo: http://www.w3.org/2006/WSC/drafts/rec/#safebrowsing

dan: can use community judgments (e.g. FI, automotive companies, healthcare providers) to determine list of trusted sites
... has to be voluntary with incentives

dan: 4 components to proposal: UI, TLD, technical countermeasures, and ?

<beltzner> rules and regulations

<serge> if the cues aren't visual or audio, what exactly are they? tactile? scented?

<tlr> tactile, when using a braille line, e.g.

<beltzner> he didn't say "not audio or visual" just "not audio and visual cues alone"

<Mez__> smellovision replaces telovision

dan: does not rely on visual cues, checking is performed automatically by browser, user can verify they are in safe mode, user must take action to get into safe mode

<beltzner> play fair, everyone!

<serge> he said "does not rely on"

dan: degree of security can vary depending on the safe mode you are in (FI safe mode might be more stringent)

serge: functionally, how is this different from secure chrome proposals?

dan: user has to take a conscious act, like cardspace, have to do something active

serge: why do you assume users will take the required action?

dan: FIs may be able to educate users to take the action, through education, training and incentives, this might be effective
... or disincentives (e.g. charge people who don't use it)

serge: why would this be more effective than other education (e.g."look at the URL")

<Audian> debate debate debate

dan: this is for the security conscious users, URL bars are spoofable

mez: is this a place for usability testing

dan: yes

Mez: we need to flesh out that this is a place for usability testing in the editor's comments

bill: is the vetting process new, or do they use existing protocols?

dan: could depend on existing protocols, e.g. EV or IP addresses

bill: this is how Safe Mode and the other mode is different, once you go beyond what is known (known whitelist), you can not protect that environment

dan: in agreement. it has to be a known whitelist

serge: we have three modes?

<stephenF> I disagree with that agreement

dan: other communities can add their own whitelist, so it is extensible

<Zakim> beltzner, you wanted to talk about tweaking this proposal to be more like cardspace

beltzner: is the purpose of the proposal a concrete design proposal, or a general description of other things that achieve the same effect (e.g. cardspace)

dan: it can describe other proposals, but the FI community needs an open proposal (not restricted to OS or browser types)

beltzner: should tweak proposal to describe new login ritual rather than user activating safe mode

tim: whitelists are fragile, become out of date
... I would rather see a proposal like this refer to something that is addressable or contactable, I was expecting this proposal to address how users who are not security professionals could be advised by someone they trust (e.g. I trust Jonathan to set my 7000 dimension browser configuration)

dan: (describes slide on multiple technical countermeasures). I agree. People should not have to be aware of complex settings

stephen: we want a macro language to describe settings, whitelists, etc. we might not be able to have a language, but we could have abstractions that browser manufactures can turn into settings
... can distribrute settings now (e.g. settings for FIs or IBM), the user could have named modes of operation.

phb: MS is trying to narrow the perimeter for what their safe mode is for. limiting the secure part to just the acquistition of credentials makes sense to me
... rather than having secure mode in which I could hand over my cc#, we should have a system where we don't give away cc# ala cardspace.

dan: proposal concepts: whitelist, strong credentials and active user actions, rules and regulations
... (jump to rules and regulations slide) sites must pass legal requirements, must agree to security measures, must pass audit, agree to legal agreements, get verified by official enitity (e.g. ABA, SEC)

<Zakim> johnath, you wanted to reply to the idea of browser-that-is-safe mode

jonathan: I really like Tim's idea. There is a Firefox add on, noscript. We should write this up as a candidate proposal different than Dan's. Dan's proposal only lets you go to safe sites. If you pass the whitelist, you don't need the other stuff we have been discussing. tim should write this up as a proposal.
... these things should be independent, not wedded together in our recommendations

dan: agrees. might want to incorporate it as a feature in my proposal, but it would be good to have as a separate proposal.

<beltzner> ACTION: tim to write up a proposed recommendation about browser lock down mode (eg: no script, etc) [recorded in http://www.w3.org/2007/05/31-wsc-minutes.html#action20]

<trackbot> Created ACTION-253 - Write up a proposed recommendation about browser lock down mode (eg: no script, etc) [on Tim Hahn - due 2007-06-07].

bill: support splitting up proposals. safe mode and "pretty safe" mode.

shawn: question about modes that allow fun (sites on whitelist?). As these sites develop or change, will they require being reaudited?

dan: FIs do that anyway. BOFA is required to be audited on a regular basis.

shawn: we are telling users these sites are fine, but if an attacker can take advantage of vulnerabilities (e.g. cross site scripting). can audits catch these vulnerabilities?
... this creates a big hurdle for websites to be audited everytime they make a change

<Zakim> stephenF, you wanted to argue against separating em

dan: FDIC might impose a bigger hurdle, but merchants might not be required to go through same hoops

stephen: don't buy that sites on whitelist are safe, because site might be compromised

<Mez__> community mode

dan: I agree. the best I can think of is that there should be a community hierarchy to separate FI sites from sports sites. Thinks Tim should write up proposal, but doesn't think two proposals can be separated.

<Mez__> vetted mode

shawn: how is this different than top level domains on steroids?

<serge> I think this reiterates my point that we should just recommend getting rid of the Internet.

dan: (jumps to TLD slide) TLDs could provide control of issuance process, easy customer recognition, could be controlled by FIs.
... problems- time to establish, ICANN approval, costs to maintain, global scaling, need for FI certification process
... we are considering TLD as another technical countermeasure like we are considering DNSSec
... we want to start with widely deployed countermeasures and then add other measures

thomas: I have TLD allergy. I worry from architectural point of view. TLDs look attractive, but you are getting into administrative process and technical and architectural concerns. you might want to rephrase proposal not to rely on machines readingTLD

tlr: all of these countermeasures, except whitelist, might be generalizable. seems to mix countermeasure and attacks. might mix useful proposals with more speculative ones

dan: I want to demonstrably say that within my community "I am not going to my bank unless they are demonstrating EV, etc". rules and regulations piece- you can't say I am a .bank without satisfying egal requirements

tlr: you should abstract away from one particular industry. this is like a common criteria like way to describe web security. there is a technical piece and process piece.

dan: different logotypes (e.g. health vs finance) will go to different lengths

stephen: this must scale outside of single geography or industry without a single central authority. chinese shoe manufactures should be able to do this along with US FIs.

dan: other communities would be able to do it. e.g the chinese shoemakers might want to have different guarantees.
... we are already talking to non-US banks. it is federated- the hogwards shoemakers would need to figure out how to create rules and regulations to create whitelist

stephen: do chinese shoemakers have to talk to $favoriteBroserMaker? If so, it doesn't scale.

beltzner: use EV or something not whitelist based to make it scalable

phb: we can make use of community logo or community slot in EV. you want the ability for an entity like BBB to come along- there has to be some body to determine criteria.

dan: the strength of the guarantees depends on vetting process. should never see a shoe logo and get to my bank.

stephen: a "single list to rule them all" will not work. a requirement of the proposal must be the ability to scale and not rely on one central authority

dan: shoe people decide how they want to police their logo, the reputation of shoe logo might be different with different vetting. or might use BBB like organization to vet merchants.

beltzner: any other comments on this proposal? I would suggest that we not hinge this proposal on whitelist.

dan: if not whitelist, then how?

beltzner: whitelists don't scale.

bill: could be combined with EV.

stephen: could be online list.

phb: could be a consumer chosen list (e.g., visa or mastercard).

<PHB> Should we maybe consider some sort of coordination / co-meeting with cabforum at some point?

<Mez_> People in both groups would know best, and you're one of them

<Mez_> should we discuss that at some point, to see what might be the agenda/goal/whatever?

dan: if user wants to ensure they are at a particular bank, user should be able to put themselves in safe mode, so when they are in it they know they can only be at the legitimate site.

beltzner: EV based is not a whitelist.

dan: EV is not a whitelist you can download, but there is a process by which you get the logo.

<tlr> more specifically, there is a notional whitelist somewhere in the background if you can get a specific community logo

dan: (repeating action items) 1) include login ritual. there is something the site can do to prompt user to take action

<tlr> POWDER does content annotations

<tlr> http://www.w3.org/blog/powder

dan: 2) automatically go to selection?
... 3) rephrase whitelist terminology, make extensible
... 4) make TLD and DNSSec potential future enhancements, rather than critical requirements initially

thomas: be clear about requirements (must, should, may) in terms of what this group could endorse

<tlr> ACTION: schutzer to revise sbm proposal - due 2007-06-15 [recorded in http://www.w3.org/2007/05/31-wsc-minutes.html#action21]

<trackbot> Created ACTION-254 - revise sbm proposal [on Daniel Schutzer - due 2007-06-15].

tlr: planning to update template in wiki

brainstorming

beltzner: documenting outcome will be critical
... no signals of safety ever?
... only signals of danger ...
... don't see upside to spoofing signal of danger ...
... also, don't visibly indicate encryption ...
... encryption without identity doesn't make sense ...

johnath: no padlock, no green bar, but larry?

stephenF: what's the danger indicator for the current default, just http?
... not encryption ...

rachna: we do that today with the browser warning messages

stephenF: danger only is state of current warnings

mez: wisdom of the crowds
... number of heads / entities / whatever ...
... maybe scoped ...
... folks who have been there ...

johnath: peer group in facebook
... reseller ratings ...
... BBB online ...
... would like to see that visualized ...

rachna: nettrust by Jean Camp, should be in SharedBookmarks

serge: there's a couple of papers like that

tjh: riskometer

general brawl about threat level

http://www.ljean.com/NetTrust/

beltzner: "site might be dangerous" applies to 90% of the web

stephenF: "it's the same as last time"

DanS: MITM attacks?

stephenF: assume it's stuff without strong security requirements

plh: video cameras -- "we want an SSL cert for a video camera"

tlr: self-signed certs, wifi routers

mez: testing populations?

johnath: what are user demographics?

rachna: Firefox user population?

beltzner: ...

stephenF: software calling home?

<serge> here's what I was looking for: http://www.cc.gatech.edu/fce/ecl/projects/acumen/

mez: integrate with dkim

<hal> I would like to know what % of users are "new" and is it changing?

mez: <explains dkim>

<tlr> staikos, we're in open-spacy brain storm mode

<tlr> bridge is on

<staikos> what is the # again?

<Mez> same one as always

serge, rachnayou can get past hotmail and yahoo filters using dkim

phb: hotmail doing dkim?! cool!

stephen: if you're doing real signatures, it's perfect, you're acocuntable. It's not even funny, it's what it's for.

beltzner: treat links from webmail / external apps as suspicious

<staikos> has anyone talked about annotating urls with security information?

<staikos> basically extending them

<tlr> staikos, nope

<staikos> we kind of touched on this a while ago

<Mez> you mean links, right?

<staikos> but it might be really useful to persue this. it covers the case where different applications interface

<Mez> yes

staikos: come back to something that was pitched very early. Interface betw applications?
... webmail or IM client providing URI ...
... sent to web browser ..
... currently same as if typed ...
... browser can't tell difference ...

<serge> actually, I set up SPF at the same time, so that could be contributing as well

staikos: send context info along?

<serge> I'm pretty sure MS does SPF

staikos: make browser go into different mode when it hits that kind of URI

beltzner: ... disable form with login button?
... do we care about cases in which users don't actively submit information?

??: malware?

<staikos> I can't get a word in but wanted to point out specifically: "html5 also has sockets, storage, and other crap we want disabled in these cases"

serge: issue with disabling login form idea

<staikos> all forms

serge: how do you identify it? ...
... what %age of pages has forms?

<staikos> but not from the form view

serge: there's usually a search box ...

<staikos> you disable sending variables via GET/POST

<tlr> staikos, that's non-trivial

<staikos> and perhaps something to prevent path-url things

<staikos> how?

<tlr> staikos, you want to use form controls as the lever, not variable

tyler: turn off form-filler assistance?

??: flash, xhr, ...

tyler: in the note we come down pretty hard on existing chrome
... chrome/content difference, all the stuff from the attacker ...
... can we just give up on the current chrome ...
... users don't expect it to have security significance ...
... new area on the screen ...
... diifferent function ...
... that does satisfy security goals that we have ...
... whacky idea is "let the existing chrome be what it has become, fix differently" ...

johnath: If signs of danger, spoofing issue becomes less exciting

rachna: wrong
... you can spoof the "not unsafe" mode ...

johnath: you can spoof the thing ...
... doesn't make sense ...
... you can forge normal chrome ...
... if there are negative warning signals ...

rachna: well, that works because you block the page

johnath: you can do whatever inside
... outer chrome commenting ...
... would make noise if there's reason to suspect danger ....
... assuming it knows to make noise

rahcna: ... and makes noise

stephenF: How do you not warn users in terms of danger
... what's the algorithm to detect "not dangerous" ...

johnath: reserved area?

tyler: forget chrome
... look at other ways of communicating security information ...
... have studied shoehorning security info into way the form filler behaves ...
... modify page content, browser behavior ...

beltzner: can we intercept folks when they do dangerous things?

<staikos> beltzner, we could also prevent SSL indicators from giving positives if we had the context info from the (ex, IM) application

beltzner: task focus, intercept at locus of task ...

stephenF: move security prefs from one browser to another one

phb: new remote for the home. You plug it into the web, download all the stuff. Reason for relevance ...
... say wandering around the country, deciding whether to pay my bills, might want to do that on this web browser ...
... keep security context in synch, when editing the one context, have a secure link to phone context ...
... lock the two together ...

stephenF: additional binding to SSL?
... bind a one-way password to SSL session via EKE; patent expires in two years ...

rachna: SRP

stephenF: That patent lives longer

tyler: keep record of whom you gave credit card number to?

<staikos> I would love that - then I could more convincingly steal peoples' idenities :)

phb: secure mode and login mode separated?
... fix the form ...

<staikos> I would only shop at the appropriate locations with their card

<hal> leaving temporarily to chair another call

tlr: past decisions
... is there more than just revisiting them?
... also, think of heuristics to detect whether somebody clicked through or not

stephenF: I want to repudiate

tjh: keeping history information synchronized betw diff browsers
... if I have one set of history in my large real estate browser, want to synch with the existing browser ...

s/staikos, discussion is continuing; we'll dial in as soon as you want us to//

johnath: we're only keeping limited history, and stuff that relies on past behavior gets better the more we have
... anybody want to recommend how much we should keep?

dan: 30 days?

rachna: what does it really mean?

audian: forever

beltzner: use lots of crypto

phb: control on the part of the user, but also on the part of the site
... there might be embarrassing stuff ...
... it could say "this is embarrassing, maybe you shouldn't be storing this in the history" ...
... think of the history scrubbing adverts on a porn site ...
... nohistory meta tag?

shawn: safari has a mode like that

johnath: so has firefox

beltzner: web site to say "don't remember me"?

phb: sites that provide that kind of info ...

beltzner: as service for user
... user can get along without modal information ...

johnath: it's another tangent
... user controlled thing isn't recommended ...
... if somebody thinks it should go in here ...
... not sure it actually fits ...
...

phb: tor gives people false sense of security

doyle: if you just do negative security, phishing sites will override?

beltzner: overlay content with indicator of insecurity

serge: do that to every site without a cert?

beltzner: here's a heuristic ...
... site where you've never entered credit card number, direct through search? ...

tlr: danger signals vs. classical network-level attacks?

stephenF: only positive signs?
... some of the most silly things are signals of danger ...

tjh: sth I'd like to see relates somewhat to what Tyler said about Chrome ...
... would like recommendations on display of security indicators in absence of chrome ...
... applies to other interactions ...
... by user agents, and that expands user agent meaning heavily ...

tlr: forms that submit elsewhere? "where am I" magic key stroke?

stephenF: would like to be able to learn that a particular xpath expression embedded in HTML is bad

johnath: fingerprinting?
... nastiness coming across ...
... dangeorus dynamic content ...

tlr: rate limiting on user interactions?

johnath: there's an ascii dungeon, you go trough by keyboard, ack a software installation

tlr: give people trust over code-triggered interactions again
... think pop-under windows ...

tyler: no dialogue boxes, ever

rachna: people don't read them anyway

yngve: if there's no dialog box, then it means that we need to make the decision

tjh: automobiles don't have dialog boxes either
... but you can still configure things ...
...

beltzner: easy understanding of what danger is in a car
... level of confidence? ...
... overall indicator ...
... present to users in more familiar way than "unencrypted" etc ...

bill-d: padlock means a number of things, break that out

stephenF: Describe the stuff in a standard language, write my own policy

yngve: beepers in cars are interesting

bill-d: don't interrupt you

beltzner: cars require users to drive them responsibly

stephenF: disagree

rachna: laws do. You can drive irresponsibly.

beltzner: You take the repsonsibility, right.
... as a browser manufacturer, I'm the one who is required to have responsibility for the user, and it's my fault ...
... Why is that more so than a car? ...

<tlr> unsafe at any web site? ;-)

beltzner: lots of uis try to do everything for the user, responsibility for trust decision delegated to the browser ...
... trains users to assume that things are rosy unless browser makes statement that things aren't rosy ...
... we just don't give people the right information ...
...
... prevent users from doing bad things, instead tell them?

stephenF: That analogy doesn't lead to useful conclusion.

bill-d: what's the choice?

johnath: firefox 2 and SSL handling?

phb: Just don't tell the user about SSL?

johnath: That's a way to do it without dialogues.
... is one mode significantly safer than another one? ...

tlr: frequent case is that people have typed in a URI

<hal> thank you

serge: if programmers can't make decision, users can't either

tyler: specific area to enter stuff that can be remembered

johnatn: Opera's magic wand is rather nice
... notion of dialogue boxes is an issue ...
...

tyler: what are the next steps?

mez: futures and +1s in the Wiki.
... for stuff out of scope or otherwise whacky ...

beltzner: I hope we're exploring all the edges

-- discussion about a bunch of heuristics ---

<Audian> i want a hole in the center of my credit card so that I can place it in my disk drive when I need to make a transaction. Let the CC transmit (encripted) all the necessary data

yngve: IE7 isn't doing Basic Auth on HTTP (sans s) any more
... not sure about proxy auth ...

stephenF: ntlm?

yngve: still in use
... but it's constant trouble ...
...

stephenF: password rules in the browser?

johnath: there are rules about building passwords

yngve: thought about that as well

dan: what's the advantage?

johnath: we can generate strong passwords

tlr: sxipper does that, has interesting failure modes

stephenF: rules for password generation?

audian: fingerprint readeR?

tlr: two different properties, warning function and using actual biometrics

stephenF: local biometrics is acceptable
... US govt having that enormous fingerprint database is a good reason for not using them for authentication ...

phb: UAE have similar mechanism to US ...
... immigration enforcement ...
...
... fingerprint readers themselves must be guarded ...

-- scribe pauses ---

stephenF: defer trust decisions
... trigger warning dialogues when something actually dangerous happens
... data submission ...

tlr: error conditions?

stephenF: stuff
... cookies, whatever ...
... just don't do it immediately ...

tlr: expanding on that, there's an idea here to limit error messages and conditions to (a) actually risky situations (data submission, not necessarily reading?), and (b) the moment when somebody does things

<beltzner> ACTION: tim to email beltzner photo of whiteboard [recorded in http://www.w3.org/2007/05/31-wsc-minutes.html#action22]

<trackbot> Created ACTION-255 - Email beltzner photo of whiteboard [on Tim Hahn - due 2007-06-07].

<beltzner> ACTION: beltzner to summarize and bring back issues to working group [recorded in http://www.w3.org/2007/05/31-wsc-minutes.html#action23]

<trackbot> Created ACTION-256 - Summarize and bring back issues to working group [on Mike Beltzner - due 2007-06-07].

next steps

mez: run down what we do going forward
... other than our copious action items ...
... expect next couple of agendae to be about getting editor's draft to FPWD
... sequence about proposals, hopefully even more commitments to put stuff into templates ...
... probably also leading to discussion about content ...
... if you think stuff should be done differently, say so ...
... one of the things we didn't do here is to have demos ...
... think seriously about beginning to implement some of the things at the demo level ...
... either fidelity level is fine ...
... start sharing as part of the agenda in October ...

rachna: we can do that online?

audian: I work with engineers daily
... goto meeting

<staikos> heh I guess it's done

tlr: vnc

mez: driving toward demo code and FPWD before or by next face-to-face, FPWD well before that
... and there's other things that need to happen ...
... aob?

tyler: feedback to PIIEditorBar proposal?

people don't seem to have actually read it

tlr: from having looked at it, it might combine a number of useful practices

tyler: think the things need to be together
... because on their own each suffers from various attacks ...
... e.g., petnames alone suffers from "out of sight, out of mind" ..
... but combined with form filler, it's actually interesting ...

-- adjourned ---

<Audian> sweet! http://news.yahoo.com/s/ap/20070531/ap_on_hi_te/spam_arrest_10