[liberationtech] Cryptography super-group creates unbreakable encryption

Q. Parker ghostdancex at gmail.com
Tue Feb 19 15:36:49 PST 2013


On Tue, Feb 19, 2013 at 11:21:11PM +0100, Julian Oliver wrote:
> ..on Mon, Feb 18, 2013 at 08:00:24PM -0800, Adam Fisk wrote:
> > 
> > I think the principle of that is great, but in practice we just can't
> > all review all the code all the time. In practice we often end up
> > trusting open source code that is far worse reviewed than much of the
> > closed source code we trust. I'm not trying to attack open source --
> > I've been writing open source code full time for the past 13 years --
> > it's what I do. But I don't think we should be delusional about it.
> 
> 
> I find this an unproductive black-and-white argument. Proprietary software does
> not grant and encourage its own users even the /possibility/ to fully audit the
> service whereas open source software does. 
> 
> It's a no brainer, quite frankly. 
> 
> We need to simply stop considering proprietary solutions at all (as it's clearly
> ridiculous to have any case of trust built atop it) and make our starting point
> the wide variety of open source software, some of which is poorly engineered and
> some which is not.
> 
> The "what sucks the least" scale must begin with open source, not proprietary
> offerings from for-profit companies with a centralised service.
> 
> Again, it's a no-brainer.
> 

This is a pretty gross oversimplification that ignores a lot of realities about
the nature of trust and how complicated things like large software systems are
assembled.

First, it seems that "trust" in the context of this thread means "do the readers
of this list trust this software" which has come to mean, from my reading, "do 
the members of this list have unfettered access to the source code". That's a
rather narrow view of trust. There are all sorts of reasons a human rights activist
might choose to trust a vendor. After all, for a non-technical user, what's to
recommend the opinion of a volunteer over the opinion of a number of professionals
working at a relatively small firm? The first is wholly dependent on the expertise
and access of the volunteer. The second is wholly dependent on the expertise and
access of the professional. The latter, however, comes with the sense of 
trust that people tend to have for somebody whose livelihood depends upon maintaining
a track record of fulfilling obligations to customers with competence and good faith.
It's not so simple as volunteer is better than vendor.

Second, I think it's hard to defend the claim that end users always know more
about the inner workings of large open source projects than they do closed ones
at private firms. Does everybody who uses Debian observe key-signing parties
among Debian developers? No, they don't. Do I use open firmware? Do I know with
absolute certainty what every piece of hardware in my laptop is doing? No, not
really. We make decisions about which systems we should trust and in what way
based on a complicated series of risk assessments, each based on a lot of factors.
I think the assertion that open source projects are always of higher quality by virtue 
of being open and that the issue is just that simple is hard to defend. For most users, 
the code being open doesn't make it any more possible for them to review it.
They'd still have to trust another reviewer, right?  It's not so simple as open versus 
closed source.

Third, I think responses on the list tend to be excessively hostile toward for-profit firms
that hope to make a living by selling/making software. A good many such firms have contributed
substantially to the Linux kernel and the Debian distribution. There are a lot of competing 
interests at play, as made obvious by the parallel thread about Ubuntu's Dash product search. 
But I'm sure there are a lot of list members who've thoroughly enjoyed the conveniences afforded 
them by the Ubuntu distro, for example, only to break into hysterics over the in-built product 
search (which should be opt-in but is disabled pretty easily) without offering up any 
alternative suggestions for paying Canonical developers. Does it make sense to expect all 
security work to happen with grant money? Do we really want to discourage attempts by small 
firms to make something interesting and useful at a reasonable profit? I don't think I do. And do 
I choose to ignore that people paid by for-profit software companies often contribute to important
open source software projects? No, I'd rather not. It's not so simple as unaffiliated
and corporate.

Should you feel comfortable vouching for software which you've not been able to adequately audit? 
Of course not, but that doesn't mean users can't establish trust for a vendor and its offerings in 
some other fashion. And does it always make sense for a for-profit firm with even the best of 
intentions to open up all of their source? I don't think it always does. I think these and plenty 
of other open questions surrounding how tools for protecting sensitive communications are made and 
used should indicate that this is far from being "black-and-white" or a "no-brainer".

> Cheers,
> 
> -- 
> Julian Oliver
> http://julianoliver.com
> http://criticalengineering.org
> --
> Unsubscribe, change to digest, or change password at: https://mailman.stanford.edu/mailman/listinfo/liberationtech

--
Q.



More information about the liberationtech mailing list