- From: Thomas Roessler <tlr@w3.org>
- Date: Mon, 18 Jun 2007 00:12:34 +0200
- To: WSC WG <public-wsc-wg@w3.org>
Minutes from our face-to-face on 31 May have been approved and are
available online:
http://www.w3.org/2007/05/31-wsc-minutes
Regards,
--
Thomas Roessler, W3C <tlr@w3.org>
[1]W3C
WSC WG face-to-face
31 May 2007
[2]Agenda
See also: [3]IRC log
Attendees
Present (in order of registration)
Thomas Roessler
Mary Ellen Zurko
Daniel Schutzer
Johnathan Nightingale
Phillip Hallam-Baker
Hal Lockhart (by phone)
Mike Beltzner
Shawn Duffy
Tyler Close
Serge Egelman
Maritza Johnson
Luis Barriga
Robert B. Yonaitis
Audian Paxson
Stephen Farrell
Tim Hahn
Stuart Schechter (by phone)
Rachna Dhamija
George Staikos (by phone)
Bill Doyle
Yngve Pettersen
Regrets
Chair
Mez
Scribe
PHB, beltzner, rachna, tlr
Contents
* [4]Topics
1. [5]agenda bashing
2. [6]Next meetings
3. [7]Note review
4. [8]Discussion of initial draft for rec-track deliverable
5. [9]Site-identifying images in Chrome
6. [10]safe browsing mode
7. [11]brainstorming
8. [12]next steps
* [13]Summary of Action Items
__________________________________________________________________
<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> [14]http://www.w3.org/2006/WSC/track/issues/open
<Mez_> [15]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
[16]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_>
[17]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
[18]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_> [19]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 [20]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
[21]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> [22]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:
[23]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:
[24]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
[25]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
[26]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
[27]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_>
[28]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
[29]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
([30]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__> [31]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:
[32]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
[33]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
[34]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
[35]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
[36]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
[37]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:
[38]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
[39]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> [40]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
[41]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
[42]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:
[43]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 [44]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
[45]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!
[46]http://news.yahoo.com/s/ap/20070531/ap_on_hi_te/spam_arrest_10
Summary of Action Items
ACTION-241 - Look at better issue tracking for rec-track documents [on
Thomas Roessler - due 2007-06-07].
ACTION-242 - add file extension remark to security context information
list [on Stephen Farrell - due 2007-06-01].
ACTION-243 - Propose link from note to threat trees [on Mary Ellen
Zurko - due 2007-06-07].
ACTION-244 - Arrange for future thread tree discussion [on Mary Ellen
Zurko - due 2007-06-07].
ACTION-245 - Draft conformance section [on Thomas Roessler - due
2007-06-07].
ACTION-246 - Draft introduction text [on Tim Hahn - due 2007-06-07].
ACTION-247 - Mark in wiki what proposals have been transferred into the
note [on Shawn Duffy - due 2007-06-07].
ACTION-260 - Write up non-indication cert attribute [on Phillip
Hallam-Baker - due 2007-06-14]
ACTION-248 - Ensure that the robustness stuff (MozillaCurrentPractises)
ends up in the recommendations [on Johnathan Nightingale - due
2007-06-07].
ACTION-249 - Propose revision of 2.3 in line with updated template,
current discussion [on Thomas Roessler - due 2007-06-07].
ACTION-250 - Propose breaking out section 2.4 into its own
recommendation [on Stephen Farrell - due 2007-06-07].
ACTION-251 - Update the recommendation template to include
justification for goals [on Tyler Close - due 2007-06-07].
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].
ACTION-253 - Write up a proposed recommendation about browser lock down
mode (eg: no script, etc) [on Tim Hahn - due 2007-06-07].
ACTION-254 - revise sbm proposal [on Daniel Schutzer - due 2007-06-15].
ACTION-255 - Email beltzner photo of whiteboard [on Tim Hahn - due
2007-06-07].
ACTION-256 - Summarize and bring back issues to working group [on Mike
Beltzner - due 2007-06-07].
[End of minutes]
__________________________________________________________________
Minutes formatted by David Booth's [47]scribe.perl version 1.128
([48]CVS log)
$Date: 2007/06/17 22:03:44 $
References
1. http://www.w3.org/
2. http://lists.w3.org/Archives/Public/public-wsc-wg/2007May/0158.html
3. http://www.w3.org/2007/05/31-wsc-irc
4. http://www.w3.org/2007/05/31-wsc-minutes#agenda
5. http://www.w3.org/2007/05/31-wsc-minutes#item01
6. http://www.w3.org/2007/05/31-wsc-minutes#Next
7. http://www.w3.org/2007/05/31-wsc-minutes#Note
8. http://www.w3.org/2007/05/31-wsc-minutes#Discussion
9. http://www.w3.org/2007/05/31-wsc-minutes#Site
10. http://www.w3.org/2007/05/31-wsc-minutes#item02
11. http://www.w3.org/2007/05/31-wsc-minutes#item03
12. http://www.w3.org/2007/05/31-wsc-minutes#item04
13. http://www.w3.org/2007/05/31-wsc-minutes#ActionSummary
14. http://www.w3.org/2006/WSC/track/issues/open
15. http://www.w3.org/2006/WSC/Group/track/issues/open
16. http://www.w3.org/2007/05/31-wsc-minutes.html#action02
17. http://lists.w3.org/Archives/Public/public-wsc-wg/2007Apr/0324.html
18. http://www.w3.org/2007/05/31-wsc-minutes.html#action04
19. http://www.w3.org/2006/WSC/wiki/ThreatTrees
20. http://www.w3.org/2007/05/31-wsc-minutes.html#action05
21. http://www.w3.org/2007/05/31-wsc-minutes.html#action06
22. http://www.w3.org/2006/WSC/drafts/rec/
23. http://www.w3.org/2006/WSC/drafts/rec/
24. http://lists.w3.org/Archives/Public/public-wsc-wg/2007May/0179.html
25. http://www.w3.org/2007/05/31-wsc-minutes.html#action07
26. http://www.w3.org/2007/05/31-wsc-minutes.html#action08
27. http://www.w3.org/2007/05/31-wsc-minutes.html#action09
28. http://www.w3.org/2006/WSC/wiki/RecommendationDisplayProposals
29. http://www.w3.org/2007/05/31-wsc-minutes.html#action10
30. http://www.w3.org/2006/WSC/drafts/rec/#favicon)
31. http://www.w3.org/2006/WSC/wiki/Glossary
32. https://addons.mozilla.org/en-US/firefox/addon/4014
33. http://www.w3.org/2007/05/31-wsc-minutes.html#action12
34. http://www.w3.org/2007/05/31-wsc-minutes.html#action13
35. http://www.w3.org/2007/05/31-wsc-minutes.html#action16
36. http://www.w3.org/2007/05/31-wsc-minutes.html#action17
37. http://www.w3.org/2007/05/31-wsc-minutes.html#action18
38. http://www.w3.org/2006/WSC/drafts/rec/#safebrowsing
39. http://www.w3.org/2007/05/31-wsc-minutes.html#action20
40. http://www.w3.org/blog/powder
41. http://www.w3.org/2007/05/31-wsc-minutes.html#action21
42. http://www.ljean.com/NetTrust/
43. http://www.cc.gatech.edu/fce/ecl/projects/acumen/
44. http://www.w3.org/2007/05/31-wsc-minutes.html#action22
45. http://www.w3.org/2007/05/31-wsc-minutes.html#action23
46. http://news.yahoo.com/s/ap/20070531/ap_on_hi_te/spam_arrest_10
47. http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
48. http://dev.w3.org/cvsweb/2002/scribe/
Received on Sunday, 17 June 2007 22:12:49 UTC