
Ask a hacker: Top four anti-surveillance apps - nikai
http://www.zdnet.com/ask-a-hacker-top-four-anti-surveillance-apps-7000016566/
======
einhverfr
I think the best apps are yet to be written. I recently wrote a blog post
([http://ledgersmbdev.blogspot.com/2013/06/tangent-design-
thou...](http://ledgersmbdev.blogspot.com/2013/06/tangent-design-thougths-
about-next-gen.html)) outlining ways I thought the SSL PKI could be tweaked to
make it quite resistant to this sort of eavesdropping.

It is still on the HN new feed, if folks want to discuss technical details,
but the reason I want to mention it here too is that key management is very
hard in a case of resisting surveillance. The current PKI ideas place too much
trust in third party certificate authorities (meaning the government can
easily pull off man in the middle attacks with the help of network providers
if they want, even without your keys), and because each negotiation occurs
without context of past ones, there is no way to detect such behavior other
than "the CA said watch out" or "this certificate isn't even plausible." Of
course you can solve these by enforcing that everyone on your network uses th
same local CA that you control but that breaks as soon as you want to talk to
someone outside.

Building a PKI that can resist such efforts is not trivial and it involves
challenging our assumptions. Until we do so however, we will run into all
kinds of problem. I may be being paranoid, but it seems like this is a good
time to be paranoid.

One of the things that SSH gets right is that it takes a diachronic approach
to key validation. We should be building this in everywhere and alerting on
key changes, while providing a way to ensure that keys can be safely and
securely changed without having errors.

~~~
dualogy
> It is still on the HN new feed

Lazy link:
[https://news.ycombinator.com/item?id=5844621](https://news.ycombinator.com/item?id=5844621)

------
IlPeach
I remember the time, about 6 or 7 years ago when I've asked in front of the
whole class to the associate professor of the security course, whether
building a text messages encryption app would have been a good idea as project
for the course. The answer was a smickering "only a drug dealer would be
interested in such a thing".

oh man, that hurt... if I only knew a valid point against the "I've got
nothing to hide" argument as I do now...

~~~
e40
_I 've got nothing to hide_

Got a handy link to that or similar arguments?

~~~
tripzilch
I keep this one bookmarked, for exactly that reason:

 _Why Privacy Matters Even if You Have 'Nothing to Hide'_

[http://chronicle.com/article/Why-Privacy-Matters-Even-
if/127...](http://chronicle.com/article/Why-Privacy-Matters-Even-if/127461)

The problem seems to be, to me it's so obvious that it matters even if you
have "nothing to hide", that whenever someone confronts me with that argument
I'm a bit dumbfounded :)

~~~
jcomis
Your link is broken, but this one works: [http://chronicle.com/article/Why-
Privacy-Matters-Even-if/127...](http://chronicle.com/article/Why-Privacy-
Matters-Even-if/127461&#x2F);

~~~
tripzilch
Fixed mine. Yours is broken in the same way :) Some weird escaping/encoding
quirk going on there that seems to be caused by the trailing slash.

------
AJ007
Read these "Bugs, Caveats, Side Notes" published on the Onion Browser app's
web site:

Major iOS SDK Limitation: Websites using HTML5 <video> tags will leak
<video>-related DNS queries and data transfer outside of Tor. This includes
YouTube, Vimeo, and any website using iOS-compatible HTML5 video. This is a
behavior of the embedded QuickTime player and there is currently no known
workaround. (h/t to josyw.)

iOS SDK Limitation: Javascript cannot be disabled in the `UIWebView`, so
script-based detection may identify your device even if User-Agent Spoofing is
enabled. iOS SDK Limitation: Related to above, the HTML5 Geolocation API
cannot be disabled. The browser will ask you for permission to access your
location if a website asks for it via the HTML5 Geolocation API. If you allow
this, then said website will (obviously) know your actual current location.

That doesn't sound remotely safe to me.

------
klibertp
I would appreciate if someone went and fixed the title to have the word
"mobile" in it. I was expecting something very different than I got :)

~~~
gasull
For the desktop: Tor and Bitmessage.

------
a3_nm
Sadly, TextSecure and RedPhone are distributed on the Google Play platform,
so, if you don't want to tie a Google account to your phone or use Android
without the proprietary Google applications, you're out of luck. (They are not
included in the free and open source f-droid repository due to disagreements
with the author.)

~~~
moxie
We don't distribute our apps on f-droid because we feel it's insecure, and
because it doesn't provide the features we need to develop stable and secure
software.

However, we are willing to distribute our apps outside of the Play Store, but
we need the following things first:

* A built in crash reporting solution with a web interface that allows us to visualize crashes and sort by app version, device type, etc. This is essential for producing stable software.

* A built in statistics gathering solution with a web interface that allows us to visualize aggregate numbers on device type, android version, and carriers for our users. This has been crucial in shaping support and development direction.

* A built in auto-update solution. Fully automatic upgrades won't be possible outside of Play Store, but we at least need something that will annoy the hell out of users until they upgrade. This is necessary for ensuring that new security features and bug fixes can be propagated quickly.

* A build system that allows us to easily turn these features on and off for Play and non-Play builds. Gradle should make this easier.

If you're interested in seeing Open Whisper Systems apps distributed outside
of the Play Store, we'd welcome your contributions.

~~~
ge0rg
Speaking as a developer who's app is both on Google Play and on f-droid, I
somehow share your feeling about f-droid being "insecure"(x), but consider all
of the other points very thin.

Crash reports and statistics are great, except if you explicitly want to NOT
spy on your users.

Auto-updates are ok, but forced auto-updates take the user's autonomy away,
and are only one step short of forced remote uninstalls (which are already
documented with Google Play, so far only for malware).

A proper build system is great indeed, but has nothing to do with the
distribution medium.

(x) f-droid security: by having f-droid build all the apps from source by
default, and signing them with their own keys, two problems appear:

a) you can not switch easily between f-droid builds and maintainer builds

b) you as the user need to trust both the author and f-droid to not be evil,
instead of just the author.

------
dave1010uk
If you have an Android phone, I'd recommend getting an Open Source ROM (so you
can verify it is secure) and removing as much proprietary software as
possible. I'd also use Firefox as Chrome for Android isn't Open Source (even
though Chromium, Blink, etc are).

~~~
Spearchucker
This suggestion comes up a lot, and yet isn't practical. I can read and write
code, like many, but haven't the time or inclination (and arguably skill) to
"verify it is secure". I can however watch what an app sends over the wire,
which applies as much to proprietary as it does to open source software.

How do you go about verifying an arbitrary app is secure?

~~~
drcube
You can trust that there are a lot more developer eyes on open source software
than proprietary software. You personally may not be able to verify every
piece of software you have, but if you run free/open software, you know it's
theoretically possible to discover vulnerabilities, and that you'll find out
eventually if those security holes are found. In the worst case, you can hire
a security professional to personally audit a program that is particularly
important to you or your business.

You have no such options with closed software.

~~~
Spearchucker
I realise that I'm risking being contrary, but my question is serious.

How would I know that an app has had lots of developer eyes on it or not? It's
crazy difficult to uncover the latest known security posture of open source
software.

Finding out _eventually_ is the exact same risk I take when I use proprietary
software. It requires my trust. And it's theoretically just as possible to
discover vulnerabilities in closed-source software (Windows, for example).

------
gasull
For the desktop:

\- Tor

\- Bitmessage

Bitmessage is specially interesting because it's not only encrypted and
private, it actually solves the problem of spam and offers 3 kinds of
messaging under the same interface: email-like, broadcast messages ala Twitter
and chan boards.

------
dapole
I think the real question should be is there possibly a back door on your
mobile os of choice, because it won't matter what app you use if your os is
already capable of capturing that data system wide.

------
jiggy2011
No iOS suggestions?

~~~
casca
If you're jailbroken (which you probably should consider if privacy is a
concern), FirewallIP is the reason I still haven't switched to Android:
[http://yllier.webs.com/firewall.html](http://yllier.webs.com/firewall.html)

~~~
BryanB55
Can you expand on why one should jailbreak? Any other jailbroken app
suggestions? I was under the impression that jailbreaking also opened you up
to be hacked and made the phone less secure.

------
buro9
[https://silentcircle.com](https://silentcircle.com) should have a mention
too.

~~~
howeyc
Claims that keys are stored locally and not sent to their network.
Applications not open source, no way for anybody anywhere to verify such
claims.

These are for paranoids, paranoids may not be able to read the source code and
verify such things, but the fact the at least someone can certainly helps.

~~~
JshWright
[https://github.com/SilentCircle](https://github.com/SilentCircle)

