From: Mark C. Langston (mark@bitshift.org)
Date: Tue Jul 08 2003 - 16:22:22 EDT
On Tue, Jul 08, 2003 at 03:16:24PM -0400, David J. Meltzer wrote:
>
> Fact is, the posts that are most harmful don't come across as "y0ur
> pr0dukt sukz", they are carefully written by intelligent folks who
> insert their lies into coherent sentences. Even with an equally
> intelligent statement refuting it by the vendor, there is no real way
> for a 3rd party observer to know who is telling the truth.
>
Then the issue everyne is really concerned with is credibility,
not accountability. The whole point of open and frank discussion of
such things is, much like in the scientific community, the peer
vetting of claims. If someone with no established credibility,
or someone who is known to be disreputable, makes a claim (particularly
if the claim is a strong or otherwise pot-stirring one), just don't
lend it credence. Use of credibility is a simple but powerful
razor in such instances. I've written up my thoughts on using it
not only in real life, but as a method of filtering e-mail by MX,
and I believe a certain other list member will be presenting
a paper shortly demonstrating the power of credibility metrics
in other realms.
The interesting thing is that accountability of the sort Al proposes
forces credibility, but credibility requires no such accountability.
It merely requires invariance of identity. This invariant identity
does not need to be a "real person", merely a stable unique identifier
to which others can assign or subtract credibility when content is
presented under that identifier.
If you feel the need to call shenanigans on a claim, and the claimant
sticks to his or her guns, the claim is either empirically
provable or disprovable, in which case anyone interested can do so
(given appropriate resources), or is not (dis)provable, in which
case the claim can be dismissed out of hand.
Honestly, folks, what we're talking about here is the positing
and gainsaying of purported facts. If a certain fact is wrong, it's
either a mistake, in which case the claimant can correct it, or
malicious, in which case the dispute over the fact should be
a warning sign to anyone willing to believe it lock, stock, and
barrel without independent verification.
Or are we suggesting that the list members are not capable of
recognizing when a claim has been questioned, and adjusting their
own beliefs accordingly unless and until the dispute is resolved?
If this is the case, I prefer to do my own thinking, rather than
be lulled into a false sense of (ahem) security by believing that
"real names" attached to posts will put and end to this.
A few simple rules of thumb when dealing with claims:
1) if you don't know and trust the reputation of the claimant,
take such claims with a large grain of salt. This holds true
for people posting using "real names" as well as nyms.
2) if you do know and trust the reputation of the claimant,
it's up to you to decide whether to trust the claim as it stands,
or to verify the claim to your own satisfaction. People who
make decisions based on the former, voluntarily sidestepping
the latter, should hold themselves, not the original claimant,
to blame.
If these rules aren't sufficient when dealing with vendors, "real
names", and nyms, one wonders whether there has been some significant
out-of-band noise generated by vendors over ceratin posts? And if
so, could it be the anti-vendor list stance, and not the (until
recently) nym-friendly list stance, that's at fault here?
-- Mark C. Langston Sr. Unix SysAdmin mark@bitshift.org mark@seti.org Systems & Network Admin SETI Institute http://bitshift.org http://www.seti.org --------------------------------------------------------------------------- The Lightning Console aggregates IDS events, correlates them with vulnerability info, reduces false positives with the click of a button, anddistributes this information to hundreds of users. Visit Tenable Network Security at http://www.tenablesecurity.com to learn more. ----------------------------------------------------------------------------
This archive was generated by hypermail 2.1.7 : Sat Apr 12 2008 - 10:53:35 EDT