Re: Opera's three security levels

Mary Ellen Zurko <Mary_Ellen_Zurko@notesdev.ibm.com>, 2006-11-24 10:22 -0500:

[quoting me]
> > So to answer your question, No, we don't have explicit actionable
> > advice associated with each of the levels. I don't see how we
> > could, practically, associate specific guidance with each of them.
> > The expectation is basically that you'll use the numbered security
> > level as another data point (along with other security context
> > information) in making a decision about the degree of confidence
> > you want to have sharing personal information with the site.
> 
> Thanks Mike. I don't think that matches any practical or
> realistic user model for the majority of users.

Why exactly doesn't it? I would think intuitively that having an
indicator that provides a greater level of granularity than just a
binary secure/insecure padlock would be helpful to users.

It gives users a simple way to visually evaluate the security of a
particular site relative to the security of other sites in a
particular security category (sites that have SSL/TLS certificates).

It's true that the numbers are potentially ambiguous and
confusable (which is more secure: a 1 or a 3?), which is why one
other thing that we do is to show the lock in various stages of
being completely open (an https site with 0 security), partially
closed/open (a site with a 1 or 2) or or completely closed (3).

I agree that a lot of these kinds of indicators have the
fundamental problem of being ignorable by users. But we have the
same kinds of problems with similar indicators in the real world:
people also ignore things like stop signs and traffic lights and
many other indicators that a designed to help protect them.

Along with that, we have the problem of certain sites that
actually teach users that it's OK to ignore warnings that browsers
emit and to ignore absence of certain security indicators (for
example, the bank sites I mentioned in my earlier message which
have login pages for which not padlock is displyed by browsers).

> That's one of the problems with security indicators; users
> haven't got a clue what to do with them. Having the indicators
> can be better than not having them, but only if there is some
> model of how to use them.

I think quite a number of users do in fact have a clue what to do
with the padlock indicator and color-change in the address bar
mean. Or at least they have a clue what it indicates (that a site
with a padlock has some level of security). Yeah, it's not a
perfect indicator but it is at least one of the few security
features that's common across browsers.

> There are studies that show that user's don't "think about"
> trust and security (Martiza and I need to get cracking on that
> annotated list; we've got a draft in email that I'll push out to
> the wiki). So having a model that assumes they will isn't
> enough.

Are you saying that our goal is to come up with mechanism for
providing security-context information that assume that users
don't have to think at all about trust and security?

I think even without consulting any studies, most of us already
well know that users don't put much thought into trust and
security, and that many users ignore existing security indicators
and warnings, and perhaps even that there are a good number of
sites actually encourage users to ignore those things.

But I will have to admit that at this point, it's hard for me to
imagine a model that doesn't assume that users will need to put
some degree of thought into trust and security, and what kind of
security mechanisms there might be that could be practically
implemented in browsers and that would not rely on users thinking
a bit about trust and security.

> What might be enough is to use this information with other browser history 
> to flag things like
> 1) discontinuities (particularly downward) for a particular site, or

We do that emit warning about discontinuites -- as do other
browsers. I suspect that the majority of users simply check the
"Don't show me this warning again." box on the dialog that we emit
for that the first time they encounter such a discontinuity. So
many or most users see that warning exactly once. (And if we
didn't have that "Don't show me this warning again." option, you
can bet that we would a have lot of (angry) users demanding it.)

But I can imagine that there might be better ways to alert users
to such discontinuities than they way that browsers are doing it now.

> 2) categories and trends and recommendations (can we use the semantic web 
> to tag site types, then say things like "the financial sites you've 
> visited in the past all have tip-top security; this one claims to be 
> financial but has mediocre security; beware"). 

I very much like the idea of having a way to intelligently put
sites into certain security categories, and to enable a way to
compare the security of a site within a certain category to that
of other sites in the same category.

But one problem with categorizing sites is that the relationship
of site to categories is one-to-many. One to very many. Given the
variety of data by which it would be useful to categorize sites --
for example, geographical (sites in Russia, sites in Denmark), age
(sites that have existed for 5 years, sites that have existed for
only 2 days), and on and on -- it would seem to me to require a
fairly elaborate user interface to present users with information
about the security categories a certain site belongs, and the
security level of the site relative to others in each category.

Another problem in regard to the specific example you mention is
that (as far as I know) there's not any standard way that's in
wide use for a particular site to claim to be a financial site --
or any other category of site.

So if we wanted a mechanism for grouping sites into categories,
it'd need to rely on some method other than self-categorization by
site content providers; either some mechanism implemented in the
browser itself, with the categorization data stored locally in
each user's environment, or some mechanism which made use of a
shared categorization data out on the network and which browsers
would need to have some standard mechanism for accessing (which
would seem to imply a new protocol of some kind and so would be
out of scope for us if we are to stick to the plan of introduction
of new protocols being out of scope for the group).

And, anyway, how would emitting a prose warning ("the financial
sites you've visited in the past all have tip-top security; this
one claims to be financial but has mediocre security; beware") be
better than just showing a visual indicator (such as Opera's
numbered padlock) that displays the relative security level of a
site? That indicator is actually already comparing sites within a
particular category -- the category of sites with SSL/TLS certs,
which is perhaps the only security category that browsers can
currently programatically place sites into.

  --Mike

Received on Monday, 27 November 2006 07:57:03 UTC