Re: ACTION-508

I wasn't saying there isn't a case for having text, just that I'm not able
to come up with text that I like. Help welcome :)

On Wed, Sep 10, 2008 at 1:56 PM, Close, Tyler J. <tyler.close@hp.com> wrote:

>  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
>