[liberationtech] OkayFreedom

Sat Oct 27 07:41:31 PDT 2012

It would serve us all well to remember, when discussing such technologies
in the future, to always ask ourselves these standard questions (or these
questions that should be standardized:)

A1. How much trust do I need to invest in the integrity and statements of
*people* in order for this service to be secure?
A2. What initiatives have those people taken to detach the project's
security from their personal effects?
A3. Is the infrastructure centralized? IHow valuable is its compromise to
an antagonist?
A4. Will my privacy be affected by changing tides of geopolitics if I rely
on this service?

These questions can truly act as a time-saving model. That being said, I
also have some technical qualms with OkayFreedom after briefly analyzing it:

B1. OkayFreedom, an anonymity service, harvests information on its users
via Google Analytics.
B2. OkayFreedom software is offered for download via HTTP and not HTTPS. It
is trivial for Iranian authorities to fatally exploit this.
B3. OkayFreedom does not make its source code available for audit by
security experts. This is seriously unscientific and provides no manner for
an empirical justification of privacy promises. This sort of thing makes
questions sch as A1 yield dangerous answers.
B4. OkayFreedom places cookies, or identifying information, inside user's
browsers, which may of use by antagonist computer forensic entities.
B5. OkayFreedom shows advertising to its users; the advertising code is
provided by third parties and may contain its own identifying code. This is
a frequent hole.
B6. OkayFreedom mandatorily asks for my email address and makes it clear
that it will share it with commercial sponsors. This is not anonymous.
B7. OkayFreedom's installation process is unusually pervasive: The
software, a closed-source binary, injects code into all installed web
browsers and installs a network device driver. Coupled with its highly
insecure mode of delivery outlined in B2, this could indeed have disastrous
consequences.

NK

On Sat, Oct 27, 2012 at 5:09 AM, Jacob Appelbaum <jacob at appelbaum.net>wrote:

> Eric S Johnson:
> > Whew. Stirred up a hornet's nest.
> >
> > We all have good experiences to share. I worry, though, that if we spend
> a
> > huge amount of time fighting each other, we'll not be spending that time
> > helping the people who really need it. None of us actually disagree with
> > each other on whether an activist in a cyberdangerous country should be
> > using a government-managed VPN. We all know about MITMing, and FinFisher,
> > and OpenVPN, etc. etc. etc.
>
> I'm not fighting with you. I merely reject your simplistic assertions.
> As an example, I told you about the extreme surveillance in Belarus (if
> I recall correctly) once and until the Swedish news covered it, it
> wasn't a reality for you; merely rumors or something of the like.
>
> eg:
>
> https://www.eff.org/deeplinks/2012/05/swedish-telcom-giant-teliasonera-caught-helping-authoritarian-regimes-spy-its
>
> That is - by default - you assume good faith of all of the players and
> anyone who seems to state anything to the contrary is paranoid. This is
> of course a tactic of either a person who is not empowered, a person who
> is working to sew discord or perhaps merely a person who doesn't know; I
> have always preferred the latter explanation. Generally, I have stayed
> quiet about it but I'm sorry to say that this email thread caught my
> interest in a way that wasn't easy to ignore.
>
> We do have good experiences to share and yet we must realize that there
> are facts about our experiences that we may not understand, we may not
> fully grok and that are part of a bigger picture. As an example - that a
> telephone can be intercepted means that it is *insecure* by *default*
> and if you've been to a place and never seen wiretapping - we must not
> forget that it is not only possible, it is policy!
>
> While you assert that we all know about MITM, FinFisher and OpenVPN - I
> think we know about them in different ways. That is - they are
> considered binary things; when in reality, a MITM isn't always changing
> a certificate. Absence of detection is often used as absence of a need
> for a concern. This is not a reasonable way to threat model at all. I'm
> sure others will chime in here and beat this horse to death. I welcome it.
>
> >
> > The most important points I think worth making is that it's really
> important
> > to a) understand the threat, and b) prioritise the response.
> >
>
> Your statements demonstrate to me that you do not understand the threat
> in a way that you convey to others. Rather, I feel that you openly
> minimize things because you feel that we cannot solve *everything* at
> once. The language used is often something that will disempower a person
> "99.9% of VPN users are principally looking for cybercircumvention" -
> this of course implies that my needs or my concerns don't matter, they
> haven't yet reached critical mass, etc. This is of course a logical
> fallacy and well, as far as I can tell, unsubstantiated in any case.
>
> > There are so many threats that if we try to solve all problems (both
> known
> > and theoretical), most end users simply won't accomplish much (not to
> > mention that our resources are limited). I can't count the number of
> times I
> > find an activist in Ethiopia, Uzbekistan, or Vietnam who's still
> accessing
> > her @yahoo.com e-mail account unencryptedly, even after having been to a
> > cybersecurity seminar one of us taught. Or whose OS hasn't been patched
> > since it was installed two years ago. Or whose entirely-unencrypted hard
> > drive has been taken.
>
>
> That is however not a reason to pretend yahoo is secure or that since
> many users use it, they obviously don't care about security. Rather, we
> should encourage them to use a more secure popular mail provider.
> Furthermore, we should encourage them to install an OS that is Free
> Software, that automatically applies security patches and that comes
> with disk encryption enabled by default.
>
> Or at the very least, we might consider telling these activists that the
> threats are real, the risks for many of them are high and that spending
> a few hours everyday might be helpful. In some cases, I think it is the
> difference between a few hours of education every week and a lifetime in
> jail. Minimizing these security realities is harmful and if we're going
> to teach users anything, we should teach them the processes by which we
> learn decide and evaluate these issues. I'd even advocate teaching about
> the philosophy that allows us to believe we have a personal right to
> protect ourselves. Merely teaching solutions leads to oversimplification
> and judgments by people who don't really ever fully understand the
> context - that is what we're doing right now.
>
> >
> > So we (and those who depend on our help) are hugely benefitted by
> tallying
> > up how much/often we know a particular threat has been used to persecute
> > someone, and then focusing our efforts on solving that threat first ...
> then
> > solving the next-most-dangerous threat ... etc.
>
> This is a pointless *general* metric Eric. We know for example that
> wiretapping is a huge risk and it poses a serious threat to people.
> Probably far more than we fully understand if we include the NSA
> warrantless wiretapping that is still ongoing.
>
> These things are not solved with technology alone, they are solved
> socially as well. However, I see neither of those things happening in
> this discussion because users are being taught about a product which
> ironically hasn't even been meaningfully evaluated!
>
> >       My main point about VPNs was that (in my experience) I know of no
> > situation in which we've learned that it was a government-owned VPN which
> > caused an activist's compromise, but I do know of lots of situations in
> > which the compromise resulted from lack of endpoint security or the
> physical
> > loss of unencrypted media, and some in which data were intercepted
> in-line.
> > So these latter are deserving of more attention on the part of
> cybersecurity
> > trainers.
> >
>
> My core point in response is that your default assumptions are simply
> rotten to the core. We will likely not learn these things and so, we may
> never know that this was the vector. Nor would it even matter if it was
> government-owned - many are government-compromised. Look at the lulzsec
> guys who were turned in by HideMyAssVPN:
>
>   http://blog.hidemyass.com/2011/09/23/lulzsec-fiasco/
>
> That in my view is a perfect example of why it doesn't matter who owns
> it *unless* you *really* trust them! What matters is that the
> architecture *and* the people are stacked against the activists. That is
> what happened in that case and now, some kids are in jail because they
> listened to the same line of argument that you're making now.
>
> But perhaps you'll argue that they're just criminals and should be
> locked up or something?
>
> > As to "99.9% of VPN users are principally looking for
> > cybercircumvention"--nope, no statistical proof. Just lots of real-life
> > experience (which is in no way minimizing the experience of everyone
> else on
> > this list).
> >
>
> Ask a person a question they don't fully understand and you'll get an
> answer that is meaningless.
>
> For example, I invite you to read my latest paper on why VPNs are
> dangerous in this context:
>
>   https://www.usenix.org/conference/foci12/vpwns-virtual-pwned-networks
>
> A perfect example is the discussion surrounding Dihydrogen Monoxide. How
> many people were fooled by the mere *wording* of the discussion?
>
> All the best,
> Jake
> --
> Unsubscribe, change to digest, or change password at:
> https://mailman.stanford.edu/mailman/listinfo/liberationtech
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.stanford.edu/pipermail/liberationtech/attachments/20121027/93c13af3/attachment.html>