[Someone1234]

> 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.

[pserwylo]

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.

[0] - https://f-droid.org/wiki/page/Deterministic,_Reproducible_Bu...

[schoen]

Congratulations to the F-Droid project on making this work; it's a great step.

[foo2312]

It may seem a bit silly to add this, but I think it is good to link the reference for those who may not have seen it before:

Even compiling from source, one also has to trust the compiler...

(see, e.g. the classic http://cm.bell-labs.com/who/ken/trust.html, pdf version at https://www.ece.cmu.edu/~ganger/712.fall02/papers/p761-thomp...)

[tormeh]

And then you have to trust the OS. And the machine... Unless you build you computer yourself from silicon, you're not going to get rid of trust.

[a1369209993]

> 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!

You're still probably screwed though.

[Fando]

To make an omelette, first you have to create the universe!

[bch]

Carl Sagans Cookbook series: How to bake an apple pie from scratch -- https://www.youtube.com/watch?v=7s664NsLeFM

[senko]

Further reading: http://en.wikipedia.org/wiki/Trusted_computing_base

[marvy]

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...

[JohnTHaller]

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.

[Someone1234]

> 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.

[JohnTHaller]

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.

[joshfraser]

It's also easy to set up a man-in-the-middle proxy and watch the network traffic an app is sending.

[Someone]

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".

[joshfraser]

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.

[Ded7xSEoPKYNsDd]

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.)

[voltagex_]

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.

[MichaelGG]

Browsers know this is s common downside to corp environments and excuse them if the proxy cert is installed. Arbitrary apps don't have to follow that.

[zak_mc_kracken]

And of course, you can always see if an app is uploading your contact data to their servers, even if that app is closed source.

[avz]

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

[avar]

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.

[stefs]

isn't this only true if the app isn't pinning certificates?

[mrpdaemon]

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.

[M2Ys4U]

Actually, you don't.

You can use two different compilers that compile each other to prove that the compilation won't be tampered with.

See https://www.schneier.com/blog/archives/2006/01/countering_tr...

[kijin]

What if both compilers are backdoored?

It's not like you have a large choice of good compilers for any given language/platform pair.

[schoen]

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."

[avz]

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.

[john61]

> In technology as elsewhere, it seems life is ultimately based on trust in someone.

trust is a function of control. With free software it is distributed trust and control. With proprietary Sw it is centralized trust and control.

Real life proved that centralized control is a bad idea, that is why we invented democracy and free software.

[avz]

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.

[oneeyedpigeon]

Contrariwise, the nefarious app has to trust that I haven't got a whole bunch of purposefully misleading data that I'm feeding it.

[nly]

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.

[stusmall]

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.

[acdha]

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?

[kuschku]

It’s actually really easy.

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.

[acdha]

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.

[kuschku]

We’re not talking about hardcoded strings, lol.

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.

[acdha]

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.

[micampe]

You say obfuscation I say compression.

[marvy]

good one!

[Someone1234]

That's true. But if you leave automatic updates enabled then the whole exercise is nearly pointless.

[mbesto]

Apple's wall garden is looking a little more rosy isn't it?

[mikeash]

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.