At 7:21 PM -0400 8/24/08, [EMAIL PROTECTED] wrote:
The publisher of the web page is not in the security business,
they are in the publishing business. But how can I respect
their publishing expertise if they fail a simple automatic
test.
Well, I guess that most of web developers are not
ljknews wrote:
My experience is that browsers succeed on standards-compliant
pages. Standard compliance should be the first test. If it
subsequently fails on a particular browser, it is a browser
defect which may or may not be of interest to the publisher.
Agreed that, talking only about
How does xHTML help stop access control vulnerabilities? Authorization
issues? CSRF problems?
And who is to say that an attacker cannot still do server side injection
(sql injection, ldap injection) or timing attacks?
I'm just getting started. xHTML is only one tiny piece of the outbound
At 9:12 AM -1000 8/26/08, Jim Manico wrote:
How does xHTML help stop access control vulnerabilities?
Authorization issues? CSRF problems?
It is indicative of the caliber of the people who built
the site.
My immediate interest is that validation combats browser crashes.
I am not interested
Hi SC-Lers,
With these last 2 messages, let's kill off the survey thread, please.
I allowed it to continue on--probably longer than I should have--
because there seemed to be valid and interesting points being made on
both sides of the debate. But that seems to have run its course, so
On 8/26/08 3:03 PM, ljknews [EMAIL PROTECTED] wrote:
I am not interested in dealing with people who cannot get
the simple things right.
Right. Because we all know that the HTML, xHTML, DHTML, CSS, and the related
standards are really simple. Nothing to it. Writing valid HTML in our
Making a very complex Ajax rich-client web applications perfectly xHTML
valid is not easy. Most of the enterprise world goes way beyond simple
flat file xHTML. Add in (the real reality of) highly database-drive
dynamically generated javascript/ajax heavy pages, and I continue to
conjecture that