[liberationtech] was: Forbes recommends tools for journalist; is now: depressing realities

Wed Dec 19 10:12:36 PST 2012

Danny O'Brien:
> On Wed, Dec 19, 2012 at 05:26:05AM +0000, Jacob Appelbaum wrote:
>> Hi,
>>
>> frank at journalistsecurity.net:
>>> But if
>>>> you're getting information security advice from a Forbes blog, that
>>>> will be the least of your worries.
>>>
>>> Where would you suggest we get information security advice from?
>>
>> This is an interesting question and I admit, I feel like it leaves a bad
>> ring in my ears...
>>
>> What kind of security advice? Who is following the advice? Does their
>> context change while they follow this advice? Do they have resources of
>> a user without more than a casual interest or are they well funded and
>> dedicated? What are their requirements? What are their temporal
>> tolerances? Do they understand safety plan or threat model without
>> further explanation? What are the stakes for failure?
>>
>> The answer to each of those questions would shift my answers to
>> subsequent questions around, I guess.
>>
> 
> Just to add some notes to Jake's excellent points to broaden the
> discussion. I hope I'm not thread-jacking, but it's Jake's comments
> unlocked a lot of points that I've been thinking about recently.

I'm glad to hear it. :)

> 
> Protecting Sources -- changing the relationship between reporter and source
> 
> One social act that journalists can adopt which has nothing to do with
> technology, but everything to do with how technology has changed both
> the threats and the opportunities of journalism, is to consider what
> *has* to be known about a source. Traditionally, the role between a
> source and a journalist has been that there's an inner sanctum of shared
> information, and then a set of carefuly managed publically released
> data.
> 

There is also a potential notion about the relationship itself being
part of that inner sanctum. That is a rather unrealistic expectation
without serious care.

> For certain beats, there's all kinds of problems with this model at this
> point. One is that technically and politically, it's getting harder to
> protect the data in the inner sanctum, even within supposedly stable
> open societies. Without exaggeration, we've accidentally built a
> data-collection system that the Stasi would marvelled at, and then put
> all the pressure against its misuse on statutory protections that have
> little oversight, poor incentives and almost no track record of punitive
> action.
> 

To make matters worse, we've created secret law, secret interpretation
and have essentially zero accountability, except to bust up the people
talking about it so that the public may learn about it. John Kiriakou,
Bill Binney, Thomas Drake and Jesselyn Radack come to mind here.

> Second, the management of the released information in order to protect
> an identity is now practically a full-time security job in itself.
> Forget protecting data that source and journalist agree is confidential;
> even the information that has been agreed to be made public can be
> compromising in ways that neither party could anticipate. This isn't a
> question of ignorance, this is a question of how skillful we can now
> collectively pool open source[1] info to deduce hidden data.

I think it is more than one thing - so in some cases, it is a matter of
simply ignoring the facts; try talking to people about NSA Warrantless
wiretaping program and the data (which by the way, I'm confident has
been used in the WikiLeaks investigation) produced by it of US citizens
on US soil. Eyes will glaze over and people will simply refuse to
discuss it. Quite depressing. In some cases, I agree that even if we
know that is/has/will/etc happen - some people don't really understand
the magnitude of the surveillance state.

> It's a
> precept of the security professionals I know that you simply can't
> de-anonymise mass databases of information; what's unknown is how little
> you can add to the wealth of already public information before a single
> identity is uncovered. 

I think you need to come to PETS and the CCC Congress more often Danny! :)

> In that sense, I'd welcome this Forbes piece,
> because it's the first time that I've seen wide public discussion of
> this problem -- that this journalist revealed information about their
> source through what both agreed should be made public. I'm pretty sure
> McAfee didn't even realise that this was a threat, let alone the editors
> and writers at Vice.

I'm not sure that I agree that it is the first time that this has
happened. I think that it is also a stretch to say that Vice was totally
clueless. WikiLeaks discussed these kinds of document issues long long
ago - see some of the early CCC talks. Perhaps that doesn't count as
wide? I'd say that all of the hubub about redacted PDFs in the last ten
years is perhaps more important and has received wider attention.

> 
> My point here is that among all of these threats, there's also
> opportunity. Some of the Net-savvier journalists I know now take a
> minimal-knowledge approach to sources; you don't need to know who the
> source is in order to verify the information you've been provided. This
> is a situation that is I think historically unusual, but is increasingly
> common. You work with the data itself to confirm its veracity. You don't
> need to know whether quarter of a million diplomatic cables were leaked
> by a particular security analyst, because you can externally verify the
> accuracy of the data.

Indeed. Scientific Journalism.

> 
> There are a lot of challenges to this approach, but there advantages
> too. It apparently increases the risk of being fed false flag info: but
> it also prevents accepting false information through simply believing
> authorities. It decreases the value of personal contacts in journalism,
> but it increases the value of data analysis. But most importantly, it
> helps both of the major problems in journalist-source protection. It
> eliminates the requirement to preserve the inner sanctum, and aligns the
> incentives of the journalist with the source to test and validate the
> safety of revealing data to the public.
> 

I think that it changes the relationship to the so-called authorities;
now they're perhaps just an anonymous person, where previously, they
were a specific person. Or they're an unknown person and a special
person is quoted as interpreting what it means. The latter is quite
common and historically quite common, I think.

> [1] in the old fashioned sense of open source intelligence
> [2] speaking as someone who was asked by McAfee about how cellphones
> triangulate location (I didn't answer) -- even if you have your name on
> a security product doesn't mean you're an expert in all security.
> 

"Very carefully Mr. McAfee, very carefully."

> Revealing our methods
> 
> I'm really really happy that Jake has talked a little about his own
> procedures, because we're really bad at this as a community. There are a
> couple of reasons for this, I think. The first is that despite all of
> our talk about the dangers of security through obscurity, we're all
> scared that revealing public information about our setup exposes us to
> increased risk. Second, we're scared of looking stupid, or being exposed
> to condemnation. 
> 

I'm not sure that I agree strongly with the first part - when someone
suggests that they use Tails, that is pretty specific! The second is
certainly true - and often - reasonable! Lots of people make really bad
choices and they hardly understand why they made those choices.
Certainly from a technology standpoint but also from a social standpoint.

> I think both of these concerns are valid. If I told you that I used
> FreeBSD 7.4 on my server, say, and that I'm a big fan of
> libpurple-driven OTR clients, it's possibly made it somewhat more
> convenient to find out a way of attacking me, even though there's at
> least a couple of ways that I'm emitting those facts almost constantly.
>

Sure, I generally agree on all counts:

  user-agent: Mutt/1.5.21 (2010-09-15)

> Second, if I *did* tell everyone I use libpurple, or that I have Skype
> on my machine, I'd be extremely vulnerable to people pointing out that
> libpurple is not exploit-free and that Skype is used as a vulnerabilty
> distribution vector. 
> 

That I think is exactly the right discussion to have - specifically
because there is a reason to use libpurple (ahem, pidgin-otr) and a
reason to use Skype (ahem, fuck, what was it again?).

> I don't know what to do about this. As a community, we jump on people
> who publically reveal less-than-perfect security practices. But we've
> all -- even if it is in retrospect -- realised risky things we've done
> in the past. We can't learn from our mistakes, and worse, others can't
> learn from our mistakes, unless we admit to them. We can't berate coders
> for not exposing their programs to security audits, unless we have a
> better way of sharing the practical knowledge we ourselves use every
> day, and we're not going to do that if we just spend our time pretending
> we anticipated the latest zeroday years before it actually came about.
> --

I'm not entirely sure but I think one answer is not to assume things
secure by default. Another is probably to understand that things written
in C are likely to have lots of specific memory corruption issues -
regardless of *which* codebase is in use. Lots of the zeroday in use
today is really lame - not just buffer overflows that are known to exist
or are patched but not shipping (ahem, pidgin on Windows) - rather,
simply not caring about metadata, location privacy, or stuff said over
phones, or sent over HTTP...

All the best,
Jake
--
Unsubscribe, change to digest, or change password at: https://mailman.stanford.edu/mailman/listinfo/liberationtech

----- End forwarded message -----
-- 
Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org
______________________________________________________________
ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org
8B29F6BE: 099D 78BA 2FD3 B014 B08A  7779 75B0 2443 8B29 F6BE