Re: What is a secure page?

There are two aspects that Yngve brings up that I believe need addressing 
at the Note level, and that we haven't addressed. 

One is scope of security indicators. I've never seen any indication that 
users think of security indicators as only referring to part of what's in 
the browser. I have presumed that they associate any security indicators 
with all of what's in the browser. I propose this as a design principle - 
absent any understandable scoping indicators, users will assume that any 
and all security context information displayed applies to everything in 
the browser. Thoughts? This seems to drive any general security context 
indicators to the least common denominator of what's displayed, offering 
two alternatives - only display what's at or above the level of the user's 
primary task area (if you can figure out what that is; the main page 
perhaps), or drive the security context indicator down to the lowest 
level. Yngve indicates the former caused severe enough usability problems 
that IE7 backed out of it. Yngve, were those serious enough that that 
approach should not be considered in this context? 

In light of that, the other aspect is displaying security of what's in the 
browser vs display security indicators for something that will take the 
user somewhere else. The button for a submit is a big one; URLs/links are 
pertinent as well. If you buy my proposed principle above, then there's a 
slippery slope about what users will assume about those links. Is there 
any deployment experience or research on that specifically? Some sites 
make sure to tell the user when they're following an "unsanctioned" link 
off the site. In the case of forms submission, it's more than just the 
button. Fields filled in will be sent out (for example). Anyone know of 
any worked examples of security context indications for forms 
data/submitting? There should be some parallels with logging in and 
passwords. Tyler, what if anything does Petname do if a submit's URL is to 
another site? I'm thinking at least a use case or two should capture these 
issues. 

Yngve, I don't find the issues around redirect to be obvious to me at all. 
Do you have a longer discussion around the security context information 
issues there? Or does someone else understand them in full? I'm guessing 
it's something about a site other than the one originally pointed to 
pushing the redirect on the browser (before the first site could 
respond?). 

          Mez

Mary Ellen Zurko, STSM, IBM Lotus CTO Office       (t/l 333-6389)
Lotus/WPLC Security Strategy and Patent Innovation Architect


public-wsc-wg-request@w3.org wrote on 12/31/2006 11:16:59 AM:

> 
> Hello all,
> 
> A part of security contexts that I do not think have been covered yet is 
 
> when a document can be called secure. Or, when should the closed padlock 
 
> (any padlock, ignore encryption strength) be dispayed?
> 
> A) I think everyone will agree that a secure (https) document loaded by 
> user action that only contain secure inline elements like images, 
frames, 
> applet's etc. should get the padlock.
> 
> B) I also think everyone will agree that such a document where at least 
> one element is loaded from an unsecure (non-https) server should NOT get 
a 
> padlock. It is generally not possible (for the client) to tell how 
> sensitive an inline element is, but in two cases, external Javascripts 
and 
> plugins/applets it should be apparent that receiving these from unsecure 
 
> sources compromises the document's security.
> 
> Opera does not display a closed padlock in such cases, and neither does 
> Mozilla or MSIE. Mozilla/MSIE give the user a warning about mixed 
> security. Originally, IE7 was supposed to block mixed security elements, 
 
> but the IE team encountered what they considered serious usability 
> problems on some sites, and (IMO, regrettably) reverted to IE6 behaviour 
 
> [4].
> 
> Of the more serious mixed security problems I've seen are external 
> Javascript served from an unsecure server (usually webbugs), but I have 
> also seen a case where a (secure) external Javascript link from a 
payment 
> page(!) was redirected to the unsecure version by a misconfigured 
> loadbalancer. I have also seen secure flashapplets load data from 
unsecure 
> servers [1].
> 
> C) What I expect be a bit more discussion about is how to rate secure 
main 
> documents that started out (when the user entered the URL, or clicked 
the 
> URL) as an unsecure http URL, which was then redirected to a secure 
> document (and all inline elements are secure).
> 
> There are three major redirect methods in use on the web:
> 
>    1) HTTP 30x redirects.
>    2) Meta refresh redirects
>    3) Javascript redirects
> 
> Except for Opera, most browsers apparently ignores the HTTP part as long 
 
> as the main document is secure. Opera only tolerates a direct 
http->https 
> HTTP redirect for GET requests, and do not display a closed padlock for 
> any other variation. I am not sure about how we currently handle meta 
> refresh redirects.
> 
> Opera's policy on this causes a number of support requests, along with 
> requests for a change to display a closed padlock for other types of 
> redirects. (The fact that we display a padlock for immediate HTTP 
> redirects is a modification of our original design that did not show a 
> closed padlock when the loading started as a HTTP URL.)
> 
> D) Additional scenarios we could look at, are how to handle
> 
>    - form submits from an unsecure document to a secure form (in 
particular 
> with passwords [2]).
>    - unsecure form submits from secure pages or applets [2]
>    - unsecure POST submits that redirect to secure pages.
>   (- others?)
> 
> In some of the above cases, the question is not just whether or not the 
> browser should display a closed padlock, but whether or not the client 
> should even permit some of that actions above (e.g mixed security in 
> documents), and how to explain such refusals.
> 
> 
> I've previously posted a couple of articles([1], [2], [3]) on my home 
page 
> that discusses some of these issues, and possible ways to handle them.
> 
> 
> [1] "'Secure' bank logins?" <URL: 
> http://my.opera.com/yngve/blog/show.dml/281609 >
> [2] "Secure sites that aren't"  <URL: 
> http://my.opera.com/yngve/blog/show.dml/382945 >
> [3] "Low security sites, what to do about them?" <URL: 
> http://my.opera.com/yngve/blog/show.dml/461932 >
> 
> [4] <URL: 
> http://blogs.msdn.com/ie/archive/2006/10/18/ssl-tls-amp-a-little-
> 
activex-how-ie7-strikes-a-balance-between-security-and-compatibility.aspx 
> >
> 
> -- 
> Sincerely,
> Yngve N. Pettersen
> 
> ********************************************************************
> Senior Developer                     Email: yngve@opera.com
> Opera Software ASA                   http://www.opera.com/
> Phone:  +47 24 16 42 60              Fax:    +47 24 16 40 01
> ********************************************************************
>