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

Received on Wednesday, 10 September 2008 04:04:52 UTC