- From: Mary Ellen Zurko <Mary_Ellen_Zurko@notesdev.ibm.com>
- Date: Thu, 24 Jan 2008 13:48:01 -0500
- To: public-wsc-wg@w3.org
- Message-ID: <OF0E8E0D99.9B7201C9-ON852573DA.00668CF6-852573DA.00674639@LocalDomain>
Excellent discussion. It always warms my heart to see multiple members of
the WG usefully engaged on working through consensus for our
recommendations. It's what makes the WG work.
Here's my pov:
I've said it before, so needing to say it twice means not only are people
not reading wsc-xit closely, they're also ignoring contentful email from
me. Our Change Of Security Level (COSL) recommendations deal with
warnings. If you want to tie together warnings and the security confidence
estimate, please at least refer to the COSL so that I know you're ignoring
on purpose, and not because you have not read and understood wsc-xit.
It would be a mistake to not address the existing security context
indicators and NOT have an explicit statement on why we're not addressing
them. It would be an oversight of such large proportions as to look lame.
The padlock is one such indicator in existence. We should address it (or
not address it on purpose, either because we can't come to consensus on
what to say about it and displays like it, or for some concrete other
reason). The security confidence estimate is all we have in that space. So
I do want us to consider how it relates to the existing deployed padlock.
If we believe that nothing better can be done in that space, then we
should seriously consider saying so. If we believe something better can be
done, we should say what. If we believe nothing is better than something,
then we should say that.
We cannot have any recommendations where we cannot point to at least one
instantiation as conformant. That means we will need some example, some
(lo fi) prototype, of anything in this space, should it go to LC. We also
need to agree on what usability testing (UT) we can and should do, and do
it. Should is not good without Can.
Mez
From:
<michael.mccormick@wellsfargo.com>
To:
<egelman@cs.cmu.edu>
Cc:
<ifette@google.com>, Timothy Hahn/Durham/IBM@IBMUS, <public-wsc-wg@w3.org>
Date:
01/24/2008 01:20 PM
Subject:
RE: ACTION-374 - proposed re-written text for 6.3, Page Security Score
We could do that but I think browser manufacturers might resist any
attempt to prescribe exactly what the primary SCI UI looks like.
What we probably could do is prototype & test a few UI widgets -- color
bar, cell phone bars, gauge, thermometer -- and then make some SHOULD
recommendations based on what works best or worst.
Or we could say UA manufacturers MUST perform their own usability tests,
and provide W3C guidelines regarding test cases and testing methodology.
Mike
-----Original Message-----
From: Serge Egelman [mailto:egelman@cs.cmu.edu]
Sent: Thursday, January 24, 2008 11:35 AM
To: McCormick, Mike
Cc: ifette@google.com; hahnt@us.ibm.com; public-wsc-wg@w3.org
Subject: Re: ACTION-374 - proposed re-written text for 6.3, Page
Security Score
There's no way of knowing unless we specify *how* the indicator is to
appear and then actually test it. Simply saying, "it should be
displayed to the user" is utterly insufficient. How it is displayed is
more important than what it actually represents, in many cases.
Thus, I don't think we should recommend displaying anything unless we
can describe unambiguously how it will be displayed.
serge
michael.mccormick@wellsfargo.com wrote:
> I predict many users are going to find this type of indicator quite
> useful. Certainly more helpful than today's misleading padlocks &
> colored address bars. If it was up to me or Tim the language would
> say MUST. Ian wants MAY. Splitting the difference and going with
> SHOULD seems like a way to split the difference. Compromise means
> nobody wins. ;-)
>
> ----------------------------------------------------------------------
> --
> *From:* public-wsc-wg-request@w3.org
> [mailto:public-wsc-wg-request@w3.org] *On Behalf Of *Ian Fette
> *Sent:* Thursday, January 24, 2008 12:27 AM
> *To:* Timothy Hahn
> *Cc:* public-wsc-wg@w3.org
> *Subject:* Re: ACTION-374 - proposed re-written text for 6.3, Page
> Security Score
>
> By saying that a user agent MAY elect not to display the indicator,
> but that it SHOULD display the indicator, we're saying we think it's
> useful, but if one wants to ignore that go ahead. I don't think that
> I'm yet willing to go along and say that I think it's useful.
>
> I really want to know what a person is supposed to do when they see
> this indicator. If they see 3/4 bars, what do they do? If they see a
> meter that's somewhere towards the right, what do they do? God forbid
> they see a "78" and have to figure that out. None of these
> representations seem like a good idea to me, and until we can come up
> with an indicator that is actually going to inform user action, I
> really don't think we be saying SHOULD about any of this, with the
> possible exception of noticing a change.
>
> Let's say that I go to my company's webmail, and it has 2/4 bars. I'm
> still going to log in. Let's say I go to a e-commerce site and it has
> 3/4 bars. What does that mean? Is it safe or not? (and I seriously
> doubt that anyone is going to take on the liability of an indicator
> that answers that question in a binary fashion, which is the only way
> this might be useful, if we actually had the data to make that
> decision which we do not).
>
> This still seems way too strong to me.
>
> On Jan 23, 2008 6:46 PM, Timothy Hahn <hahnt@us.ibm.com
> <mailto:hahnt@us.ibm.com>> wrote:
>
>
> Ian,
>
> In addition to the level of indirection I referred to below, I
also
> added this clause:
>
>
> > > The user agent MAY elect to display a visual indicator in
> primary chrome
> > > only when a change in "security confidence estimate" values
is
> observed.
> > >
>
> I added this upon reflection of your and Jonathan's comments on
the
> 16 January call where you seemed to desire to not always show a
> visual indicator.
>
> I still believe that some type of meter that has more than 0/1
> gradations is better than a meter that is binary and also better
> than no meter at all.
>
>
> Regards,
> Tim Hahn
> IBM Distinguished Engineer
>
> Internet: hahnt@us.ibm.com <mailto:hahnt@us.ibm.com>
> Internal: Timothy Hahn/Durham/IBM@IBMUS
> phone: 919.224.1565 tie-line: 8/687.1565
> fax: 919.224.2530
>
>
>
> From:
> "Ian Fette" <ifette@google.com <mailto:ifette@google.com>>
> To:
> Timothy Hahn/Durham/IBM@IBMUS
> Cc:
> public-wsc-wg@w3.org <mailto:public-wsc-wg@w3.org>
> Date: 01/23/2008 05:24 PM
> Subject: Re: ACTION-374 - proposed re-written text for 6.3, Page
> Security Score
>
>
>
> ----------------------------------------------------------------------
> --
>
>
>
> I think that what I was saying on the call, and I heard the same
from
> at least Johnathan, was that it's unclear what it means even if
you
> have a dial, or "3 bars out of 4". At the end, it doesn't help me
> decide whether to proceed or not. The indirection didn't solve
this
> problem.
>
> On Jan 23, 2008 2:13 PM, Timothy Hahn <hahnt@us.ibm.com
> <mailto:hahnt@us.ibm.com>> wrote:
> >
> > Ian,
> >
> > Thanks for the feedback.
> >
> > I tried to express a level of indirection between what is
> displayed (I
> > referred to this as a "visual indicator") and the value itself
> (which I
> > referred to as the "value"). This indirection was meant to
allow
> for a
> > difference between what is displayed and the "raw score" value
> itself.
> >
> > I welcome suggestions on making this more clear in the
write-up.
> >
> > Relative to your desire for MAY vs. SHOULD - given the
different
> opinions of
> > the people that have been discussing this, I made the bold
> decision that
> > SHOULD seemed appropriate.
> >
> >
> > Regards,
> > Tim Hahn
> > IBM Distinguished Engineer
> >
> > Internet: hahnt@us.ibm.com <mailto:hahnt@us.ibm.com>
> > Internal: Timothy Hahn/Durham/IBM@IBMUS
> > phone: 919.224.1565 tie-line: 8/687.1565
> > fax: 919.224.2530
> >
> >
> >
> >
> > From: "Ian Fette" <ifette@google.com
<mailto:ifette@google.com>>
> > To:
> > Timothy Hahn/Durham/IBM@IBMUS
> > Cc:
> > public-wsc-wg@w3.org <mailto:public-wsc-wg@w3.org>
> > Date: 01/23/2008 04:55 PM
> >
> > Subject: Re: ACTION-374 - proposed re-written text for 6.3,
Page
> Security
> > Score
> >
> >
> > ________________________________
> >
> >
> >
> > I'm still unclear on the following two points:
> >
> > The user agent SHOULD provide a visual indicator in primary
chrome
> > which varies relative to the "security confidence estimate"
value.
> > Examples of such visual indicators (non-normative) are gauges,
> > thermometers, a selection of several textual descriptions, and
> > color-gradations.
> >
> > The visual indicator SHOULD be especially conspicuous in
display
> when
> > the "security confidence estimate" value is different than the
value
> > which was observed for the loaded page in previous visits to
the
> > loaded page.
> >
> > It sounds to me like there was a lot of agreement on the call
that
> > changes in this score might be informative. I don't think
there was
> > any agreement that the raw score itself was informative. I
don't
> > understand why we're saying that the score SHOULD be indicated
in
> > primary chrome, nor do I understand why it makes sense to show
it if
> > the score has changed (i.e. "Hey, this was 78 and now it's 68"
-
> > "Great, what does that mean"). I think it may make sense (MAY)
> to call
> > out what changed, but calling out the score (either normally,
or
> even
> > when it changes) still makes no sense to me.
> >
> > I would love to see these SHOULD -> MAY
> >
> > -Ian
> >
> > On Jan 23, 2008 10:41 AM, Timothy Hahn <hahnt@us.ibm.com
> <mailto:hahnt@us.ibm.com>> wrote:
> > >
> > > To Mez:
> > >
> > > I agree with your proposal and will make that be so in the
draft.
> > >
> > > To Mike:
> > >
> > > While I, myself, would prefer stronger language, I worded
the
> updates per
> > > the discussion from the group (during the weekly conference
> call as well
> > as
> > > on the mailing list).
> > >
> > > Regards,
> > >
> > > Tim Hahn
> > > IBM Distinguished Engineer
> > >
> > > Internet: hahnt@us.ibm.com <mailto:hahnt@us.ibm.com>
> > > Internal: Timothy Hahn/Durham/IBM@IBMUS
> > > phone: 919.224.1565 tie-line: 8/687.1565
> > > fax: 919.224.2530
> > >
> > >
> > >
> > >
> > > From: Mary Ellen Zurko/Westford/IBM@IRIS
> > > To:
> > > Timothy Hahn/Durham/IBM@IBMUS
> > > Cc:
> > > public-wsc-wg@w3.org <mailto:public-wsc-wg@w3.org>
> > > Date: 01/23/2008 01:29 PM
> > > Subject: Re: ACTION-374 - proposed re-written text for 6.3,
Page
> > Security
> > > Score
> > > ________________________________
> > >
> > >
> > >
> > > I propose that you also change the title of the section to
> "Security
> > > Confidence Estimate"
> > >
> > > Mez
> > >
> > >
> > >
> > >
> > >
> > >
> > > From:
> > > Timothy Hahn/Durham/IBM@IBMUS
> > > To:
> > > public-wsc-wg@w3.org <mailto:public-wsc-wg@w3.org>
> > > Date:
> > > 01/23/2008 11:29 AM
> > > Subject: ACTION-374 - proposed re-written text for 6.3,
Page
> Security
> > Score
> > > ________________________________
> > >
> > >
> > >
> > >
> > >
> > > Hi all,
> > >
> > > From last week's meeting (16 January 2008) I took an action
to
> propose
> > > re-written text for the "Page Security Score" section.
> > >
> > > From the latest wsc-xit draft, the current text reads:
> > >
> > > --- Start ---
> > > 6.3 Page Security Score
> > >
> > > See also: ISSUE-129
> > >
> > > Please refer to the following entries in the Working Group's
> Wiki for
> > > relevant background information:
> RecommendationDisplayProposals/PageScore
> > >
> > > The user agent MUST reduce the state of all security context
> information
> > > made available to a single value. A partial order MUST be
> defined on the
> > set
> > > of possible values.
> > >
> > > The user agent MUST make the security context information
> value available
> > to
> > > the end user, in either primary or secondary chrome.
> > >
> > > The user agent MUST make the formula by which the value is
> calculated
> > > available to the end user. Documentation of the user agent
is the
> > likeliest
> > > place.
> > >
> > > The form of the indicator of this value will depend on the
> user agent and
> > > end user abilities. The user agent SHOULD provide a a
primary
> chrome
> > > indicator
> > >
> > > --- End ---
> > >
> > > Here is my proposed re-written text:
> > >
> > > --- Start ---
> > > 6.3 Page Security Score
> > >
> > > See also: ISSUE-129
> > >
> > > Please refer to the following entries in the Working Group's
> Wiki for
> > > relevant background information:
> RecommendationDisplayProposals/PageScore
> > >
> > > The user agent SHOULD provide a means of reducing the
> collection of
> > security
> > > context information which is available for any loaded page
to
> a numeric
> > > value (termed a "security confidence estimate").
> > >
> > > The calculation algorithm for the "security confidence
> estimate" MAY be
> > made
> > > selectable by the end user or offered by separately
installed
> user agent
> > > plug-ins.
> > >
> > > The user agent SHOULD provide a visual indicator in primary
> chrome which
> > > varies relative to the "security confidence estimate" value.
> Examples of
> > > such visual indicators (non-normative) are gauges,
thermometers, a
> > selection
> > > of several textual descriptions, and color-gradations.
> > >
> > > The visual indicator SHOULD be especially conspicuous in
> display when the
> > > "security confidence estimate" value is different than the
> value which
> > was
> > > observed for the loaded page in previous visits to the
loaded
> page.
> > >
> > > The user agent MAY elect to display a visual indicator in
> primary chrome
> > > only when a change in "security confidence estimate" values
is
> observed.
> > >
> > > The user agent MUST make the details of all available
security
> context
> > > information available to the end user, in either primary or
> secondary
> > > chrome.
> > >
> > > If a "security confidence estimate" is provided, the
provider
> of the
> > > implementation MUST make the calculation algorithm by which
> the "security
> > > confidence estimate" value is calculated available to the
end
> user.
> > > Documentation for the user agent or plug-in which is
employed
> is the
> > > likeliest place.
> > >
> > > The visual realization of the "security confidence estimate"
> value will
> > > depend on the user agent and end user abilities.
> > >
> > > --- End ---
> > >
> > >
> > > Tim Hahn
> > > IBM Distinguished Engineer
> > >
> > > Internet: hahnt@us.ibm.com <mailto:hahnt@us.ibm.com>
> > > Internal: Timothy Hahn/Durham/IBM@IBMUS
> > > phone: 919.224.1565 tie-line: 8/687.1565
> > > fax: 919.224.2530
> > >
> > > [attachment "smime.p7s" deleted by Mary Ellen
Zurko/Westford/IBM]
> > >
> > >
> > >
> >
> >
> >
>
>
>
--
/*
PhD Candidate
Carnegie Mellon University
"Whoever said there's no such thing as a free lunch was never a grad
student."
All views contained in this message, either expressed or implied, are
the views of my employer, and not my own.
*/
Received on Thursday, 24 January 2008 18:48:20 UTC