- From: Thomas Roessler <tlr@w3.org>
- Date: Wed, 5 Mar 2008 19:52:48 +0100
- To: WSC WG <public-wsc-wg@w3.org>
Minutes from our meeting on 2008-02-27 were approved and are
available online here:
http://www.w3.org/2008/02/27-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
27 Feb 2008
See also: [2]IRC log
Attendees
Present
Thomas Roessler, Mary Ellen Zurko, Tyler Close, Ian Fette, Jan
Vidar Krey, Anil Saldhana, Johnathan Nightingale, Hal Lockhart,
Rachna Dhamija, Maritza Johnson, Bill Eburn, Phill Hallam-Baker,
Stephen Farrell, Yngve Pettersen, Serge Egelman
Regrets
Tim_H, Dan_S, Luis_B, Bill_D
Chair
Mez
Scribe
tlr
Contents
* [3]Topics
1. [4]administrivia
2. [5]previous meeting's minutes
3. [6]action item closures
4. [7]open action items, 2nd try
5. [8]anything lost due to inactivity?
6. [9]agenda bashing
7. [10]logistics for next face-to-face
8. [11]access-control update
9. [12]low fi prototyping of security confidence estimate
* [13]Summary of Action Items
__________________________________________________________________
administrivia
<johnath> looks like progress now
(various musings about success dialogues)
I still am
<stephenF> what's the web conf url?
<johnath> stephenF: [14]http://www.webdialogs.com
<Mez> [15]http://www.w3.org/2008/02/20-wsc-minutes.html
<stephenF> ta
previous meeting's minutes
[16]http://www.w3.org/2008/02/20-wsc-minutes.html
mez: well, it seems like we wanted to publish use cases as a note, as
opposed to going to Last Call
... so do we agree that the resolution was MEANT to be publication as
Note?
... thomas, please manipulate the minutes accordingly
tlr: nods
RESOLUTION: we meant Publish as Note, and approve that
<scribe> ACTION: thomas to work with tyler to get wsc-usecases
published as note [recorded in
[17]http://www.w3.org/2008/02/27-wsc-minutes.html#action01]
<trackbot-ng> Created ACTION-396 - Work with tyler to get wsc-usecases
published as note [on Thomas Roessler - due 2008-03-05].
<johnath> Ah, quite so!
action item closures
mez: no issues there?
yngve: a bit of a complaint about the web conferencing thing
... they say I don't have the right browser ...
... I'd rather not have to change user agent ...
mez: sorry, it's the only thing I could get hold of on short notice
<Mez>
[18]http://lists.w3.org/Archives/Public/public-wsc-wg/2008Feb/0053.html
open action items, 2nd try
mez: any issues?
nope
anything lost due to inactivity?
mez: none
<Mez> Logistics for next face-to-face meeting
<Mez>
[19]http://lists.w3.org/Archives/Member/member-wsc-wg/2008Feb/0010.html
<Mez> Update on access-control
<Mez>
[20]http://lists.w3.org/Archives/Public/public-appformats/2008Feb/0275.
html
tlr: before we go to the agenda bashing, want to beat up Phil
... to get ACTION-387 done ...
agenda bashing
<PHB2> what is the web conf code? IO can't find the Mez missive
<maritzaj> 3336389
mez: thomas asked for next f2f logistics and access-control
... anything else?
... finally the thing that was on the agenda -- "security confidence
estimate"
... next meeting is March 5
tlr: while we're talking "next metings", I think 12 March needs to be
cancelled
ian: was?
tlr: 5 March next, then 19 March, cancel 12 March.
<Mez> Logistics for next face-to-face meeting
<Mez>
[21]http://lists.w3.org/Archives/Member/member-wsc-wg/2008Feb/0010.html
logistics for next face-to-face
[22]http://www.w3.org/2006/WSC/Group/logistics-osl.html
[23]http://www.w3.org/2002/09/wbs/39814/wscf2fosl/
yngve: hotels generally full. Please book early, and avoid surprises.
... you typically can cancel hotel bookings ...
... just to mention an anecdote, even state dept had to ...
... dump diplomats out of town ...
mez: I have an anecdote, too!
yngve: would be good to know if we need to expand the block early
mez: btw, I will need to use an IBM approved hotel
<scribe> ACTION: thomas to add "will use the opera block" to
registration form [recorded in
[24]http://www.w3.org/2008/02/27-wsc-minutes.html#action02]
<trackbot-ng> Created ACTION-397 - Add \"will use the opera block\" to
registration form [on Thomas Roessler - due 2008-03-05].
ifette: what's the hotel price?
<serge> it looked like around $140 at the top end
johnath: $140 if you're paid in the wrong dollar
<hal> no info on F2F on [25]http://www.w3.org/2006/WSC/Group/
mez: anything else
tlr: what's your deadline?
yngve: not sure how quickly
... but the sooner the better ...
<scribe> ACTION: thomas to link oslo logistics from WSC/Group [recorded
in [26]http://www.w3.org/2008/02/27-wsc-minutes.html#action03]
<trackbot-ng> Created ACTION-398 - Link oslo logistics from WSC/Group
[on Thomas Roessler - due 2008-03-05].
<johnath> FYI - westhotel.no is just the Oslo Best Western
<Mez> Update on access-control
<Mez>
[27]http://lists.w3.org/Archives/Public/public-appformats/2008Feb/0275.
html
access-control update
tlr: Mozilla said they *won't* ship an implementation that uses ambient
auth information
... expect quite a bit of discussion to come up ...
low fi prototyping of security confidence estimate
<Mez> 7) Low fi prototyping of security confidence estimate
<Mez> [28]http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#page-score
<Mez>
[29]http://lists.w3.org/Archives/Public/public-wsc-wg/2008Feb/0051.html
<Mez>
[30]http://lists.w3.org/Archives/Member/member-wsc-wg/2008Feb/0007.html
<Mez> There seemed to be general agreement that we would not go to LC
with anything that was not at least lo fi prototyped (unless it was the
sort of robustness recommendation where only lack of compliance could
be prototyped). Working through the prototyping of SCE in a meeting
seemed to be the only possibility for it to make it to LC in June.
mez: I think I was the only one who followed up
<ifette> mez: I cheated and did work
<Mez>
[31]http://lists.w3.org/Archives/Public/public-wsc-wg/2008Feb/0051.html
<rachna> At the f2f, Hal mentioned using the Netcraft toolbar as an
example
<rachna> [32]http://toolbar.netcraft.com/
hal: what was the question?
rachna: you mentioned that the thing (and the bars that it shows about
risk confidence...)
hal: risk rating; red / green / thermometer
... information from their database ...
... they have records; can tell you how old web site is ...
... country, couple things aroudn ...
mez: nobody seemed fit to turn that into some proposal
<serge> yeah, it's really nice for the user's perspective, because most
websites have a small sliver of red
mez: anybody regretting that?
ifette: I don't regret seeing that proposed ...
... what's the country supposed to tell you ...
... US web site might easily pull in malware from Russia ...
<Mez> there is no plan, other than whatever is in xit that isn't
"making it"
ifette: not clear that it's useful information at all ...
hal: thermometer display as an example
<rachna> The problem is that whatever users see frequently becomes a
"legitimate" indicator
mez: anybody else want to propose something?
<Mez> ack stephen f
<Zakim> stephenF, you wanted to ask what's the plan for post-June
proposals in this space
stephen: wondering if there is or is not a plan that we come back to
after June?
mez: stuff that's being left out
... SCE is one of these things ...
... sense at f2f was that it's not well fleshed out enough to consider
it ...
... people wanted to see *something* ...
... that's what we're looking at ...
rachna: chance for stuff to come back after June?
mez: if we still exist then, why not
serge: regarding the netcraft toolbar, there's a study known which
found this one pretty useless
... it's in the shared bookmarks ...
... look for "toolbar" ...
<Zakim> ifette, you wanted to discuss mez' proposal
mez: want there to be a conscious decision on SSL state
ifette: rereading MEZ's proposal
... key point is that (reads e=mail) ...
<tyler>
[33]http://www.simson.net/ref/2006/CHI-security-toolbar-final.pdf
tlr: there are some changes in the pipeline that might affect this ...
... basically, smaller problems ...
mez: mumble
<Mez> [34]http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#typesoftls
ifette: if somebody decides that people don't really understand
difference between these levels ...
... that should be a good thing ...
... it seems the current idea is a tri-state lock ...
... not sure why that's necessarily better than binary ...
... if implementor wants to give weak same treatment as no tls ...
... not sure why we pick ...
mez: we make that distinction; there were variants of change of
security level ...
... if anything that's explicable only in terms of strong/weak ...
... should make it, then it's possibly important to give signals ...
<yngve> Opera's multiple level description:
[35]http://my.opera.com/yngve/blog/2007/06/19/it-aint-ev-til-its-ev-all
-ev
ifette: thought it wasn't necessarily something that's exposed to user
yngve: just pasted pointer at our multilevel system
... we don't display a padlock if it's not level 3 ...
... mostly binary now ...
tlr: "weakly TLS" was for cases in which something looks fishy, but has
some security properties; idea was "don't tell user about padlock"
hal: if weak tls better than no tls ...
... by having indicator, encourage web sites to use something ...
... if it's just binary, no visible benefit ...
mez: should i take away that it's 2 state vs 3 state?
ifette: my biggest issue was binary vs ternary
... if binary, it boils down to lock as implemented in IE / FF ...
mez: my IE doesn't show a negative symbol
ifette: absence of lock as separate state
... 16x16 block that shows nothing vs 16x16 block that shows lock ...
mez: I didn't mean it to say it should, but as phrased, it probably
does
ifette: if my interpretation was sufficient, I'd be happy
<rachna> I think that we have enough data to know that users don't
notice the absence of indicators
ifette: given talk about current best practices, wouldn't be sad if the
proposal made it in
mez: anybody seeing something in web conf?
<PHB2> not a sausage
mez: so that would mean we should drop anything that makes tri-state
sound attractive
<Mez> remove this
[36]http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#typesoftls
mez: I think it would be removing the second part of the proposal ...
<Mez> remove this
<Mez> The TLS indicator MUST present a state this is only for strongly
TLS
<Mez> protected pages. The TLS indicator SHOULD differentiate between a
page
<Mez> that is weakly TLS-protected, and one that has no TLS protection
at all.
mez: errr, no that's not what I mean
<Mez> Web user agents MUST make information about the [[identity]] of
the Web
<Mez> site that a user interacts with and the state of TLS protection
available.
<Mez> The [Definition: [[identity signal]] ] and [defn TLS indicator]
SHOULD be
<Mez> part of primary user interface during usage modes which entail
the
<Mez> presence of signalling to the user beyond only presenting page
content.
mez: retain change to 6.1.1 that injects some sort of indicator
<Mez> Otherwise, they MUST at least be available through secondary user
<Mez> interface. Note that there may be usage modes during which this
<Mez> requirement does not apply: For example, a Web browser which is
<Mez> interactively switched into a no-chrome, full-screen presentation
mode
<Mez> need not preserve any security indicators in primary user
interface.
<Mez> User interactions to access this identity signal or the TLS
indicator MUST
<Mez> be consistent across all Web interactions. This includes
interactions
<Mez> during which the Web user agent has no trustworthy information
about the
<Mez> [[identity]] of the Web site that a user interacts with, and when
TLS has
<Mez> not been used to protect those interactions. In the former case,
user
<Mez> agents SHOULD indicate that no information is available. In the
latter
<Mez> case, they SHOULD indicate the interaction was not TLS protected.
<Mez> User agents with a visual user interface that make the identity
signal and
<Mez> TLS indicator available in primary user interface SHOULD do so in
a
<Mez> consistent visual position.
<serge> wait, this reads like only EV certs will cause TLS icons to
appear?
<serge> it sthat a correct interpretation?
mez: uh, there's something on EV there?
ifette: strongly TLS protected
... GoDaddy domain validated cert qualifies ...
<serge> yeah, you lose
mez: I only ripped out strong
<serge> well it doesn't matter, because that's not the current text
ifette: what I liked first sentence that said "there must be state for
strongly TLS protected"
... I think the states should be "strongly TLS protected" vs
"everything else"
serge: the text that you just pasted says that the identity of the site
must be known
mez: I haven't changed identity stuff; changing that is not part of my
proposal ..
... I took the current text ...
... and added stuff about TLS indicator ...
... proposal is meant to be adding stuff about TLS indicator ...
serge: going by what you pasted
... says trustworthy information regarding identity of web site ...
<ifette> My proposed text: The TLS indicator SHOULD have two states.
One state SHOULD indicate that the connection is Strongly TLS
protected. The other state SHOULD indicate that the connection is not
Strongly TLS protected.
<serge> okay, so then what happens to self signed ones?
<serge> the no-TLS indicator?
<serge> that's very confusing
<ifette> serge, probably
<serge> and that would be confusing
<ifette> at least, until it has passed the probation period or whatever
<serge> "uhh, it says HTTPS, but the other indicator says no TLS"
<Mez> Web user agents MUST make information about the state of TLS
protection available.
<Mez> The [defn TLS indicator] SHOULD be
<Mez> part of primary user interface during usage modes which entail
the
<Mez> presence of signalling to the user beyond only presenting page
content.
<Mez> Otherwise, it MUST at least be available through secondary user
<Mez> interface. Note that there may be usage modes during which this
<Mez> requirement does not apply: For example, a Web browser which is
<Mez> interactively switched into a no-chrome, full-screen presentation
mode
<Mez> need not preserve any security indicators in primary user
interface.
<Mez> User interactions to access the TLS indicator MUST
<Mez> be consistent across all Web interactions.
<Mez> This includes when TLS has
<Mez> not been used to protect those interactions. In this case, web
user agents
<Mez> SHOULD indicate the interaction was not TLS protected.
<Mez> User agents with a visual user interface that make the
<Mez> TLS indicator available in primary user interface SHOULD do so in
a
<Mez> consistent visual position.
<ifette> +1 to tlr
tlr: I think it should be secure page, strongly tls protected
The TLS indicator SHOULD have two states. One state SHOULD indicate
that the web page that the user interacts with currently is a Strongly
TLS protected page. The other state SHOULD indicate that the connection
is not Strongly TLS protected.
(roughly)
phb: if it's only strong TLS, it's not a TLS indicator
ifette: nobody said ev, we talked about properly configured domain
certified
pbaker: this is supplemental to EV indicator?
<ifette> supplimental, i would think
pbaker: is this orthogonal to EV indicator or replacing it?
<ifette> i would not intend this to replace the ev indicator
pbaker: are we *intending* to override EV indicator ...
<ifette> i would think this is a lock refinement
mez: we're talking about TLS / strong TL Sindicator, not Ev
serge: biggest problem is that on some pages there is going to be https
and another indicator claiming no tLS
... which for the users who bother to notice indicator is going to be
confusing ...
... can't just have two states between not strongly and strongly
protected ...
... there should be at least three states if we differentiate between
different https uri states ...
mez: confusion because of https url
... which wouldn't be consistently aligned with other idnicators ...
... is that your argument?
<Zakim> stephenF, you wanted to ask what if both TLS indicator and EV
indicator? (if there will be an EV indicator in xit)
serge: it is
<rachna> Serge, I am surprised to hear that you think more states will
help maters
<serge> rachna: I don't :)
<rachna> more states = more confusion
stephen: we should decide whether both should be up or one should
replace the other
<serge> rachna: I think that'll make this idea less terrible :)
stephen: if there's separate strong TLS and EV, then we should talk
about replacing each other
<Zakim> ifette, you wanted to say that https with lock is confusing if
the connection is using the null cipher
mez: not sure if anything could cause that problem
<serge> rachna: but at the very least I think that we shouldn't show
the absence of the TLS indicator, instead maybe show it with a red
circle around it when TLS is missing
ifette: the way I'm reading proposed text is basically "if there's
strongly secure page, show lock. otherwise, don't"
... serge's point is "https, no lock" means they don't understand
what's going on ...
... point I would like to make is we're nowhere saying that this is
only treatment ...
... all we're saying is "if it's not good, don't show lock"
<PHB2> +1
ifette: all this says is "if not secure page, don't show lock"
<Mez> I had attempted to say that there should be a incdicator whether
or not there is tls (strong or otherwise)
ifette: i could see a version of browsers doing no lock, but having an
info bar
... so I don't think the lack of consistency is inherent to this
FWIW, I don't see anything that's going on in that visual session,
either.
<Mez> In this case, web user agents
<Mez> SHOULD indicate the interaction was not TLS protected.
yngve: opera is probably closest to what Ian was talking about
... currently, not showing padlock ...
... if there's mixed security problem ...
... or OCSP problem ...
... or weak keys involved on encryption ...
... we do show more information in 2ndary chrome ...
... want to do more there than we currently do ...
... think strong TLS indicator should be specified for primary chrome
...
mez: the primary / secondary stuff was taken from identity signal
<Mez>
[37]http://lists.w3.org/Archives/Public/public-wsc-wg/2008Feb/0051.html
(confusion)
<Mez> Web user agents MUST make information about the state of TLS
protection available.
<Mez> The [defn TLS indicator] SHOULD be
<Mez> part of primary user interface during usage modes which entail
the
<Mez> presence of signalling to the user beyond only presenting page
content.
<Mez> Otherwise, it MUST at least be available through secondary user
<Mez> interface. Note that there may be usage modes during which this
<Mez> requirement does not apply: For example, a Web browser which is
<Mez> interactively switched into a no-chrome, full-screen presentation
mode
<Mez> need not preserve any security indicators in primary user
interface.
<Mez> User interactions to access the TLS indicator MUST
<Mez> be consistent across all Web interactions.
<Mez> This includes when TLS has
<Mez> not been used to protect those interactions. In this case, web
user agents
<Mez> SHOULD indicate the interaction was not TLS protected.
<Mez> User agents with a visual user interface that make the
<Mez> TLS indicator available in primary user interface SHOULD do so in
a
<Mez> consistent visual position.
<Mez> The TLS indicator SHOULD have two states. One state SHOULD
indicate that the connection is Strongly TLS protected. The other state
SHOULD indicate that the connection is not Strongly TLS protected.
<Mez> The TLS indicator SHOULD have two states. One state SHOULD
indicate that the web page that the user interacts with currently is a
Strongly TLS protected page. The other state SHOULD indicate that the
connection is not Strongly TLS protected.
<Mez> The TLS indicator MUST present a state this is only for strongly
TLS
<Mez> protected pages. The TLS indicator SHOULD differentiate between a
page
serge: there are plenty of studies in the shared bookmarks re lock
<Mez> that is weakly TLS-protected, and one that has no TLS protection
at all.
serge: that people don't notice the lcok ...
... I've seen people notice https before noticing lock ...
... still have potential scenario where someone notices https ...
<stephenF> That's all too much text for me to consider in detail now.
I'll read xit whenever.
mez: my sense is that everybody is ok with the big paragraph.
<Mez> Web user agents MUST make information about the state of TLS
protection available.
<Mez> The [defn TLS indicator] SHOULD be
<Mez> part of primary user interface during usage modes which entail
the
<Mez> presence of signalling to the user beyond only presenting page
content.
<Mez> Otherwise, it MUST at least be available through secondary user
<Mez> interface. Note that there may be usage modes during which this
mez: so I'm putting it in IRC again ...
<Mez> requirement does not apply: For example, a Web browser which is
<Mez> interactively switched into a no-chrome, full-screen presentation
mode
<Mez> need not preserve any security indicators in primary user
interface.
<Mez> User interactions to access the TLS indicator MUST
<Mez> be consistent across all Web interactions.
<Mez> This includes when TLS has
<Mez> not been used to protect those interactions. In this case, web
user agents
<Mez> SHOULD indicate the interaction was not TLS protected.
<Mez> User agents with a visual user interface that make the
<Mez> TLS indicator available in primary user interface SHOULD do so in
a
<Mez> consistent visual position.
<Mez> variant 1) The TLS indicator SHOULD have two states. One state
SHOULD indicate that the connection is Strongly TLS protected. The
other state SHOULD indicate that the connection is not Strongly TLS
protected.
mez: I think we have three proposals on the table here ...
<Mez> variant 2) The TLS indicator SHOULD have two states. One state
SHOULD indicate that the web page that the user interacts with
currently is a Strongly TLS protected page. The other state SHOULD
indicate that the connection is not Strongly TLS protected.
<Mez> variant 3) The TLS indicator MUST present a state this is only
for strongly TLS
<Mez> protected pages. The TLS indicator SHOULD differentiate between a
page
<Mez> that is weakly TLS-protected, and one that has no TLS protection
at all.
<yngve> Yngve's take on what serge was talking about:
[38]http://my.opera.com/yngve/blog/show.dml/461932
ifette: don't see Thomas's change in here
mez: 2nd one
ifette: happy if 2nd one is supposed to cover mixed content
considerations
... also, we're not saying there are no other indicators, right?
phb: to serge, think we need to first specify that there must be an
unambiguous indicator with correct semantics
... consider triage ...
... later on, go back and propose withdrawing some of the confusing and
conflicting semantics ...
... in particular things like https -- should ask whether browsers
should continue to display https when user hasn't input it ...
mez: looking forward to concrete proposal on that
phb: premature in round 1 to propose withdrawing that
... let's first get document out that say "consistent indicators that
give users a fighting chance" ...
<Mez> "give users a fighting chance" - I do like that one
phb: getting rid of clutter should be phase 2 ...
<Zakim> stephenF, you wanted to ask that we don't strawpoll just now,
but do it on the list or next week
stephenF: mostly, seems like things are fairly reasonable, but I'm
confused ...
... would hope we can look at text on the mailing list, decide there,
or next week ...
mez: would rather we make decisions at meetings
stephen: multiple paragraphs in editor's draft?
<serge> this is insanity!
<johnath> [39]http://pastebin.mozilla.org/
<johnath> use that!
<johnath> it's what we use
<johnath> :)
stephen: can we have this in the draft?
<johnath> mez ^^
stephen: I don't think it's well-prepared enough ...
<serge> can we move on?
mez: ok, so I'll prepare a place in the wiki
<rachna> I'm off IRC for a few minutes but will be on the phone.
hal: what's variant 1 vs variant 2?
ifette: variant 2 covers mixed content
<serge> so it seems like we're arguing about redefining the TLS icon,
when most users don't notice them, and those who do don't currently
know what they mean.
hal: want intended difference
ifette: mixed content
<Mez> [40]http://www.w3.org/2006/WSC/wiki/TlsIndicator
hal: does strongly protected TLS include EV?
ifette: EV + proper domain-validated
hal: they don't have to be augmented assurance?
... is that right?
ifette: yes
yngve: https that user also sees is good point, but in part can't get
away from that
... posted about it in articles ...
<Mez> we're going to the straw poll right after yngve's comments folks
<ifette> [41]http://pastebin.mozilla.org/346814 :-)
hal: don't getting variant 3
... it hasn't have grammar ...
... is this that or what?
[42]http://www.w3.org/2006/WSC/wiki/TlsIndicator
<Zakim> stephenF, you wanted to ask that variant 2 "SHOULD have 2
states" is a bit odd
stephen: If it has 17 states, is it compliant?
tlr: i.e., exactly 2 or at least?
ifette: think exactly
<serge> are we not going to get to Action 389?
<serge> because I need to go soon
stephen: variant 4 -- MUST instead of SHOULD
<ifette> ACTION-389?
<trackbot-ng> ACTION-389 -- Serge Egelman to write up error levels --
due 2008-02-13 -- PENDINGREVIEW
<trackbot-ng> [43]http://www.w3.org/2006/WSC/track/actions/389
stephen: otherwise same as variant 2
<serge> I SHOULD take a shower now, since I MUST go to work today
yngve: what opera has when it comes to EV is no padlock, padlock,
padlock on green
<johnath> I think I just fell off the call
ifette: say there MAY be addtl state for AA certs used
<Mez> you can still straw poll
<ifette> The indicator MAY have an additional state to indicate that
the connection is protected with an AA certificate.
ifette: happy if that's part of any of them
... variant 2 ...
<tyler> Since we're adding variants, could we have one for drop this
proposal entirely?
mez: presumption is that we have 2, 3, or 4
<ifette> Variant 2 has my vote
<hal> 3
<tyler> none of the above
<anil> I do not see the variants. where are they>?
<jvkrey> [44]http://www.w3.org/2006/WSC/wiki/TlsIndicator
<ifette> [45]http://www.w3.org/2006/WSC/wiki/TlsIndicator
<anil> thank u
<serge> is there a none of the above option?
<jvkrey> 3
<maritzaj> 3
<serge> 3, if these are the only choices
<PHB2> 4
abstain
<PHB2> actually change to 3
<johnath> I'm with serge, I think there's substantial information
suggesting that it's near-irrelevant, but 3 among the options
<anil> 2min
<stephenF> i prefer 3 but that preference could change if the
definition of strongly-protected changed
<anil> 4
<yngve> 2 but "connection" should be clearer and refer to elements
loaded as part of the page
ifette: saw a lot of support for variant 3
... which basically indicates that lock should be tri-state ...
... strongly TLS protected, weakly, and no TLS ...
... not a usability expert ...
... interested in hearing from Rachna and SErge ...
... heard Rachna say more states mean more confusion ...
... wondering whether the people voting for variant 3 are saying that
there should be indication "weak vs strong", somewhere ...
... or tri-state ...
yngve: opera had that, moved away from it
hal: how did you determine that it was confusing?
yngve: numbers, etc
<Mez> 2 - ifette
<Mez> 3 - hal, jvkrey, maritzaj, serge, phb2, johnath, stephenf, yngve
<Mez> 4 - anil
<Mez> abstain - tyler, tlr, mez
ifette: 2 also had yngve
<Mez> 2 - ifette, yngve
<Mez> 3 - hal, jvkrey, maritzaj, serge, phb2, johnath, stephenf
<Mez> 4 - anil
<Mez> abstain - tyler, tlr, mez
stephenF: difficulty picking -- all this depends very much on strongly
protected definition
... the result of that could change my vote ...
mez: what we've got now is sth we can carry forward to june
... that consists of first paragrph and var 3 ...
... with as little inconsistencies and all that as we can get ...
ifette: are we happy carrying var 3 forward?
... this is sth that opera dropped, and ff isn't showing broken locks
...
... disturbing to me that we are making that suggesting ...
serge: I think we should know what this lookslike
<Zakim> ifette, you wanted to agree with serge, and say that I am
really uncomfortable recommending something that all browsers just
dropped
ifette: think serge has a good point here
<Zakim> Thomas, you wanted to note that there's "feat;ure at risk"
ifette: don't think this can go into last call ...
<johnath> whoops - phone dropped again
<Zakim> ifette, you wanted to discuss features at risk
tlr: let me observe that there are features at risk which get pruned
during candidate rec.
ifette: strongly opposed to recommending sth that all browsers recently
dropped
... think this is a bad move ...
<serge> why?
<serge> we dont' know why they dropped them!
mez: note one browser vendor voted for that variant
<stephenF> did all browsers recently drop tri-state? I didn't hear
that, just that opera did and maybe FF3
hal: I think that right now this is the best option; could probably be
persuaded otherwise
<serge> best partice is another term for "we have no evidence that this
really works"
mez: if there's current practice that we recognize as good, should put
that in the spec
... rest of sce is out of spec for June ...
... nobody proposed any of that ...
... think there's group support and consensus on this ..
ifette: I object, *not* formally, want to go through this on mail
<scribe> ACTION: ifette to try to craft some text that revolves around
weak/strong signalling [recorded in
[46]http://www.w3.org/2008/02/27-wsc-minutes.html#action04]
<trackbot-ng> Created ACTION-399 - Try to craft some text that revolves
around weak/strong signalling [on Ian Fette - due 2008-03-05].
Mez: next meeting: march 5th
... attempt to use web conference declared a failure ...
<serge> when are we going to discuss error levels?
<serge> I need to iron out the text
<serge> I don't want it included as written, I know it needs some minor
editing
mez: does somebody want it on the agenda
serge: well....
ACTION-399?
<trackbot-ng> ACTION-399 -- Ian Fette to try to craft some text that
revolves around weak/strong signalling -- due 2008-03-05 -- OPEN
<trackbot-ng> [47]http://www.w3.org/2006/WSC/track/actions/399
tlr: will go through it
adjourned
Summary of Action Items
[NEW] ACTION: ifette to try to craft some text that revolves around
weak/strong signalling [recorded in
[48]http://www.w3.org/2008/02/27-wsc-minutes.html#action04]
[NEW] ACTION: thomas to add "will use the opera block" to registration
form [recorded in
[49]http://www.w3.org/2008/02/27-wsc-minutes.html#action02]
[NEW] ACTION: thomas to link oslo logistics from WSC/Group [recorded in
[50]http://www.w3.org/2008/02/27-wsc-minutes.html#action03]
[NEW] ACTION: thomas to work with tyler to get wsc-usecases published
as note [recorded in
[51]http://www.w3.org/2008/02/27-wsc-minutes.html#action01]
[End of minutes]
__________________________________________________________________
Minutes formatted by David Booth's [52]scribe.perl version 1.133
([53]CVS log)
$Date: 2008/03/05 18:51:47 $
References
1. http://www.w3.org/
2. http://www.w3.org/2008/02/27-wsc-irc
3. http://www.w3.org/2008/02/27-wsc-minutes.html#agenda
4. http://www.w3.org/2008/02/27-wsc-minutes.html#item01
5. http://www.w3.org/2008/02/27-wsc-minutes.html#item02
6. http://www.w3.org/2008/02/27-wsc-minutes.html#item03
7. http://www.w3.org/2008/02/27-wsc-minutes.html#item04
8. http://www.w3.org/2008/02/27-wsc-minutes.html#item05
9. http://www.w3.org/2008/02/27-wsc-minutes.html#item06
10. http://www.w3.org/2008/02/27-wsc-minutes.html#item07
11. http://www.w3.org/2008/02/27-wsc-minutes.html#item08
12. http://www.w3.org/2008/02/27-wsc-minutes.html#item09
13. http://www.w3.org/2008/02/27-wsc-minutes.html#ActionSummary
14. http://www.webdialogs.com/
15. http://www.w3.org/2008/02/20-wsc-minutes.html
16. http://www.w3.org/2008/02/20-wsc-minutes.html
17. http://www.w3.org/2008/02/27-wsc-minutes.html#action01
18. http://lists.w3.org/Archives/Public/public-wsc-wg/2008Feb/0053.html
19. http://lists.w3.org/Archives/Member/member-wsc-wg/2008Feb/0010.html
20. http://lists.w3.org/Archives/Public/public-appformats/2008Feb/0275.html
21. http://lists.w3.org/Archives/Member/member-wsc-wg/2008Feb/0010.html
22. http://www.w3.org/2006/WSC/Group/logistics-osl.html
23. http://www.w3.org/2002/09/wbs/39814/wscf2fosl/
24. http://www.w3.org/2008/02/27-wsc-minutes.html#action02
25. http://www.w3.org/2006/WSC/Group/
26. http://www.w3.org/2008/02/27-wsc-minutes.html#action03
27. http://lists.w3.org/Archives/Public/public-appformats/2008Feb/0275.html
28. http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#page-score
29. http://lists.w3.org/Archives/Public/public-wsc-wg/2008Feb/0051.html
30. http://lists.w3.org/Archives/Member/member-wsc-wg/2008Feb/0007.html
31. http://lists.w3.org/Archives/Public/public-wsc-wg/2008Feb/0051.html
32. http://toolbar.netcraft.com/
33. http://www.simson.net/ref/2006/CHI-security-toolbar-final.pdf
34. http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#typesoftls
35. http://my.opera.com/yngve/blog/2007/06/19/it-aint-ev-til-its-ev-all-ev
36. http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#typesoftls
37. http://lists.w3.org/Archives/Public/public-wsc-wg/2008Feb/0051.html
38. http://my.opera.com/yngve/blog/show.dml/461932
39. http://pastebin.mozilla.org/
40. http://www.w3.org/2006/WSC/wiki/TlsIndicator
41. http://pastebin.mozilla.org/346814
42. http://www.w3.org/2006/WSC/wiki/TlsIndicator
43. http://www.w3.org/2006/WSC/track/actions/389
44. http://www.w3.org/2006/WSC/wiki/TlsIndicator
45. http://www.w3.org/2006/WSC/wiki/TlsIndicator
46. http://www.w3.org/2008/02/27-wsc-minutes.html#action04
47. http://www.w3.org/2006/WSC/track/actions/399
48. http://www.w3.org/2008/02/27-wsc-minutes.html#action04
49. http://www.w3.org/2008/02/27-wsc-minutes.html#action02
50. http://www.w3.org/2008/02/27-wsc-minutes.html#action03
51. http://www.w3.org/2008/02/27-wsc-minutes.html#action01
52. http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
53. http://dev.w3.org/cvsweb/2002/scribe/
Received on Wednesday, 5 March 2008 18:53:37 UTC