WSCWG weekly

19 Dec 2006

See also: IRC log; agenda


Thomas Roessler
Geoerge Staikos
Mike Beltzner
Mary Ellen Zurko
Tyler Close
Bill Doyle
Stephen Farrell
Hal Lockhart
Phillip Hallam-Baker
Mike McCormick
Tim Hahn
Paul Hill
Tony Nadalin
Mary Ellen Zurko
Thomas Roessler


approve minutes from last meeting; http://www.w3.org/2006/12/12-wsc-minutes

mez: completes first agenda item

<tlr> RESOLVED: minutes accepted

mez: completes second agenda item, approves minutes

Scope discussion

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].

Summary of Action Items

[NEW] ACTION: Farrell to draft "out-of-scope" text for proxies etc that do not involve human interaction [recorded in http://www.w3.org/2006/12/19-wsc-minutes.html#action01]
[NEW] ACTION: Hahn to propose text on how corroboration with independent sites should be scoped [recorded in http://www.w3.org/2006/12/19-wsc-minutes.html#action03]
[NEW] ACTION: hal to drive discussion on presentation of content-based filtering on list, draft text [recorded in http://www.w3.org/2006/12/19-wsc-minutes.html#action07]
[NEW] ACTION: hal to edit out content blocking part [recorded in http://www.w3.org/2006/12/19-wsc-minutes.html#action04]
[NEW] ACTION: Nadalin to write concrete "content blocking out of scope" section, or to declare defeat [recorded in http://www.w3.org/2006/12/19-wsc-minutes.html#action05]
[NEW] ACTION: tjh to describe how corroboration with independent sites should be scoped [recorded in http://www.w3.org/2006/12/19-wsc-minutes.html#action02]
[NEW] ACTION: Tyler to merge the TCB-related points [recorded in http://www.w3.org/2006/12/19-wsc-minutes.html#action06]
[NEW] ACTION: zurko to maintain volunteer list in NoteIndex in the wiki. [recorded in http://www.w3.org/2006/12/19-wsc-minutes.html#action08]
[End of minutes]