- From: Thomas Roessler <tlr@w3.org>
- Date: Wed, 16 Jan 2008 17:07:54 +0100
- To: public-wsc-wg@w3.org
Minutes from our meeting on 2008-01-09 were approved and are
available online here:
http://www.w3.org/2008/01/09-wsc-minutes.html
A text version is included below the .signature.
--
Thomas Roessler, W3C <tlr@w3.org>
[1]W3C
Web Security Context Working Group Teleconference
9 Jan 2008
[2]Agenda
See also: [3]IRC log
Attendees
Present
MaryEllen_Zurko, PHB, Thomas, serge, Tyler, ifette, billeburn,
yngve, asaldhan, jvkrey, Bill_Doyle, johnath, rachna, dans
Regrets
Luis_B, Maritza_J, Stephen, F
Chair
MaryEllen_Zurko
Scribe
AnilSaldhana
Contents
* [4]Topics
1. [5]next face-to-face
* [6]Summary of Action Items
__________________________________________________________________
<trackbot-ng> Date: 09 January 2008
<tlr> Scribe: AnilSaldhana
<Mez> I presume there have been no offers to host in San Jose on the
original dates
<tlr> there hasn't been much of anything
<tlr> *sigh*
<tlr> Coffee: FreshlyGround
<tlr> irc client crash. yay
<Mez> eek!
<tlr> as long as it restarts fast enough...
<tlr> So, I presume the big agendum today is sorting out the f2f...
<Mez> there's a lot of other stuff on the agenda
<Mez> but if you need the time and it has to be done in a meeting, then
it has to be done in the meeting
<tlr> I know... Looked at all the issues and the text again.
<tlr> Well, whatever the resolution is, we need to get to one quickly.
And if people don't react to e-mail, I'd rather do it in a meeting than
call up everybody one by one.
<tlr> who was regretted again?
<tlr> Luis and?
<tlr> btw, have you had a look at Al G's latest?
<Mez> yes
<Mez> some editorial, some not quite
<Mez> nothing we can't resolve, just need to grind through the process
<tlr> ScribeNick: asaldhan
<tlr> zakimm, ??P12 is billeburn
<PHB2>
[7]http://www.amazon.com/dotCrime-Manifesto-Stop-Internet-Crime/dp/0321
503589
<tlr> anil, please join the call....
<PHB2> I wrote a first draft and the PR folk rewqrote it
xakim, number?
<PHB2> Had to take out the claim that I invented the computer and such
<ifette> 867-5309....
<PHB2> They somewhat over stated some of it
<PHB2> To say the least, I really want to meet that guy
Mez: agenda is
... first item, scribe - anil
<ifette> Can we get links?
<ifette> before approving?
<Mez> [8]http://www.w3.org/2007/12/19-wsc-minutes.html
Mez: agenda item ???
<tlr>
[9]http://lists.w3.org/Archives/Public/public-wsc-wg/2008Jan/0064.html
<Mez>
[10]http://lists.w3.org/Archives/Public/public-wsc-wg/2008Jan/0038.html
Mez: open action items
... 5) [CLOSED] ACTION-340
... Agenda Bashing
... ISSUE-123 - Safe Form Bar: HTTP assumptions in "no TLS" section
... ISSUE-124 - Safe Form Bar: reliable text
... ISSUE-125 - Safe Form Bar: on screen masking phrased in terms of
visual agents
<johnath> (sorry I'm late)
Mez: Issues will linger unless you want them sooner
... All participants must have reviewed the rec doc by now
... anything on agenda bashing?
next face-to-face
Mez: discussion on next f2f
<ifette> nonrefundable, but with what sort of a change fee?
tlr: 5/6 feb at google, Mountain view. Ian unfortunately says there is
an issue with hosting. No one has come forward to host. Change of dates
is not a problem for many except 1 (costly air ticket)
... usual 8 week notification period should be followed. If anyone in
the silicon valley can help out in the hosting, please come fwd
PHB2: how many people?
tlr: 15-20
tyler: saw tlr's email yest. HP has issues with placing all folks in 1
room - NDA issue exists - if no NDA issues exist - HP can host
ifette: tlr has specified "no NDA"
<PHB2> [hey what happens if someone acks someone not on the queue?]
tlr: NDA is a serious issue. W3C policy.
... non-negotiable
tyler: there is still a possibility,. Still looking for a room with no
NDA
PHB2: Can provide a room. Not sure about food.
... meeting at Verisign and food outside.
... went through a reorg. Hence got to figure out who the manager is.
... 20 people can be held in the room.
tlr: potentially at HP. Alternative at Verisign (no food). We will
still hold the meeting at the old dates.
Mez: we need to keep everybody appraised.
tlr: tyler, mountain view?
tyler: cupertino
<ifette> yes
<ifette> 10mi
tlr: should be able to drive.
... (Message to list) we will stick to old dates. The nearest airport
is SJC. TBD - HP or Verisign. Please register asap
<ifette> TLR, can you post a registration link?
tyler: rachna, any chance we can hold at commercenet
rachna: we can do it
<Mez> network?
<Mez> food?
rachna: tons of places to eat at University Avenue.
<Mez> network is more important :-)
<ifette> sjc
<ifette> but not by much
rachna: airport can be either
... SJC or SFO
tlr: we can decide at the end of the call (tyler, rachna) to decide on
the place.
<tlr> RESOLUTION: Stick to dates of 5/6 Feb, CommerceNet, HP or VSGN to
host, sort out details after call.
Mez: rest of the agenda
<ifette> link?
<Mez> [11]http://www.w3.org/2006/WSC/track/issues/123
<tlr>
[12]http://lists.w3.org/Archives/Public/public-wsc-wg/2007Dec/0106.html
Mez: reads the description of issue-123 aloud
<Mez> idempotent
ifette: tlr's comments about safe/unsafe. Google search and many alike
use GET
... passwords etc are always POST and generally considered unsafe. Do
not recreate the POST without a notification to user.
yngve: agree with ifette. Resubmitting POST makes 2 automobile
purchases ????
<Mez> can someone remind me what section?
<Mez> 7.something no doubt
<yngve> s/Resubmitting POST makes 2 calls/Resubmitting POST can result
in two purchases, e.g. two cars/
tyler: do not understand what people are having issues about
<tlr> [13]http://www.w3.org/TR/wsc-xit/#safebar-must-have-tls
<Mez>
[14]http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#safebar-must-hav
e-tls in the very current draft
tlr: what gave me the impression that there is a https request involved
is the following text:
<Mez> The user agent MUST offer an interaction to attempt navigating to
a secure version of the current page. Exercising that interaction MUST
navigate the browser to a URL constructed by changing the current
page's URL scheme to a corresponding one that uses TLS. For example, an
http: URL is converted to an https: URL.
tlr: "Exercising that interaction MUST navigate the browser to a URL
constructed by changing the current page's URL scheme to a
corresponding one that uses TLS. For example, an http: URL is converted
to an https: URL."
... we do not know how we came to the current page as we may have
arrived from a POST operation
<Mez> all the normative text in 7.2 is:
<Mez> The editor bar supports safe entry of text strings by the user
into a web site with which a continuous relationship has been
established. The user can expect this continuity to be securely
enforced and the transmissions protected from eavesdropping and
tampering. Currently, these properties can only be supported on the web
through the use of TLS. The editor bar MUST NOT be enabled for
exchanges that are not protected by TLS. If the user hits the editor
bar attention key
tyler: to give a context in section 7, there is a set of unspoken
expectations that user may do to use web securely
... how users view certificates. we can try automate.
<Mez> on phone
<Mez> he's in irc?
<tlr> tyler: can we build some of the user's know-how in terms of uri
fiddling into code?
<ifette> tyler: there are unspoken expectations, many people try to
substitute https for http
<ifette> ... so why can't we automate that
<tlr> ... something useful to do along the lines of what people
currently do ...
<johnath> scribe's back
<Mez> I tink dan needs to be muted
ifette: it is unclear replacing http with https may work. sometime,
misconfiguration in apache server may give a page
... what is the expectation: how do u handle the case YYY
<yngve> Error case: try [15]https://www.spv.no/
ifette: a person may try to click on a page that is secure and hits a
dead end
tyler: the person used the safe web form editor to enter the data
ifette: will it say: do u want to find a secure version of this page?
tyler: it will not be a dialog box. But some messaging that will say
johnath: not the case. can be tampered with.
<Zakim> johnath, you wanted to agree that this often works, but isn't
reliable
johnath: without going into specific examples that ifette mentioned.
Agree that it is useful technique. Lazy way of getting to secure way is
to enter https. Since we are standardizing, I agree with ifette's
concerns that this is not a foolproof method
... I do not think we go in a productive way, advanced users will go
back and try something new.
<ifette> q+
tyler: particular scenario user is in, this is the best thing to do
johnath: I am not sure about that. Failure mode: we refuse to submit
this non-secure way.
<tlr> johnath, you're having voip trouble
<johnath> I'll type - alas
<johnath> My message was that, basically, this trick is often useful,
but not sufficiently so to *mandate* in a w3c spec
tyler: users took time to locate the place where they enter info. If u
say, try again, they will not be happy
<johnath> That if we didn't do this, and instead left it to sites to
expose secure logins, and wrote the safe form filler to just refuse to
participate in insecure logins, forcing the users back to the site UI
tlr: one hand I agree moving folks to a secure page is objectively
better. If we had TLS for HTTP, it would have been better
tyler: http proxies do not support http-tls upgrade
... technology does not exist
tlr: it is not deployed at all. we have two distinct url schemes. Same
domain name, diff scheme
... means that path space might be unrelated
<Mez> MUSTs should probably work all the time
tyler: it is strange that u say that it works only in few cases
<Mez> MAYs might be able to work some of the time
<yngve> Error case: try [16]https://www.spv.no/
yngve: I pasted url above.
... in this case, it is my bank's home page. loading that page gives
the expired certificate.
<tlr> good point, secure servicese on different domain isn't that
rarely seen...
yngve: also I pasted a link to europe car rental yesterday. the Credit
Card information is on a unsecure page.
... getting to this page came via a POST
ifette: basically, 2 things
1. often the case, especially with shared web hosts - mom&pop setup
scribe: first host has ssl setup. they click on the first link . they
are sent to a different site. which is the same server but virtual host
2. we are creating a requirement for a multi-home web sites
scribe: best thing to do. most people is to do submit the form anyway.
Probability of risk is low. Can call Credit Card company that I got
screwed.
tyler: I use this on google
... logging into mail account.
<Mez> I personally have actually had problems with fraudulant
transactions and my credit card company
tyler: banks many offer http
<Mez> I'm wondering how much more it's happening to people
tyler: there are many circumstances that this proposal will fail. IN a
situation that a user is in, the best thing to do is browser try to
find a secure version of the page.
<Mez> could even extract and show all the https: urls displayed, not?
<Mez> no?
ifette: going "BACK" may mean you are going to a POST page
<tlr> tlr: so, the good idea here is that *if* this happens, user MUST
be able to get back
<tlr> ... that can be back button or not; reversibility is key point
...
tlr: whatever u did to the user, it should be an "reversible" state
dan: I type a url, it can be showing content (text, images) etc
... we are usability org. Should not try to fix all evil.
... we need to make recommendations about things that needs fix. But
mainly from usability view.
... we need to make recommendations that work more often than others.
tlr: I said already
ifette: one other Q. What happens once they are on secure website. we
are on the secure editor.
... try for secure version
... they get to a site. they have no history with this page. they need
to fill some fields that are commonly used. Is safe form editor the
answer?
tyler: yes. the safe form editor can be used
... will take fewer keystrokes
... than manual
tlr: another Q.
... lets assume we come with interaction paradigm. User should go to
previous state rather than submit.
... user is presented "try to take me to safer place" or "take me back"
... what to expect? what is the other path to move on when users do not
get to secure TLS form
tyler: in that case johnath's advice is best
... johnath suggested we skip this whole business of finding a secure
page and leave it on the user to do the task of finding a secure
navigation
... this website is badly designed and the user goes scouting for the
safe form
tlr: Q: is the interaction a MUST?
tyler: why do u want to change MUST to SHOULD?
tlr: consensus from the group
tyler: SHOULD is fine
ifette: we are recommending that is not guaranteed to work
... we are creating standard that users have to follow
tyler: there is a really high bar to be set
<ifette> but a spec is a high bar too
tyler: poorly designed website interaction
<tlr> nope
<Mez> want to put in the pointer to defs?
tyler: offering an alternative
<Mez> [17]http://www.ietf.org/rfc/rfc2119.txt
tlr: describes scenarios of usage of MAY
<Mez> 5. MAY This word, or the adjective "OPTIONAL", mean that an item
is
<Mez> truly optional. One vendor may choose to include the item because
a
<Mez> particular marketplace requires it or because the vendor feels
that
<Mez> it enhances the product while another vendor may omit the same
item.
<Mez> An implementation which does not include a particular option MUST
be
<Mez> prepared to interoperate with another implementation which does
<Mez> include the option, though perhaps with reduced functionality. In
the
<Mez> same vein an implementation which does include a particular
option
<Mez> MUST be prepared to interoperate with another implementation
which
<Mez> does not include the option (except, of course, for the feature
the
<Mez> option provides.)
<Mez> . SHOULD This word, or the adjective "RECOMMENDED", mean that
there
<Mez> may exist valid reasons in particular circumstances to ignore a
<Mez> particular item, but the full implications must be understood and
<Mez> carefully weighed before choosing a different course.
Mez: encourage everyone to peruse the normative words
<ifette> next steps on issue?
Mez: discussion has been on the normative word (MAY, SHOULD etc) to be
used and reversibility of user interaction
tlr: we need to add discussion between ifette and tyler about
reverisbility
<Zakim> ifette, you wanted to say we could also drop that section
ifette: I definitely agree with tlr about going back to good state.
Firefox is bloated with memory usage. It is not easy to throw this
constraint. MUST is difficult. SHOULD is probably ok
tyler: responding to reversibility. Open the url in new tab and check
it out
<tlr> I'd like to keep that point consistent with 6.4, where it's
currently a SHOULD; open to discussing that point, though.
tyler: and then close it
<tlr> "it" meaning reversibility
tyler: we need to get feedback from usability studies
<serge> yeah, sure
<serge> it just all takes a lot more time than people realize
ifette: usability studies will be great. But scares me that we fallback
on usability studies
... they suck at educating at internet compatibility
<serge> of course Ian is saying this having never conducted a usability
test before
ifette: usability is necessary but not sufficient for features used by
millions of users
serge: all usabilty testing is critically important.
<ifette> and serge, that would not be accurate
<ifette> and I said it's necessary, but not sufficient
serge: people underestimate the effort at usability studies
... very difficult to conduct usability tests for everything
ifette: I said necessary but not sufficient. Concerns about priorities
and limited time is valid.
... I am not saying usability studies is bad but am saying that it is
not sufficient
<tlr> consensus + CR exit criteria fulfilled...
tyler: rachna and serge bear with me on my hypothesis about usability
<Mez> which are?
<Mez> review, comment, respond,
<Mez> and coding
tyler: if we constructed a web page with a web form asking user CC
number
<Mez> anything else?
<ifette> tyler you were breaking up for a second there
<ifette> ok now
<tlr> mez, effectively, what the group negotiates them to be, within
constraints in process doc.
tyler: what % of users will choose either of the options presented
serge: depends on how u present to the user
<Mez> tlr, I don't think we can negotiate away review, response, and
coding. Or can we?
tyler: I have a webpage with a login form.
<tlr> we can negotiate additional requirements ;)
<Mez> no kidding
tyler: browser shows them a message do not enter information and says
go to the home page again and look for the secure page
... study whether the user will follow the browser advice or they going
to enter the form information
<rachna> instead of asking a yes or no question, you should observe
behavior (they will say "yes" always, but won
tyler: that is a simple screen shot, one boolean question to deal with
<ifette> erm +1 to what serge is saying
tyler: should we create a bundle of tests
... and study how users will interact
serge: we have many proposals that need testing
PHB2: what we need to try and do. how we going to interface with
usability world. More work than rachna and serge can handle. Most of us
are engineers and not scientists (difference of temperament etc)
... engineers are not good at working with other people's thought
processes
... traditional security - feature completion
... usabiility - will the user use the system securely
... my concern with PII bar - will the user use it securely
... if we need to succeed. we need to make usability influence software
engineer in the positive.
<Zakim> ifette, you wanted to say that what tyler described might test
the form editor a bit, but doesn't test the internet breaking and
comaptibility with all the random sites on the web,
PHB2: there is a difference b/w engg practice and science. We
(engineers) cannot solve this by becoming scientists
ifette: we need to agree well in advance as to what we are going to
test
... we can create a PII bar and test it. But we can never test it in
the open world with millions of users.
<serge> So we're abandoning science in favor of faith?
ifette: and guarantee its safe usage
<serge> hey, I just repeated what was said.
<ifette> ack
<ifette> zakim is whispering
ifette: propose a strawman poll to change it to MAY
tyler: this was the concern I had before (worrying about the text of
the recommendation without testing)
<serge> but aren't others here arguing for not using objective data?
tyler: I am working on prototyping the user seeking the secure resource
<tlr> serge, no. The argument is to have others do that work, instead
of the group doing the research.
tyler: personally, I am not affected with the strawman poll
<serge> okay, sure, but if no one steps up, nothing gets done.
tlr: I would like to see the reversibility text
yngve: one concern about tabs
<Mez> if no one steps up, I choose the next step
yngve: user may not be prepared that it will happen
<tlr> I'd recommend against tabs, rather say "should be reversible,
instructions available" or some such.
<tlr> ACTION: tyler to draft reversibility text for 7.2.4 [recorded in
[18]http://www.w3.org/2008/01/09-wsc-minutes.html#action01]
<trackbot-ng> Created ACTION-368 - Draft reversibility text for 7.2.4
[on Tyler Close - due 2008-01-16].
Mez: tyler is willing to take action item on reversibility text
<tlr> tyler, action ok like that?
ifette: strawman poll?
Mez: issue and the minutes of the meeting
... next step ?
<serge> as I've said from the start, EVERY proposal should have to go
through prototyping and testing for us to consider it
tyler: next step - prototype - change language after testing
ifette: understand that tyler is prototype - usability testing. But my
concerns will not be addressed
tlr: then the Q is what is our expectation.....
Mez: something u want to propose
tlr: I can drop a note into the tracker. I do not want to lose track of
a concern of a member that this should be "MAY"
Mez: am flexible about it
ifette: am happy to open an issue
tyler: when you open the issue, please add information about your
concerns that you want it to be a "MAY"
tlr: I will take an action to draft words about interaction with url
schemes
<tlr> ACTION: thomas to draft some language about webarch interactions
for ISSUE-123 [recorded in
[19]http://www.w3.org/2008/01/09-wsc-minutes.html#action02]
<trackbot-ng> Created ACTION-369 - Draft some language about webarch
interactions for ISSUE-123 [on Thomas Roessler - due 2008-01-16].
tyler: when you have hit the sand, trying to save the user
... what is the scenario
Summary of Action Items
[NEW] ACTION: thomas to draft some language about webarch interactions
for ISSUE-123 [recorded in
[20]http://www.w3.org/2008/01/09-wsc-minutes.html#action02]
[NEW] ACTION: tyler to draft reversibility text for 7.2.4 [recorded in
[21]http://www.w3.org/2008/01/09-wsc-minutes.html#action01]
[End of minutes]
__________________________________________________________________
Minutes formatted by David Booth's [22]scribe.perl version 1.128
([23]CVS log)
$Date: 2008/01/16 16:07:30 $
References
1. http://www.w3.org/
2. http://lists.w3.org/Archives/Public/public-wsc-wg/2008Jan/0064.html
3. http://www.w3.org/2008/01/09-wsc-irc
4. http://www.w3.org/2008/01/09-wsc-minutes.html#agenda
5. http://www.w3.org/2008/01/09-wsc-minutes.html#item01
6. http://www.w3.org/2008/01/09-wsc-minutes.html#ActionSummary
7. http://www.amazon.com/dotCrime-Manifesto-Stop-Internet-Crime/dp/0321503589
8. http://www.w3.org/2007/12/19-wsc-minutes.html
9. http://lists.w3.org/Archives/Public/public-wsc-wg/2008Jan/0064.html
10. http://lists.w3.org/Archives/Public/public-wsc-wg/2008Jan/0038.html
11. http://www.w3.org/2006/WSC/track/issues/123
12. http://lists.w3.org/Archives/Public/public-wsc-wg/2007Dec/0106.html
13. http://www.w3.org/TR/wsc-xit/#safebar-must-have-tls
14. http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#safebar-must-have-tls
15. https://www.spv.no/
16. https://www.spv.no/
17. http://www.ietf.org/rfc/rfc2119.txt
18. http://www.w3.org/2008/01/09-wsc-minutes.html#action01
19. http://www.w3.org/2008/01/09-wsc-minutes.html#action02
20. http://www.w3.org/2008/01/09-wsc-minutes.html#action02
21. http://www.w3.org/2008/01/09-wsc-minutes.html#action01
22. http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
23. http://dev.w3.org/cvsweb/2002/scribe/
--
Thomas Roessler, W3C <tlr@w3.org>
Received on Wednesday, 16 January 2008 16:08:09 UTC