Re: iframe@security

Ben Boyle <benjamins.boyle@gmail.com>, 2008-01-19 14:07 +1000:

> 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

For one thing, I think it risks giving developers and content
authors the impression that they can address iframe (in)security
issues by just using something like this at the markup level. And
that doesn't seem very prudent.

> b. do other UAs already use similar attributes? (if so, that'd be a
> compelling cowpath right?)

It's true that specifications for some things that began as
proprietary features in IE -- like innerHTML and XmlHttpRequest --
are now parts of W3C draft standards. But that's not just because
they ended up getting implemented in other browsers. It's both
because it became clear enough that they were really worthwhile
that enough sites started using them, and the market value of
implementing support for them then became clear.

But just the fact that other browser vendors have implemented
support for some things that started out as non-standard/
proprietary features of other browsers doesn't mean that those
features should automatically get blessed as standards. Sometimes
the only reason that browsers have implemented some of that stuff
is just to get particular sites and make use of them (e.g., sites
for large banks and airlines) working in their browsers.

Those kinds of sites often have a captive customer base, so they
feel free to be lazy, ignore standards, and force their customers
to use particular browsers. Other browser vendors then have to
make those sites work in their browsers -- or else risk losing (or
never gaining at all) the users who depend on access to those
sites. So the other browser vendors bite the bullet and go ahead
and implement support for some of that non-standard stuff not
because they think it's a brilliant idea but because the need to
try to maintain and grow their market share forces them to.

And that's not to put the blame solely on Microsoft, because
they're not the only browser vendor guilty of unleashing
non-standard features like that on the world.

> c. in general, what's this group's approach to proprietary markup? do
> we play a role?

I think the approach that's been taken pretty consistently in the
development of HTML5 over the last 3 or 4 years -- for markup and
other browser features both standard and non-standard -- is:

  - look at data about how many sites are actually making use of
    the feature
  - of those sites that are using the feature, how many are
    actually using it in a conformant way (the way they are
    intended to be used)
  - in conformance requirements for authors, don't document those
    features that the data indicate aren't being widely used -- or
    aren't being used in the way they are intended (though those
    features may still need to be spec'ed for implementors in
    order to ensure interoperability even when authors ignore the
    authoring-conformance requirements and use them anyway)

I think the Web Authoring Statistics (http://code.google.com/webstats/)
report that Google published a couple years ago has provided a lot
insights, and also some reports produced using smaller data sets
that others have produced.

In the particular case of the iframe security attribute, I think
if it were being used widely enough, it would probably have noted
by in now in some of those reports.

And I think that's also true in general -- I really doubt that
there's existing markup out there in the wild that's in wide use
and that hasn't been taken into consideration and either
incorporated into the spec already or intentionally omitted
(rightly or wrongly).

  --Mike

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

-- 
Michael(tm) Smith
http://people.w3.org/mike/
http://sideshowbarker.net/