Le Thu, 16 Mar 2006 13:45:54 +0200, Alexey Feldgendler
<[EMAIL PROTECTED]> a écrit:
<...>
A DOMDocument interface has to be exposed to the contained scripts
anyway, ahy not also make it accessible from the outside?
Yes, but I'm afraid it's a technical challenge to implementors. Their
browser engines might need some rewrites to properly support <sandbox>ing
content. Therefore, instead of rewrites, they'll hack the <sandbox>es,
opening a wide variety of security holes competing for the crown of "the
first web virus".
<...>
I'm not speaking about enforcing ID uniqueness at the time of parsing
the page, but only at the time of calling getElementById(). I believe it
will break very few pages, if any.
I know that many web applications have bugs like this: they have a CSS
rule like "#titlebar { font-weight: bold; }" and a single titlebar on
the page. After that, the requirements change, and they have more than
one titlebar on a page. To make the rule apply to all titlebars, they
give them all the same ID (instead of using class, not ID, in CSS
rules). While such documents are non-connforming, they should not, in my
opinion, cause parse errors even in standards mode. Here is why:
duplicate IDs are wrong, but it's obvious what the author means, and
it's easy to do "what the author intended".
Usually in such applications the scripts don't call getElementById() for
those ID values which occur more than once. If they occasionally do,
it's really a programming bug. I don't believe that there are
applications that really rely on the particular behavior in this case,
though I admit that there are possibly some that have this bug unnoticed
and still work. I think that this case should trigger an exception in
standards mode because, for this bug, there is no obvious fix to apply,
and we don't know "what the author meant" -- does he want to do
something to the first element with the specified ID, the second, or
both.
Under no way should this happen. This is adding confusion to an already
over-confused web author (as in: a web author who doesn't know much web
development).
Therefore, it's clear nothing has to be changed in quirks mode, but in
standards mode:
1. break during parsing.
2. break JS code if it sets the id of a node to a duplicate ID.
Or simply leave it as it is: quirks mode behaviour.
<...>
Simply picking the last matching node is actually hiding a bug and
letting it go unnoticed. (Why the last one? Why not the first, for
example?)
That's true, but this happens in many, many other cases.
<...>
I did not see LiveJournal, so I don't know what kind of features they
offer.
<sandbox> would probably do "the trick" (would help a lot with security
in this case also).
Yes, I think so. Actually, my activity around the sandboxing idea has
been inspired by several recent security incidents with LiveJournal and
its styling system which failed to filter out some patterns of dangerous
HTML.
True. As you said, there are risks with buggy <sandbox> implementations,
but that's an advantage actually: relying on browser fixes, instead of
site-by-site fixes. I prefer to get a single patch from the implementor,
than wait for hundreds of sites to fix them. Yet, this is an advantage to
malicious users too: distribution of the "virus"/exploit can be very
powerful and fast.
<...>
Yeah, really, I sound a bit contradictory. Actually, in my opinion, HTML
is better than most of ad-hoc markup languages, and HTML with scripts is
still better than just HTML.
Exactly.
And another thing: HTML 5 is about to make HTML pages more powerful,
there are going to be menus, datagrids and such, but most of these
features are useless without scripting, aren't they? For example, a
datagrid isn't really sortable at client side without a script, which
makes it useless in blogs and CMS unless they allow some scripting.
True.
So, <sandbox> may be designed to help tighting-up security on the web,
but we should also try to think of how's it actually in usage,
side-effects, etc. It definitely solves problems, but will it cause
other problems? How important are they?
Of course, there is a lot more to think and talk about. I suppose there
are going to be problems with particular buggy implementations of
sandboxing and exploits specifically targetted at holes in such
implementations. I suspect that web application authors and site
administrators will be hesitant to allow user scripting even in
sandboxes because of the possible browser bugs. Though, because
sandboxes can be useful even if scripting inside them is completely
disallowed, I hope that the use of sandboxes becomes somewhat popular
even before site administrators decide to allow scripting.
True, but I'd test. If it works in major browsers as I want, then why not?
Especially in the case of intranet web applications.
--
http://www.robodesign.ro
ROBO Design - We bring you the future
