mez: completes first agenda item
<tlr> RESOLVED: minutes accepted
mez: completes second agenda item, approves minutes
mez: let's start talking through OutOfScope
... (starts walking through the list at http://www.w3.org/2006/WSC/wiki/NoteOutOfScope)
... "Non Web User Agents" is still definited somewhat generically ...
... the protocol point is one that's come up a lot ...
... what we should have are examples on "are web protocols" and "aren't web
protocols" ...
... second item: "Email Processing", specifically email client apps and
back-end email protocols
... including SMTP which is a non-web protocol example
... discussed on email what to do when there's a web agent that has an email
protocol, good coverage on that exists. Web agents dealing with non-web
protocols need to display a consistent security context in their
interface.
... next, "assume that foundation of the computing base is trusted"
... finally, "future looking web protocol/agent use cases" basically says
that we're not psychic
stephenF: do we need a bullet about web-user agents that are headless or not being used by users but instead by servers?
Mez: +1
... action assigned!
stephenF: I'll take the action to craft that language and bullet point
<trackbot> Created ACTION-51 - Draft \"out-of-scope\" text for proxies etc that do not involve human interaction [on Stephen Farrell - due 2006-12-26].
hal: should we include snail mail in this somehow, or otherwise capture the fact that phishing has tendrils into "real-world" effects
Mez: we'd need an example showing that it should be in scope
hal: right, I'm saying it should be out of scope
Paul: I believe that people are looking for best practises
<beltzner> drafted text in response to ACTION-42 on site-to-user communication ...
<beltzner> ... that could involve snail mail ...
<beltzner> ... easy to imagine that to be phishing attack ...
tlr: my take is that what beltzner described is
a best practise on the "user interaction" between business/site and the end
user; not sure to what extent that should be our focus
... we should talk about the ways to talk about this experience, not the
specific mediums
beltzner: so you're talking about going medium independent?
Paul: yeah, sometimes you see statements that "we never ask for {whatever}", and if those are valid anti-phishing techniques we should probably describe those
Mez: I'd like to ensure that we not consider every aspect of the use case scenarios as in scope
<tlr> I'm not getting the proposal.
tjh: much of this may rely on a person/entity
realizing that they can't trust just what they see from one location
... ... and they'll have to ask some independent entity to corroborate
beltzner: are you talking OpenID/cardspace?
tjh: I'm not trying to! ...
... if I go to a site, look at a zip file, look at the MD5 sum, that may or
may not still be correct, because they could generate their own
tjh: ... but if I go to some other independent
site and corroborate, that has a better value statement
... as long as I know they're independent
Mez: I think I've been using "authority" to convey overtones that aren't covered by your suggestion
<trackbot> Created ACTION-52 - Propose text on how corroboration with independent sites should be scoped [on Tim Hahn - due 2006-12-26].
tlr: getting back to email/speaking about
security scenario, I think there is a line between describing business
practises (which is out of scope) and saying how security context should be
communicated when users are trained about it
... ... I got concerned when I heard hal saying that if business practises
are anti-phishing practises we need to make recommendations
Mez: the part of that which is in our scope is saying what can be done robustly and understandably
tlr: we want to say "what you can't tell people about their web environment 'cause it's just not true"
Mez: right, because it muddies the usability of what can or can't be done
billd: if we can't make a clear distinction about risk, does the scenario fall out of scope?
Mez: because {muddled} context for the user, I'm not sure; was there something in particular?
billd: some situations are clear (PKI, username/pwd, URL) when there is information to build on, but should we be carrying scenarios when we don't really have any information and just have business practises or "other things" to go on
Mez: so if there's no security context information then it does feel like whatever other recommendations we make would be out of scope, yes
billd: yes, yes
... just trying to determine what happens when a user knows that a site is
shady, but doesn't care, do we get in the way?
... trying to express things in term of risk to the user
Mez: you might be moving on to the next item, which is content blocking
billd: right, but even in declaring that as out-of-scope, is there something we can say about it being out of scope (???)
Mez: we've had discussions about this on email,
like what to do / how to present "there's no security context" to users
... so I don't think null-set security context is out of scope
tlr: getting back to email exchange from a week
ago, there is a situation where we might say "giving users an override" isn't
going to do them any good
... ... as currently phrased, I'm not sure that the content blocking section
of OutOfScope doesn't pre-judge that
stephenF: about browser history, is there an assumption that the only history that's available is the history that's stored locally; there could be other browser history information that could be saved to improve security context detection
Mez: yes, flushing history will be taken into account
stephenF: right, but I was thinking that even flushing history could contain hash chains that we could use for security context
Tyler: I added the Content Blocking section to
out of scope ...
... ... am I supposed to take it out?
Mez: no, I wouldn't
Tyler: should I take an action to fix the phrasing?
Mez: it was thomas who raised the point ...
tlr: so, I'm picturing man in the middle
attacks, where we have good data that users just click-through the warning
dialogs
... that would be a situation in which _not_ giving the user an override
could be the right thing from a security perspective
Mez: I see that example, but I don't know if that's covered by our charter
tlr: from my perspective, in that use cas eI
just described, I see two questions ...
... .. 1) if there's something the browser knows that there's something it
could present to the user, and that's in scope ..
... .. 2) what do we provide if there isn't anything useful to present to the
user, when we know they won't be able to really understand it or the browser
can't really help ... in those cases, we might need to require a hard-fail
Mez: so tie that to the charter
tlr: so the charter can't force a conclusion
that is ultimately emperical; if that's what our context tells us, we ought
to be able to make that user decision for them
... ... I wouldn't want a scope note to ultimately inhibiting this kind of
statement
billd: in that case you can present the fact that there is security context, there is a risk, and the user can move forward
tlr: going back to the scoping text ...
... ... the conclusion that I see drawn from our charter and this scoping
note is that "we must never remove an override"
... ... and I don't think we've actually drawn that conclusion. have we?
Tyler: I think I agree with tlr, but also that
our charter lacks clarity here
... ... but browser vendors have agreed that blocking content makes the
browser seem broken
beltzner: I think this group can recommend that content be blocked outright, but it will be up to the browser vendors to enforce that as a group
staikos: was gonna say the same thing
Mez: so it sounds like content blocking should be in scope? anyone disagree?
<Nadalin> I think that there are different levels of content blocking, some may be out of scope
billd: it gets back to risk vs. no risk, and how we should act appropriately in those situations
tony: we need to be careful to make sure it doesn't come down to describing what content should and shouldn't be blocked
tlr: agrees with recent discussion
... content blocking should be available as a result of the security prodigal
failing
... content filtering should be available as a reaction to the security
context that is available
... when we get to interaction/usability issues, the content blocking issue
might resolve itself
Tyler: I think we can rename content blocking
to connection blocking and move that to in-scope
... like turning off SSL1/2 would be inscope, but blocking content over
supported protocols would be out of scope
<stephenF> connection not so good a term if working via proxy
tony: I worry that people might interpret that as refusing that connection without looking at the content
hal: I was going to agree with Thomas, for today it's sufficient to say that it's not out of scope, and we should figure it out as we go along since today it will be hard to get consensus without thinking more deeply about the use cases
<stephenF> +1 to hal, tlr
<trackbot> Created ACTION-53 - Edit out content blocking part [on Hal Lockhart - due 2006-12-26].
Mez: volunteers Hal to take an action
tony: I do worry that removing this from out-of-scope opens us to "specification creep" and nobody likes bloated specs (except the '70s)
Mez: that sounds like you're volunteering to re-write it
tlr: can you give an example of the direction you don't want things to creep in
tony: *ponders*
Mez: let's give tony some time, so let's assign him a follow-up action as an early christmas gift
tjh: I agree that we're struggling with the inscope/outofscope with content blocking, and I observe that filtering/blocking is an action someone can take as opposed to something you can watch/analyse or think about
Tyler: I want to go back to the suggestion of
rephrasing as connection blocking, since most objections seem to be about
content based detection
... ... connection blocking based on outdated protocols should be in scope,
content based blocking might be harder to scope.
tjh: I was satisfied with the resolution to keep the section and simply narrow it to reduce the amount of out of scopiness
tlr: we should stop ratholing here, and stop ruling things out of scope when we don't even have an example
tjh: I don't think that out of scope and in scope need to be exhaustive
Mez: tony will re-write content blocking section or present himself for group-wide shaming
<trackbot> Created ACTION-54 - Write concrete \"content blocking out of scope\" section, or to declare defeat [on Anthony Nadalin - due 2006-12-26].
Mez: (reviews meeting to make sure nobody's unhappy)
Tyler: in content based detection, we decided we weren't making recommendations, but rfranco said that they're going to continue doing that, and so I was wondering if we should standardize a recommended presentation
Mez: I believe email discussion led us to believe that would be in scope
tlr: so the takeaway was ways to display were
in scope, ways to detect out of scope
... but, I'm on queue for illustrating the redundancy in outofscope with the
last section beltzner added
Mez: you just took an action, and you don't even know it!
tlr: sigh, I guess I did
<trackbot> Created ACTION-55 - Merge the TCB-related points [on Tyler Close - due 2006-12-26].
tlr: *parries, gives action to tyler instead*
Tyler: wanted to point out that presentation of the results of content based detection -- I'm against that if we don't know what the algorithm is
<stephenF> +1 to tyler, can't see how we can do it
Tyler: ... I also think content based detection isn't a good thing to do, as I pointed out in email.
Mez: we should discuss further on the list
<trackbot> Created ACTION-56 - Drive discussion on presentation of content-based filtering on list, draft text [on Hal Lockhart - due 2006-12-26].
Mez: next meeting: we'll talk about goals,
start parceling out empty sections of notes, learn about love and life
through the lessons of a friendly dog who can just never settle down ...
... you'll want to volunteer for sections you want to write about since
otherwise you'll get assigned one you don't want.
<trackbot> Created ACTION-57 - Maintain volunteer list in NoteIndex in the wiki. [on Mary Ellen Zurko - due 2006-12-26].