W3C home > Mailing lists > Public > public-css-testsuite@w3.org > February 2012

Re: Requirements for (level >=3) tests

From: Bjoern Hoehrmann <derhoermi@gmx.net>
Date: Wed, 22 Feb 2012 04:33:03 +0100
To: Boris Zbarsky <bzbarsky@MIT.EDU>
Cc: public-css-testsuite@w3.org
Message-ID: <j2j8k7d5695mga561aab01ks8mfem2ifdr@hive.bjoern.hoehrmann.de>
* Boris Zbarsky wrote:
>If the test is not easy to analyze, it's generally hard to impossible to 
>tell whether the test is demonstrating a bug in the test or a bug in 
>browsers, especially if several browsers agree on their rendering of the 
>test.
>
>Note that being easy to analyze is the important thing; good coding 
>practice is only relevant insofar as it aids analysis.

Assume that the test case exposes a remote code execution vulnerability.
What is more important: coming up with the test case, or that it is easy
to analyze the vulnerability the test case exposes? What is easier, what
is more valuable, to come up with the test case, or that it is easy to
analyze it, once the test case is available? Would you reject a report
of a remote code execution vulnerability because it looks complicated?

The point being, creativity beats usability, I would rather have some-
one tell me something I did not think of, than having someone tell me
something I can easily digest. Someone telling me something new in a
manner that is easy to digest would be best, but it being easy is quite
secondary. Efficiency is something to optimize for, as I noted, but the
simple "ease" is rather unimportant.
-- 
Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 
Received on Wednesday, 22 February 2012 03:33:31 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 22 February 2012 03:33:39 GMT