At 01:28 PM 5/6/02 -0500, Mike Messmore wrote:
>Right now the w3c is trying to remove logic and layout from (X)HTML as
>much as possible. It is a language for content. I don't see how logic
>such as this is an elegant solution to the problem at all. It looks to

It seems to me that the tag is for content.

>me like yet another ugly hacked on extension to the HTML standard. Not
>to mention the fact that even if it got accepted today you're looking at
>5 years before enough people have a browser that it would make it worth
>even considering using this on a site as some sort of a security
>measure.

It is indeed ugly. But the current situation is uglier. If you have a
prettier solution, do let us know. Relying on parsers and filters to work
doesn't look prettier to me.

This tag proposal is indeed for the future. If we don't start now, five
years from now I'm willing to bet so many more OTHER features would have
been added that would make security even harder to maintain. People are
creating more and more ways to turn things ON, I figure creating a space
for OFF switches or even just debate would be useful.

Acceptance concerns haven't stopped people from introducing new features
and or even breaking websites for browsers that don't support them.

I believe layering on more security is helpful, esp in this case the added
cost seems minimal. Web app authors should continue to filter content, but
this helps substantially increase security for those using web browsers
that support the tag. A safety net.

>Rather than making an obscure demand that will never be met or
>supported, ask yourself this: Why are you allowing HTML from untrusted
>users? Is there a better solution? If you trust the users, then HTML
>is fine. Otherwise, you need to look somewhere else.

Because users want HTML, not just plain text with some bold/underline stuff?

As most of the browser security problems have been due to active content,
not nonactive HTML, and most users are happy with just the latter, it seems
that it is a decent compromise to have users receive HTML without active
content.

Which is likely to be safer - a browser viewing parsed and filtered hostile
content, or a browser supporting the noactive tag viewing filtered hostile
content marked noactive?

My view is even if the noactive supporting browser parses the content
differently from my filtering parser, the noactive tag will help make it
very likely that the active content modules are turned off and thus reduce
the risk substantially, even if one or both of the parsers have a bug.

Here's one of many possible web app scenarios:

Site A displays content licensed from Site B.

Users trust Site A, but have not established any relationship with Site B.

The tag will allow Site A to use active content on its site and help ensure
that any active content that somehow slips in from Site B would be turned off.

Regards,
Link.

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]