"more secure" 3rd-party file sharing?

[Bill McGonigle]

On Aug 23, 2006, at 08:07, Ben Scott wrote:

>  I know that fixing wetware makes the Microsoft patch process look
> easy, but ultimately, it is what is needed.  No matter what you do,
> you can't have a secure system with insecure people.  This is
> inescapable fact.

you also can't have fool-proof people.  I wonder how the TLA's handle 
this.

>> ... forcing all users to use PGP or S/MIME ...
> [forcing users to use web page thingy]
>> ... blocking outbound 25, 465, 587 at the firewall and
>> stripping attachments at the MTA ...
>
>  You think you can get away with the later when you couldn't get away
> with the former?

Yeah, I can't control the recipients who would also need to run PGP or 
S/MIME in that model.

> ... one layer of auditability ...
>
>  Your mail server cannot keep logs?

yeah but not of who read the message where and when.

>> ... links can be expired ...
>
>  True, but so what?

you can limit the exposure to a single download, for instance.  It 
doesn't stop intentional forwarding but it reduces unintentional spread 
(compromised machines, nosy mail admins, etc.)

>  The only real advantage I can think of is that if a luser realizes
> they've sent the file to the wrong person before the recipient grabs
> the file, the luser would able to cancel the transfer.  I suppose
> that's something, but I wonder how often it would really get used.

Good thought - I hadn't considered that.

>  You could accomplish the same thing by enforcing a mandatory
> quarantine on outbound email attachments.  Maybe have the quarantine
> have some minimum time before it can be released by the original
> sender.  Maybe have it auto release after some amount of time.  Maybe
> allow others to release files (so two people have to fsck up before
> the disclosure happens).

Also good ideas.

>> ... SSL can be enforced ...
>
>  So can PGP or S/MIME.  (Yes, I saw your report of their objection.
> You presumably saw my objections to their objection.  :)  )

right, again only on the sending side.  How I wish everybody had S/MIME 
certs stored on smartcards. :)

-----
Bill McGonigle, Owner           Work: 603.448.4440
BFC Computing, LLC              Home: 603.448.1668
bill at bfccomputing.com           Cell: 603.252.2606
http://www.bfccomputing.com/    Page: 603.442.1833
Blog: http://blog.bfccomputing.com/
VCard: http://bfccomputing.com/vcard/bill.vcf