RE: ACTION-508

Hi Ian,

An argument could be made that differing TLS-security levels is a hole that can be opened by the attacker, without the knowledge or collaboration of the victim site; whereas the other holes you discuss require explicit collaboration by the victim site. Under this argument, you could draft text that ignores mixed-content issues, while still requiring lowest common denonimator presentation of TLS-security level. Under this interpretation, the chrome presentation informs the user whether or not they have a secure connection to the web page, not whether that page may give away sensitive information it receives. Since server-side holes prevent the browser from guaranteeing the latter, the former is the only enforceable interpretation the browser can provide anyways.

--Tyler

________________________________
From: public-wsc-wg-request@w3.org [mailto:public-wsc-wg-request@w3.org] On Behalf Of Ian Fette
Sent: Tuesday, September 09, 2008 9:04 PM
To: public-wsc-wg@w3.org
Subject: ACTION-508

I was supposed to "Draft spec language about downgrading indicators to level of least-secure frame".

I tried coming up with good text for this, but I failed. Originally I thought we wanted to say something like "Any security indicators as to the security of a top-level resource SHOULD take into account the security levels of any other resources in any other windows or tabs (if the user agent supports multiple windows or tabs), and display for the current top-level resource an indicator reflective of the lowest security level for any window or tab that shares the same origin (as per the same origin policy in use in the browser for scripting)."

The problem is that you also have issues like cookies - e.g. for all you know, an HTTPS site could be setting a non-secure cookie that could be read/modified on a non-HTTP connection in another tab, do you bork the indicator for the HTTPS tab just because of that? Do you require people to figure out if it's scriptable, or if it might be scriptable (e.g. there's no handle right now but perhaps somehow it could get a handle to the other resource? my attempt leaned at the latter). What about sites that could share information via other means, e.g. using flash local storage, or any of the html5 data storage apis, etc?)

And then how do you actually explain, when the user clicks on the broken lock or whatever indicator is shown, why they don't see a "good" status in a method that the user can actually understand?

This sounded like a good idea, but the devil is in the details and I'm having a real hard time working out the details. If anyone else wants to take a crack at the text, you're welcome to do so. My thoughts are above, feel free to take them or leave them, but as for me I'm marking this action as pending (e.g. I am not likely to contribute further text here on my own).

-Ian