- From: Sven Latham <sven.latham@doihavetime.com>
- Date: Mon, 13 May 2002 13:12:29 +0100
- To: <www-html@w3.org>, "Lincoln Yeoh" <lyeoh@pop.jaring.my>
Hi, 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. Regards, Sven Latham ----- Original Message ----- From: "Lincoln Yeoh" <lyeoh@pop.jaring.my> To: <www-html@w3.org> 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 content > 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 points > (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 other > 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 not > 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 some > way to turn things off. > > For as features keep getting added, the filtering parsers could increase in > 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 it > 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