On Sat, 17 Apr 2004, Mike M wrote: > On Fri, Apr 16, 2004 at 04:44:04PM -0400, Andrew Perrin wrote: > > I think the principle is essentially that of the panopticon (perhaps in > > reverse): > > Panopticon. Cool word: to see without being seen. >
Thanks :) - it's not mine, though - Jeremy Bentham's, I believe (being too lazy to go look it up). > > the possibility that an observer could discover untoward > > behavior without first being observed creates a disincentive for engaging > > in the untoward behavior in the first place. So I trust the package > > maintainer because s/he knows that someone else could discover malicious > > behavior with little cost and no prior observation. > > Even so, a window of opportunity exists for malware to enter the system. > So how do you minimize your exposure? > > I am thinking that there needs to be a live CD with a minimal OS, X, > network support, firewall and traffic logger/analyser, and browser. It > needs to be code reviewed by a public entity. This is then used for > financial transactions on the web. This is the most common highly > sensitive use of the web for most people. > > The next best thing would be a small live CD from a well known source > and hope that the package maintainers and developers are trust worthy. > Trust develops over time from lots of people using it and not having > any problems. This is essentially a problem of trust, it seems to me. Your approach serves to limit the number of people with access to code that requires a high degree of trust. Another option would be to set up some sort of rating system, whereby a user could assign a level of trust to each developer; you track developers through packages, assigning a package the lowest level of trust of any developer who works on it; and then you tell your apt setup to disregard any package with a trust score below X, where X is defined as your level of confidence. It's not technically hard (I would think, but then hey, I'm a social scientist, not a programmer), I would expect the hardest part to be keeping up with all the possible developers who need rating. ap ---------------------------------------------------------------------- Andrew J Perrin - http://www.unc.edu/~aperrin Assistant Professor of Sociology, U of North Carolina, Chapel Hill [EMAIL PROTECTED] * andrew_perrin (at) unc.edu -- TriLUG mailing list : http://www.trilug.org/mailman/listinfo/trilug TriLUG Organizational FAQ : http://trilug.org/faq/ TriLUG Member Services FAQ : http://members.trilug.org/services_faq/ TriLUG PGP Keyring : http://trilug.org/~chrish/trilug.asc
