> If your app is closed-source then they have no way of verifying you're not downloading all their contacts to their servers.
That's a common fallacy. Even if it is open source someone could still be doing that. In order to be secure you would have to:
A) Download the source yourself
B) Inspect the source
C) Compile the source
Just because you have the source doesn't mean what you get from the Play Store/Amazon App store is 1:1 identical or even similar.
There is secret option D, have someone you trust do A through C and then give you the hash of the resulting compiled file. But two programs compiled on two machines often give different results due to library versions, compiler versions, environmental settings, and so on.
I'm an F-Droid developer, and we do in fact do secret option D.
There is a small but passionate group of people who are very focused on deterministic builds in Android working with us as well [0]. The end goal is to be able to install fdroidserver, then run:
fdroid verify
And it will do all of this for you (download source, compile source, verify binary against another binary).
Of course, option B) is always a problem, but I guess the best solution short of paying to audit every single open source app is to fall back to the many eyes theory and hope it holds us in good stead.
EDIT: For those interested, one of the reasons we are interested in deterministic builds is so that we can verify that our build of the source corresponds to the upstream build. If that is the case, then we will be confident distributing the upstream binary (i.e. signed by the upstream developer). It is not possible to install a .apk from upstream, and then update it with a version signed by F-Droid - for very good and legitimate reasons. Distributing builds signed by upstream alleviates this problem.
> Unless you build you computer yourself from silicon
And the chip design, and the fab control software, and the tools that make the tools that make the tools.
And descrete components won't help you because transistors are large enough to conceal a mircocontroler emulating a transistor and listening for high-frequency handshake signals.
Relays are probably safe since you can make those yourself out of iron and copper (rods, springs and wire), and conveniently those are the same things you need to build motors!
There is a simple antidote to this problem, as long as you have 1) the source code to the compiler you suspect of being bad, and 2) a second compiler (binary only), written by someone who is not friends with the first one. For instance, if you want to verify that gcc is not evil, you need the gcc source, and MS Visual C++. The basic idea is summarized by Bruce Schnier here:
https://www.schneier.com/blog/archives/2006/01/countering_tr...
Except that it is possible to have lots of someones reliably do A through C with a defined environment and get the exact same output every time they compile it. It's referred to as 'deterministic' builds. Bitcoin and Tor are doing it, for example.
Most of the people that dismiss the security advantages of open source either don't understand them or are trying to sell you some closed source code.
> Most of the people that dismiss the security advantages of open source either don't understand them or are trying to sell you some closed source code.
If you wish to imply the issue is due to my lack of understanding then go right ahead, but at least first explain why what I said is wrong.
A lot of people get their apps from the app stores on Android/iOS/etc. App stores do not provide the raw source and let you compile it last time I checked. So in order for OSS to provide a security advantage over closed source you'd have to sideload your apps after doing the inspection and compilation stages yourself (or having a trusted third party do it).
People throw the "open source so secure" justification around all the time, it is rarely justified. Really you aren't trusting OSS, you're trusting third parties who inspect the code on your behalf (e.g. distro' vendors in the Linux world). In the app world there are no third parties doing the verification step for you, unless you count Apple.
As a general rule, you're trusting both the publisher and 3rd parties that can verify the code makes the build.
An app store can easily provide a binary that can be verified by 3rd parties. Again, it's more about others being able to verify it rather than you being able to build it yourself. And the publisher can provide the source via another means to all interested parties.
App stores aren't the best example since it's mostly closed source games and social apps... think Candy Crush and Facebook. On Android, I run many apps that have the full source code available like Firefox and KeePass. Quite a few public eyes are on apps like Firefox, including on the build system. Most real work and real apps run on desktops and laptops where you don't even have the limitations of the app store to worry about (though you do moreso with each build of Mac OS X).
Saying 'both types of publishers can lie!' is a bit of a false equivalency. On the open source side, you have deterministic builds. And, even without verification, open source is a big advantage over closed source. Others can look through the code to see how it works. Verify that security elements are properly implemented. Submit fixes to such elements. Even see how it works in code to ensure you have more complete testing of the provided binary and have an easier time knowing if something that wasn't in the code was added, since the binary is doing something it shouldn't be based on what the code says. You get no such benefits from closed source code.
And if you can't make head or tails of it, you may conclude "good, it seems encrypted. Unfortunately, that means I cannot tell what they send to their server".
I assume you'd set up a custom CA on your proxy so you can spy on the https traffic. I'd be suspicious if I saw large blogs of data that had been encrypted in the application instead of at the network layer.
But then best practices say you should be doing cert pinning. That will block your CA.
Although for most apps modifying that check to look for another cert is probably not too hard. (But of course if the app is obfuscated and does integrity checks on itself, it can get arbitrarily complicated.)
I visit sites with cert pinning at $EMPLOYER. $EMPLOYER runs a very expensive solution from Blue Coat which includes a MITM CA - no issues intercepting anything here. Amusingly, this meant the proxy itself was vulnerable to Heartblead while the client machines were not.
The only foolproof way to get around this is to hardcode the certificate into the application itself, or at least the intermediate chain. Otherwise, you could have always intercepted the first request and made that the certificate of record.
Anyone could use a network sniffer to see it is uploading something, but you can't tell what since the content may be encrypted. Advanced user may be able to follow the data in a debugger, but that's a lot of work. Very advanced user could instrument the code to perform data flow analysis, see https://www.cs.cmu.edu/~wklieber/papers/soap2014-didfail.pdf
You can relatively easily MITM most applications by uploading a custom root certificate to your phone, and doing SSL termination + re-establishment on a router your phone is using.
The chain of trust doesn't quite stop at compiling the source, in order to be really sure that nothing unintended is going on you have to compile the compiler yourself. At the end of the day you will have to trust some bootstrapping binary compiler unless you put it together yourself in machine language.
Schneier's summary of Wheeler's method says: "This countermeasure will only fail if both [compilers] are infected in exactly the same way. The second compiler can be malicious; it just has to be malicious in some different way: i.e., it can't have the same triggers and payloads of the first. You can greatly increase the odds that the triggers/payloads are not identical by increasing diversity: using a compiler from a different era, on a different platform, without a common heritage, transforming the code, etc."
Good point. Given sufficient paranoia this train of suspicion can be continued even deeper down the rabbit hole: you'd need to inspect the hardware designs and make sure the hardware you've got was actually produced according to the inspected designs.
In technology as elsewhere, it seems life is ultimately based on trust in someone.
Trust is a function of the expected incentives of the trusted.
One way to manage their incentives is by exercising control, but there are other more friendly ways, too. For example, shared goals, community, reputation, financial rewards, reciprocity and ethics standards all provide weaker or stronger reasons to trust others.
In practice you can disassemble Java apps to pseudo source code anyway. I've done it several times to APKs to see what is going on under the covers. Deliberate obfuscation would be immediately suspicious.
I wouldn't say that. Obfuscation isn't that rare in Android. Proguard offers tree shaking and optimization features that are useful in mobile. Some frameworks even require it. AFAIK most set ups for scala on android need proguard because the standard lib is so big.
1. How closely would you have to look to notice something like a weak crypto setup or other “accidental” change less obvious than sending everything to “all-your-bytes.nsa.gov”?
2. How many people other than blackhats actually have the time to do this for every single automatic update?
I tried understanding the APIs several phone apps are using, (the apps are heavily obfuscated), so I decompiled them and hacked my own small deobfuscater where I could rename stuff half-automatically.
Then I went through the code of Google Apps with this, and it’s actually really nice. Although kinda surprising how many Google Apps have hardcoded API keys for their services floating around, for example there is one Google App which has a hardcoded key that allows full unthrottled API access to all of the Google Maps APIs. For free.
I just did this out of fun, as I’m mostly working on Android OpenSource apps, but it was quite easy and interesting to see how Google obfuscates their apps.
Finding predictable things like hard-coded strings is a significantly easier task than proving that none of the code is doing something sneaky. It's much easier to look for something like an access key than confirm that the numeric constants being passed to a crypto function are the correct ones or that it's not leaking something which would make it much easier to crack.
This is encryption and obfuscation on multiple levels, classes passing each others state through hashing and encryption schemes on multiple levels, added bytecode hackery, etc.
Exactly my point – it's unreasonable to expect that higher level of reverse engineering will be done reliably for every release of even a small percentage of the apps being published.
That assumes that Apple fulfills the role of "someone you trust do A through C." Even if you trust Apple's intentions, they don't do a very good job of checking apps for actual damaging stuff (as opposed to irrelevant crap that offends their sensibilities), so it's not helpful.
That's a common fallacy. Even if it is open source someone could still be doing that. In order to be secure you would have to:
A) Download the source yourself B) Inspect the source C) Compile the source
Just because you have the source doesn't mean what you get from the Play Store/Amazon App store is 1:1 identical or even similar.
There is secret option D, have someone you trust do A through C and then give you the hash of the resulting compiled file. But two programs compiled on two machines often give different results due to library versions, compiler versions, environmental settings, and so on.