See also: IRC log
<tlr> http://www.w3.org/2007/07/11-wsc-minutes
<tlr> RESOLUTION: minutes accepted
tlr: I have 3 substantive agenda items, any
others?
... first, review use cases note
... also would like an update from sduffy
... then self signed certs, then browser lockdown
<tlr> no changes
<tlr> http://www.w3.org/2006/WSC/drafts/wsc-usecases/
tlr: tyler, can you give us a quick update
tyler: I think right now, the ball is in my
court on a number of things
... tlr's note, one or two issues where consensus has been declared, but the
changes haven't been made
... also, some changes tlr suggested in email didn't make it in
<tlr> process part is ISSUE-73
tyler: I was hoping to go through threat trees again, but no time
<tlr> ISSUE-6
tlr: have you had a look at mobile (issue
6)?
... I believe we have 2 proposed additional use cases, and discussion seems
to have slowed
tyler: I don't think I've looked at it yet
<tlr> http://www.w3.org/2006/WSC/Group/track/issues/6
tyler: are they in the most recent emails,
linked from tracker?
... I don't see a declaration of consensus
tlr: we haven't quite declared consensus
... I see from the most recent emails that there is one use case, and one
change to section 10. I'm happy to let this linger, and/or close the decision
today
... any opinions?
<tlr> http://lists.w3.org/Archives/Public/public-wsc-wg/2007Jul/0198.html
luis: from my side, it looks okay
tlr: my suggestion to tyler would be to have a look at clearing up "prior interaction", extract the use case, extract the changes to 10.1.1, make the changes, and put it out for reveiw
tyler: That's possible.
tlr: by what deadline?
tyler: you already built in a deadline of next week
<tlr> ACTION: tyler to extract changes from ISSUE-6, sort out "prior interaction" confusion, if any [recorded in http://www.w3.org/2007/07/18-wsc-minutes.html#action01]
<trackbot> Created ACTION-269 - Extract changes from ISSUE-6, sort out \"prior interaction\" confusion, if any [on Tyler Close - due 2007-07-25].
<tlr> ISSUE-38
<tlr> http://www.w3.org/2006/WSC/Group/track/issues/38
<tlr> http://lists.w3.org/Archives/Public/public-wsc-wg/2007Jun/0120.html
tlr: this issue has a proposal from Jun 15, no traffic since, I think that counts as consensus
<tlr> RESOLUTION: ISSUE-38 closed; text from Mez to be added to draft
tlr: given silence on the phone, I'll record it as closed
<tlr> http://lists.w3.org/Archives/Public/public-wsc-wg/2007Jul/0212.html
tlr: I sent an email with proposed disposition
for 11 issues, but unfortunately we haven't heard from Bruno or Rob, the
originators of these
... the proposal would be to reassign 78 to rec-track documents, and close
the others without change, though with extra notes, in some cases
... I would like to briefly review a couple
... first, 82, shared use, the proposal is to reject this issue since we have
had ample discussion on "shared systems" already, and closed the
discussion
... next, 88, around information architecture, there hasn't been any followup
from Bruno as to what that would mean for the group
... if anyone can recommend meaningful things around this issue, speak up
tyler: before we leave issue 88, the text description is short, but looks similar to language in the note - what's the difference?
tlr: I understand what the note says about
"authoring applications", but not what it means to "recommend use of
information architecture" in any concrete way
... issue 94 has at least 4 subpoints...
<tlr> http://www.w3.org/2006/WSC/Group/track/issues/94
tlr: first - the portability of settings across platforms and technologies - not sure it's in scope
<tlr> http://lists.w3.org/Archives/Public/public-wsc-wg/2007Jul/0100.html
tlr: of the 4 subpoints, some replicate other
issues, and several look out of scope
... worth noting that mez has added some of this material to the
future-proofing/PlusOne section of the wiki
... if anyone has issues with any of the proposed dispositions, speak up
now
... I propose that we resolve to adopt the recommended dispositions
<tlr> RESOLVED: issues dispoed as proposed in http://lists.w3.org/Archives/Public/public-wsc-wg/2007Jul/0212.html
tlr: no objections, resolved
<tlr> ACTION: thomas to implement issue disposal as described in resolution above in minutes [recorded in http://www.w3.org/2007/07/18-wsc-minutes.html#action02]
<trackbot> Created ACTION-270 - Implement issue disposal as described in resolution above in minutes [on Thomas Roessler - due 2007-07-25].
tlr: with that, we are down to significantly fewer issues against the note
<tlr> http://www.w3.org/2006/WSC/drafts/rec/
<tlr> shawn, please speak up
sduffy: all the proposals in template format
are now in teh document
... there are a few that don't quite conform, that have been added anyhow
... there is one that I wasn't sure what to make of - BMA browser recs
... nowhere near template format
<sduffy> http://www.w3.org/2006/WSC/wiki/BmaBrowserRecommendations
sduffy: anyone know the state of that
Chuck: I know what it's about - I think Dan started to incorporate some of it with safe browsing mode
sduffy: Okay, safe browsing has been added
Chuck: the BMA document precedes the work of this group, and anticipates a lot of the issues we are tackling. I don't think it was intended as a recommendation, more as a reference document
sduffy: Okay, I can add that as a reference, but it was in the list of recs, so I wasn't sure how to handle it
<sduffy> http://www.w3.org/2006/WSC/wiki/RecommendationDisplayProposals
sduffy: the ones that still need to be updated are listed in the wiki
<sduffy> http://lists.w3.org/Archives/Public/public-wsc-wg/2007Jun/0064.html
sduffy: the other thing to do is re-arrange the document in accordance with Mez' suggestions
<Zakim> stephenF, you wanted to ask about whether tim H's stuff is in that sbm text
stephenF: the safe browsing mode that Tim H was talking about in dublin - did that get rolled in
<tlr> In the wiki: Browser Lock Down (Added to the Editor's Draft - 20070629)
<sduffy> http://www.w3.org/2006/WSC/wiki/RecommendationDisplayProposals
tlr: Tim H's stuff is called Browser Lockdown, and is a separate rec
stephenF: at some point, someone might say that these things are so similar they should be combined
sduffy: sure, that's possible down the road
tlr: do we have conformance claims for all the
included recommendations
... e.g. EV certificates
sduffy: right, that one is listed as needing update
tlr: are there others like that?
sduffy: there are 4 that aren't conforming to the template as a whole, but they vary in where they don't adhere to the template
tlr: my question was, do we have others (except EV) where conformance specifically is missing
<sduffy> http://www.w3.org/2006/WSC/wiki/RecommendationDisplayProposals
tlr: okay, can you prod the authors of the template-breaking ones via email
sduffy: alright. Quick question - we've had a deadline twice already, to get updated. If they are not updated by this deadline, do we drop them?
tlr: alright, I don't know where RevisitingPastDecisions is lacking, so I don't think we should wait too long, but I think it's worth discussing where they misconform
sduffy: alright, I will call that out in the emails
tlr: and please be clear that if the
recommendation is not updated in time, they won't be included
... we don't have a date for the FPWD
tyler: are we going to do the usability-specialist markup and review before FPWD?
tlr: I don't know Mez' plan
tyler: it seems like we should apply our internal expertise before soliciting public comment
tlr: My opinion is that if there is low hanging
fruit, I think it should be applied, but we don't want to wait for formal
high-quality analysis/research
... hard to talk about it with all four usability experts off the call
tyler: We just risk looking naive, if we don't make meaningful reference to the existing usability work in the field
tlr: As I said, we don't have a solid date for
FPWD anyhow, there will be more work between now and then
... next week is a better week to have this discussion than this week
<tlr> ACTION: shawn to prod authors of CertErr, RecRevisitingPastDecisions, EVCert, Letterhead about template conformance; deadline for answers is either this Friday or next meeting [recorded in http://www.w3.org/2007/07/18-wsc-minutes.html#action03]
<trackbot> Created ACTION-271 - Prod authors of CertErr, RecRevisitingPastDecisions, EVCert, Letterhead about template conformance; deadline for answers is either this Friday or next meeting [on Shawn Duffy - due 2007-07-25].
tlr: I think that's it for the text of the draft so far - anything else?
stephenF: Let's assume we have consensus around
a set of proposals for handling TLS certificates in general
... after that, the question is what to do differently for self-signed
certs
... obviously SS certs come with no guarantees - they are a leap of faith -
how can that happen without confusing the user, and without opening yourself
up to attack
... if you decide that you want to permit it, how do you mitigate the risk
... it's a hard problem, and we don't want to ignore it
<johnathjust to get the conversation rolling ... ... one of the obvious answers ... ... self-signed certs are dead stop ... ... error page ... ... exception: text of the error page could say "if you have good reasons, you can do X to override" ... ... then treat cert as otherwise valid for that domain ... explicitly extend trust ... ... another way of establishing identity ...
tlr: I put myself on the queue to make an
alternative proposal
... stephenF mentions the ssh leap of faith
... that is, when you have your first interaction with a site, you learn the
site/key association, but on subsequent visits, if the cert changes, noise is
made
... if the assumption that "in most cases, your first interaction with a site
is legit" is a valid one, then you're basically safe as long as things don't
change
... and when they do change, you can behave very attack-detected style of
behaviour
<stephenF> I like that first-few-as-if-unsecure idea
tlr: so if there is a downgrade from CA-signed to self-signed, that's an error. But if it is the same certificate presented consistently, we can start to show trust indicators
tjh: I wanted to comment on both proposals
... I don't like the notion of making the user decide, in either of these
modes
... it would seem to me that SS certs are something we have to handle, moreso
than just "don't use them"
<tlr> for the record, the second proposal does not necessarily make the user pick
tjh: maybe just requiring them to retrieve it out of band
<stephenF> -1 for requiring out-of-band
tlr: jumping the queue to say that my proposal doesn't require user choice up front necessarily
stephenF: I don't like the idea of requiring an
out of band interaction
... before you meaningfully improve security, you've already become
unusable
tyler: I also think we need a usable answer, I think they're very useful
<tjh> I was thinking more of allowing some "more knowledgeable person" to have procured/installed the "right" SS-Certs
<tjh> and if not there, no-worky.
tyler: I don't like johnathan's proposal - I have heard the opinion expressed that using SSL shouldn't make things worse than HTTP
<stephenF> +1 for that -1
<tyler> http://www.w3.org/2006/WSC/drafts/rec/#piieditor-conformance-association
tyler: tlr and stephenF both made reference to
the ssh model, where you only get notified when things change
... if you look at the PII editor proposal, there's language around
determining whether "this is the same site I spoke to last time"
... and then the only question is the initial leap of faith
... we need extra care there, since secrets are sometimes passed along in the
first interaction
<stephenF> leap-of-faith here for SSCs means we also need to consider notAfter in the past then and now (just noting that so I don't forget so easily:-)
<tjh> I do like the idea of usage of "is this different than before" (history information) in deciding if this is "ok" or not.
<stephenF> good point to propose "safe" entry points to SSC-secured content
<tlr> -1 to that idea
tyler: this means we should consider the kind of URL we'd allow for leap of faith situations
<tlr> +1 to "thou shall have entry points"
tlr: we have 10 minutes left
stephenF: I think the idea of a safe entry points is a good one
tlr: I'm heavily against proposing heuristics
to gauge "safety" of a url
... my proposal in that case would be to abstract it a little - "have safe
entry points" - don't pass secrets when you have reason
<stephenF> how would I know there's a secret in a URL?
tyler: when site A is linking to site B, it
might expect B to be CA-signed. We need the browser to intervene at runtime
if it turns out that B is less trustworthy
... microsoft does that today, with their anti-phishing reporting, stripping
identifying detail
Chuck: this issue more than others calls out
the fundamental issue with how browsers communicate TLS status
... I think we have to be fairly crisp about indicating to the user the
difference between having an encrypted session, and having an identified
partner
... network appliances use self signed certs all the time, and that's not
going to change, it's important to their operation
<sduffy> 12 pm meeting... gotta run... I'll prod the authors of the 4 non-templatified proposals
Chuck: I know it's hard, but it seems like what's needed is a mechanism for pushing certs out to user agents
<stephenF> trust anchor mgmt anyone?
<Zakim> stephenF, you wanted to more-or-less agree with tlr on leap-of-faith and to ask if its really ok to propose that the browser store all certs it sees forever
tlr: cutting chuck off because stephenF has an answer to the current point
stephenF: trust anchor management is something
that the IETF has a BoF for next week, which is looking at precisely the
topic of delivering trust anchors
... I do like the idea of a growing trust, where it takes N interactions or N
days, to establish trust for a SScert
... if we go down this route around spotting changing certs, there are a lot
of details to figure out (e.g. expiry)
... that's a fairly complicated bit of context
Chuck: first of all I do wish I could attend the BoF but it seems unlikely
<yngve> old article: http://my.opera.com/yngve/blog/show.dml/461932
Chuck: the point I wanted to make was that there have been a variety of attempts to help users make/manage trust decisions (e.g. Mac OS keychain)
<stephenF> chuck: if you can arrange someone else from an FI to come to the BoF, let me know
Chuck: the problem is, users don't know how to deal with it, and browsers don't communicate it well
<stephenF> just to note that the assumption here is that we've already sorted out the "normal" TLS case
tlr: I think the IdentitySignal recommendation is a piece of that discussions, part might also be about revisiting past decisions
yngve: this is an area where there are probably
no good solutions
... what we are probably looking for is the most usable solution. I'm not
sure I like either of the existing solutions
... the problem with keeping the history is that you develop lock in, and
risk problems during data loss
... posted a link to an article of mine in IRC
<Chuck> Again, in the real world, there are commercial solutions to the problem of local history being lost. For example, syncronization services can handle this problem, and do for many users
tlr: are johnathan or stephen interested in taking up this conversation
stephenF: I'd be happy to work with you on that next week
<tlr> ACTION: stephen to draft proposal for self-signed certs over beer with Thomas [recorded in http://www.w3.org/2007/07/18-wsc-minutes.html#action04]
<trackbot> Created ACTION-272 - Draft proposal for self-signed certs over beer with Thomas [on Stephen Farrell - due 2007-07-25].
<Chuck> In my case, my history of trusted certs (and password-web site connections) is synchronized across multiple systems, and on a Internet service
<tjh> http://www.w3.org/2006/WSC/wiki/RecommendationDisplayProposals/BrowserLockDown
tjh: the overview of this recommendation is to
allow for the myriad config settings to be collected into a set of things
that makes sense for a given usage case/site list
... so if you have a set of sites where javascript would be fine, you can
turn it on, but off for sites where it might be dangerous
... the goal is to greatly reduce the questions asked of the user about
security settings
... instead, collective knowledge of security experts can be used to tweak
those settings according to browsing mode, which is the only thing that is
contingent on the user
... in cases like corporate-deployed browsers, users shouldn't be prompted to
change settings, they shouldn't even have the option
tjh - <reads conformance language from wiki>
tjh: a colleague of mine remarked that there
ought to be a way to specify whether or not to start in lockdown mode, and
should require overt action to break out
... seems like this applies to a great many of the use cases
... one important limitation is the annoyance that users will experience if
the configuration is overly restrictive
<Zakim> stephenF, you wanted to ask if this and sbm should be merged (when tim's done with the intro)
stephenF: I like this idea, and I like SBM, but I think they're really the same idea. Should they be merged?
<Zakim> johnath, you wanted to ask, after tjh's intro, whether this is intended to be a voluntary mode or not, particularly for non-corporate use cases
stephenF: it's obviously about setting things like whether to run javascript based on the sites being visited
<tjh> I am open to merging or at least investigating that merge
<johnath> q to tim (might have talked about this in Dublin) -- interpretation of discussion was that it would be nice ... ... to declaratively say "I want to be safe" ... ... didn't realize it would be for instance controlled by admins ... ... or really anything more than basically a big button that says "disable dynamic content" ... ... rules that are downloaded? ... ... not something built in to the browser? .. ... when stephen said these things are the same, took a second to realize why ... ... but if framed in terms of corporate deployed browser, that does sound a lot like SBM .. .. "here's the listof sites, here's what you can / can't do" ... ... "make me safer" button is a different story ...
tjh: I didn't mean to imply a big switch - I
use using javascript toggle as an example
... as for corporate - that too was an example
... I tried to bring that out with references to geek squad, or social
networking groups
johnath: I am just wondering if this reco involves vanilla out-of-box experience, or only with third-party additions
tjh: I expect that at first it will be purely as an addition, but maybe that evolves over the time
<stephenF> +1 for getting new safe-browsing/lockdown "macros" from wherever (with care of course)
tjh: I expect that users will live in user mode most of the time, and only in admin mode when they are ready and willing to make security decisions
Chuck: the BMA discussions say a fair bit about
a need for this
... for a website to put some constraints on how a browser will interact with
it
... what is missing is how the website can communicate those expectations to
the user agent
<stephenF> just to note that we have the same problem with dkim/ssp and there use DNS
Chuck: right now there's no way for a browser to determine whether a given site intends to use javascript
<Zakim> stephenF, you wanted to ask about level of complexity - is #include <tlr-setttings.h> allowed, what about #define foo bar?
Chuck: I think we should start thinking about practical solutions, even if they're imperfect
stephenF: I assume we are not discussing, though we could, a standard way of expressing these settings-bundles
<tlr> I think that expressing these settings might be a worthwhile endeavour, but likely outside of scope here.
stephenF: I would like to see the settings
consider some kind of consistency across browser
... there are issues of complexity here
... which may create problems with composing things, introducing new
vulnerabilities, etc
tjh: I haven't gotten as far as figuring out if it's a micro-language, or a database, or a .ini file
tlr: the ability that chuck was hinting at - a way for sites to call out the features they want
johnath: I think WHATWG (?? maybe??) is considering certain limited versions of Chuck's idea, like a header tag to request no script processing, to prevent XSS
Chuck: there are quite a few plugins that do things like NoScript, and per-site security settings - there's a lot of approaches already happening here worth citing
that sounds like action on Chuck to compile a list :)
<Zakim> johnath, you wanted to reply to stephen
<tlr> stephen: Should FPWD have SBM and LockDown separate?
<johnath> might be useful to get separate comments on them, as they might evolve differently ... SBM is whitelist only, to a large extent ... ... LockDown sounds richer ... ... separate issues for public review, unless everybody insists that they be combined ...
<Chuck> I agree with Johnath
<stephenF> counterargument is lockdown seems to include possibility of whitelist ... one proposal included in the other ... ... have some text that points out the relationship ...
<johnath> I hear you ... ... broad reading of lockdown could easily subsume SBM ...
tlr: we're out of time - give tjh final word
<tlr> ... keep them separate, but point out relationship ...
tjh: definitely want to add the bit about
current work, mentioned by Chuck.
... fine by me to leave them separate, but agree that there might be language
to add
<Chuck> Re: examples, I'd cite the noscript plugin for Firefox as one example, and the OmniWeb browser (Mac only) as an example that allows the user to take an extreme degree of fine-grained control over what a Web site is allowed to do.
<tlr> next week, 25 July, MEZ to chair
<tlr> yngve: Yngve @ IETF as well, then vacation & regrets for that time
<stephenF> PHB will probably be in Chicago as well
<tlr> meeting adjourned
<tlr> ISSUE-78 reassigned to rec-track deliverables
<tlr> ISSUE-79 close without change to Note text
<tlr> ISSUE-80 close
<tlr> ISSUE-81 close without change to text
<tlr> ISSUE-82 reject (and close) since topic was decided
<tlr> ISSUE-84 close without change
<tlr> ISSUE-86 close without change
<tlr> ISSUE-89 close as duplicate of ISSUE-80
<tlr> ISSUE-93 close without change
<tlr> ISSUE-94 close; part out-of-scope, part duplicate of ISSUE-87