Re: Tag to turn off active content?


I hope I understood your email correctly, (and that mine makes some sense!)

Although it would be a nice feature to be able to turn on/off certain
parsers at will, surely this should be a decision taken by the rendering
software rather than the markup author? I understand that by disabling
parsers and extras (Java VM, Flash, etc.) it would prevent pointless loading
of such extras, but if anything this should be a choice made on the client
side instead.  For example, you cite that resources would be an issue.
Instead of the X/HTML author determining that no Javascript exists on a
page, the browser should be intelligent enough not to load the JS parser in
the first place on the basis that it doesn't encounter <script
language="Javascript"> tags in that page.  If processor time were a concern
then much better the software allow it's user to disable particular
'modules' than each web author explicitly list said module as disabled.  By
the same token, that would rely on every web author denying the module in
order for resources to stay down - again, easier just for the software to
allow the end user to disable it!

I suspect (and hope) that browsers nowadays are far more sensible than to
load every module, the Java VM, Javascript, VB Script parsing, Flash, etc.
immediately and for every page (I don't pretend to know much about software
engineering or the inner workings, but to a layperson this would appear to
make perfect sense!), instead only loading the module when it is required.
Therefore the solution for a web author to avoid the Flash module loading,
is simply not to have any Flash in their page.

To address the security issue, I don't understand why any specific author
would be concerned that their own page is a security risk - seems like an
extremely paranoid author if they don't trust their own code (maybe I've
misunderstood?) Even so, I think browsers again should be responsible for
the security, and for creating a safe environment where internet pages are
dealt with according and as determined by the user, not by the author who by
all ideal terms should be determing the layout and content of the page, and
not (in most cases) the means by which it is rendered.


Sven Latham
----- Original Message -----
From: "Lincoln Yeoh" <>
To: <>
Sent: Monday, May 13, 2002 5:37 AM
Subject: Tag to turn off active content?

> Hi,
> Is there a tag to tell the browser to turn off/ignore active content
> especially for security reasons (I know it's debateable what active
> is, but scripts and active-x would be a good start). By turning "off" I
> don't mean that stuff that is already running should be turned off. It is
> more of telling the browser to ignore active content between certain
> (active content quoting).
> If not, I'm suggesting something like:
> <activeoff lock="Random_hard_to_guess_string" except="java">
> browser deactivates active content modules/parsers except for java.
> content here. Active content not displayable (except for java).
> </activeoff lock="wrong_string">
> Still no active content displayable.
> </activeoff lock="Random_hard_to_guess_string">
> (I'd like to drop the except option but I'm putting it there for
feedback -
> it could be useful for those who know what they are doing - they are
> confident of filtering certain types of active content safely).
> Apparently the above is not XML/XHTML compliant, if it isn't I'm sure
> alternatives would do, the main thing is to be able to tell the browser to
> switch things off and back on. The alternative tag(s) could then be
> something like a self closing <br/> tag. I'm open to suggestions on XML
> compliant methods.
> Why I am suggesting this is because there are so many methods to turn
> things on, whilst there are rather few methods to turn things off. It's
> intended to globally effective right from the start, but rather setting
> things in place for the future - so that at least one day we will have
> way to turn things off.
> For as features keep getting added, the filtering parsers could increase
> complexity and resource usage, and likely decrease in effectiveness. Also
> what the browser's parser sees is not necessarily what the website's
> filtering parser sees. By having this feature in place, in the future if
> becomes impractical to filter everything out (resource, etc), at least
> there is a safety net for the browser to fall back on.
> Furthermore if a brand new safe feature is added, there could be a way for
> existing websites to allow it safely. Otherwise the only safe view left
> won't support it - it'll be automatically turned off by a paranoid
> filtering parser (filters out everything except known safe tags).
> Regards,
> Link.

Received on Monday, 13 May 2002 09:25:15 UTC