First part: name one high assurance system Google has ever produced or a low assurance system that top tier hackers gave up on? Did their mobile OS have a strong TCB with POLA on the apps and trusted path? Did their web services use native code (minimal attack surface) with checks manually or automatically built in to stop most attacks? Did they perform a covert channel analysis on their cryptographic stuff? Do they know what those are unlike many INFOSEC types I meet? Has anything they designed used an architecture that made leaks or code injection nearly impossible? If not, then my statement stands until Google demonstrates the ability to make a secure product or one that approximates that. They haven't caught up to Daniel Bernsteins' Qmail claims much less top-tier work like KeyKOS [1] or Burroughs [2]. Ancient, top tier work...
Re third parties. There are numerous academic teams doing hardware or compiler work on making Linux-based systems immune to code injection or at least isolated. OK Labs did OKL4 with user-mode Android for isolation. Samsung leveraged INTERGITY microvisor in Knox. Perseus Security Framework did something similar with a Linux personality, modified by Sirrix or SYSGO I believe for mobile. Control-pointer integrity does this on hardware supporting segments (x86). DIFT catches when incoming data screws with pointers and such, also ported to Linux. Automated diversification and keyed hardware SOC's to make Linux probabilistically secure. Several methods ported to Linux to stops leaks or injection with crypto tricks. Many things Google could've used for mobile and non-mobile. NSA did SEAndroid. Then there's Tor, modders, and Android developers tools/tips to lock down Android and turn off Google's leaks. About everyone but Google did great work in securing Android.
To test you on your own claims, would you trust a vanilla Android installation's security out of the box or make some modifications first? I'd mod it or assume I'm game for whoever.
re unqualified in strong INFOSEC
Everything you mention they, like IT in general, built on foundations of quicksand: low assurance hardware, firmware, and software that has regularly been defeated by skilled hackers. So, sure they pushed some good security technologies that stop low to mid-grade hackers or solve pieces of the puzzle (see my use of "exceptions"). Yet, Google themselves and their Android users were hacked with quite vanilla techniques due to their system and software architecture. There are systems in EAL6/7 and under SPOCK program that NSA pentesters couldn't breach despite having 2+ years to try. Matasano said something similar about Secure64's SourceT OS, too. The things they have in common is bottom-up, end-to-end, medium-to-highly assured (EAL6+) lifecycle. That's strong requirements, design, implementation, analysis, testing, build, configuration, and independent verification of that. Google hasn't done (censored) in this area despite having the brains to do so. Matter of fact, their smartest work IIRC was Native Client and it was smashed because they intentionally weakened the security model for performance reasons.
Almost all their stuff has been knocked down by serious hackers or subversions. It's why they needed the bug bounty. Smart idea if you're pushing low to mid grade throughout your whole stack. Didn't stop the Chinese and NSA from smashing them. They didn't even need esoteric techniques. The definition of high assurance security is the level of rigorous security engineering needed to resist well-funded, sophisticated threats with time on their hands. They never came close, so why do you trust them to do it now without proof? Trust, but verify.
Re third parties. There are numerous academic teams doing hardware or compiler work on making Linux-based systems immune to code injection or at least isolated. OK Labs did OKL4 with user-mode Android for isolation. Samsung leveraged INTERGITY microvisor in Knox. Perseus Security Framework did something similar with a Linux personality, modified by Sirrix or SYSGO I believe for mobile. Control-pointer integrity does this on hardware supporting segments (x86). DIFT catches when incoming data screws with pointers and such, also ported to Linux. Automated diversification and keyed hardware SOC's to make Linux probabilistically secure. Several methods ported to Linux to stops leaks or injection with crypto tricks. Many things Google could've used for mobile and non-mobile. NSA did SEAndroid. Then there's Tor, modders, and Android developers tools/tips to lock down Android and turn off Google's leaks. About everyone but Google did great work in securing Android.
To test you on your own claims, would you trust a vanilla Android installation's security out of the box or make some modifications first? I'd mod it or assume I'm game for whoever.
re unqualified in strong INFOSEC
Everything you mention they, like IT in general, built on foundations of quicksand: low assurance hardware, firmware, and software that has regularly been defeated by skilled hackers. So, sure they pushed some good security technologies that stop low to mid-grade hackers or solve pieces of the puzzle (see my use of "exceptions"). Yet, Google themselves and their Android users were hacked with quite vanilla techniques due to their system and software architecture. There are systems in EAL6/7 and under SPOCK program that NSA pentesters couldn't breach despite having 2+ years to try. Matasano said something similar about Secure64's SourceT OS, too. The things they have in common is bottom-up, end-to-end, medium-to-highly assured (EAL6+) lifecycle. That's strong requirements, design, implementation, analysis, testing, build, configuration, and independent verification of that. Google hasn't done (censored) in this area despite having the brains to do so. Matter of fact, their smartest work IIRC was Native Client and it was smashed because they intentionally weakened the security model for performance reasons.
Almost all their stuff has been knocked down by serious hackers or subversions. It's why they needed the bug bounty. Smart idea if you're pushing low to mid grade throughout your whole stack. Didn't stop the Chinese and NSA from smashing them. They didn't even need esoteric techniques. The definition of high assurance security is the level of rigorous security engineering needed to resist well-funded, sophisticated threats with time on their hands. They never came close, so why do you trust them to do it now without proof? Trust, but verify.
[1] http://www.cis.upenn.edu/~KeyKOS/
[2] http://www.smecc.org/The%20Architecture%20%20of%20the%20Burr...