iframe@security

I read with interest this post on the IEBlog about a proprietary
'security' attribute for iframe [1]
I don't think it's a new attribute, just a new post offering advice to authors.

I checked our latest HTML 5 draft and didn't find such an attribute,
and that makes me wonder ...

a. should we? I'm no expert on web security (nor even an author that
uses iframes often) but the post made sense to me, and it can see it
might be useful, as an author, to have an attribute such as this to
suggest to the UA the level of trust/security (I'm know many
techniques are already being used in UAs around domain/cross-site
checks, phishing checks, etc.). I would never expect a UA to blindly
trust the author's recommendation (of course there are malicious
authors), that would remain the province of the UA and/or user's
configuration choices.
b. do other UAs already use similar attributes? (if so, that'd be a
compelling cowpath right?)
c. in general, what's this group's approach to proprietary markup? do
we play a role?

It's this last point that interests me more.
I'd like to see markup that is implemented be "valid", the reason
being that I'll otherwise be forced to endure long discussions over
the relative merits of "100% valid markup, no exceptions!" vs the
pragmatic use of proprietary markup that provides useful features. The
valid markup camp is particularly strong as we are constrained by WCAG
compliance, and thus must "use markup properly" [2].

I'm not actively looking for proprietary markup to include in the
spec, nor looking to make an example of IE, nor overly concerned
whether iframe@security is in or out of the spec ... iframe@security
just crossed my inbox today and it seemed timely to ask these
questions.

cheers
Ben

[1] http://blogs.msdn.com/ie/archive/2008/01/18/using-frames-more-securely.aspx
[2] http://www.w3.org/TR/WCAG10/wai-pageauth.html#tech-identify-grammar

Received on Saturday, 19 January 2008 04:07:50 UTC