WSC WG weekly
16 Jan 2007

approve last meeting's minute?

<tlr> http://www.w3.org/2007/01/09-wsc-minutes

<tlr> RESOLVED: minutes approved

Newly closed action items per agenda

<tlr> http://lists.w3.org/Archives/Public/public-wsc-wg/2007Jan/0111.html

use case discussion

<tlr> http://www.w3.org/2006/WSC/wiki/NoteUseCases

PhoneLure Use Case

<tlr> http://www.w3.org/2006/WSC/wiki/NotePhoneLure

Brad: usecase describes phishing by voice browser

Brad: part of idea to identify other modalities than std browser

<Mez> The conflicting proposal for out of scope is at....

<Mez> http://lists.w3.org/Archives/Public/public-wsc-wg/2007Jan/0081.html

Brad: how broad should scope be, include multiple modalities?

Phil: objective of my post was to eliminate issues which are important for Internet crime, but not in scope for this group because we would need other expertise, e.g. SS7, telephony

MEZ: is there stuff here we can recommend, w/o getting into atttacks on phone system?

<stephenF> available to whom?

Brad: There is WSC info avail to voice browser but currently there is no chrome. We don't have to deal with telco protocols just how to display info.

Phil: I have a concern with dealing with real phone numbers. There currently exists a way to shut down a phone # in about 30 mins, with a court order. I want us to stay on the Internet protocol side. We can consider SIP, but not to talk to legacy phone network.

<tlr> +1

Stephen: agree

Brad: +1
... how can present info consistently in different modalities

Stephen: should cover for example blind person

Chuck: mistake to think it is a SIP world already
... other approaches could be addressed by W3C, e.g. Skipe, IM, etc.

<tlr> chuck: could leverage recommendations in skype, im, etc areas, for consistency

Phil: wanted to specify new generation, but exclude legacy phone system
... phone number gives approx line to draw
... need to cover web first, then consider other modalities
... accessability is important, consider real attacks
... security thru obscurity works
... risks currently low

Stephen: don't think accessability is top priority, but should consider if making display recommendations

<tlr> I think I hear violent agreement on the phone use case, would like to see that turned into action and move on...

Stephen: colored bars could be an issue

<Mez> who should redraft the out of scope option, and turn it into what?

<tlr> brad to propose, phil to review, then close the thing?

<Mez> brad, is that good for you?

Phil: color blindness is a real concern

<tlr> and the other way around for the use case (PHB to propose edits, Phil to review them)

<Mez> Phil, are you good with that?

<tlr> ACTION: porter to redraft out-of-scope item for phone [recorded in http://www.w3.org/2007/01/16-wsc-minutes.html#action01]

<trackbot> Created ACTION-79 - Redraft out-of-scope item for phone [on Brandon Porter - due 2007-01-23].

<tlr> ACTION: hallam-baker to redraft phonelure use case [recorded in http://www.w3.org/2007/01/16-wsc-minutes.html#action02]

<trackbot> Created ACTION-80 - Redraft phonelure use case [on Phillip Hallam-Baker - due 2007-01-23].

<tlr> http://lists.w3.org/Archives/Public/public-wsc-wg/2007Jan/0067.html

MIke's use cases

Mike: started with what padlock meaans, etc.
... not what users really want to know
... see email

<tlr> Alice enters her credit card number on Bob's Plumbing web site, then wonders if computers or people at her ISP (Carol's Cheap Internet Co.) will be able to read it in transit.

<Mez> Looking at

<Mez> http://www.w3.org/2006/WSC/wiki/NoteDesignPrinciples

<Mez> re: Hal right now, see:

<Mez> http://www.w3.org/2006/WSC/wiki/NoteAssumptions

<stephenF> hal sez: we (securitry folks) try to educate users to think about risk

<stephenF> hal sez: users think binary "secure/insecure"

<stephenF> hal asks: what does padlock mean today? good-guy or that-dns

<stephenF> hal warns: we're gonna hit this sometime

<Mez> I do see a compromise. Tactically, we can present a user model that users understand today. Strategically, those of us who believe security professionals can change the way the world thinks, can propose how that would work for discussion

Tyler: users can deal with risk management in real world, why not on web?

MikeM: users can deal with non-binary risk

Phil: issue raised by Browser vendors, not hard to provide info to users, but hard to change chrome once a change is made
... hard to back out changes

<stephenF> +1 to PHB's point => do experiments before recommendations

Phil: have to pursuade is worth making change

<Mez> It's in our assumptions section, which you've all reviewed since I sent out the pointer, right?

<tlr> mez, I think you ought to summarize the criticla points of that on the phone...

<Mez> Thomas, I think you're leading this discussion

Tyler: create continuity of experience

<PHB> There are actually two functions here, one is if I have an existing trust relationship with a party is the party I see on the Web the same one I already know. The second is how do I form a trust relationship wiuth a previously unknown party online

<stephenF> just want to emphasise that I really agree with improving the same as last time stuff

<Mez> +1 to killing the category of attacks that spoof an existing trust relation

Phil: current attacks adress hijacking existing trust relationships

Stephen: +1 to same as last time stuff

MEZ: some of this is covered in assumptions

<tlr> http://www.w3.org/2006/WSC/wiki/NoteDesignPrinciples

<stephenF> will read so

<stephenF> I did read before, generally liked, but not sure its "gospel"

<Mez> please put forward anything you may or may not be willing to buy into

<Mez> this is an attempt to level set the team on how we'll come to concensus, which is critical

halGoing back to Mike's message, I see "A. Can eavesdroppers read my session?" and "C. Have the web pages I'm seeing been tampered with?" in one category and "B. Is the web site really the one I requested?" and "D. Is the web site reputable?" in a different category. A. and C. can really only be answered either by describing the technology in place or by saying you don't know, since it depends on correct configuration, etc. On the other hand, B. and D. represent more like what the SSL padlock is trying to express. In the case, of D. perhaps with extended validation certificates.

MIkeM: these are real questions users have, may not have answers

<PHB> Should we organize a joint session with CABForum

MikeM: important to have usecases which represnt real user's views

tlr: +1
... need to work on design principles and assumptions first
... take up mini usecase under design principles at F2F

Tyler: hoped to get first part of Note finished this week, are some up in the air?

tlr: some are up in the air

Tyler: plan to move text to XML, only I have write access to CVS

tlr: stuff added to wiki after tomorrow may not get into editor's draft

Tyler: agreed

Forward Interactions

<tlr> http://lists.w3.org/Archives/Public/public-wsc-wg/2007Jan/0089.html

tlr: describe FollowALink Usecase

<chuck> Opinion, this is actually one of the most troubling issues for both users and service providers. There are a lot of important issues to be addressed here, and they're fairly high priority.

<Mez> then it's good we've got a proposed use case for it

Stephen: do you mean we should tell user where they are going before the go there?
... or somehow evaluate site accessed
... can you give an example?

<beltzner_> I think the use case simply represents the fact that link redirection can mislead a user into thinking they've gone somehwere that they haven't. I don't think it posits a solution.

tlr: hypothetical, is current URL display actally misleading?

Tyler: don't understand what info the user is trying to get?

tlr: could tell where you are going

<stephenF> maybe we need to differentiate between displaying what *is*, versus, guessing what *will* be?

Mez: even if can not fix a problem, should document it

<chuck> We do seem to be mixing up "use cases" with recommendations. The real issue is that there are important issues of "trust" that involve the "flow" of commerce from one site to another, and possibly back.

<stephenF> ok

<tlr> ACTION: tyler to follow up on the use case [recorded in http://www.w3.org/2007/01/16-wsc-minutes.html#action03]

<trackbot> Created ACTION-81 - Follow up on the use case [on Tyler Close - due 2007-01-23].

tlr: everyone please report missing items from F2F agenda