WHEN NOT TO USE CRC

|  Lately increasingly weird applications of CRCs have popped up, written by
|  people who don't understand CRCs and their limitations.
|  The CRC calculated from a block of data is NOT unique; it is highly probable
|  that a different block of data gives the same CRC value.
|  Many people respond with "yes, but do look so unique".
|  They may well look unique to us, but if you need a unique fingerprint to
|  compare two blocks of data, CRC is NOT the right method.
|  CRCs can identify certain kinds of bit-errors in a limited length data block,
|  not distinguish two or more completely different sets of data!

While I will certainly accept that CRC's do not provide data
security against tampering (it's easy to tamper with the data
and update the CRC to match), and will accept that a 16-bit
CRC has a 1/65,536 chance of declaring things identical when
they are not, in what way are CRC's worse than other hash alg-
orithms in cases where deliberate attacks are not an issue?
If one selects two data blocks from a typical file and computes
an N-bit CRC on both of them, is the probability significantly
higher than 1/2^N that the CRC's will match?

Note that if the systems you mentioned did a 16-bit CRC on the
newsgroup names or a 32-bit CRC on messages, collisions would
not be surprising even given pure chance.  Is a CRC somehow
worse than other methods?