From owner-freebsd-security@FreeBSD.ORG Sun Jul 27 03:48:04 2008 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ACCD3106567D for ; Sun, 27 Jul 2008 03:48:04 +0000 (UTC) (envelope-from chris@noncombatant.org) Received: from strawberry.noncombatant.org (strawberry.noncombatant.org [64.142.6.126]) by mx1.freebsd.org (Postfix) with ESMTP id 8663C8FC0A for ; Sun, 27 Jul 2008 03:48:04 +0000 (UTC) (envelope-from chris@noncombatant.org) Received: from [10.0.0.102] (unknown [64.142.6.126]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by strawberry.noncombatant.org (Postfix) with ESMTPSA id 3B67B866B94; Sat, 26 Jul 2008 20:48:04 -0700 (PDT) Message-Id: <2E998E52-257B-47BF-917F-4FB41E9D5854@noncombatant.org> From: Chris Palmer To: Matthew Dillon , Liste FreeBSD-security In-Reply-To: <200807242320.m6ONKPgW007279@apollo.backplane.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v926) Date: Sat, 26 Jul 2008 20:48:03 -0700 References: <60254.1216921273@critter.freebsd.dk> <4888C882.30707@elischer.org> <200807242320.m6ONKPgW007279@apollo.backplane.com> X-Mailer: Apple Mail (2.926) Cc: Subject: Re: A new kind of security needed X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Jul 2008 03:48:04 -0000 On Jul 24, 2008, at 4:20 PM, Matthew Dillon wrote: > I think the best way to approach the problem is to work out the > desired > userland API first... find the easiest and most convenient way to > wrap > an application, what kind of features are desired, etc, and then > implement it. I think Szilveszter Adam was right to point out that any such system needs to work with the user, and support what the user needs in a way that fits well with they interact with an application. Rather than being the easiest and most convenient (for the developer), the API should be the simplest means to provide what the user needs. That may have been what you meant when you said "what kinds of features are desired", though. There's a great book that covers a wide range of security and usability topics called *Security and Usability: Designing Secure Systems That People Can Use*, by Cranor and Garfinkel. I highly recommend it. http://books.google.com/books?id=wDVhy9EyEAEC&dq=lorrie+faith+cranor+simson+garfinkel+usable+security&pg=PP1&ots=BOKHuIHr2u&sig=e-DoE4ap0ldkxffFqUs8LaROmYc&hl=en&sa=X&oi=book_result&resnum=1&ct=result