Re: iframe@security

Anne van Kesteren wrote:
> What if the message comment contains "</div>" followed by some dangerous stuff? 

Indeed. However, this could be an issue for any HTML element that is
capable of being a host for "dangerous stuff" and scripted injections
etc allow malicious authors to use the humble <a> element as a hook for
all sorts of horrors. I guess I am interested in what would be best in
"principle"  (for authors, and end users in terms of support, or it
working basically) and a more neutral element that is capable of working
in any browser seems to me like a good idea.  Easy to author, addition
of an attribute to an existing element in the spec seems to be easier
than creating a new element and the issue of getting it supported AFAIK
and so on.

> What about clients that do not support the security attribute? 

I guess its like anything, if it works and is relatively easy to
implement for vendors they /may/ support it. If /it/ is a good idea in
the first place but you would know more about how that works than I do.

>There has been extensive discussion on this already on the WHATWG mailing list [...]
>there weren't really any proper solutions for the problem, apart from content authors ensuring they can't be spoofed on their end.

If you (or any other interested parties) wouldn't mind, please keep this
list posted if there any other useful discussions relating to security
on the WHATWG list. Accessibility and security are awkward bedfellows
and I am really interested in how to make web applications more
accessible and also more secure without compromising either domain. Oh,
and that should include usability also.

Further "easy to author, elegant solutions that hide their complexity
from the end user" off list discussions welcome ;-)

Thanks Anne.

Josh

Received on Monday, 21 January 2008 12:20:21 UTC