Message-ID: <200208022005.g72K52176586@mailserver2.hushmail.com>
From: choose.a.username at hushmail.com (choose.a.username@...hmail.com)
Subject: Re: it\'s all about timing

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Let me ask you this, who _exactly_ is bound by the END USER LICENSE AGREEMENT?

Why not have the vendor include in it, "if you find a bug in our product, agree to inform us and us only until we resolve the issue"

I come to your house and play on your machine. You are the party who installed the software and selected "I agree" when you installed that piece of software. Now I find a bug and do with it as I see fit. Is this correct?

I think one of the anti virus companies tried to pull a similar stung in the EULA where by accepting installation you were not allowed to write a review of their product without their permission. In New York or New Jersey possibly, the States Attorney shot it down in two seconds. Cannot remember the vendor Mckafee or nai or symantec or something.

Any in the scenario above where I use your machine and installed software and find a bug, given there is that condition in the EULA to which you, the party who installed the software and agreed to the terms, am I now bound too?

On Fri, 2 Aug 2002 14:07:53 -0400 (EDT), full-disclosure@...ts.netsys.com wrote:
>>It is interesting that the people screaming loudest for some sort of
>>order in the submission of bugs, are in fact non-bug hunters at
>>all. Rather a vocal group academics who intent of have their name on a
>>draft or ratified document they came up with. Sure some may have
>>posted a few findings but none are consistently doing so, and the bug
>>hunters, sure don't sound like they need some else telling them what
>>to do. You don't hear them crying to for order.
>>
>>Wonder why that is.
>
>I think it's because there are more "consumers" of vulnerability
>information than just other bug hunters, for example, people who want
>to remove those bugs from their vulnerable systems.  I would be very
>interested in hearing the experience of bug hunters who are also
>responsible for the security of large, diverse networks; they may see
>this situation from both angles.
>
>The audience for a security advisory includes individuals and
>organizations with many different needs for security information.
>Having some order to disclosure can make it easier for people to
>identify the vulnerabilities that they care about, and to secure their
>systems.
>
>The audience includes:
>
>- System administrators, who often need to manage or support dozens of
>  products
>
>- Security administrators, who need to research and understand
>  hundreds of vulnerabilities across their enterprise, and who may not
>  fully understand all the products that have been deployed at their
>  enterprise.
>
>- Vulnerability database maintainers, who need to research,
>  understand, and/or verify thousands of vulnerabilities.  Since
>  databases are relied upon by many people, errors or inconsistencies
>  in your own advisories will be multiplied greatly.
>
>  For a list of some of the challenges in vulnerability database
>  maintenance, see my post at:
>  http://lists.netsys.com/pipermail/full-disclosure/2002-July/000568.html
>
>- Vulnerability researchers, who may have specialized research
>  interests that require greater detail (or different types of detail)
>  than most of your audience.
>
>- Potential customers, or the consultants that they rely on
>
>- Existing customers who care about security issues but do not
>  regularly read advisories
>
>
>Sysadmins and security admins often have time pressures that may make
>it difficult for them to sift through "noisy" vulnerability
>information - incomplete, inaccurate, etc.  If an advisory is released
>without a vendor patch, the admins then have to keep track of which
>bugs are outstanding, and figure out which researchers they can trust
>when there is no vendor patch.
>
>One of the roles of vulnerability databases is to sift through the
>"noise" and make it easier to access vulnerability information.  But
>since it's resource-intensive for experienced vulnerability database
>maintainers to manage the noise, it seems reasonable to assume that
>admins may have difficulty managing the same information... or at
>least figuring out which information is actually correct.  The job is
>only going to get harder with the increasing de-centralization of
>vulnerability information.
>
>In my experience, the most informative and accurate security
>advisories offer a mixture of the details that researchers provide,
>along with the correct version, fix and actual cause of the problem,
>as is often best known by vendors.
>
>High-quality information may not be needed by everyone, and some
>people may not think it's important, but better information means
>better security overall.
>
>- Steve
>_______________________________________________
>Full-Disclosure - We believe in it.
>Full-Disclosure@...ts.netsys.com
>http://lists.netsys.com/mailman/listinfo/full-disclosure
>

-----BEGIN PGP SIGNATURE-----
Version: Hush 2.1
Note: This signature can be verified at https://www.hushtools.com

wmYEARECACYFAj1K5NMfHGNob29zZS5hLnVzZXJuYW1lQGh1c2htYWlsLmNvbQAKCRDT
5JkCl0iMkKqkAJ4khfHRcswINj5QVP5ayNvqvK3KzACeO3Mn1FHsdlUUngoND4uYTUxg
j7k=
=+dvP
-----END PGP SIGNATURE-----


Communicate in total privacy.
Get your free encrypted email at https://www.hushmail.com/?l=2

Looking for a good deal on a domain name? http://www.hush.com/partners/offers.cgi?id=domainpeople

Powered by blists - more mailing lists