True necessity of Records? [was: CryptoSeal]

[Lance Cottrell]

It is not an easy problem. It is hard to make reliable and maintainable systems without keeping the kinds of logs and records that law enforcement might later want.
Even if it is your policy to delete records, it is easy for a court to order you to maintain any records that you are producing.
The only safe posture is to architect systems so as to never keep those records. Unfortunately that makes all kinds of other tasks more difficult. Therefor the whole service is more expensive to run, and may be less reliable.
For a dedicated privacy service like Anonymizer, that is a reasonable tradeoff, but it will be a hard sell to phone companies and such.

This is not to say that it would not be a good thing for these companies to have a short data retention window vs. the long period they have now, but it would not provide that much additional protection.

--
Lance Cottrell
loki at obscura.com



On Oct 25, 2013, at 4:25 AM, Ulex Europae <europus at gmail.com> wrote:

> At 11:14 PM 10/24/2013, Peter Gutmann wrote:
> 
>> (This issue isn't unique to telcos, it seems to be near-universal, it's always easier to keep data lying around than to figure out what to delete).
> 
> I've seen that as well.
> 
> The phenomenon would seem to be a hallmark of poor design. The system
> should keep track of what went where and automatically delete it unless
> prevented from doing so. That was certainly the case with the systems
> and data I have personal experience with, poor design leading to
> irresponsible retention of user financial (credit card) data in particular.
> 
> 
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/html
Size: 2765 bytes
Desc: not available
URL: <http://lists.cpunks.org/pipermail/cypherpunks/attachments/20131025/f667d3d9/attachment-0001.txt>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4877 bytes
Desc: not available
URL: <http://lists.cpunks.org/pipermail/cypherpunks/attachments/20131025/f667d3d9/attachment-0001.bin>