Search Mailing List Archives


Limit search to: Subject & Body Subject Author
Sort by: Reverse Sort
Limit to: All This Week Last Week This Month Last Month
Select Date Range     through    

[liberationtech] Deconstructing the security risks narrative of Haystack

Collin Anderson collin at averysmallbird.com
Fri Sep 17 08:23:42 PDT 2010


This histrionics over "bullets in the head" from disclosure is pretty
overplayed and ignores the capacity of the Iranian government. If Evgeny was
able to get a copy, then it seems equally probable that the IRG or a
disreputable infosec group could have. And, while I have a childlike
admiration for Mr. Appelbaulm, if he was able to find fatal flaws in a day,
so too could some Sharif University student.

Inevitably there would have been flaws, and its absurd to think that the
other side wasn't interested in finding them out.

On Fri, Sep 17, 2010 at 8:13 AM, Alec Muffett <alec.muffett at gmail.com>wrote:

>
> On 17 Sep 2010, at 09:10, Mehdi Yahyanejad wrote:
> > On Sep 17, 2010, at 12:26 AM, Jacob Appelbaum wrote:
> >
> >> To be fair - I said that our analysis took six hours - the issues that
> >> are the most horrible were spotted in less than a minute. One minute.
> >
> > Thanks for confirming my observation. You knew that these risks can be
> > discovered in less an a minute. You also believed that the risk puts
> > "bullet to their heads", and you still went public with it? Why?
>
>
>
>
> Let's be blunt:
>
> * It is better sooner than later to expose bad software, because
>  without exposure even more people will adopt software that
>  could put them at risk.
>
> * I am not a big fan of "the needs of the many outweigh the needs of
>  the few", but practically this is how harm-minimisation works in the
>  world of software.
>
> * The notion that adoption of flawed software can be mitigated or
>  corrected without the light of publicity is regrettably false;
>  empirically it has been proven again and again that some form of
>  full-disclosure is the best way to raise public awareness of
>  software security flaws.
>
> * It is especially hard to to prevent adoption of flawed software in
>  the face of hagiographic public-relations stories.
>
> * Risking N peoples' heads with regime-fired bullets is better than
>  N*100 peoples' heads; blame those who fire the guns first and
>  foremost, and secondarily those who by stupidity or design put
>  dissidents in harm's way by virtue of tagging them in some manner.
>
> * But don't blame the people who explain to potential victims the
>  danger of being [thusly tagged] through use of [such software]
>
> There is a lot of crap circulating about Haystack; as someone who
> followed the project for about a year but with a background in hard
> network security, Haystack rang dozens of snake-oil alarm bells[1] but
> countered with such elegant, fluffy media coverage that even
> today I can't decide whether it was by intent of the organisers, or
> by shared groupthink of the media, that it rose to such prominence.
>
> But I will be glad if it's dead.  There is plenty of room for
> alternatives, and if Kerckhoffs' principle becomes more widely
> understood as a result, I shall be doubly so.
>
>        -a
>
> [1] http://www.interhack.net/people/cmcurtin/snake-oil-faq.html
>
>
>
> _______________________________________________
> liberationtech mailing list
> liberationtech at lists.stanford.edu
>
> Should you need to change your subscription options, please go to:
>
> https://mailman.stanford.edu/mailman/listinfo/liberationtech
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.stanford.edu/pipermail/liberationtech/attachments/20100917/a2c93712/attachment.html>


More information about the liberationtech mailing list