"Csaba Gabor" <> wrote in message
news:TRz6e.296$...
> In this case the OP does not seem to be appealing to this
> group as a developer so that should be the end of it.
> However, as I discussed in my posts, referenced below, this
> "security mechanism" really isn't. Any author who wants to
> have that mechanism bypassed is simply going to add that
> into hir original web page, you don't even need to get the
> size right - Zero security has been gained, and I argue
> that some has been lost.
You seem to misunderstand what Mark of the Web does, and what it means.
A script loaded from a local hard disk has unlimited security (it can
access the local file system for example). This is why any HTML document
that is loaded into the Web browser from the local disk requires the
user agree to not one, but two warnings that the script can take
malicious actions.
A script loaded from a local hard disk with the Mark of the Web has the
same permissions as an HTML document loaded from the Internet zone (as a
result, it can _not_ access the local file system for example). This is
why a page loaded from the local hard disk with the Mark of the Web does
not result in a prompt, the script can not do anything that a script
loaded from the Internet can not do (barring any unpredicted security
vulnerabilities).
> If you are only concerned about a handful of pages, I suppose
> it's OK to expect a completely HTML illiterate person to figure
> out that they should add that construct to their web page.
> Oops. I mean scaring and confusing hir by that 'content bar'
> (I call it a content bar because it bars content) that comes
> up and having them click a few extra times. But it is
> unbelievably burdensome to the web developer, not to
> mention imposing another cavalier unstandard when there is
> already a mechanism for the same thing, <base href=...>
<base href=...> does not do the same thing.
As outlined above, the Mark of the Web actually changes the security
zone in which the script executes.
> As a result, a developer might lose a day to figure out how to,
> and then turn off mechanisms that are supposedly protecting hir,
> but are in reality hindering hir efficiency. The point is that
> if a protection mechanism is made to hinder a user's efficiency,
> that mechanism can expect to be turned off resulting in a more
> exposed condition. This is something the designers of such
> programs should consider.
The developer would not lose a day if they have familiarized themselves
with the changes to Service Pack 2 made to Internet Explorer.
However, the security mechanism is not intended to protect just the Web
developer, it is intended to protect all users of Internet Explorer. It
is simple enough (using provided Microsoft documentation) to write and
test scripts from the local hard disk in Internet Explorer without being
prompted. And I would argue that you should not be testing your Web
pages loaded from a local hard disk anyway, you should be running your
own Web server to most closely mimic the environment in which your pages
will be loading.
--
Grant Wagner <>
comp.lang.javascript FAQ -
http://jibbering.com/faq