See also: IRC log
<tlr> ACTION-248 done, need to be added to editor's draft
<scribe> ACTION: Anil to add to editor's draft [recorded in http://www.w3.org/2007/09/19-wsc-minutes.html#action01]
<trackbot-ng> Created ACTION-296 - Add to editor's draft [on Anil Saldhana - due 2007-09-26].
<tlr> ACTION-296 is to add material from http://lists.w3.org/Archives/Public/public-wsc-wg/2007Sep/0057.html to editor's draft.
<tlr> ACTION-284 on Stephen is overdue
<tlr> ACTION-284 reassigned to PHB, Due before F2F
Action 293 almost all dealt with via email, Tim to continue
<tlr> ACTION-288, ACTION-289, ACTION-295 closed Everyone will want to review the material...
<tlr> ACTION-285 Strong/weak algorithm action on Yngve completed,
<scribe> ACTION: anil to make sure it is in editor's draft [recorded in http://www.w3.org/2007/09/19-wsc-minutes.html#action02]
<trackbot-ng> Created ACTION-297 - Make sure it is in editor's draft [on Anil Saldhana - due 2007-09-26].
<tlr> ACTION-297 refers to http://lists.w3.org/Archives/Public/public-wsc-wg/2007Sep/0014.html
<tlr> http://lists.w3.org/Archives/Public/public-wsc-wg/2007Sep/0045.html
TLR: Concentration on public draft of the rec track document
<ifette> PII-bar issues?
tlr: any points where we should add discussion
to F2F, i.e. agenda bashing
... PI-bar is on agenda
Ian Trip out to sith street in Austin on Tuesday night?
tlr: is it in Wiki
<tlr> http://www.w3.org/2006/WSC/wiki/MeetingTaxisAndDinners
Ian please do so, people please add themselves to wiki
tlr: one more preparation point on Austin, Anil has action to put version of Mike McCormick's in editor's draft
tlr: appologies not yet got use cases in, bad
internet connectivity and meetings
... closure on a number of issues for use cases note
... open issues 6, 83, 101
tyler: plus issue 25
tlr: not an issue needs change on this
tyler 6, 83, 101
tlr: on last call, Bill Doyle, progress on comment tracker?
Bill, working on it
tlr: input from Louis on this one
<tlr> http://lists.w3.org/Archives/Public/public-wsc-wg/2007Sep/0031.html
tlr: did not make it to the list, above is the
URI
... anything else needed?
... anyone else with issues
[silence]
<johnath> I'm not silent out of ignorance or lack of caring per se, I just don't claim particular expertise on whether it covers the territory appropriately
<tlr> issue-6 ready for closing
tlr: looks like mez should declare consensus on the list and we declare this done
topic issue 101
tlr: bunch of discussion recently, updated proposal for this use case
<tlr> http://lists.w3.org/Archives/Public/public-wsc-wg/2007Sep/0030.html
<ifette> http://www.w3.org/2006/WSC/track/issues/101
tlr: Question is how to communicate information on compromise to the user
tyler: need interaction that users can understand directly
<johnath> ack \
tyler: need easy to use, pleasant to use UI
... concerned that we presuppose that particular interaction makes sense to
user
... need to study interaction,
... need to notify user before they interact with possibly compromised
site
... jackson paper on MSFT phishing filter showed that when users were aware
that the filter is there that they become more vulnerable to phishing
attacks.
... overconfidence,
... need to formulate use cases to test ability of users to discriminate
<ifette> Whoa, I only saw emails from me, tryler, and one from rachna - that's not "an awful lot of email"
<ifette> Tyler, the only resistance has come from you
tlr: one question, in your description, put lot of emphasis on not assuming an interaction, is the emphasis on the information to be displayed to the user?
tyler: no, use case is that user will know about disreputable sites and act on information provided
tlr: is the problem in the knowing whether the
site is compromised or communicating this to the user
... distinguish between interaction between user agent and user and th
knowledge the user is attempting to act on.
tyler: do not want to make assumption that the communication to user apriori wrks
<johnath> tyler - I'm trying to find the part of the Jackson study that makes the claim you quote. The closest I can find is:
Ian: tyler has raised many points,
... would be fine with use case that says 'if users do this then how should
they do it'
... " standardized warnings probably work better
... saying we should look at it, figure if we should make a recomendation
<johnath> "Across all groups, participants were fooled by homograph pages 11% of the time if a “suspicious page” warning was displayed, compared to 48% of the time if no warning was displayed (t(26)=4.48, p<.001). Although the effect of the warnings is statistically significant, its applicability is limited because the participants were aware that they needed to classify sites (see discussion in Section 5.5)."
Ian: on the Jackson paper, confusing phishing
and malware,
... with malware even if you know what sites are bad you want to warn them
tlr: we are edging into area of solutions
Ian: with phishing web sites it is usually a site you have never interacted with before
<tlr> two distinctions -- 1., no trust decisions; 2., phishing is usually not known, malware might come from trusted site
<tlr> by way of compromise
<tlr> different process
Ian: with malware it is usually a highly trafficed site, one that has been previously visited
<johnath> nope, just checking it
PHBReference in Jackson paper is problematic,
he was testing a different interaction and a different type of attack
jackson also talked about anti-phishing warnings
Talking about supressing warnings vs. positive indications. Completely
outside scope of this study
<johnaththis is the case
PHBDoesn't see that this type of study adds
anything. People in labs behave differently
... Only types that are useful is if you have a very high n (number of
people)
... How this thing is used three months down the line that matters, not
initial use in laboratory
... doesn't see problem with use case as described
yngve: seeing reports from people complaining that phishing filter is not reporting well known phishing sites
they expect filter to be perfect or nearly perfect if they think it is a well known site
tlr: tyler to respond
<ifette> MALWARE not phishing!!!!one!
tyler: first point is on the standard presentation for warning\
<ifette> It's already done. Go to google.com and do a search, you will get warnings on some results...
<ifette> and FF3...
tyler: need to demostrate that the warnings
work, need to show that the warning works first
... on scope, it is clear that this is in scope, if the proposal works it is
in scope
<yngve> ifette, phishing filters are one area where we currently have experience with blacklists
tyler: on third point where user becomes compromised when visiting URL, that is bug in user agent which is out of scope
ian: I mean drive by downloads
tlr: when we say scope we mean fixing bugs in
software
... but if there are cases where we are talking about making interactions to
make drive-by harder that is not out of scope
<ifette> correct tlr
tlr: we are essentially talking about cases where the browser is saying that something bad is going to happen when a site is visited
<tlr> http://lists.w3.org/Archives/Public/public-wsc-wg/2007Sep/0030.html
<johnath> whoop - softphone crash, brb
<tlr> "I'm happy to change it to the following if it would make people happier:"
Proposal: remove last sentence where it says what warnings should betty be presented with and replace with how should this happen
<ifette> I think the proposal was to change the last sentence from "what warnings" to "what interaction", not to remove the sentence entirely
tyler: re phb, need to revist testing methodology
<tlr> ifette, correct
<ifette> Tyler, with malware the user has no ability to detect attack whatsoever
tyler: study measured deacrease in users ability to detect an attack
<johnath> (sorry phil - lotsa typing)
tyler: need to have positive result before we can make a recommendation
<ifette> PHB: Problem is same problem that Thomas has, last sentence is problem
<ifette> ... is meant to be a use case, is talking about a specific mechanism
<ifette> ... just the last part of the sentence, think that the existance of the blacklist can be taken as part of context of use case b/c the usecase is all about "it is known that there is a problem..." implies some information somewhere
<ifette> ... just last part of sentence, what warnings, suggest re-wording to "How to betty be dissuaded / discouraged from visiting this site / continuing this interaction"
<tlr> apologies for the noise
<johnath> I think Jackson's being misquoted here, but if we're declaring that off the table, so much the better
how should bettybe discouraged from continuing with this interaction?
Ian: problem is going from a known good state to known bad case
TLR: don't think this is the point of contention
<johnath> phb - please mute
Ian: think it is as tyler is liumping two issues together
<johnath> (thx phil - that's some aggressive typing! :)
ian: point is that with malware the users cannot distinguish good from bad
tlr: thats a meta point we have passed
... we have two proposals here, is either acceptable to Ian and Tyler
<tlr> "What warnings should Betty be presented with?" -> "What interaction should occur?"
IAn: which are the two, proposals
tlr: putting into IRC
Ian: both are acceptable
[PHB saw his proposal as refining TLR's]
tlr: are these acceptable to tyler?
<ifette> I am not willing to drop the part about calling out the fact that "the browser has knowledge" because that totally kills the use case
tyler: don't suppose that we will but in the
interests of consensus would accept use case with entire last sentence
... use case assumes that information exists, can't assume that
tlr: what is presupposed is the presence of that information
<ifette> Who is calling from NJ?
tyler: its the difference between a test and the thing being tested.
<ifette> PHB: Think we need to
distinguish here...
... hearing what tyler is saying... really two issues here
... 1 is that we have blacklist information, and is that information valid
... second is that if we present that information to user, will user act on
the information in the way that we wish them to act
... Perhaps two independent use cases, one that tests the first piece, one
that tests the second piece, if we were doing this in the large
... since the validity of the list and method of obtaining is out of scope,
use case that presupposes having information with a reasonable degree of
confidence
... and attempting to use that to get the user to act in a particular way, is
a valid piece
... sees difference between PHB's proposal and TLR's
... TLR's talks about interaction, ties to mechanism
... PHB took another step back, talked about an outcome, closer to Tyler's
objection
... By stating in terms of outcome, have criteria that Blacklist needs to be
accurate at certain level to justify user confidence, maintined confidence
... too many false postiives trains user to ignore, that is something that
could be tested
... mechanism for generating certainly shouldn't be tested
tlr: what I think you are saying the question is whether if that information exists whether it is to be useful
<tlr> alternative idea: "What interaction, if any, should occur?"
that is good with me
<ifette> not good with me
tyler: if we take out of this all notion of relying on blacklist then it is possible that other use cases that don't make use of blacklist
might be able to meet the use case
<ifette> not good to take out "at the time of the present request"
<ifette> no go
ian: don't understand the problem with at the
time of the present request, it is saying the site used to be good, now is
bad
... all saying is if the browser chooses to use information
tyler: what you seem to be talking about is if users are infexcted with malware,
ian: do not want recommendation phase to
necessarily mention blacklists
... all I am saying is that the interaction is fundamentally different from
phishing
tyler: then lets keep use case focused on malware, lets just focus on malware and not mention blacklists
tlr: think that you are both agreeing that user agents might have found some way to indicate that user agents has somehow determined that example.com is bad
tyler: not correct
... should not be dictating that this use case be solved using any particular
technique
PHBIf you consider the problem as a state
diagram
... a use case describes a specific state within that diagram
... can remove the reference to blacklists and replace that with "there is an
indication that the site is very likely to be bad"
... can avoid mentioning blacklists
... might have inspection of content, etc
... blacklist need not be list of bad IPs / sites / whatever
... with that change made, think that the use case relates to a state, a
condition, that you are starting from
... in that case, differentiating between case where info is available an
info is not, seems to be an essential feature to be a use case
... not sure why malware is so different from phishing
... Certain types of phishing where it's equally applicable, focus is
essentially correct
<m case where you don't, need to differentiate those two
use cases
s/tath/that/
... not sure why malware is so different from phishing
PHB: Certain types of phishing where it's equally applicable, focus is
essentially correct
<ifette> ... with change from blacklist to indication that info avail
<Zakim> ifette, you wanted to address that
ian: have already made PHB's change
tyler: wants to strike last sentence
tlr: disagree
tyler: use case guides to particular solution
ian: thats for phishing not for malware
tlr: don't want to discuss particular
techniques
... presumption is the distinction between the state where the browser does
or does not know
<ifette> striking the sentence entirely kills the usecase
<tyler> ifette, why do you say that?
tlr: don't know basis for tyler's beleivfr that the WG should not discuss cases based on assumption that browser can make the distinction
tyler: what you said is so complex I can't follow
tlr: use case is about the state change from good to bad and what the user interface should be
<johnath> tyler - tlr's declared it out of conversation, but can you point me to the data in jackson that finds site warnings ineffective? I've read it, and am rereading it now, but can't find that.
tlr: for the use case to be useful the distinction must be present
tyler: we have this information declared in scope within the note
<johnath> I can find information about the green bar being ineffective, that training made it worse, etc, but on "suspicious site" warnings, I see a statistically significant improvement, so I'm trying to reconcile what you're saying
tyler: can make use of any information in any use case
<ifette> THIS DOENS'T MENTION BLACKLISTS AT ALL TYLER!!!ONE!\
tyler: only effect of calling out particular information in this use case causes assumption of particular solution
tlr: no this is not a mechanism, it is information available to the user
<tlr> ack
<maritzaj> have to leave for another meeting, bye.
<ifette> I would like a straw poll
<ifette> on the revised text
<ifette> Betty tries to connect to a web site at <http://www.example.com/>. She visits this site frequently to read various news and articles. Since her last visit, the site example.com has been compromised by some method, and visitors are now being infected with malware. At the time of the current request, Betty's user agent now has information saying that example.com is a known bad site. What warnings should Betty be presented with?
tyler:I have consulted with other people who have served on standards bodies to get advice on how to handle this issue. They've agreed that ensuring the use-cases are not biased towards any particular recommendation is a good and normal thing to do. I don't understand why this has been such a tricky issue. I'm surprised hat we've spent so much time arguing this point.
<tlr> http://lists.w3.org/Archives/Public/public-wsc-wg/2007Sep/0030.html
tlr: time for a straw poll.
<scrissti> i would be neutral
tyler: objection: we have gone over time and have lost people
<tlr> change of last sentence: "What warnings, +++if any++, ..."
<tlr> apologies, o
<ifette> Betty tries to connect to a web site at <http://www.example.com/>. She visits this site frequently to read various news and articles. Since her last visit, the site example.com has been compromised by some method, and visitors are now being infected with malware. At the time of the current request, Betty's user agent now has information saying that example.com is a known bad site. What warnings, if any, should Betty be presented with?
<tlr> "What interaction, if any, should occur"
Proposal: Betty tries to connect to a web site at <http://www.example.com/>. She visits this site frequently to read various news and articles. Since her last visit, the site example.com has been compromised by some method, and visitors are now being infected with malware. At the time of the current request, Betty's user agent now has information saying that example.com is a known bad site. What interaction, if any, should occur"
<ifette> Betty tries to connect to a web site at <http://www.example.com/>. She visits this site frequently to read various news and articles. Since her last visit, the site example.com has been compromised by some method, and visitors are now being infected with malware. At the time of the current request, Betty's user agent now has information saying that example.com is a known bad site. What interaction, if any, should occur?
tlr: will record votes on call
... will mimute callwithin 24 hours and ask for any other votes on mailing
list
PHB accepts new wording
PHB accept
<asaldhan> need 2-3 minutes
<jvkrey> abstain
Tyler: vote against
<scrissti> i abstain
Rachna: abstain
Johnath: off call
ifette: accept
<asaldhan> accept
TLR: accept
... will hold vote open asking those who are present to
tyler: disagree
TLR: will be at XML sig workshop next week as will many others
call adjourned.