clists at perrin.socsci.unc.edu
Sat Apr 17 14:44:39 EDT 2004
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.
Andrew J Perrin - http://www.unc.edu/~aperrin
Assistant Professor of Sociology, U of North Carolina, Chapel Hill
clists at perrin.socsci.unc.edu * andrew_perrin (at) unc.edu
More information about the TriLUG